[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ISSForum] Proventia Devices (Fiber packet captures)
I'm not sure I understand the issue.
(1) Things like HTTP do indeed look at the response
(2) Packets can often be viewed in the console along with the events
(3) The "SensorStatistics" event diagnoses installation problems far better
than looking at response packets.
(4) The sensor can log all packets to disk.
Remember that ISS puts data into "detail" fields attached to events, and that
in order to see these, you usually have to right-mouse-click on the event and
choose "View Event Details". (That's the way I do it when working with
indvidual events, but there are other ways). When packets are attached to an
event, they are likewise just another event "detail".
The "SensorStatistics" is an event that, when enable, fires every 15 minutes.
It pulls data from the state tables within the protocol-analysis engine. One of
the most interesting event details is "tcp.acknodata", which means that the
sensor saw a tcp ack packet for data that the sensor did NOT see. If the sensor
isn't dropping packets, it means a packet was dropped BEFORE it reached the
sensor. Common conditions for this are overloaded/misconfigured span ports, or
routing tables that will forward packets around the sensor. Another value in
that event tracks separately "half" TCP connections, where we see data in one
way, but not another. This is even more conclusive of a
The sensor has the ability to log ALL packets (not just the ones that trigger
with event. This gets difficult in high load environments, but I've done it up
to around 200-mbps.
I am most interested in the sentance below: "Why can't Network Sensor look for
a simple 404 on a simple web query? Since ISS can't do it". The Network ICE
technology that RealSecure/Proventia is based upon was the first product to do
that; I'd like to know why it isn't working in your evironment.
Chief Scientist, ISS
--- "HACKER, ERIC W" <ERIC_W_HACKER@xxxxxxxxx> wrote:
> It is going to be very hard for me to explain this in a nice way since I am
> so used to ISS not understanding how their product gets used in the field,
> especially in a large enterprise. Log evidence is mostly worthless for much
> of what a packet trace is used for.
> For starters, one will need packet captures outside of the IDS engine to
> determine why false positives or false negatives are occurring. This is even
> more critical in a closed signature sensor.
> When one is installing a sensor, one must test to be sure that the sensor is
> properly hooked up to the network. In a large enterprise, there are many
> times when the IDS engineer is not physically hooking up the device and/or
> configuring the devices that are sending the traffic to the sensor. ISS
> support suggests turning on an HTTP signature and sending an HTTP request.
> This is inadequate. There are many instances where:
> 1) There are firewalls in the way that would block sending an HTTP
> request from a convenient system.
> 2) There is not web server available on the other side for testing
> (especially as we build the network ahead of the servers).
> 3) One must test for bidirectional packet captures, as specifically
> on the 604 and 1204 when using taps to send the traffic. This is especially
> a problem on the 1204F where there is a high opportunity for the person
> connecting the fiber from the tap to plug it in to the sensor wrong.
> 4) One must check to see that a switch span is set up correctly.
> This can involve multiple VLANs. It is simple to start a snoop/tcpdump and
> watch all the VLANs. It will be a pain to send multiple attacks out each
> time for validation and match them up to multiple events in the console. 
> ISS is currently incapable of providing signatures that can determine if an
> attack is successful. ISS Scanner is woefully inadequate for enterprise
> work.  Fusion is two to three years behind the SIM competition and mostly
> disappointing. Why can't Network Sensor look for a simple 404 on a simple
> web query? Since ISS can't do it, there are some people who have scripted
> their own packet capture responses to do it themselves. An analyst can then
> quickly eliminate the failures. Having no multiple packet captures
> eliminates this very effective method to make scale RealSecure to hundreds
> of sensors.
> There are times when one may want to watch all the activity of an attacker,
> not just what is triggering alerts. It would be difficult to quickly
> coordinate with the network team to have someone set up a sniffer to do
> that. Sometimes the sniffer requires the SPAN port that the network sensor
> is using. The sensor should be able to do this.
> If some of these needs sound new and haven't been asked for by customers
> before, perhaps it is do to the fact that network sensors previously could
> do this. It is difficult to imagine that one could build a sensor without
> thinking about capturing packets as a requirement, especially given the
> backgrounds of some of the engineers there.
> Eric Hacker, Enterprise Security Information Architect, FleetBoston
>  Nevermind cluttering up all the 'real' attack data with a bunch of
> events that are only for testing.
>  Try having discussions with a data-center manager that you have to
> deploy this software on a workstation class box and he's just going to have
> to buy a shelf for the rack and waste several rack units. Then try securing
> the OS install.
> > -----Original Message-----
> > From: King, Bob (ISSAtlanta) [mailto:BKing@xxxxxxx]
> > Sent: Wednesday, January 28, 2004 2:01 PM
> > To: HACKER, ERIC W; Reeves, Mike; issforum@xxxxxxxxxxxxxxxx
> > Subject: RE: [ISSForum] Proventia Devices (Fiber packet captures)
> > Actually both the A604 and A1204 support Log Evidence. This feature was
> > added to the higher-end Proventias last year, and it provides for raw
> > packet capture and display of the packet on the SiteProtector Console.
> > You don't have to use any additional software such as tcpdump.
> > It is the packet that triggered the event that gets forwarded to
> > SiteProtector. The only possible drawback is that only one packet is
> > captured. I have had several customers ask for multiple packet capture,
> > and we are researching that implementation, but right now a single packet
> > is captured.
> > So unless I missed something you should be OK. Hopefully this is good
> > news.
> > Bob
> ISSForum mailing list
> TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
ISSForum mailing list
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to https://atla-mm1.iss.net/mailman/listinfo