[Oisf-users] [Spam Score 8.139] Re: Suricata nfqueue does not receive packets

[Chris Boley]

Albert, if you happen to be using this inline between an ISP service
delivery switch and your firewall interface, ISP’s often tag their frames
that they are sending you with a specific vlan ID. Or possibly if your IPS
topology is designed where your scanning between two switches that might
have been “trunks”  where it’s tagging vlan ID’s to the frames; then You
would need to enable the appropriate sysctl flags to tell your bridge to
send tagged frames to IPTABLES. Otherwise it won’t do it and anything in
the forward rule will be ignored. By default in Ubuntu those flags aren’t
enabled. That was what I was guessing may be happening to you.

On Thu, Mar 8, 2018 at 5:43 PM Albert E Whale <
Albert.Whale at it-security-inc.com> wrote:

> I don’t think so.  How can I tell if the packets are actually getting to
> Suricata??
>
> Sent from my iPhone
>
> On Mar 8, 2018, at 5:06 PM, Chris Boley <ilgtech75 at gmail.com> wrote:
>
> Sorry I replied directly the first time.
> Are the frames crossing the bridge tagged with vlan ID’s?
>
> On Thu, Mar 8, 2018 at 3:33 PM Albert Whale <
> Albert.Whale at it-security-inc.com> wrote:
>
>> I am running Suricata 4.0.4, and attempting to run with the NFQ. I have
>> AF-Packet working perfectly, but I wanted to run in IPS mode, and I
>> understand that this is only available while using nfqueue.  Here's the
>> Startup log information.
>>
>> 8/3/2018 -- 09:14:19 - <Notice> - This is Suricata version 4.0.4 RELEASE
>> 8/3/2018 -- 09:14:19 - <Info> - CPUs/cores online: 4
>> 8/3/2018 -- 09:14:19 - <Config> - luajit states preallocated: 128
>> 8/3/2018 -- 09:14:19 - <Config> - 'default' server has
>> 'request-body-minimal-inspect-size' se
>> t to 31625 and 'request-body-inspect-window' set to 4241 after
>> randomization.
>> 8/3/2018 -- 09:14:19 - <Config> - 'default' server has
>> 'response-body-minimal-inspect-size' s
>> et to 41627 and 'response-body-inspect-window' set to 16218 after
>> randomization.
>> 8/3/2018 -- 09:14:19 - <Config> - DNS request flood protection level: 500
>> 8/3/2018 -- 09:14:19 - <Config> - DNS per flow memcap (state-memcap):
>> 524288
>> 8/3/2018 -- 09:14:19 - <Config> - DNS global memcap: 16777216
>> 8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled
>> for modbus protocol.
>> 8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled
>> for enip protocol.
>> 8/3/2018 -- 09:14:19 - <Config> - Protocol detection and parser disabled
>> for DNP3.
>> 8/3/2018 -- 09:14:19 - <Info> - Enabling fail-open on queue
>> 8/3/2018 -- 09:14:19 - <Info> - NFQ running in standard ACCEPT/DROP mode
>>
>> The IPTables has been configured as such:
>>
>> iptables -nL  | grep -v DROP
>> Chain INPUT (policy ACCEPT)
>> target     prot opt source               destination
>>
>> Chain FORWARD (policy ACCEPT)
>> target     prot opt source               destination
>> NFQUEUE    all  --  0.0.0.0/0            0.0.0.0/0 NFQUEUE num 0
>>
>> Chain OUTPUT (policy ACCEPT)
>> target     prot opt source               destination
>>
>>
>> I also have the following configuration setup for nfq:
>>
>> nfq:
>>    mode: accept
>>    repeat-mark: 1
>>    repeat-mask: 1
>>    bypass-mark: 1
>>    bypass-mask: 1
>>    route-queue: 2
>> #  batchcount: 20
>>    fail-open: yes
>>
>> This is running on Ubuntu:  #35~16.04.1-Ubuntu
>>
>> As I mentioned, I successfully launched suricata inline (I have two
>> bridged Ethernet interfaces) with af-packet, but I do not see it
>> behaving as a True IPS, and while the nfq appears to launch, it is NOT
>> processing any packets in the logs.
>>
>> Any suggestions where to look next?
>>
>>
>> --
>> --
>>
>>
>>
>> _______________________________________________
>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>> Conference: https://suricon.net
>> Trainings: https://suricata-ids.org/training/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180308/41618502/attachment-0002.html>