Nmap Development mailing list archives
decoys and limiting outbound RST packets
From: Michael Rash <mbr () cipherdyne org>
Date: Sat, 1 Jan 2005 17:19:30 -0500
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
Current thread:
- decoys and limiting outbound RST packets Michael Rash (Jan 01)
- Re: decoys and limiting outbound RST packets Slarty (Jan 02)
- Re: decoys and limiting outbound RST packets Martin Mačok (Jan 02)
- Re: decoys and limiting outbound RST packets Michael Rash (Jan 02)
- Re: decoys and limiting outbound RST packets Martin Mačok (Jan 02)
- Re: decoys and limiting outbound RST packets Michael Rash (Jan 02)
- Re: decoys and limiting outbound RST packets Martin Mačok (Jan 03)
- Re: decoys and limiting outbound RST packets Martin Mačok (Jan 02)
- Re: decoys and limiting outbound RST packets Slarty (Jan 02)
- Re: decoys and limiting outbound RST packets Michael Rash (Jan 02)
- <Possible follow-ups>
- RE: decoys and limiting outbound RST packets robert (Jan 05)