[Snort-devel] Plugin API Feature Request

Jeff Nathan jeff at ...835...
Fri Feb 10 10:04:05 EST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Thomas,

I don't completely understand your issue I still suspect that a  
callback within the main pcap loop would be sub-optimal.

Perhaps your database provides you a handle that is selectable or  
similar?  In that case you could register an event for the database  
handle and its callback could call your intended callback, provided  
the database was in a suitable state.

If you traverse a list of plugin callbacks and one of them blocks,  
then all of snort is blocked.  Perhaps this is a circular argument,  
it's not intended to be so, however...


On Feb 3, 2006, at 10:18 AM, <Thomas.Seiler at ...2736...>  
<Thomas.Seiler at ...2736...> wrote:

>
> Hi snort-devel list,
>
> Sorry if some of you receive this twice.
>
> On 1/21/06, Jeff Nathan <jeff at ...835...> wrote:
>> With respect to issue 2, this can be done with libevent, as I did in
>> the XML output plugin (op_alert_xml) in barnyard
>
> When I use libevent, then I can't use the database connection  
> because it
> could be in any state (i.e. currently executing a statement) when
> control is given back to me. Most database client libraries are not
> thread safe, nor asynchronous.
>
> I therefore think that a periodic, synchronous callback enriches the
> snort Plugin API. Please consider the current function  
> InterfaceThread()
> in snort.c:
>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 
> "
> /* Read all packets on the device. Continue until cnt packets read */
> if(pcap_loop(pd, pv.pkt_cnt,
>              (pcap_handler) PcapProcessPacket, NULL) < 0)
> {
>     if(pv.daemon_flag)
>         syslog(LOG_PID | LOG_CONS | LOG_DAEMON,
>                "pcap_loop: %s", pcap_geterr(pd));
>     else
>         ErrorMessage("pcap_loop: %s\n", pcap_geterr(pd));
>
>     CleanExit(1);
> }
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 
> "
>
> Here is the same code modified a little bit to allow periodic plugin
> callbacks:
>
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 
> "
> /* Read all packets on the device. Continue until cnt packets read */
> if (PluginPeriodicCallbackList->next == NULL)
> {
>     /* no periodic plugin callbacks registered,
>      * so we can optimize for speed and use pcap_loop
>      */
>     if(pcap_loop(pd, pv.pkt_cnt,
>                  (pcap_handler) PcapProcessPacket, NULL) == -1)
>     {
>         if(pv.daemon_flag)
>             syslog(LOG_PID | LOG_CONS | LOG_DAEMON,
>                    "pcap_loop: %s", pcap_geterr(pd));
>         else
>             ErrorMessage("pcap_loop: %s\n", pcap_geterr(pd));
>
>         CleanExit(1);
>     }
> } else {
>     /* some periodic plugin callback were registered */
>     while(pv.pkt_cnt) {
>         /* check if its time to call a plugins periodic callback */
>         /* this code yet to be done */
>
>         /* read some packets until the timeout occurs */
>         pkt_cnt_read = pcap_dispatch(pd, pv.pkt_cnt, (pcap_handler)
>                                  PcapProcessPacket, NULL);
>         if (pkt_cnt_read == -1)
>         {
>             if(pv.daemon_flag)
>                 syslog(LOG_PID | LOG_CONS | LOG_DAEMON,
>                        "pcap_loop: %s", pcap_geterr(pd));
>             else
>                 ErrorMessage("pcap_loop: %s\n", pcap_geterr(pd));
>
>             CleanExit(1);
>         }
>         pv.pkt_cnt -= pkt_cnt_read;
>     }
> }
> """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
>
> The outer if statement optimizes for the case where no plugin  
> registered
> a periodic callback. In the else statement, I do basically what
> pcap_loop does: calling pcap_dispatch in a loop. But in between the
> calls to pcap_dispatch, I can dispatch to a plugin periodic callback.
> This way, the callbacks stay in sync with the packet processing and  
> its
> possible to use the database connection or modify data structures  
> inside
> such a callback handler.
>
> What in the above code would need to be changed in order to have it
> included into a future snort release? I would be happy to supply the
> necessary patches.
>
>
> Best Regards,
> Thomas Seiler
>
> -----------------------------
> Thomas Seiler
> Ing. sys. com. dipl. EPFL
> SWISSCOM AG
> Innovations
> Security and Service Management
> Ostermundigenstrasse 93
> CH - 3050 Bern
> SWITZERLAND
>
> Phone:  +41 (0)31 342 42 69
> Mobile: +41 (0)79 427 97 26
> Fax:    +41 (0)31 892 62 27
>
> thomas.seiler at ...2736...
> http://www.swisscom.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel


- --
http://cerberus.sourcefire.com/~jeff       (DSA key id 6923D3FD)
"Not everything that is counted counts, and not everything that  
counts can be counted."   - Albert Einstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFD6lvYEqr8+Gkj0/0RAl1UAJ9lwKSvHwbdZzsvsKi2CO5B7Qle+ACeMHSl
QcCmCr/8jMRrth8GQH62+vw=
=8FuN
-----END PGP SIGNATURE-----




More information about the Snort-devel mailing list