I'm reading about nmap's SYN scan, and it says Nmap sends an RST immediately after the server tries to establish the handshake.

My question is - why bother with the RST? Is it to prevent the server from trying to reconnect on every checked port, and thus create unneeded incoming traffic to the scanning machine? Would that traffic slow the scan down immensely?

I would guess that that pattern of SYN, RST should be easy to "read" by IDSs, and I'm not sure why it is there in the first place. Why not register the response and keep going?

2 Answers 2


Leaving a connection in syn_rcvd state will raise flags as well as this is a common denial of service attack.

If you don't send a RST, the server will remain in a syn_rcv state for up to 60 seconds and retransmit the SYN ACK up to 5x. This will waste resources on the network you're scanning and cause a bunch of (depending on the speed and success of your scan) of retransmitted SYN ACKs being sent back to you.

The 60 second and 5 retries are linux defaults - these values will vary.


This is technically false: Nmap does not send a RST at any point in the half-open SYN scan. Instead, it relies on the scanning machine's OS to send RST packets in response to what the kernel views as unsolicited SYN-ACK packets. This is the same mechanism that is probed by Nmap's ACK scan (-sA) to map out firewall rules. Of course, this means that if your scanning system has a firewall, it's very likely that it drops unsolicited SYN-ACK packets instead of responding with RST, so you could potentially create a SYN flood condition. It's best to turn off such rules or to add an explicit rule to allow sending of RSTs in this case when performing large scans so that you don't burden your targets.

Regarding stealth, it's important to know your history. Nmap was released in 1997, predating BlackICE, Snort, and Bro (all created in 1998). At the time the "stealth SYN scan" was so named, an Intrusion Detection System was a program to check your logs for failed connection attempts. Since SYN scan never completes a TCP handshake, the application is never notified. The event dies in the kernel and there's nothing in the application log to indicate anything went wrong. These days, however, the situation is almost inverted; organizations are much more likely to have a network IDS/IPS than a properly configured SIEM/UTM/log analysis capability.

  • A properly configured firewall will not silently drop unsolicited SYN-ACK packets. If you receive an unexpected SYN-ACK from a legitimate server, chances are that you will be receiving more, unless you respond with a RST. Moreover sending the RST will reduce the risk of an attacker successfully spoofing your IP.
    – kasperd
    Jun 25, 2016 at 16:58
  • @kasperd All very good points. Unfortunately, lots of "security experts" who use Nmap also use iptables with very simple rulesets: drop everything, allow by exception, no special handling for out-of-order packets. Jun 26, 2016 at 12:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .