Re: decoys and limiting outbound RST packets

[Martin Mačok <martin.macok () underground cz>]

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