[Snort-devel] [PATCHES] Fixes for daq_nfq

Kelvie Wong kwong at ...3121...
Tue Mar 22 19:39:42 EDT 2011


Hey Russ,

Sorry it has been a while; I have finally gotten a chance to update Snort/DAQ
again for testing.

I haven't found the time to set up the test bench to reproduce the crashing
issue; however, I have found another bug.

DAQ 0.5 doesn't seem to work with the version of libpcap I'm running; in this
snippet:

    if (!ScTestMode())
    {
        pcap_t* pcap = pcap_open_dead(DAQ_GetBaseProtocol(), DAQ_GetSnapLen());
        data->dumpd = pcap ? pcap_dump_open(pcap, data->logdir) : NULL;

        if(data->dumpd == NULL)
        {
            FatalError("log_tcpdump: Failed to open log file \"%s\": %s\n",
                       data->logdir, pcap_geterr(pcap));
        }
        pcap_close(pcap);
    }

pcap_open_dead is being called with DAQ_GetBaseProtocol, which takes the value
from nfq_daq_get_datalink_type.

The problem is that nfq_daq_get_datalink_type now returns DLT_IPV4 or DLT_IPV6
instead of DLT_RAW (as it did in 0.2). According to the pcap manpage
(http://www.tcpdump.org/pcap3_man.html) it supports neither of those values.

As a result, log_tcpdump outputs the error message:

ERROR: log_tcpdump: Failed to open log file "/var/log/snort/snort.log.1300810527": Success

whenever snort is started with the NFQ DAQ module. (I start it like snort -vv -c /etc/snort.conf -Q --daq nfq)

I'll also recommend doing something similar to the following:

diff --git a/src/output-plugins/spo_log_tcpdump.c b/src/output-plugins/spo_log_tcpdump.c
index a24a410..d061e37 100644
--- a/src/output-plugins/spo_log_tcpdump.c
+++ b/src/output-plugins/spo_log_tcpdump.c
@@ -399,7 +399,7 @@ static void TcpdumpInitLogFile(LogTcpdumpData *data, int nostamps)
         if(data->dumpd == NULL)
         {
             FatalError("log_tcpdump: Failed to open log file \"%s\": %s\n",
-                       data->logdir, strerror(errno));
+                       data->logdir, pcap_geterr(pcap));
         }
         pcap_close(pcap);
     }

As it gives a better error message in this case; errno wasn't touched by this
error. With this patch, I get the error:

ERROR: log_tcpdump: Failed to open log file "/var/log/snort/snort.log.1300810527": 
/var/log/snort/snort.log.1300810527: link-layer type -1 isn't supported in savefiles

Anyways, this is my workaround:

diff --git a/os-daq-modules/daq_nfq.c b/os-daq-modules/daq_nfq.c
index 87cbf6d..d4f736b 100644
--- a/os-daq-modules/daq_nfq.c
+++ b/os-daq-modules/daq_nfq.c
@@ -634,8 +634,7 @@ static uint32_t nfq_daq_get_capabilities (void* handle)
 static int nfq_daq_get_datalink_type(void *handle)
 {
     NfqImpl* impl = (NfqImpl*)handle;
-    int dlt = IP4(impl) ? DLT_IPV4 : DLT_IPV6;
-    return dlt;
+    return DLT_RAW;
 }
 
 static const char* nfq_daq_get_errbuf (void* handle)


Just wanted to let you know,
Kelvie

On December 9, 2010 09:33:19 AM Russ Combs wrote:
> Have you tested with DAQ 0.3?
> 
> On Tue, Nov 2, 2010 at 4:31 PM, Kelvie Wong <kwong at ...3121...> wrote:
> 
> On November 2, 2010 01:08:36 pm Russ Combs wrote:
>  > Too bad NFQ is so buggy.  Any idea when this fails and when not?  Is it
> > 
> > certain traffic?
> 
> I am not quite sure. Mainly I have been testing this with a nmap scan of
> the TCP ports; this also happens for a storm of TCP packets as well. I
> hadn't tested this against other types of traffic, prior to apply this
> patch.
> 
> > If this happens always or never, for a given run of Snort, the patch is
> > reasonable.  If it is every other packet, we may be better off just
> > adding the smallest delta possible to the timestamp to keep them
> > sequenced.
> 
> For the type of traffic I had tested (I placed printf statements inside
> there), it was every single packet, and not just some of them.
> 
> > The freeze scenario should be eliminated with daq 0.3.  Can you verify
> > that?
> 
> I do not have a test bench set up right now, but I may be able to get a few
> tests in later after I have exhausted my other committments.
> 
> > The early exit is a little different.  Does this indicate a permanent
> > error?  Can you elaborate on the conditions?
> > 
> > The errors were presumbed permanent and Snort exits to avoid consuming
> > excessive resources.
> 
> I have attached a packet capture that can reproduce it every single time on
> one of our hardware configurations -- I have not tested it elsewhere.
> Packets are still queued normally from NFQ after nfq_handle_packet returns
> an error. Snort exits at around the 1000th packet.
> As I have mentioned earlier, I don't have a test environment set up
> currently (nor the time to set it up), so I'm terribly sorry I can't be of
> more help right now.

-- 
Kelvie Wong
Software Developer

Wurldtech Security Technologies Inc.
Suite 1680 - 401 West Georgia St.
Vancouver, B.C.  V6B 5A1
Canada

Phone:       + 1.604.669.6674
Toll Free:   + 1.877.369.6674
Fax:         + 1.604.669.2902
Website:    http://www.wurldtech.com/

"ARE YOU ACHILLES CERTIFIED?"

This message is intended only for the named recipients. This message
may contain information that is privileged, confidential or exempt
from disclosure under applicable law. Any dissemination or copying
of this message by anyone other than a named recipient is strictly
prohibited. If you are not a named recipient or an employee or agent
responsible for delivering this message to a named recipient, please
notify us immediately by telephone at 604-669-6674, and permanently
destroy this message and any copies you may have. Email may not be
secure unless properly encrypted.




More information about the Snort-devel mailing list