doc/userguide: add IPS with BPF info, minor cleanups

diff --git a/doc/userguide/performance/ignoring-traffic.rst b/doc/userguide/performance/ignoring-traffic.rst
index cb1930071d33564e92eeba049a7a771118e27172..2b1ecdb4c74f50644b370ee1986d2f594ed0f1db 100644 (file)
--- a/doc/userguide/performance/ignoring-traffic.rst
+++ b/doc/userguide/performance/ignoring-traffic.rst
@@ -7,9 +7,9 @@ may be trusted, or perhaps a backup stream should be ignored.
 capture filters (BPF)
 ---------------------
 
-Through BPFs the capture methods pcap, af-packet and pf_ring can be
+Through BPFs the capture methods pcap, af-packet, netmap  and pf_ring can be
 told what to send to Suricata, and what not. For example a simple
-filter 'tcp' will only send tcp packets.
+filter 'tcp' will only capture tcp packets.
 
 If some hosts and or nets need to be ignored, use something like "not
 (host IP1 or IP2 or IP3 or net NET/24)".
@@ -33,16 +33,24 @@ Using a capture filter limits what traffic Suricata processes. So the
 traffic not seen by Suricata will not be inspected, logged or otherwise
 recorded.
 
+BPF and IPS
+^^^^^^^^^^^
+
+In case of IPS modes using af-packet and netmap, BPFs affect how traffic
+is forwarded. If a capture NIC does not capture a packet because of a BPF,
+it will also not be forwarded to the peering NIC.
+
+So in the example of `not host 1.2.3.4`, traffic to and from the IP `1.2.3.4`
+is effectively dropped.
+
 pass rules
 ----------
 
 Pass rules are Suricata rules that if matching, pass the packet and in
 case of TCP the rest of the flow. They look like normal rules, except
-that instead of 'alert' or 'drop' they start with 'pass'.
+that instead of `alert` or `drop` they use `pass` as the action.
 
-Example:
-
-::
+Example::
 
   pass ip 1.2.3.4 any <> any any (msg:"pass all traffic from/to 1.2.3.4"; sid:1;)
 
@@ -57,9 +65,7 @@ host. This is not efficient however, as the suppression is only
 considered post-matching. In other words, Suricata first inspects a
 rule, and only then will it consider per-host suppressions.
 
-Example:
-
-::
+Example::
 
   suppress gen_id 0, sig_id 0, track by_src, ip 1.2.3.4
 
@@ -75,11 +81,22 @@ the bypass is done in the kernel or in hardware.
 bypassing traffic
 -----------------
 
-Aside from using the ``bypass`` keyword in rules, there are three other ways to bypass traffic.
+Aside from using the ``bypass`` keyword in rules, there are three other ways
+to bypass traffic.
+
+- Within suricata (local bypass). Suricata reads a packet, decodes it, checks
+  it in the flow table. If the corresponding flow is local bypassed then it
+  simply skips all streaming, detection and output and the packet goes directly
+  out in IDS mode and to verdict in IPS mode.
+
+- Within the kernel (capture bypass). When Suricata decides to bypass it calls
+  a function provided by the capture method to declare the bypass in the
+  capture. For NFQ this is a simple mark that will be used by the
+  iptables/nftablesruleset. For AF_PACKET this will be a call to add an element
+  in an eBPF hash table stored in kernel.
 
-- Within suricata (local bypass). Suricata reads a packet, decodes it, checks it in the flow table. If the corresponding flow is local bypassed then it simply skips all streaming, detection and output and the packet goes directly out in IDS mode and to verdict in IPS mode.
-- Within the kernel (capture bypass). When Suricata decides to bypass it calls a function provided by the capture method to declare the bypass in the capture. For NFQ this is a simple mark that will be used by the ruleset. For AF_PACKET this will be a call to add an element in an eBPF hash table stored in kernel.
-- Within the nic driver. This method relies upon XDP, XDP can process the traffic prior to reaching the kernel.
+- Within the NIC driver. This method relies upon XDP, XDP can process the
+  traffic prior to reaching the kernel.
 
 Additional bypass documentation: