[Snort-users] 2.1.3RC1 event_queue and custom ruletypes/log rules?

Bamm Visscher bamm at ...539...
Mon May 3 10:07:02 EDT 2004

Sounds like a good time to discuss the output 'kludge' and the different ways some users (like me) are running to implementaion problems.


  I want to use an output plugin that uses a DB. The only sane way to implement this is with unified out and barnyard. I want packet data in the DB, not just alert info, so I am forced to use log_unified (versus alert_unified). I also require a lot of packet capturing (log ip any any -> any any when possible) and I want this data in binary (pcap) format so I can parse it easily with tcpdump/ethereal/tcpflow/etc as needed.

I have been unable to come up with a decent/graceful solution to the above problem. If I use a custom ruletype and the default order, the malicious packet will never make it to my custom ruletype and thus not be logged in binary (so if I replay the flow, I have everything BUT the 'bad packet), or if I change the rule order, then packets that match my new ruletype, will never make it to the alert chain. In the end, I am forced to either run an instance of snort in IDS mode, and another in 'packet logger' mode (I could also use tcpdump or similar). This is not the most graceful solution as I've been told that having mulitiple pcap processes can degrade performance significantly. Another problem with the above solution is that in some environments, logging everything isn't plausible, so if I have to create filters. I might get a packet that is alerted on by IDS_SNORT but not logged by LOGGER_SNORT.

I think the original idea behind the output functions (alert/log/pass) worked, but things were semi-broke with the addition of custom ruletypes and even more so with unified out. The 'event queue' is a much needed/wanted function and I'd hate to see it also handicapped by the current implementaion of output functions. Personally, I'd like to see the alert queue traverse the entire alert chain until it hits a 'pass'.


On Mon, May 03, 2004 at 11:50:39AM -0400, Jeremy Hewlett wrote:
> On Wed, Apr 28, Erik Fichtner wrote:
> > Are custom rule types not part of the new event_queue?  
> > (which, by the way, I think I like.)
> Thanks for trying out the new event queue mechanism!
> > does not produce expected behavior.. the "sample alert" packets do not
> > appear in traffic.log, only in alerts.log.  So, I think to myself 
> > 'self.. perhaps it only works on "alert" types.'  so I make "traffic"
> > an "alert" type (with output alert_fast: /dev/null  (YUCK!))..   same
> > behavior.   So....  help?
> Currently how the event queue works is that depending on the order of
> the alert types, we log multiple events of the highest ordered alert
> type. So, for example - 
> if you have pass->alert->log order, and you alert on two "pass" rules,
> three "alerts," one "log" we only will log the two pass rules. This is
> because if you have a "pass" rule you don't want to see alerts, so we
> only log the highest ordered alert type.
> So, for your example, if you ordered the "traffic" alert type first
> you should see the "traffic" event but not the "alert" event.
> Your example brings up a good point - do we want to allow multiple
> logging of different alert types while keeping in mind there are some
> alert types we don't want to log because of a lower priority ordering...
> We'll look into this - feedback welcomed.
> Thanks!

More information about the Snort-users mailing list