[Snort-users] Idea for a Denial of Service against Snort

Jeff Nathan jeff at ...2...
Thu Jul 20 19:20:33 EDT 2000


Sorry for breaking the quoting below.

I would agree that if we're attempting to attack the reporting mechanism
of snort in particular, we pick the rules which generate the most
noise.  Syslog in particular _will_ be uncooperative when asked to deal
with lots of traffic.  Unlike some existing commercial IDS
implementations, snort doesn't seem to suffer the same plight as
products whose reporting mechanisms are imminently dossable (like the
product whose name rhymes with shmibeslop barometer).   We should all
hope that any IDS solution we use would not limit the rate at which
events were logged but would rather be accurate enough to not generate
extensive logs that were filled with useless information.  In any event,
if your particular ruleset generates a good bit of traffic that isn't
particularly interesting to anyone _but_ you, don't you still want to
see it (you did, after all, decide to load the rule which would generate
an alert of some type).  I couldn't speak with a great deal of authority
on the subject, but I would guess that snort could handle far more
alerts than the mechanism by which the alerts are delivered could
handle.

-Jeff


Erich Meier wrote:
> 
> On Thu, Jul 20, 2000 at 11:56:14AM +0200, Andrea Barisani wrote:
> > Hi!
> >
> > Recently I was thinking about a denial of service against machine that are
> > using snort and I came up with this strange idea.
> >
> > If i create a set of scripts or a program that would read a snort rules
> > file and would flood some host with all the packets that matchs the
> > entries of that rules-file I can create a LOT of work for the logging
> > system of snort. I guess that flooding for just a minute could cause
> > several problems even on fast machines.
> > I have not yet test that, mainly because I haven't the time to build the
> > program but I wonder if there is someone who wants to try that.
> >
> > Maybe could be useful an option in snort that limits the rate of events
> > logged per second...
> >
> > What do you think?
> 
> I think the problem lies not within snort. It really can keep up with a high
> frequecy of alarms, even without binary logging and fast alerts. Do you really
> want to drop alerts at the very first stage?
> 
> IMHO the problem lies in the rest of the alarm chain. Syslogds could be swamped.
> Lots of sysadmins watch their logfiles with swatch or logsurfer and send alerts
> by email. And that's the real danger. With a slow mail delivery system or if
> the recipients use some kind of filtering system (e.g. procmail) the mailserver
> goes south.
> 
> Been there, done that. :-(((
> 
> So a rate limiting system for swatch et al. would be far more effective.
> 
> Erich
> 
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/snort-users

-- 
Jeff Nathan                          <jeff at ...2...>
Core R&D                         http://www.hiverworld.com
Hiverworld, Inc.       Continuous Adaptive Risk Management




More information about the Snort-users mailing list