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.
--------------------------------------------------------------------------
