000012891 - Session in RSA NetWitness Investigator appears to have source and destination addresses reversed

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

Article Content

Article Number000012891
Applies ToRSA NetWitness NextGen
RSA NetWitness Investigator
IssueSession in RSA NetWitness Investigator appears to have source and destination addresses reversed.
When reviewing session data in Investigator you may notice that the source and destination IP addresses in a session appear to be reversed from what you would expect based on having viewed the raw packet data beforehand.
For example:
  • You look at an individual IP packet using a packet analyzer like Wireshark.
  • You see that a local host is the destination and that a remote host is the source.
  • When you find the same packet in NetWitness Investigator is shows the local host as the source and the remote host as the destination.
  • 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.
Investigator would appear to be showing you the exact opposite of what your packet analyzer told you.
CauseCause of Behavior:
Packet analyzers like Wireshark and others look at individual packets and glean their meta information like source and destination from the IP packet headers of the individual packets.  In the example above the IP header contains both the source and destination IP addresses in their expected locations.  However, the source and destination information applies to that packet only.
 
NetWitness NextGen products provide you with greater visibility by analyzing the entire session, in this case TCP.  If "SYN" and "ACK" flags are set on the TCP header than this packet represents the second step in a three-way TCP handshake.  The three-way TCP handshake is described below.
 
The Three-Way TCP Handshake:
  1. Source sends packet with the "SYN" flag in TCP header to destination.  This is commonly referred to as a "SYN"
  2. Destination replies with the "SYN" and "ACK" flags set in the TCP header of the response.  This is commonly referred to as a "SYNACK"
  3. Source sends a final packet with the "ACK" flag set in the TCP header.  This is commonly referred to as an "ACK" or "acknowledgement"

Once the destination receives the "ACK" from the sender, the TCP session initiated by the source has been established between the source and destination.
 
Were we to look just at the second packet of this handshake we might wrongly assume 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 "SYN" request from the source host.
 
Since NetWitness products are designed to help you analyze entire sessions between hosts, this is the expected behavior of the system.  Fortunately NetWitness NextGen products provide you with a large number of ways to customize the system to allow you to present data in the way most meaningful to your organization.  Solutions on this portal, NetWitness Community and the NextGen Product Documentation are excellent sources on how to customize your installation.

ResolutionIn our decoders, which direction packets are assigned is completely determined by /decoder/config/assembler.voting.weights settings. Our decoder is evaluating multiple parameters and each parameter is assigned a weight that is than used as a score in voting system.
The voting total can be positive or negative for either stream and server would have the highest voting number. In a tie we just default to first packet as it is now.
Here is the overview of this voting process:
1) -1 vote if first packet of session assumption: client talks first
2) +1 vote if larger than other stream assumption: server usually provides more data
3) +1 vote if lower port than other stream assumption: server usually has lower port
4) +1 vote if routeable ip address assumption: server could be internet
5) +1 vote on lowest ip octect (192.168.1.2 & 10.10.10.3 would compare 2 to 3) assumption: organizations usually use lower octects for static ips/servers.
6) +10 votes if syn/ack,fin/ack,rst/ack assumption: definitive method with server only acking syn/fin/rst
7) -10 votes if syn,fin,rst (client) assumption: definitive method with client only requesting syn, fin, rst without acks
8) If only 1 packet session just use the src as CLIENT
So if desired, one can change decoder /decoder/config/assembler.voting.weights settings to get desired results. But this change will be global.
Legacy Article IDa58684

Attachments

    Outcomes