000016485 - Berkeley Packet Filter (BPF) is not filtering the expected traffic on RSA NetWitness Platform decoders due to VLAN tagging

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support on Sep 26, 2019
Version 3Show Document
  • View in full screen mode

Article Content

Article Number000016485
Applies ToRSA Product Set: Security Analytics, NetWitness Logs & Network
RSA Version/Condition: 10.x, 11.x
Platform: CentOS
O/S Version: EL6, EL7
IssueBerkeley Packet Filter or BPF is not filtering the expected traffic on RSA Security Analytics or NetWitness decoders due to VLAN tagging.
A tcpdump or windump filter is not producing the expected output while testing a potential BPF.

BPF has been implemented in Decoder Configuration from ADMIN (for NW11) or Administration (for SA10)->Services-Config for the decoder->General but you're still seeing the sessions in RSA Security Analytics or NetWitness Investigation.
User-added image
 

CausePer System-level (BPF) packet filtering best practices and examples for RSA NetWitness decoders or the User Guide, BPF filters should be tested using tcpdump or windump prior to implementation to ensure they provide the expected behavior.  In certain instances and on some networks, you might encounter issues where the variables supplied to tcpdump are not presenting the expected output.  This might be due to instances where the network being sniffed is segmented into several VLAN's and the packets are being tagged with a VLAN ID. 

Using the below tcpdump variables, you would expect to see traffic to or from the host 10.20.10.12. 
When the packets being sniffed are tagged with VLAN ID's, the below tcpdump statement will yield ZERO results despite traffic originating from or destined to 10.20.10.12:

tcpdump host 10.20.10.12


Therefore, in an adverse query, you would expect to see no results containing 10.20.10.12 with the below tcpdump statement. 
As previously mentioned, if the packets being sniffed are tagged with VLAN ID's, the above statement will NOT filter out the traffic and you will see activity to and from 10.20.10.12


tcpdump not (host 10.20.10.12)

 
Resolution

In these instances, you should try combining the current tcpdump variables with the vlan variable to correctly identify this traffic. Modifying the above queries to the below syntax, tcpdump will filter the traffic and output the expected results:

tcpdump (vlan and host 10.20.10.12)
or
tcpdump not (vlan and host 10.20.10.12) 



For example, if you want to block 150.175.0.0/16 traffic which is VLAN 710 tagged, you can use the following bpf rule to achieve this:



!((vlan 710) && (src net 150.175.0.0/16 && dst net 150.175.0.0/16))




Please reference the aforementioned System-level (BPF) packet filtering best practices and examples for RSA NetWitness decoders or the User Guide when creating Berkeley Packet Filters. Should you have any questions or need additional assistance, please contact RSA Support and reference this article ID.

Legacy Article IDa58789

Attachments

    Outcomes