Nmap Development mailing list archives
Re: decoys and limiting outbound RST packets
From: Martin Mačok <martin.macok () underground cz>
Date: Sun, 2 Jan 2005 13:59:34 +0100
On Sat, Jan 01, 2005 at 05:19:30PM -0500, Michael Rash wrote:
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.
This is intended feature - closing half-open connection reduces the load on a target system.
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.
True, but you should choose the decoys carefully anyway. Setting them to real/active/reachable IPs is more clever than to some random IPs.
the scanner may have fat-fingered a decoy IP on the Nmap command line, or the scanner might be working off old data, etc...
If you feed the nmap with wrong input it can't do much to save the situation generally.
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.
Easy to do without changing nmap, just make a wrapper similar to this: #!/bin/sh # usage: $0 [nmap options] <target> NMAP_OPTIONS="" TARGET="" while [ "$#" -gt 1 ] ; do NMAP_OPTIONS="$NMAP_OPTIONS $1" shift done TARGET="$1" if iptables -A OUTPUT -p tcp --tcp-flags RST RST -d "$TARGET" -j DROP ; then nmap $NMAP_OPTIONS "$TARGET" iptables -D OUTPUT -p tcp --tcp-flags RST RST -d "$TARGET" -j DROP fi
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.
You could block *all* traffic from the target (on a local firewall) because nmap will still see the packets through pcap_open_live(). It will just not be delivered to OS's TCP/IP stack so it will not respond to it (which should be even better than letting the OS to respond with RST and then dropping it).
This would make it impossible for the target to glean any useful information during a decoy scan from the scanner
Mmm... are you sure? Let's say that the target sees parallel probes to same ports from N different IPs (ie. decoy scan). It could divide the IPs into two groups and send the response(s) to single probe just to the first group and send nothing to the second. If retransmission occurs, the real IP is among the second group, otherwise it is in the first group. This way it could get the real IP with just after log(N) probes. The solution would be (a) using >>2^N decoys when scanning N ports or (b) no retransmissions during decoy scanning or (c) always retransmit when using decoys. (or (d) random retransmissions...) (b) or (c) should be easy to implement. My personal opinion is that it is not worth it because (1) decoy scans are not very widely used and so (2) I haven't seen any firewall/IDS/IPS that does something even close to detect/prevent decoy scanning and (3) there is idle scanning too.
This feature would only be enabled through an explicit command line argument, which would contain the firewall architecture (?).
IMHO, too much complicated. Carefully choose decoys and/or make a wrapper around nmap that set/unset the firewall. On Sun, Jan 02, 2005 at 10:31:05AM +0000, Slarty wrote:
However, as nmap now has the "idle scan", decoys aren't really necessary for people who want to hide their IP address while scanning, as the "idle scan" does not send any non-spoofed packets to the target anyway.
True, but with idle scanning, you can't make a difference between closed or filtered port.
Anyway, RST blocking is a useful feature on its own even without decoys and spoofing: - Reduces network traffic during big scans
I don't think so. It would cause the target to retransmit SYN+ACK for several times so it will actually generate more traffic. It could also DoS the target (SYN flood).
- Less likely to trigger IDS (if they have a rule which spots reset half-open connections)
AFAIK IDS usually detects spikes abnormal SYN traffic. Martin Mačok IT Security Consultant --------------------------------------------------------------------- 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)