[Snort-devel] more fun questions

Martin Roesch roesch at ...48...
Thu Jan 18 17:51:02 EST 2001


Todd Lewis wrote:
> 
> On Thu, 21 Dec 2000, Martin Roesch wrote:
> 
> > > The problem is that the output plugin would not know what the paengine
> > > was or what the paengine's ID for that packet was, unless it were all
> > > global, which I think is a bad idea.
> >
> > Well, you'd activate a specific output plugin to put Snort in "gateway mode"
> > that would automatically assume that the proper paengine was being used.
> > There's no law that says you can't pair plugin elements together.
> 
> OK, so I was sitting down to figure out how I would do this, and I realized
> two more problems with this approach:
> 
> - In the user-space firewall case, how do you track the disposition of the
> packet as it goes through the rules?  If you are just changing a flag in
> the Packet struct, then it's easier to tune the decision making algorithm
> on packet disposition.  I.e., with the set-a-flag-and-dispose-at-the-end
> approach, if you decide to discard a packet, a later rule can override
> that decision, because the packet has not actually been discarded,
> whereas under the output-plugin approach, your decision has already
> been made and you can not override it.  (Viz. the differences in policy
> between kernel-space firewalls on first-decision versus last-decision
> to see that people want this flexibility.)
> 
> - What about the existence of the raw packet buffer?  If you are
> discarding the packet in the middle of rule processing, then that buffer
> may be reclaimed, precluding further rule processing.  So, your plugin
> has to reach back up into the rule processing and abort treatment of
> that packet; this breaks layering.
> 
> Both of these issues again suggest to me that the better way to treat
> this is to have rules set a flag in the Packet structure and have the
> paengine dispose of the packet when rule processing is done.
> 
> However, I am open to other ways to deal with these problems, and if
> there are such approaches, and if you, Martin, continue to think that
> the output-pplugin approach is better, then I want to give it a shot.

The output plugin approach hews closer to what has been done in Snort
before.  It can also be treated as a preprocessor, but if we do that
then we'll be trying to make decisions ahead of the detection engine. 
Maybe we should think about new action keywords, pass and drop and have
the system specifically integrate netfilter functionality.

Can you describe for me the way you envision the packet flow through
Snort for this application?

    -Marty

--
Martin Roesch
roesch at ...48...
http://www.snort.org




More information about the Snort-devel mailing list