Skip to content
  • There are no suggestions because the search field is empty.

NetWitness vs Wireshark sessions

Issue

When viewing the same packet data in NetWitness Platform and Wireshark simultaneously, it may be noticed that NetWitness "sessions" do not match up to what is seen in the default view of Wireshark.  This behavioral difference may cause concern if an assumption is made that "sessions" is part of the protocol on the wire. Both NetWitness and Wireshark refer to the term session, but the term session has a different meaning to each tool.

To help understand the difference, its important to note that TCP as a protocol is connection oriented, not session oriented. NetWitness Platform makes use of sessions to chunk parsed BPF data into manageable portions.  This fundamental difference is explained further in the "Resolution" section of this article.

Resolution

IEEE  RFC's define a TCP connection as the corresponding IP addresses and port numbers at both ends of the connection. Connections can be established to the same ip and port, but the client that opens the connection randomly chooses a different dynamic port for each connection it makes. In the case of TCP, once a connection is made, the client on either side of a TCP connection must maintain a 32-bit sequence number to keep track of how much data has been transmitted. To do that, a sequence number is generated and placed on each transmitted packet.  These sequence numbers provide the means to track transmission success, or flag it with a reason code when the transmission is unsuccessful (tcp.flags.X).

Tools like Wireshark by default display  relative sequence and acknowledgement numbers in place of the actual values. In Wireshark, relative sequence numbers were created as a way to make tcp streams far easier to follow by the tool user.

However, it is important to note that these relative numbers are not what is actually generated on the wire. To see the difference, relative sequence numbers can turned off in Wireshark, and more information is provided on the Wireshark wiki here on the use of relative sequence and acknowledgement numbers here:
 
https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers
 
NetWitness Platform's use of sessions is quite different, and is described herein:
 
For UDP: packets from same source and destination IP/ UDP port pairs are assembled into a single NetWitness session until a preconfigured limit is reached. Those limits are such as timeouts, assembler.size.max, etc.
 
For TCP: source and destination IP/TCP port pairs plus TCP flags are used to assemble an NetWitness TCP session until a preconfigured limit is reached,  again, such as timeout, assembler.size.max, etc.
 
On an NetWitness Decoder, there are several parameters in /decoder/config that dictate what a NetWitness  session will be.
Here are some determining factors for NetWitness sessions on the Decoder, noting that changing these parameters should only be done after consulting NetWitness Support or Professional Services.
 
assembler.size.max: limits the size of the session assembled
 
assembler.timeout.session: specifies a time period to wait for the last packet in the session before the session is considered completed. Note this value it is used for all UDP and TCP traffic, and a decoder will never remove a TCP session when RST/FIN are encountered. The only thing that that will remove this is a network rule or BPF on the decoder itself to filter that traffic out. Based on these factors, if additional packets for the timed out session arrive later, a new session may be created if a threshold is reached.
 
assembler.timeout.packet: the amount of time allocated to time packets out of the packet pool and write packets to the database. This is important to understand when line rates are sufficiently low. In that instance, waiting for the packet pool to fill would introduce latency beyond the timeout duration, as when the packet pool is full, the oldest packets are removed when new packets are received. This assumes assembler.timespan is less then assembler.timeout.packet (more decoder settings)
 
Normal behavior on an NetWitness Decoder is for a session to be parsed after a timeout is either reached, or after it's forced out of the pool due to memory constraints. When a  NetWitness  session has not reached a configuration defined limit, active, packets will continue to be chained to the same session after parsing by default when assembler.session.flush is set to 1 (the default).

This fundamental difference explains why what is seen in Wireshark with relation to "sessions" differs from what is seen in NetWitness Platform.

Product Details

NetWitness Product Set: NetWitness Logs & Network
NetWitness Product/Service Type: Packet Decoder, Investigation
NetWitness Version/Condition: 11.x , 12.x
Platform: CentOS , AlmaLinux
 


Summary

This article describes the difference between NetWitness vs and Wireshark sessions.


Approval Reviewer Queue

Technical approval queue