Re: [PATCHES] Fixes for daq_nfq

[Russ Combs <rcombs () sourcefire com>]

Thanks, comments inline ...

On Tue, Mar 22, 2011 at 7:39 PM, Kelvie Wong <kwong () wurldtech com> wrote:

> 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:

Are you using the latest Snort?  The NFQ DAQ was recently changed to return
the IP4 or IP6 flavor instead of RAW because Snort determines the layer 3
protocol from the layer 2 header, and in this case there is no layer 2
header.  Returning IP4 or IP6 allows Snort to work with either.

>    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.

Yes but see above.  This isn't a pcap issue.

> 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);
>     }
>
> Thanks, I'll bug it.


> 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 () wurldtech com> 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.
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel