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

[#1]

Article Number

000026580

Applies To

RSA NetWitness NextGen
RSA NetWitness Decoder
RSA NetWitness Hybrid
RSA Security Analytics
RSA Security Analytics Decoder
RSA Security Analytics Hybrid

Issue

System-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.

Resolution

Introduction

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 10.21.0.0/16 and dst net 10.21.0.0/16)

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".

Examples

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

not (net 10.21.0.0/16)

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

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

The following filter combines both IP and HOST:

not (host 192.168.1.10) 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 10.21.1.2 or dst host 10.21.1.3) # drops any port 53(DNS) traffic sourced from 10.21.1.2 or destined to 10.21.1.3.

not (ip proto 50 or port 53) or not (src net 10.21.0.0/16 and dst net 10.21.0.0/16) # drops 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

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.

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.

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 "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. 10.10.10.0/24)
• 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 and excellent reference for BPF-style packet filters.

 http://biot.com/capstats/bpf.html

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.

Notes

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.