[Oisf-users] NFQUEUE in general

[Chris Boley]

In order to run Suri as an IPS (NFQUEUE mode)  there's many things that
come into play.
This post asks a couple of things.
Firstly,
1. Documentation lends itself to the "how to compile with nfqueue features"
2. Suggests generically how IPTABLES should be configured.

I kind of get that we can't account for everybody's environment but a
little more detail would be VERY helpful.

Unless I missed this somewhere in "readthedocs", why does it not address:
A. Loading the bridge_flt kernel module ie, how and why.. (Very important
BTW)
It can be done very simply but is a critical component. Ubuntu 16.04
specifically doesn't do this by default and tons of noobs get stonewalled
by this.

B. Configuring sysctl flags appropriately to make NFQUEUE work in a bridge
with Suri. (also critical) Ubuntu 16.04 specifically doesn't do this by
default. If I've missed this in the docs somewhere, sorry I'm asking about
it...

C. Configuring sysctl flags appropriately to make NFQUEUE work in a bridge
that has vlan tagged packets. (this area brings a couple of dynamics that
are important)
    1c. enabling more appropriate sysctl flags to deal with VLAN info
appropriately.

    2c. Explanations of bridges handling VLAN tags and how it affects
bridge MTU requirements...

Quote from another list:
Suricata looks at your MTU on the interface it is running on and adds 16
for its "Bucket length" (like snaplen on snort but not configurable on
suricata). This makes the "snaplen" of data for each packet 1516 if you
haven't changed from the default MTU of 1500. This leaves out the VLAN
information which makes it almost impossible for the "stream" processor in
suricata to actually tell which packets are related to which streams on
which VLAN. This can cause website issues, no alerts on logs, etc... The
fix is to change your MTU to 1502 which makes suricata again add 16 giving
you a total of 1518 "snaplen" which will then be large enough to include
the VLAN information.

Have I missed these things mentioned in the "ReadTheDocs"?

Also, nothing talks about NFQUEUE tuning..
for example load balancing NFQUEUE generic example for an 8 core proc:
sudo suricata -q 0 -q 1 -q 2 -q 3 -q 4 -q 5 -q 6 -q7 -c
/etc/suricata/suricata.yaml

I know there's a feature request in for this:
Feature #2150
How does that play into setting up iptables with:
iptables -A FORWARD -j NFQUEUE --queue-balance 0:7  (asking about queue
balance)

Does one contradict the other? Can somebody help me understand these two?
Pros and cons?

I'm also curious why IPTABLES/nftables isn't mentioned more in
documentation as a way to separate out unwanted traffic prior to it ever
touching the NFQUEUE rule? This indirectly speeds up IDPS engines immensely
and I would think is worthy of mention in documentation for NFQUEUE.

Bridge configuration itself for a non networking type can be onerous for a
noob too.
I'm know FOSS software comes at a price. IE.. "learning". But I'm not
opposed to helping them understand what they need either. It took me a very
long time to round up all these elements into a cohesive formula that works
well. I would offer that more people would use suricata if they could
figure it out.

This list is about helping the community of users. Maybe somebody has
already asked them. If so, my apologies for the duplication.
CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20180407/54d692a7/attachment.html>