Re: Recent anti-NIDS Gartner article

["Srinivasa Rao Addepalli" <srao () intotoinc com>]

You are right that sniffer IDSes don't come in the way of
packets and throughput of traffic is not suffered by IDS.
But, I am not sure whether this is significant advantage in
 small/medium market segments.

Some reasons why I feel Inline IDSes don't require expensive
hardware and more suitable.

One of the biggest problems in IDS world is false positives and
too many alerts. To avoid these false positives, IDSes are 
implementing protocol intelligence. That means, IDSes need to
maintain some sort of state information on per connection basis.
If you take HTTP as an example, this state information involves 
storing URL and in case of TCP connections, data packet buffering
OR pure data buffering, if the packets come out of order (people
refer to this as TCP streaming or TCP reassembly). In case of
IP, packets need to be buffered for IP reassembly. So, lot of state
information need to be maintained at different levels. Assume that
on per HTTP connection, if 500 bytes of state information is maintained,
for 10000 simultaneous connections, you require 5 Mbytes of memory.
And if it coupled with TCP and IP packet buffering, memory required
for IDS goes up substantially.  If there is no memory available for new
packets, the packets get dropped, but if there is any exploit
script in these packets, then tap IDS does not even know and packets
go to the internal machines/servers. If it was the Inline IDS, it has
control over dropping the packets, when resources are not available
and thereby it .at minimum, make sure that they detect all the attacks in the
packets which are being forwarded. Also, Inline IDS when found in
these situation have control on removing unused session and freeup
old packet buffers etc.. An attacker can overwhelm the tap IDS with
irrelevant sessions and then pass the packets to the internal network
without tap IDS detecting them.

In case of IP reassembly, different TCP/IP stacks have different
ways to do reassemble overlapped fragments. In case of tap IDS,
it has to reassembly in all possible ways and pass them many
times through the protocol intelligent modules and this adds up to
the more CPU utilization. In case of Inline IDS, it has control over on reassembling
and fragmenting in unified manner.

In case of 'tap IDS', there is no clear way to know when it can remove
state information. If it removes too early, it might not detect the attacks
in further packets OR generate alert indicating 'protocol anomaly' and
even more dangerous thing is that attacker can take advantage of this
and evade IDS detection. That means, the state information should be
kept longer and means the memory is required not only for active
connections, but also for in-active connections.

Again, I am not ruling out the need for 'tap IDS', but I am only
questioning their relevance in low end market segment.

Thanks for your patience
Srini




Intoto Inc. 
Enabling Security Infrastructure
3160, De La Cruz Blvd #100
Santa Clara, CA 95054
www.intotoinc.com
----- Original Message ----- 
From: "Stephen Samuel" <samuel () bcgreen com>
To: "Srinivasa Rao Addepalli" <srao () intotoinc com>
Cc: <focus-ids () securityfocus com>
Sent: Wednesday, June 18, 2003 2:12 PM
Subject: Re: Recent anti-NIDS Gartner article


> Srinivasa Rao Addepalli wrote:
> > IDSes which sniff or tap of the network, have several disadvantages
> .....
> > -  Need expensive hardware for good performance and detection rate.
> > Due to this, these might not survive in SOHO and SME market segments.
> .....
> > market segment. Today, IDSes can be configured to inform Firewall, but
> > I don't think anybody seriously thinks that this solves all the problems.
> > Having protection capability within the IDS provides more control or
> > accurate protection.
>
> An inline IDS is going to have (almost) all of the requirements
> of a passive one with the *addition* of having to foreward (and
> filter) packets. Unless you cut the detection functionality, I
> can't see how this is going to lessen the hardware requirements.
>
> Also: once you have your IDS inline and blocking packets, it's
> (IMHO) now an IPS -- even if it's still reporting suspicious
> traffic that it's not actingo on (IPS with IDS extensions).
>
> ((
>   Now, of course, within my definition, an IDS reporting
>   aggregiously nasty traffic to a firewall which then drops
>   the offending connection would classify (as a system) as
>   an IPS capability -- but that would apply to the cluster
>   and not to the IDS itself just because it's reports are
>   being responded to in an automated manner.
> ))
>
> One of the nice things about a sniffing-only IDS is that it
> is essentially invisible to the network. Unless you can
> direct a packet directly at the IDS, there should be no
> way for an attacker to notice it there (security by
> obscurity).
>
> -- 
> Stephen Samuel +1(604)876-0426                samuel () bcgreen com
>    http://www.bcgreen.com/~samuel/
>     Powerful committed communication. Transformation touching
>         the jewel within each person and bring it to life.

-------------------------------------------------------------------------------
Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the 
world's premier technical IT security event! 10 tracks, 15 training sessions, 
1,800 delegates from 30 nations including all of the top experts, from CSO's to 
"underground" security specialists.  See for yourself what the buzz is about!  
Early-bird registration ends July 3.  This event will sell out. www.blackhat.com
-------------------------------------------------------------------------------