[Snort-users] announcement & questions: user space firewall

Todd Lewis tlewis at ...724...
Wed Nov 29 18:28:20 EST 2000


On Tue, 28 Nov 2000, Martin Roesch wrote:

> > 5) PROPOSED CHANGES
> > 
> >         A) MULTIPLE ACTIONS PER RULE
> 
> Ok, this doesn't look like it'd be too terribly hard to implement.  One
> interesting thing to consider is the interaction that this will have with
> Andrew Baker's multi-level alerts that will be coming out in Snort 1.7.
> 
> This also adds layers of complexity to the whole packet
> handling/storing/manipulation code if we're going to do rule correlation later
> on.  This is something we should add after 1.7 ships.

Would it be the end of the world if I added this now?  I'm eager to get this
work done.

> >         B) PLUGGABLE PACKET ACQUISITION ENGINES
> 
> This all sounds reasonable.
(...)
> Ok, this will require some changes in the decoders, as well as some of the
> plugins.  We're pretty tightly bound to pcap right now in the TCP stream
> reassembler and the defragger, plus the layer 2 decoders all expect a
> pcap_pkth to be handed in.  We'll probably want to change them to something
> more like this:
> 
> void DecodeFoo(struct snort_timeval *ts, u_int32_t cap_length, u_int8_t *pkt)
> 
> Where ts is the packet timestamp, cap_length is the amount of data being
> handed to the decoder, and *pkt is the pointer to the data.  Pretty straight
> forward.
> 
> The plugins that use pcap headers explicitly right now will have to be
> modified to switch to the new scheme.  The defrag plugin should be changed to
> use memory a little more efficiently in the future anyway, so this will be a
> good time to get things straightened out.
> 
> As the decoders become plugins, we'll have to encapsulate their functionality
> a little more highly, associating the printout routines directly with the
> decoders that they service and making the decode/printout phase of things more
> of a "best effort" mechanism where the packet dumps are printed as deeply into
> the packet's structure as decoded data is available for.
> 
> Here's a question: can this firewall code control whether packets are
> forwarded or dropped by other interfaces?  If it can, we can take a stab at
> doing the first gateway IDS, which would be extremely righteous.... :)

Again, I would like to procede with this modification as well.  If there
are no objections, I'd like to use Marty's simplified interface for the
core paengine routine.

If other people have documentation on what their plans are or actual code,
then I am happy to accomodate them.  Otherwise, I would like to get going.
Would anyone object to this?

Should I do my work on the CVS version?  I plan on doing it in two parts
and submitting each patch separately.

--
Todd Lewis                                       tlewis at ...724...

  God grant me the courage not to give up what I think is right, even
  though I think it is hopeless.          - Admiral Chester W. Nimitz




More information about the Snort-users mailing list