Why is the server returning 3 SYN + ACK packets during a SYN scan?

Question

When you do a SYN scan against a opened TCP port (not filtered by Firewall), the server normally returns 3 SYN + ACK packets.

So, why 3 of that?

The target server is a Linux machine if relevanted to this question, and the scanner in use is NMAP.

Answer 1

The normal TCP three-way handshake consists in a SYN from client to server, then a ACK+SYN from server to client, then an ACK from client to server. However, TCP has been designed to provide reliable data transport over a medium which is not reliable: stand-alone IP packets can get lost, damaged, duplicated, or transmitted out-of-order. That's why TCP is needed in the first place.

A server who has received a SYN responds with a ACK+SYN, and then expects an ACK as response. However, the server is well aware that packets can get lost, including its own ACK+SYN. So the server sends the ACK+SYN, then waits... and if it does not receive the final ACK from the client, the server assumes that its ACK+SYN might have been lost, so it emits it again. And again. Until the ACK from the client is received (which will not happen when the client is not a true client, but a port scanner which only sends SYN), or the server loses interest and gives up.

Each given operating system is responsible for deciding when, and how many times, a SYN or SYN+ACK or ACK will be repeated. On a Linux system, see the special files in /proc/sys/net/ipv4/ called tcp_syn_retries and tcp_synack_retries: they contain the number of times the kernel would emit SYN (respectively SYN+ACK) on a given connection attempt when being a client (respectively server). On a 3.2.0 kernel, I see that both files contain "5", meaning that a server subject to a port scan will emit five SYN+ACK packets. If you observe only three, then maybe your particular server was configured that way (this is as simple as echo 3 > tcp_synack_retries). Or maybe the server still uses the default value of 5, but your detection system was not patient enough: successive retransmissions use exponential delays, so the last retries can take a substantial number of seconds before being retransmitted.

Note that, to be able to retransmit SYN+ACK packets, the server must necessarily allocate a bit of RAM for that connection attempt, in order to remember this particular proto-client and retransmit the SYN+ACK. Abusing this allocation is the basis of the SYN flood attack. Lowering the maximum number of retransmission will make the server more robust against such attacks. In the extreme case, SYN cookies are a way for the server to not remember anything; as a consequence, when a server uses SYN cookies, it will respond with only a single SYN+ACK upon an incoming SYN. Since you observe that the particular server you are scanning sends the SYN+ACK several times, then you have demonstrated that this server does not employ SYN cookies, and is thus potentially vulnerable to SYN floods.