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

Jeff Nathan jeff at ...2...
Thu Jul 20 20:49:09 EDT 2000


Er, make that shmiberslop barometer.

Woops, forgot an 'r' in there.

-Jeff

Jeff Nathan wrote:
> 
> 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
> 
> _______________________________________________
> 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