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

Fri Mar 9 01:10:50 UTC 2018

I followed a similar guide, I’ll go back and read that one once I get home.
it’s been working well for over a year, I also set the bypass flag, but
that’s is mainly paranoia, in case it stops listening.  I need packets to
flow on the servers that suricata runs on (I get an alert, immediately, if
not).

At home now, the docs are similar, i'm not sure why i chose the second
option.  I also use saltstack for all configurations and my states are:

nfqueue-input:
  iptables.append:
    - chain: INPUT
    - jump: NFQUEUE
    - queue-bypass: ''
    - save: True
    - require:
      - sls: iptables

nfqueue-output:
  iptables.append:
    - chain: OUTPUT
    - jump: NFQUEUE
    - queue-bypass: ''
    - save: True
    - require:
      - sls: iptables

so I ignore forward.  I may not be helping, but i'm going to see on some of
my staging servers what happens if i change to FORWARD only.

Hopefully good info for both of us.  There are no bridged cards, this is
configured on EC2 instances with no advanced networking, all instances that
suricata is running on are public, or have at least a one public port.

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

> Hi Jeff, I implemented the forward because of the guide here:
>
> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/
> Setting_up_IPSinline_for_Linux
>
> According to the Guide, the forward Is us3d to protect the network behind
> the IPS, the INPUT setting was for protecting the host.  Did I
> misunderstand that?
>
> Sent from my iPad
>
> On Mar 8, 2018, at 5:56 PM, Jeff Dyke <jeff.dyke at gmail.com> wrote:
>
> I'm not to sure how helpful this is, but do you see
> 8/3/2018 -- 22:12:59 - <Info> - NFQ running in standard ACCEPT/DROP mode
> in your suricata.log (timing aside)
> Also i attach this to my INPUT route, any reason you're only using
> FORWARD.  Do you see any bytes and packets rising in FORWARD.
>
> Jeff
>
> On Thu, Mar 8, 2018 at 5:39 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/
>>
>>
>> _______________________________________________
>> 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/60aeeec1/attachment-0002.html>