decoys and limiting outbound RST packets

[Michael Rash <mbr () cipherdyne org>]

Hi -

This is a proposal for a new feature for Nmap.  This may have been
suggested before, but a quick check in the dev list archives did
not turn up anything obvious.

Problem:
    Nmap TCP scans that don't use TCP connect() and that generate a
SYN/ACK from a target system will generate a RST packet from the
local TCP stack on the scanning system since the SYN/ACK packets
are unsolicited.  When decoys are used, this can provide the target
with a means to determine the real scanning IP if the decoy IP
addresses are not "up".  Unfortunately, even if the scanner
determines that the decoy addresses are "up" (from the perspective
of the scanner's IP), this provides no guarantee that the decoy
addresses are up from the perspective of the target.  The SYN/ACK
packets may by dropped by a stateful packet filter, or the decoy
IPs may simply reject all network traffic from the target IP, or
the scanner may have fat-fingered a decoy IP on the Nmap command
line, or the scanner might be working off old data, etc...

Proposed solution:
    Provide an interface to use a local packet filter (if available)
to restrict outbound RST packets to the target for the duration of
any scan that causes unsolicited SYN/ACK packets to be sent to the
scanning system.  Blocking outbound RST packets instead of incoming
SYN/ACKs will allow any normal sessions to complete that are
initiated with the target system during the scan.  This would make
it impossible for the target to glean any useful information during
a decoy scan from the scanner, and would allow the scanner to not
have to worry about potential packet filters that might block
SYN/ACKs to the decoys.  This feature would only be enabled through
an explicit command line argument, which would contain the firewall
architecture (?).  E.g. on Linux-2.4 and above,
"--fw_netfilter_block_rst" or something, which would add the
following rule to the OUTPUT chain for the duration of the scan
(one rule for each target system and/or network):

iptables -I OUTPUT 1 -d <target> -p tcp --tcp-flags RST RST -j DROP

Of course, this could simply be scripted around Nmap, but why not
include it as a feature (which is disabled by default of course)?

Disadvantages:
    Will cause more SYN/ACKs to be generated by the target for open
ports since no RST would be seen.  Also, requires either using a
library to interact with the underlying firewall, or interacting
with the userland firewall program itself (I would personally vote
for the later and checking return codes since dependencies would
probably be minimized).  Others?

Would this feature be useful?  I will provide a patch in a few days
unless the idea gets shot down.

--Mike

Michael Rash
http://www.cipherdyne.org/
Key fingerprint = 53EA 13EA 472E 3771 894F  AC69 95D8 5D6B A742 839F

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List archive: http://seclists.org