2

When I scan myself I will often see random open ports:

nmap -sT -T normal -p 1-65535 localhost

E.g.

43194/tcp open  unknown
58167/tcp open  unknown

Sometimes nothing, sometimes a couple like that.

I see however that this has been a false positive before, but it is now very old:

http://seclists.org/incidents/2002/Dec/136

There is some other user also reporting this more recently though:

https://bbs.archlinux.org/viewtopic.php?id=168197

But there doesn't seem to be that many who have noticed it. I also find it strange that this is still a "bug"/issue with the kernel. Has this problem really been the same for that long?

Can anyone else confirm that this is normal behaviour (the test must be executed several times to be conclusive, probably varying from system to system if this is indeed a kernel/nmap issue)? I've tested this on several physical machines now, and the result is the same. Including one machine which had its OS recently installed and has never been running a network facing service so a compromise seems very unlikely.

My ip_local_port_range is 32768 61000

Kernels tested: 3.16.3-smp, 3.17.8-gentoo-r1

Nmap versions: 6.4, 6.47

This also happens if I scan my IP, but from the same physical machine. If I scan the machine from a different machine, even with -T insane, I never see these ports open.

nobody
  • 19,814
  • 17
  • 56
  • 77
AttributedTensorField
  • 803
  • 1
  • 8
  • 15

1 Answers1

7

Yes, this is a known issue with Linux: a connection to localhost on a closed ephemeral port has a small chance (usually about 1 in 28000) of connecting to itself with a 4-way or "split" handshake. Nmap suffers the most from this bug, since it connects to so many different ports at once that the chances amount to a near-certainty of happening at least once in a localhost -sT (TCP Connect) scan.

Nmap has a long history with this bug. In 1999, Fyodor reported it to the LKML, but it was deemed to be an edge case in the RFC, and not a bug in the Linux kernel. A workaround was put in place in 2000, but it was removed in February 2013 as part of a cleanup effort, since it had a race condition. The next release was Nmap 6.40, which you say shows the invalid results.

Last summer, I introduced a change to check for and re-test these spurious results. The next release of Nmap will not have the same problem.

EDIT: The bug affected versions 6.40 - 6.47. It was fixed in 6.49BETA1 (2015-06-03).

bonsaiviking
  • 5,825
  • 1
  • 20
  • 35