(Optional) Configure System-Level (BPF) Packet Filtering

You can use Berkeley Packet Filters to control which packets and logs are processed by a Decoder.

Berkeley Packet Filters (BPF) are applied to the packet stream before the packets are copied to the Decoder adapter for analysis. This allows unwanted traffic to be efficiently discarded. These discarded packets are not accounted for in any Decoder statistics (capture rate, packets dropped, and packets filtered and total packets).

The Decoder also supports system-level packet filtering defined using tcpdump/libpcap syntax. Specifying a Libpcap filter can efficiently reduce packet volume based on Layer 2 ‐ Layer 4 attributes. A Libpcap filter is appropriate for use when a Decoder is receiving a traffic volume that is placing a load against the physical resources of the platform. In this scenario, the Decoder may consistently drop packets and have a large number of capture pages available(/decoder/stats/capture.pagefree is high).
The following is an example of a libpcap filter to keep only packets that do not have both source and destination addresses in the 10.21.0.0/16 subnet.
not (src net 10.21.0.0/16 and dst net 10.21.0.0/16)
For a full reference of the Libpcap filter syntax, see the main pages for:

To add a system-level Berkeley Packet Filter:

  1. Go to netwitness_adminicon_25x22.png (Admin) > Services.
  2. In the Administration Services view, select a Decoder service and netwitness_ic-actns.png​ > View > Config.
    The Services Config view is displayed with the General tab open.
    ConfigVw26.PNG
  3. In the Decoder Configuration Section, under Adapter, click in the field next to Berkeley Packet Filter.
  4. Type only one filter in the field. If you want to filter multiple items, join multiple expressions using and. Several examples are provided below.
    The user interface validates input at the time you enter your filter string.
  5. To save the filter, click Apply.
    If the syntax is correct, a confirmation message is displayed.
    If the syntax is incorrect, a Packet filter is not valid message is displayed and a corresponding log message will follow in the log messages on the Decoder:
    164474800 2020-May-01 19:03:08 warning Decoder Failed to parse filter ‘example_badrule': syntax error
  6. To activate the filter, you must stop and start capture on the Decoder:
    1. Change the Config view to the System view.
    2. Click Stop Capture.
    3. Click Start Capture.
      The active filter will be displayed in the Decoder logs.

Examples

These are several filter examples:

  • Drop packets to or from any address in the 10.21.0.0/16 subnet:
    not (net 10.21.0.0/16)
  • Drop packets that have both source and destination addresses in the 10.21.0.0/16 subnet:
    not (src net 10.21.0.0/16 and dst net 10.21.0.0/16)
  • Drop packets that are from 10.21.1.2 or are headed to 10.21.1.3.
    not (src host 10.21.1.2 or dst host 10.21.1.3)
  • Combine both IP and HOST:
    not (host 192.168.1.10) and not (host api.wxbug.net)
  • Drop all port 53 traffic, both TCP & UDP:
    not (port 53)
  • Drop only UDP port 53 traffic:
    not (udp port 53)
  • Drop all IP protocol 50 (IPSEC) traffic:
    not (ip proto 50)
  • Drop all traffic on TCP ports 133 through 135.
    not (tcp portrange 133-135)

The following filters combine some of the above to demonstrate how to put multiple directives into one filter:

  • Drop any port 53(DNS) traffic sourced from 10.21.1.2 or destined to 10.21.1.3.
    not (port 53) and not (src host 10.21.1.2 or dst host 10.21.1.3)
  • Drop any traffic using IP proto 50 or port 53 or any traffic from net 10.21.0.0/16 destined to net 10.21.0.0/16
    not (ip proto 50 or port 53) or not (src net 10.21.0.0/16 and dst net 10.21.0.0/16)

Caution: The use of parentheses can have a large and potentially disruptive effect on the use of Packet Filters. As a best practice, keep "not" operations outside of parentheses and always test your rules before deploying them. Failure to properly format your rules (despite input validation) can cause a packet filter to drop ALL traffic or behave in other unexpected ways. This is due to the way packet Libpcap filters work and is not the result of any logic within NetWitness software.

Testing

BPF filters can and should be tested using either tcpdump or windump to ensure that they will provide the expected behavior before implementing them. This example shows a test of a filter using windump:

windump -nni 2 not (port 53 or port 443) or not (ip proto 50)

Conversions

If for the sake of performance, you have decided that an existing network rule filter would be better running as a System-Level Packet Filter, you can convert it. There are a few things to remember when doing conversions.

  • && becomes and
  • alias.ip becomes host if a single host or net if a network.
  • ip.src becomes src host if a single host or src net if a network.
  • ip.dst becomes dst host if a single host or dst net if a network.
  • Use CIDR notation when listing a network (that is, 10.10.10.0/24).
  • || becomes or
  • ! becomes not
  • Multiple rules must be joined with and.

The manual for TCPDump also gives examples of filters and strings that can be used:
http://www.tcpdump.org/tcpdump_man.html

Additionally, the following site provides an excellent reference for BPF-style packet filters:
http://biot.com/capstats/bpf.html

Caution: If you are capturing vlan tagged packets, above standard bpf filter may not work. For example, if you use not (udp port 123)to filter vlan tagged NTP traffic on udp port 123, it will not work. This is because the bpf filter machinery is simple and does not account for protocols not referenced in the rule. So the OS executing the bpf filter will look for the udp port values at the byte offset they would occur in a standard Ethernet/udp packet; but the optional vlan tag fields in the Ethernet header pushes those values by 4 bytes, thus the bpf filter rule will fail. To fix it, you need to change the bpf filter to: not (vlan and udp port 123).