|Applies To||RSA Product Set: NetWitness Logs and Packets (Security Analytics), NetWitness NextGen (Legacy)|
RSA Product/Service Type: NetWitness Investigation Module, Investigator Think Client
RSA Version/Condition: 9.x, 10.x, 11.x
Platform: CentOS, Windows (Thick Client)
|Issue||When investigating the meta for packet-based sessions in NetWitness, the source and destination IP addresses in the session appear to be reversed from what you would expect after having reviewed the raw packet data.|
So the meta appears to be the opposite of what you would expect.
Cause of the Behavior:
The short answer is that RSA NetWitness doesn't automatically assume that the first packet received represents the true start of the session. It is not uncommon due to data capture placement (i.e. the location in the network topology where the decoder data source such as a Tap is placed), that only one direction of traffic is seen. Due to this, it is not assumed that the first packet received is the client in a client-server network conversation. As a result, RSA NetWitness uses a voting algorithm to determine which IP is the source and which IP is the destination.
Option 1: Amending the Weights in the Voting Algorithm
In RSA NetWitness Packet Decoders, the traffic direction where packets are assigned is determined by the /decoder/config/assembler.voting.weights setting. The decoder evaluates multiple characteristics for each packet seen (and for the session as a whole) and adds to the score to each IP address in the network conversation. Each direction is referred to as a stream within the product. An assembled packet session either has one stream (for packets which only flow in a single direction) or two streams (bi-directional traffic).
The voting total can be positive or negative for either stream and the stream with the highest voting number is assigned the server role. In the case of a scoring tie, the score of the first packet is used by default.
Voting Process Overview
Warning: This change will affect ALL future sessions. Historical sessions will be unaffected.
Option 2: Use a Parser to Indicate the Traffic Flow Direction
Introduced in NetWitness 10.x, customers now have the option of deploying the Lua parser called traffic_flow. This is now an integral part of the RSA Hunting Pack - https://community.rsa.com/docs/DOC-92774
This represents a far more flexible approach to customizing which IPs are considered internal or external. Unlike Voting Weights, traffic_flow can on Log Decoders as well as Packet Decoders.
Rather than depending on which ip.src and ip.dest, it is now recommended that analysts refer to the traffic flow direction meta to determine if traffic is inbound [to be internal network], outbound [to external network] or lateral.
To generate traffic flow meta, the traffic_flow lua parser may need to acknowledge from RSA Live (if not provided by a content RPM).
To customize the IPs that are considered to be internal or external, customers can create/edit traffic_flow_options.lua (the template can now also be found in RSA Live as Traffic Flow Options).
Once deployed to a decoder, traffic_flow_options.lua can continue to be edited in the Files section of the Packet or Log Decoder service config in the NetWitness Web UI.
For consistency, many customers choose to edit the file on one Decoder and then push this file to the remaining Packet and Log Decoders.
Traffic Flow Product Documentation Reference - https://community.rsa.com/docs/DOC-44948
The above reference has some examples at the bottom of the expected form of entries in traffic_flow_options.lua.
|Legacy Article ID||a58684|