Re: Snort in a cluster

[Jason <security () brvenik com>]

Williams Jon wrote:

> I'm glad to hear someone else is doing this.  I was at a conference and
> talking with the Sourcefire tech guy, and when I mentioned that we were
> doing this, he looked at me as if I'd just stepped off a spaceship.

Was it a Star Trek conference? :-)
Did you happen to look like one of these?

http://uk.geocities.com/magoos_universe/borg.htm

> Even after I'd explained what we were doing (i.e. better performance of
> any any -> any any rules, stripping out sections of aggregated taps,
> etc.), he still didn't seem to grasp that someone would want to do this.
> <shakes head>

I happen to agree for a number of reasons which may not have been 
considered.

By using this method you effectively blind the process and can only see 
traffic destined for the areas that you can predict an attack might go. 
This should be used only in select cases where it is absolutely required.

New address space and systems are spun up every day, how do you 
effectively split a 10.0.0.0/8 net and balance that traffic reliably 
using a bpf?

How do you account for a local segment that also overlays 192.168 addresses?

How do you handle the 169 address space, most systems will happily talk 
with it on local segments these days and proxyarp can cause it to route 
fine too.

How do you handle things that infect inside and spoof source addresses? 
You will be blind to these completely.

Should any system in a segment decide to utilize the entire local pipe 
for worm propagation or become the subject of a DoS the under powered 
sensor that is designated to handle that traffic is dead, even if more 
bandwidth is available upstream to survive the DoS conditions.

> It does work quite well, though.  I've got three individual boxes that
> are each monitoring 80-90 mbps sustained, the traffic coming from 40 or
> 50 ethernet taps.  Much cheaper than buying one computer for each tap or
> mucking about with multiple interfaces in a single box. 

One box that monitors 500Mbs would be preferred if you ask me, there are 
still issues however.

If traffic crosses multiple taps and arrives out of step with the origin 
traffic you will be duplicating alerts.

Aggregating all of those taps also means that you can be blind in total 
for your IDS infrastructure simply by overloading the output of the 
aggregation device, an aggressive worm infection on 2 machines can 
easily get you there. Provided it is not spoofing source addresses you 
might see it on your filtered devices for a few minutes before 
everything chokes.

While it might work it ultimately comes down to this solution being less 
than desirable in many common cases. I think there are much better ways 
that are reasonably affordable that do not have these limitations.



> Jon
>
> -----Original Message-----
> From: snort-users-admin () lists sourceforge net
> [mailto:snort-users-admin () lists sourceforge net] On Behalf Of Michael
> Stone
> Sent: Friday, July 09, 2004 9:24 AM
> To: snort-users () lists sourceforge net
> Subject: Re: [Snort-users] Snort in a cluster
>
> On Fri, Jul 09, 2004 at 02:01:44PM +0100, you wrote:
>
> > If you need more power for snort than a single CPU can provide, you 
> > probably want to be looking at having multiple sensors and a IDS 
> > load-balancing solution (e.g. Radware or Top Layer).
>
>
> Or you can adjust the pcap filter so snort sees less traffic. I've had
> good success running multiple snorts on one system where each sees part
> of the traffic and together they can keep up with a faster link than a
> single process trying to watch everything.
>
> Mike Stone
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital
> self defense, top technical experts, no vendor pitches, unmatched
> networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=ort-users



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users