Re: Nmap Decoy Fingerprinting

[Fyodor <fyodor () nmap org>]

On Sat, Nov 25, 2017 at 6:59 PM, Who Am I? <wh0am1terminal () gmail com> wrote:

> Hey there.
>
> I was playing around with the decoy directive (the -D option) when I
> noticed something about the packets. When close to the end of the scan, the
> victim's IP address always sends multiple TCP packets with the RST and ACK
> flags set back to the real scanner's address.
> Basically, if someone were to scan me with Nmap and use decoy addresses,
> then I could conclude which address is the real address by looking at the
> packets sent back to me with the RST and ACK flags set.
> This observation, if implemented in a smart way, could nullify the purpose
> of using decoy packets.
> In fact, I made a simple proof-of-concept program
> <https://github.com/wh0am11/nmap_decoy_fingerprinting> that can
> demonstrate this. Basically, this program, when subjected to an Nmap scan
> with decoys in an isolated network, will determine which one is the real
> address. Further instructions are provided in the link above.

Hi S.  Thanks for the note.  The issue you describe is that, if you do an
Nmap SYN scan against a target, the target will send a SYN/ACK back from
each open port that you probe.  The TCP stack of the host doing the
scanning sees this SYN/ACK and doesn't know what it relates to (since Nmap
sent the raw packet rather than using the sockets API), and so the scanning
host sends a RST/ACK back to the target to say "I didn't expect this
packet".  It is true that this could allow someone running a packet sniffer
on the target network (or a program like you wrote) to determine the host
doing the scanning if that is the only host to send the reset packets.  But
from an Nmap user perspective, there are several ways to avoid this:

1) If the decoys are actually live hosts, they will generally send the
RST/ACK packets back too.  So this is mostly only an issue if you choose
dead/unresponsive decoys.  And in that case, the target could also use
other methods as well to determine which IP is live.  So it is usually best
to choose decoys which are actually live hosts.

2) It only takes a one line iptables or nft command on Linux to tell the
scanning host not to respond to the unexpected SYN/ACK packets.  An
attacker could even run this on their machines, and then choose decoys such
that only one of them is a live system which will respond with the
RST/ACKs.  And then your program would finger that decoy as the likely
scanning culprit.

For these reasons, you can't really say for sure that the responsive host
(sending the RST/ACKs) is for sure the scanning host.  Perhaps it is fair
to suspect that host, since a naive user might just pick random down IP
addresses as decoys and may leave their own scanning host acting as
default.  But at the end of the day, this is all under the control of the
person doing the scanning.

Still, it's great that you sent the note and created the tool since it
should help people better understand the concepts involved.

Cheers,
Fyodor

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/