[Snort-devel] Fwd: Snort blocking connection but not logging the drop

Cody Brugh cbrugh at ...2499...
Thu May 15 21:06:54 EDT 2014


FYI, this issue is now resolved..  I run snort on a physical server and had
one of these offloading methods enabled on the NIC.  I disabled and traffic
is flowing without issues now!

Many thanks to Russ for helping determine Snort wasn't the issue.

*Note:  *

Some network cards have features named "Large Receive Offload" (lro) and
"Generic Receive Offload" (gro). With these features enabled, the network
card performs packet reassembly before they're processed by the kernel.

By default, Snort will truncate packets larger than the default snaplen of
1518 bytes. In addition, LRO and GRO may cause issues with Stream5
target-based reassembly. We recommend that you turn off LRO and GRO. On
linux systems, you can run:

    $ ethtool -K eth1 gro off
    $ ethtool -K eth1 lro off




On Thu, May 15, 2014 at 3:09 PM, Russ Combs (rucombs) <rucombs at ...3461...>wrote:

>
>  ------------------------------
> *From:* Cody Brugh [cbrugh at ...2499...]
> *Sent:* Thursday, May 15, 2014 2:55 PM
>
> *To:* Russ Combs (rucombs)
> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
> logging the drop
>
>   do you suggest maybe changing from afpacket to something else for DAQ?
>
> * You could try that.  You should post to snort-users to see if other
> users have had this issue.  This doesn't appear to be a bug.
>
> --daq afpacket
>
>
>
> On Thu, May 15, 2014 at 2:45 PM, Russ Combs (rucombs) <rucombs at ...3461...>wrote:
>
>>
>>  ------------------------------
>> *From:* Cody Brugh [cbrugh at ...2499...]
>> *Sent:* Thursday, May 15, 2014 2:33 PM
>>
>> *To:* Russ Combs (rucombs)
>> *Subject:* Re: [Snort-devel] Fwd: Snort blocking connection but not
>> logging the drop
>>
>>    fetch ... is still being blocked and no alerts show.....
>>
>>  * If it is still being blocked it isn't Snort.  It could be your DAQ,
>> but I doubt that too.  You can double check Snort's shutdown / usr1 stats
>> to make sure the packet counts are correct to verify that.
>>
>> * Note also that Snort usually doesn't block port 443 because the traffic
>> is usually encrypted so no inspection.  If anything, Snort will whitelist
>> that traffic, meaning don't inspect it.  Check for whitelist counts in the
>> shutdown / usr1 data.  Try disabling ssl to see if there is any change.
>>
>> * However, it really seems like there is something else like a firewall
>> blocking port 443.
>>
>>  Can you run that fetch command on a snort in-line setup that you might
>> have?
>>
>> ...
>> Result=0x00000000
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20140515/06a06ee4/attachment.html>


More information about the Snort-devel mailing list