Nmap Development mailing list archives

Re: nmap -sT localhost showing ephemeral ports?


From: Fyodor <fyodor () nmap org>
Date: Wed, 12 Feb 2014 12:22:30 -0800



20:17:03    bonsaiviking $ <ketilmore6>  turns out the nmap -p 1-65000 was
finding open ports by accident because source port sometimes was equal to
destination port. (birthday paradox)
20:17:07    bonsaiviking $ wtf
20:18:58    bonsaiviking $ confirmed on svn r32703
20:19:31    bonsaiviking $ but only with -sT


Yeah, Linux has long had this "feature" (I consider it a bug) where if you
attempt a connect() to a closed port on localhost, sometimes the kernel
will by luck choose the source port of the connection you're trying to
establish to be the same as the destination and you end up effectively
connected to yourself.  Anything you type is echoed back to you.

I think this should be fixed in the kernel.  It is in charge of assigning
the source port and it should check and avoid assigning the port you're
trying to connect to.  After all, it can lead to real-world problems beyond
just port scanners like Nmap.  Suppose you have an application running on a
high port and you try to connect to it.  And suppose it has crashed or
wasn't started properly.  You should get a connection refused so you know
what is going on.  Instead the connection can sometimes succeed and get in
this bizarre self-connected state.

Anyway, while I think it should be fixed in the kernel, I don't foresee
that happening.  I reported it to the Linux kernel mailing list nearly 15
years ago and offered to submit a patch, but it was shot down by David
Miller who still seems to be pretty much in charge of Linux networking.
 Here's the thread:

https://lkml.org/lkml/1999/8/29/111

So we should probably just work around it ourselves.  The easiest way might
be to choose our own source port for each connection and bind() to it
rather than implicitly allow the kernel choose an ephemeral source port.
 We should probably only do this on Linux unless we find the problem on
other systems.  We might limit it to localhost connections too.  Of course
we'd need a loop so that if the bind fails (the port we choose might
already be in use) we can choose another one until we succeed.

You can intentionally create this sort of self-connection with Ncat by
specifying the same source and dest port:

$ ncat -v -p 31338 localhost 31338
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:31338.
Woo!  Self-connected
Woo!  Self-connected
^C


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


Current thread: