000026580 - System-level (BPF) packet filtering best practices and examples for RSA NetWitness decoders

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 5Show Document
  • View in full screen mode

Article Content

Article Number000026580
Applies ToRSA NetWitness NextGen
RSA NetWitness Decoder
RSA NetWitness Hybrid
RSA Security Analytics
RSA Security Analytics Decoder
RSA Security Analytics Hybrid
IssueSystem-level (BPF) packet filtering best practices and examples for RSA NetWitness decoders.
How to properly configure BPF packet filtering on Security Analytics decoder or hybrid appliances.


DECODER 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.  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. However, any packets discarded are not accounted for in any DECODER statistics (capture rate, packets dropped, and packets filtered and total packets).
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).


How to Add System-Level Packet Filters

Within NetWitness Administrator, connect to the DECODER where you want to implement system-level packet filters.  On the dashboard for the DECODER make sure you have clicked on "Stats" in the upper-right corner of the window.  Then click on the "Adapters and Rules" button.  In the "Capture Config" windows under the "Adapter" tab you'll see "Libpcap Filter".  In this field you can input one filter.  To filter multiple items you may join multiple expressions using "and".  Refer to the examples in the section that follows.

Once you are finished click "OK".  It will then be necessary to stop and start collection on the DECODER.  In the logs you will see an entry similar to this:

30927 2010-Oct-25 15:28:58 Decoder info Setting bpf filter: not (src net and dst net

NetWitness Administrator will validate input at the time you enter your filter string.  If it is incorrect, it will let you know with "Packet Filter is not Valid".




The following filter will drop packets to or from any address in the subnet:

not (net

The following filter will drop packets that have both source and destination addresses in the subnet:

not (src net and dst net


The following filter will drop packets that are from or are headed to

not (src host or dst host


The following filter combines both IP and HOST:

not (host and not (host api.wxbug.net)


The following filter will drop all port 53 traffic, both TCP & UDP:

not (port 53)


The following filter will drop only UDP port 53 traffic:

not (udp port 53)


The following filter will drop all IP protocol 50 (IPSEC) traffic:

not (ip proto 50)


The following filter will 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: 

not (port 53) and not (src host or dst host # drops any port 53(DNS) traffic sourced from or destined to

not (ip proto 50 or port 53) or not (src net and dst net # drops any traffic using IP proto 50 or port 53 or any traffic from net destined to net


Note: The usage of parenthesis can have a large and potentially disruptive effect on the use of Packet Filters.  As a best practice keep "not" operatiors 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.



BPF filters can and should be tested using either tcpdump or windump to ensure that they will provide the expected behavior before implementing them.

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



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

  • "||" or "or"

  • "&&" or "and"

  • "!" or "not"

  • "ip.addr" 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.  (i.e.

  • Multiple rules must be joined with "and"

The manual for TCPDump also gives examples of filters and strings that can be used.


Additionally, the following site provides and excellent reference for BPF-style packet filters.



If you are unsure of any of the steps above or experience any issues, contact RSA Support and quote this article ID for further assistance.


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)

Refer to KB article BPF is not filtering the expected traffic on RSA NetWitness decoders due to VLAN tagging for additional details.

Legacy Article IDa58702