Re: IDS and Bandwidth

["David W. Goodrum" <dgoodrum () nfr com>]

To further comment on reducing data sent by the IDS Sensor to the 
Central server, you might also check to see if additional, 
"non-alerting", functionality is disabled.  For example, NFR's products, 
and many other IDS systems, can "record" lots of information that may 
have nothing to do with an "intrusion".  For example: a record of every 
piece of mail ever sent, a record of every URL request, a record of 
every FTP command, etc.  This information can be a LOT of information 
that you may not necessarily need from an IDS box, and so you may want 
to turn it off.  I once turned on every single piece of extra 
information I could possibly retrieve on a T1 line, and generated over 
250,000 records in a 24 hour time period.  These records were not false 
positives, simply things that "could" be recorded if I chose to enable 
those features.  That's the danger with end users who might turn on 
every single check mark, thinking they're getting better security (or 
better protection), without reading the fine manual first.  :)

Also, you have to look at your architecture.  Let's say you have 100 
sensors all monitoring 100Mbps fully saturated links, and trying to send 
back all the information I've described above back to your "central 
server" which only has a 100Mbps connection.  If you've misconfigured, 
or not tuned the system properly, it is conceivable that the aggregate 
of those 100 IDS sensors is maxing out your pipe back at the "central 
server".  If you turn off additional features that may not be required, 
and if you tune the system properly, you shouldn't have a problem unless 
your implementation is improperly architected.

good luck,

dave

--
David W. Goodrum, CEH
Senior Systems Engineer
(nfr)(security)
http://www.nfr.com

See NFR Security at these upcoming events:

Security Ventures 2005, July 13, New York, NY
HomeSec, July 21, Washington, DC


Michael Boman wrote:

> On 5 Jul 2005 03:46:39 -0000, bhaskar.gupta () tcs com
> <bhaskar.gupta () tcs com> wrote:
>  
>
> > Dear frendz
> >
> > I am working as an IDS operator in my company. Due to big size of the organisation, different IDS nodes are monitoring 
> > different centers through a central master node. Since there are lot of incidents ( including false positives ) 
> > generated across the organsation, there is a complaint from our networking team that IDS is consuming lot of bandwidth 
> > over networking
> >
> > I am really not able to figure out how much IDS can eat up network bandwidth.
> >
> > Please throw some light on this.
> >    
>
> Hi  bhaskar,
>
> While an IDS does not consume any bandwidth in the data acquisition
> mode itself, sending the alerts to a central server does take up some
> bandwidth - and the more data you need to send (alert size and
> frequency), the more bandwidth it consumes.
>
> You can limit this by having the alert collector (central server, as
> you call it) as close as possible to the IDS sensor (by using the
> notion of LAN bandwidth is cheaper then WAN bandwidth). I would also
> trim down as much of the alerts as you can that you really not
> interested in. Not only will it save bandwidth and storage, but the
> IDS will also work faster and better when it needs to care about less.
> However, don't remove too much because then you might miss something
> important.
>
> Depending on how timely you want the attacks on the alert collector
> you may want to investigate into traffic shaping between IDS sensor
> and alert collector, but be aware that less traffic available for
> sending alert data = longer latency before you get the bells and
> whistles activated on the alert console.
>
> Best regards
>  Michael Boman
>
>  


--------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from 
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 
to learn more.
--------------------------------------------------------------------------