|Applies To||RSA NetWitness NextGen|
RSA NetWitness Investigator
|Issue||Session 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.
|Cause||Cause 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:
Once the destination receives the "ACK" from the sender, the TCP session initiated by the source has been established between the source and destination.
|Resolution||In 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 ID||a58684|