Re: decoys and limiting outbound RST packets

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

On Sun, Jan 02, 2005 at 05:49:00PM -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.

> Perhaps also an option to force Nmap to only send up to
> R retransmissions where R>=0 would be useful too.

I have implemented optional retransmission limit with R>=1 (see list
archives or wait for next nmap release). If you allow just one
retransmit, the algorithm above still works because (in most cases)
nmap sends one probe to a port that responds and two probes (== one
retransmit) to a port that does not respond.

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

Changing it to R=0 would need a small (?) tweak in "excessive drops ->
BoostScanDelay" mechanism which I may try to do in future if I have
enough free time.


On Sun, Jan 02, 2005 at 06:14:10PM -0500, Michael Rash wrote:

> > > 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.
> >
> > In this case, the target could send SYN+ACK probe to every
> > non-responding IP after the scan. If there is an IP that responds
> > then it is the IP of the scanner.
>
> That's true, but does this mean the RST blocking feature is not
> useful?

IMHO it is not useful because it would make detecting real IP even
easier.

Anyway, it is not guaranteed that the real IP of the scanner is among
the ones that are responding with RST packets to SYN+ACK replies. I've
come across many different firewalls that are blackholing *all* RST
packets (which is stupid IMHO - maybe it was meant as a reaction to
recent TCP RST/Window weakness? Or DDoS backscatter mitigation? silly
one...) and the scanner may be going through one of those.

> How many people are actually going to do this vs. just watch RST
> packets coming back (or lack thereof)?

The SYN+ACK probe from the target will even happen automagically
because of standard retransmissin mechanism (if syncookies on target
don't kick in). So if somebody is "just watching RST packets" then she
would see that one IP that was not sending RST packets during the scan
suddenly starts sending them right after the scan. This could be
mitigated by delaying the deletion of RST blocking firewall rule for
several minutes after the scan but clever target could also try to
send SYN+ACK probe to all non-responding sources from *different* IP
(!=target) during the scan and find out which one has the RST blocking
rule (the scanner).

> If a patch happens to appear that implements this, is there any
> reason that it shouldn't be accepted?

I'm not the maintainer so the decision will be on Fyodor. Personally,
I would not like nmap touching firewall rules at all ...

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