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.
You look at an individual IP packet using a packet analyzer like Wireshark.
You see that an internal host is the destination and that a remote host is the source.
When you are reviewing the meta in Investigation, it shows the internal host as ip.src and the remote host as ip.dest.
Looking closely at the packet in your packet analyzer, you notice that the "SYN" and "ACK" flags in the TCP header of the packet are set.
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.
Packet analyzers such as Wireshark often rely on information obtained from individual packets to generate metadata about the network traffic. An example would be using the IP packet headers of individual packets to determine the source and destination IP of the traffic of that packet only.
RSA NetWitness provides you with greater visibility than a single packet by analyzing the entire session, such as the TCP Flags.
As the RSA NetWitness product suite is designed to help you analyze entire sessions between hosts, this is the expected behavior of the system.
Example Scenario affecting the Voting Algorithm - TCP Flags
The Three-Way TCP Handshake:
Source sends packet with the "SYN" flag in TCP header to destination. This is commonly referred to as a "SYN" or Synchronize message;
Destination replies with the "SYN" and "ACK" flags set in the TCP header of the response. This is commonly referred to as a "SYN-ACK" or Synchronize-Acknowledgment message;
Source sends a final packet with the "ACK" flag set in the TCP header. This is commonly referred to as an "ACK" or "Acknowledgment" message.
At the end of the 3rd message, the TCP handshake is considered to be complete and the network session established.
From this, we may infer that if "SYN" and "ACK" flags are set in the TCP header then this packet represents the second step in a three-way TCP handshake.
Were we to just examine the second packet of this TCP handshake, we might incorrectly assume that the entire session was started by the destination host since it is the destination host's IP address that appears as the sender. Only by looking at the entire three-way handshake would we know that the second packet is merely an acknowledgment of the original synchronize request from the source host.
Note: The sessions that are most likely to be affected by the reversal are those that:
Only include one direction of traffic. This can be seen in the meta streams=1 which indicates a single direction of traffic.
Only have a single packet e.g. an ICMP datagram.
Have an undetected service protocol i.e. service=0 (OTHER).
Within the RSA NetWitness suite, users are provided with a large number of ways to customize the system to allow them to represent data in the most meaningful way to their organization.
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
-1 vote if first packet of session [assumption: client talks first]
+1 vote if larger than the other stream [assumption: server usually provides more data]
+1 vote if lower port than other stream [assumption: server usually has lower port]
+1 vote if routable IP address [assumption: server could be internet]
+1 vote on lowest IP octet (192.168.1.2 & 10.10.10.3 would compare 2 to 3) [assumption: organizations usually use lower octets for static IPs/servers]
+10 votes if SYN/ACK,FIN/ACK,RST/ACT [assumption: strongly associated with server role as it usually acknowledges only these TCP Flags]
-10 votes if SYN,FIN,RST [assumption: strongly associated with client role as it usually acknowledges only these TCP Flags]
If only 1 packet in session, then the source is assumed to be the client.
One may amend the following setting in Explore mode of the Decoder service - /decoder/config/assembler.voting.weights settings to change the calculated outcome.
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.