Re: decoys and limiting outbound RST packets

[Michael Rash <mbr () cipherdyne org>]

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

> On Sun, Jan 02, 2005 at 11:18:15AM -0500, Michael Rash wrote:
>
> > > 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 in 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.
>
> Not true. The algorithm above does not depend on RST packets. It
> depends on scanner retransmitting the probe when it gets no answer.

Ah, yes, I see where you're going now.  This algorithm would work,
but the target could only implement this on ports that are not
already running servers (unless the availability of existing
servers is something the target cares nothing about :).  I stand
corrected in that this would be a strategy to eventually discover
the real IP, but the number of systems that would go to this length
vs. those that would just look at RST packets would seem to
indicate that the --fw_netfilter_block_rst option might still be
useful.  Perhaps also an option to force Nmap to only send up to
R retransmissions where R>=0 would be useful too.  In some cases
users might want to sacrifice some accuracy if it at the same time
it meant that Nmap would generate less traffic.  Then detecting
decoys becomes hard again for R=0.

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