Re: decoys and limiting outbound RST packets

[Michael Rash <mbr () cipherdyne org>]

On Jan 02, 2005, Martin Ma?ok wrote:

> 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.

Yes, but if decoys are used which filter SYN/ACKs from the target,
the SYN/ACKs will be retransmitted anyway, and we can't tell if
any of the decoys will actually filter.  The only guaranteed
reduction would just be from the connections associated from the
IP of the scanning 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.

Sure, but active/reachable from the perspective of the scanner
does not necessarily mean the same from the perspective of the
target.

> > 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.

Agreed.

> > 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

Yes, I mentioned that it could easily be scripted in my original
email.  One of the reasons I think the feature would be useful is
that not everyone is going to know exactly how to setup Netfilter
to properly block outbound RST packets to the target system.
Adding the --fw_netfilter_block_rst (or some such) option to Nmap
provides this directly so they don't have to know how to script
it manually.

> > 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).

Dropping all traffic from the target would break any existing
sessions that some other user on the scanning system might have
with the target.  Of course the target would know that the
scanning system is up if there is a legitimate session, but just
blocking outbound RST packets means that at least any existing
session would not be broken.  Blocking the RST frees the Nmap
user of having to check for an existing session.

> > 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.

But the target would have no idea if the real IP is blocking its
own outbound RST packets.  If not, the real IP is in the first
group above.  Adding the --fw_netfilter_block_rst option means
that the target would have even less confidence about whether
RST packets are being blocked, since then the scanner does not
have to go through the trouble of scripting it.

--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