IDS mailing list archives
Re: IDS and Bandwidth
From: "David W. Goodrum" <dgoodrum () nfr com>
Date: Tue, 05 Jul 2005 19:47:10 -0400
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.
--------------------------------------------------------------------------
Current thread:
- IDS and Bandwidth bhaskar . gupta (Jul 04)
- Re: IDS and Bandwidth Tony Rall (Jul 05)
- Re: IDS and Bandwidth Fergus Brooks (Jul 05)
- Re: IDS and Bandwidth Michael Boman (Jul 05)
- Re: IDS and Bandwidth David W. Goodrum (Jul 05)
- Re: IDS and Bandwidth Mayank Bhatnagar (Jul 05)
- Re: IDS and Bandwidth Mark Teicher (Jul 05)
- <Possible follow-ups>
- RE: IDS and Bandwidth PPowenski (Jul 05)
- RE: IDS and Bandwidth MailTest (Jul 12)
- RE: IDS and Bandwidth THolman (Jul 13)
- RE: IDS and Bandwidth Nathan Davidson (Jul 15)
- RE: IDS and Bandwidth Michael Allgeier (Jul 17)
- Re: IDS and Bandwidth Tony Rall (Jul 05)