The Danger of Decoy-Initiated SYN Floods
The decoy option (-D) should be used with caution! As mentioned on the nmap man page, it's possible to inadvertently SYN flood a destination station if a decoy IP address isn't actually on the network. This could disable a remote device and may require a restart of the remote device before it would be accessible again. The results of a SYN flood are usually unpredictable because of the differences in operating systems and TCP/IP stacks.

A SYN flood is created when a device has received an excessive number of SYN requests. This overwhelming number of SYN packets prevents the station from creating new TCP-based application connections.

During a normal TCP handshake, this transfer of packets occurs:


A TCP handshake using a spoofed address doesn't operate this way. A connection using a spoofed IP address never completes the TCP handshake. Although the first two frames of the "spoofed" handshake are identical, the second frame is correctly sent to the IP address of the "real" non-spoofed station. Because the real IP address receives an acknowledgement to a SYN that it never sent, it replies with a TCP reset frame. The destination station receives the RST, and releases the resources associated with this halfway-built TCP connection.


If the nmap source spoofs an IP address that isn't on the network, this half-built TCP connection never resets! The SYN/ACK replies are sent to an IP address that isn't on the network, so a RST is never sent back to the destination station. Nmap will continue to spoof packets to the destination station, and the resources available on the destination station will continue to decrease as it waits to complete the TCP handshake. If the destination station's resources are depleted, it will not create new TCP sessions for any nmap-related or legitimate network traffic.

This is one of the few instances where an untrained nmap user can really cause some havok on the network! Be careful when using decoys!