[Snort-devel] [ekr at ...168...: Re: format string in ssl dump]

Todd Lewis tlewis at ...120...
Sat Dec 16 12:06:57 EST 2000


I am not sure that I quite understand what you are wanting to do, but
from the messages I've seen, I think that there may be some overlap with
my work.  Let me run it past you and get your feedback.

What I have implemented is a packet acquisition interface for snort.
Each packet acquisition engine (paengine) exports the following interface:

/* datatypes */
typedef struct paengine {
   char *name; /* name of the paengine, e.g., "pcap" */
   int (*configure)(char * config); /* config file entry for engine; 0 on>
                                     * success, other on error */
   int (*init)(void); /* initialize driver; 0 on success */
   int (*loop)(void (*)(char *, struct pcap_pkthdr *, u_char *));
                     /* loop function for driver; takes a grinder as an
                      * argument. 0 on success, other on failure. */
   int (*close)(void); /* close driver; 0 on success */
   int (*get_devtype)(void); /* # of the device type; called after conf() */
   int (*get_capabilities)(void); /* caps of the driver; called after conf() */
} paengine;

So far, I have implemented two paengines under this interface: pcap and
netfilter on Linux 2.4.  I also plan to build one for divert sockets
under FreeBSD.

The reason I want to do this is so that I can turn snort into a user-space
firewall.  I have already done this in a prototype with snort; abstracting
the packet acquisition code allows me to do it in a clean way.

I am still basically emulating pcap.  I grab packets and pass them into
a handler routine that examines them.  We have discussed changing this
interface in a couple of ways:  1) simplifying the callback passed into
loop() to pass less extraneous data (not very important), and 2) rather
than having a single call back in loop, separating the packet decoding
logic from the packet examination logic.  The second piece would look
something like this:

> My initial thinking is that I would like for snort.c:ProcessPacket to be
> an int instead of a void and to return the verdict on the packet, i.e.,
> to end with "return(p.verdict);".  My qualm about this approach is that
> there might be other information that the paengine wants out of the packet
> analysis guts of snort, and so a more general solution may be called for.
> That more general solution involves breaking down packet handling.
> It would probably look something like this in each paengine:
> 	static void take_action(Packet *p);
> 	void paengine_main_loop(void (*munge_packet_callback)())
> 	{
> 		u_char buf[BUFSIZE];
> 		Packet p;
> 		while(get_packet(&buf, sizeof(buf))){
> 			(*munge_packet_callback)(&buf, &p); /* dependent on packet type */
> 			process_packet(&p);                 /* global, general for snort */
> 			take_action(&p);
> 		}
> 	}
> That way, the paengine has visibility into the Packet struct, which
> can be extended to pass around whatever info is needed.

So, I am not sure if your code would be another packet acquisition engine,
or a munge_packet_callback function.  What do you think?  Marty, et al.,
what do you think?

To me, the biggest problem seems to be that you deal with sockets and we
deal with packets, and my code doesn't solve that problem in any very
helpful way.  Then again, I don't think I understand your work well
enough to say.

Todd Lewis                                       tlewis at ...120...

  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-devel mailing list