At an MSSP, a capture shows a TCP SYN from port 51514 to port 22, and a junior analyst treats port 51514 as the service and the destination host as the client. What is the correction?
Select an answer to reveal the explanation.
Short Explanation
The person who placed the call is the client, and the extension they dialed is the service. You have a SYN from port 51514 to port 22, so the sender is the client and port 22 is the service. The trap is treating the high source port as the service, the server as the side that opened the SYN, or the MAC as the client.
Full Explanation
A TCP connection opens with a SYN from the client, then a SYN-ACK from the server, then an ACK. On this packet the SYN was sent from port 51514 to port 22, so the host that sent the SYN is the client and destination port 22 is the service being contacted. Port 22 is the SSH service port. The correction is this: The host that sent this SYN is the client, and destination port 22 is the service that host contacted. The reversed reading is this: Port 51514 is the listening service, and the host that received this SYN is the client. That swaps both sides, because 51514 is the source port on the opening SYN and the receiver of that SYN is the server. The handshake reading is this: The server opened this session by sending the SYN, so the source of the SYN is the service. The server answers an opening SYN with a SYN-ACK rather than starting this session with the SYN. The link-layer reading is this: The source MAC address is the client identity to rely on for this IP-layer investigation. A MAC address does not remain the client identity for an IP flow under investigation. On the exam, the destination port of the opening SYN is the service, and the source of that SYN is the client of this hop, even if a translator sits in front of the original host. In operations, confirm the flags are SYN without ACK and record source address plus destination port 22 before you name the client and the service.