[Snort-users] announcement & questions: user space firewall
tlewis at ...724...
Wed Nov 29 11:40:53 EST 2000
On Tue, 28 Nov 2000, Martin Roesch wrote:
> Two words: Bad ass. :)
Thanks! I'm glad you like it.
> Interesting, I wonder if we could get it to interact with something like
> ip-filter in a similar way?
My understanding is that ip-filter can redirect TCP or UDP traffic to
normal local sockets, much as ipchains can under Linux today. You could
make that work, but I don't believe that you can send non-TCP/UDP traffic
through it, and you have to use your own packet re-insertion stuff.
Much better is netfilter's ip-queues under Linux 2.4 or FreeBSD's
divert sockets, which dump everything to a raw socket. With netfilter,
you don't even have to copy the packet back down the kernel space, so,
with the exception of context switch overhead, it shouldn't be any more
expensive than the pcap case; I think that's pretty cool.
If someone wanted to build an ip-filter engine, I believe that it could
plug into the proposed paengine framework.
> > I propose that a single rule begin with a set of one or more actions,
> > rather than one and only one action as it is now. I think that this
> > change is necessary even without my modifications; the fact that alert
> > implicitly calls log is pretty gross, and as more actions are added to
> > snort, the ability to combine them is important.
> > (...)
> 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.
1) What interaction will that be?
2) How do I find out more about that work? Is there a design doc on it?
> 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.
Can you expand on this?
> The existing structure of doing alerts with auto-logging is an artifact of
> Snort's early days.
Understood; I was just using it to demonstrate the need for multiple
actions per rule.
> > B) PLUGGABLE PACKET ACQUISITION ENGINES
> > pcap is not the only way to get packets. I would like to abstract out the
> > package acquisition mechanism, convert pcap into the first such engine,
> > and then take my libipq stuff and make that into an engine.
> Good idea, we're also talking about abstracting the decoding system for 1.7+.
> Pluggable decoders are something that'll be highly desirable with this
> implementation since we can have data handed to us in (potentially) several
> formats. There's also been talk of making Snort work on non-packet data as
> well, but that's way off in the future.
Can you give me some examples of decoders that would be implemented in
a pluggable system? Are you talking about stacking IP on top of ATM, or
being able to swap IPv4, IPv6 and AppleTalk? Are there cases where the
paengine identifying the type of packet it issues, like in my proposal,
would not be sufficient for the decoders to do their jobs? If not, then
are there other problems with the layering between packet acquisition
and packet decoding?
> > snort would default to pcap, or whatever else the builder wants the
> > default to be. The engine could then be set either via a command-line
> > argument or via a config file entry.
> > (Not that I want to do this now, but my personal preference is that these
> > engines be dynamically-loadable shared objects. I used this approach for
> > drivers for a DNS server called Dents that I helped develop. Then again,
> > I believe that snort's plugins should be loaded in the same way. I know
> > that this raises portability problems, so I'm not going to tackle it for
> > now, but if others are interested, I can certainly help in this work.
> > I am intentionally proposing this interface in such a way that it is
> > amenable to being used via loadable modules later.)
> Yes, we're going to switch to this after version 1.7. At the rate we're
> adding in major architectural changes, we might want to call the following
> release 2.0. :) I need to get up to speed on how the dlopen() et al.
> functions work and look at what it's going to take to get this way of doing
> things implemented in Snort.
Absolutely. For Dents, we decided to use glib, which made tons of stuff
easier, including module loading, since they had a module system which
works with dlopen, windows dll's, etc. dlopen is easy to use, at least
on platforms where it's supported. Where you don't have dlopen, you
can use one of the new, fancy self-contained linkers which are derrived
from XFree's linker; rasterman's new image manipulation program uses
that stuff, I believe.
> When we're done with this phase of the development, Snort will truly become a
> flexible packet analysis framework that you attach functionality to. It
> should be pretty interesting to see how it turns out. :)
I think you've got a winner on your hands here, Marty. From the
little bit of hacking I've done on snort to date, I've been impressed
by how straightforward it's going to be to add this stuff. Plus, you
fill a much-needed niche. I think you've got the jump on everyone
else on building the world's first all-singing, all-dancing packet
> > Future work:
> > - This interface only supports one connection per engine. It would be nice
> > to use session identifiers to differentiate among different connections.
> > This would require for the loop to be outside of the engine and for
> > the engines to export enough functionality to fit into an external
> > select loop, or something. Complicated, and since snort doesn't support
> > this presently anyway, ignored for now.
> What do you mean by one connection per engine? One data source (e.g. pcap)?
What I mean is that, e.g., with FreeBSD divert sockets, you can open
multiple sockets on multiple ports and then add firewall rules at various
points in your firewall chain to divert specific traffic to a specific
divert socket port. This results in multiple sockets, potentially each
with the need for their own configuration, etc. So, you would say something
/* add each engine's fd to an fdset */
/* select on the fdset */
/* depending on which fd triggered, call its handler */
Or something. I'm not really worried about it right now, since the
way to do this is just run a separate snort instance for each one.
It's just something to keep in the back of one's head.
> 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,
As for stream reassembly, that's an interesting area, because there's a
lot of work already done in various kernels to do that. They've already
got a ton of that code done and with years of testing behind it thanks
to NAT; there's an increasing push, e.g., with netfilter, to reuse that
code for firewall purposes. I will try to read up on this work and see
if I can offer some comments on what the right thing to do here might be.
I had been hoping that just passing raw packets into DecodeRawPkt would be
enough. I'll have to take a look at the TCP stream reassembly stuff's use
> plus the layer 2 decoders all expect a
> pcap_pkth to be handed in.
I already build a pcap_pkthdr to pass to the grinders. Is that
insufficient? If you discard the pcap interface, then you're going to
have to come up with something which is going to be virtually identical;
for this reason, I decided just to keep it.
> 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
That would be just dandy with me.
> 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.... :)
The firewall code controls whether packets are forwarded or dropped.
(I'm not sure what the "by other interfaces" part means.) The entire
purpose of this exercise is to turn snort into the first gateway IDS,
which would indeed be most righteous. Personally, I think that the
IDS/firewall division is a historical accident anyway; if you're examining
a packet, then why not pass judgement on it? I am very excited about this
> > D) INTEGRATION WORK
> > I will probably need some help with the auto* stuff to get this integrated
> > properly. I plan to program this with all of the #ifdef's I need in
> > the code and, by default, have it all turned off.
> Which auto* stuff? I'll help where I can.
autoconf/automake, etc. I'll just need support for finding libipq and
enabling the ipq plugin in configure; it should be a piece of cake for
someone who understands that stuff.
> You SecureWorks guys have been turning out some good stuff lately!
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