S09 - Practical TCP Analysis

  1. The TCP Handshake Intro
    1. Stateful protocol
      1. Maintains the State of the connection
        1. e.g., this connection is open and available to transmit data, or it's closed and it is not available for transmission
    2. Three packets
      1. SYN: Client > Server
        1. Picks a random port number
        2. Identifies the service client wants to talk to
      2. SYN-ACK: Server > Client
        1. Acknowledgement of the SYN request
      3. ACK: Client > Server
        1. Acknowledgement of the SYN-ACK
  2. TCP Section Analysis
    1. First: Packet transmission time delta (not in section)
      1. If there is a significant delta between SYN and SYN-ACK packets, you're closer to the client
      2. If there is an insignificant delta between SYN and SYN-ACK packets, you're closer to the server
        1. The delay would be between the SYN-ACK and ACK
    2. Source/Destination ports
    3. Stream Index
      1. Identifies the conversation stream
      2. Helpful if multiple TCP conversations going on at once
    4. Conversation Completeness
      1. Tracks which handshakes the conversation has received (SYN, SYN-ACK, FIN, etc.)
      2. A "complete" conversation has everything
    5. Segment length
      1. How much data is encapped in the packet
    6. Sequence/Acknowledgement numbers
      1. First number is the ISN (Initial Sequence Number)
        1. Usually totally random and very large
        2. Wireshark converts the raw ISN to be a relative ISN
          1. e.g., 234908572139847589234 = 1
      2. The Sequence number is the one generated by the sender
      3. The Acknowledgement number is the sequence number the sender predicts it will receive in the host's next packet
        1. The next bit is called a ghost bit
        2. Subsequent numbers are based off the TCP Segment Length
          1. S9 - Practical TCP Analysis-1.png
          2. Confirms receipt of all sent bytes
          3. S9 - Practical TCP Analysis-2.png
    7. Flags
      1. The first 4 flags (Reserved, Accurate ECN/Nonce, Congestion Window Reduced, ECN-Echo, and Urgent) are not often used
      2. The last 5 flags (Acknowledgement, Push, Reset, Syn, and Fin) are frequently used
        1. Ack: Once established, basically every packet will have an ACK flag
        2. Push: Sending data that should should be processed quickly
          1. It's the end of a block, should be sent out the door quickly, etc.
        3. Reset/Fin: Used to close a conversation
        4. Syn: Used to initiate a conversation (SYN, SYN/ACK)
    8. Window Size
      1. The amount of data that can be received at once
      2. Think of it like a receive buffer
        1. If the other host sends more data than the other can receive, it will cause congestion and issues
      3. 2 byte value
        1. Absolutely highest value is 65535 bytes
        2. Not ideal for modern networks
        3. TCP Options attempts to fix this
    9. TCP Options are exchanged in the SYN packets
      1. Maximum Segment Size (MSS): An advertised value in bytes
        1. Not negotiated, just an advertisement
      2. Windows scale: Allows sender the multiple the Window Size value by a certain amount
        1. Can increase window size up to 1 gigabyte
      3. SACK (Selective Acknowledgement): Allows acknowledgement of non-contiguous datablocks
        1. Both sides must support
  3. Analyzing TCP Packets
    1. Convenient Columns
      1. TCP Segment length
      2. Relative Sequence Number
      3. Ack number
    2. S9 - Practical TCP Analysis-2.png
      1. Since the client acknowledgement doesn't include new data, its Seq number doesn't change
  4. Dropped TCP Packets
    1. tcp.analysis.flags are Wireshark analysis flags saying that something is missing
    2. Big chunk of missing packets
      1. S9 - Practical TCP Analysis-3.png
      2. Missing data between 1095618 and 1047438
        1. There are 48,180 missing bytes; divide by maximum segment size (1460) to get 33 packets (32 missing packets and the last received packet)
      3. Client sends a block of Dup ACKs, which tells the sender which packets it needs to retransmit
        1. A Duplicate Acknowledgement number goes out to last-good packet before missing chunk
        2. In TCP Options, under Selective ACK (SACK), the missing data
          1. Provides the left edge (first missing packets) and right edge (first packet received after missing packets)
      4. When looking for the retransmission, check the "Next Sequence Number" or add the TCP Length to the last good Seq number
        1. S9 - Practical TCP Analysis-4.png
      5. Sometimes Wireshark tracks retransmissions as "Out-of-order"
    3. When you see a lot of packets missing in a row, it can imply a router buffer issue
      1. When it's spottier, it can be a link-layer issue
  5. Closing TCP Connections
    1. Two ways to shut down
      1. Fin: A clean shutdown
      2. Reset: An abortive release
        1. Common during scans to send a reset to connection requests on ports you're not listening on
          1. When scan requests hit open ports, you'll often see SYN, SYN-ACK, ACK, RST
          2. For scans that hit closed ports, you'll often see SYN, then RST immediately from the target host
        2. If the scan is blocked by a firewall, there won't be any response
    2. If a packet crashes, nothing happens, sessions end unexpected, etc., it can indicate a reset
      1. Not necessarily bad on their own, but if there are a lot of them, or people are complaining about disconnected sessions, can indicate a problem
  6. Activity
    1. What is the network round-trip time between client and server (just milliseconds is fine)?
      1. 97 Milliseconds
    2. The client sends a request to the server in packet 4 and 5. Did the server receive these packets? What is the relative ACK number that it returns in the next packet?
      1. Yes, the ACK number is 1496
    3. What happens next? Who sends the keep alive? Client or Server?
      4. The SEQ number doesn't match (it's one short than it is predicted to be), and client sends the TCP Keep-Alive
      1. The client backs up 1 byte, and sends 1 byte of data
    4. How long does it take to send this packet (in full seconds)?
      1. 45 seconds
    5. Does the server TCP stack respond? Y/N
      1. Yes
    6. How long before another keep-alive is sent (in full seconds)?
      1. 45 seconds
    7. Has the application responded yet at this point? Y/N
      1. No
    8. At last, how long does it take the application to respond to the request? What is the application response time in full seconds?
      1. Another 18 seconds, for a total of 108 seconds
    9. Is this problem due to the client, network, or server?
      1. Server; Client has sent a request, the server received it, and Client/Server appear to be communicating fine otherwise along the network, but the service is taking forever to respond.