9

I scanned both localhost, and the IP address of the LAN adapter, and this is the produced output.

Starting Nmap 5.51 ( http://nmap.org ) at 2012-10-12 18:06 Eastern Daylight Time
Skipping SYN Stealth Scan against localhost (127.0.0.1) because Windows does not support scanning your own machine (localhost) this way.
Nmap scan report for localhost (127.0.0.1)
Host is up.
PORT      STATE   SERVICE
1/tcp     unknown tcpmux
3/tcp     unknown compressnet
4/tcp     unknown unknown
6/tcp     unknown unknown
7/tcp     unknown echo
9/tcp     unknown discard
13/tcp    unknown daytime
17/tcp    unknown qotd
19/tcp    unknown chargen
20/tcp    unknown ftp-data
-------redacted-for-posting-purposes-------
60020/tcp unknown unknown
60443/tcp unknown unknown
61532/tcp unknown unknown
61900/tcp unknown unknown
62078/tcp unknown iphone-sync
63331/tcp unknown unknown
64623/tcp unknown unknown
64680/tcp unknown unknown
65000/tcp unknown unknown
65129/tcp unknown unknown
65389/tcp unknown unknown

Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds

Unknown for all ports scanned. I then proceeded to scan "scanme.nmap.org", and had regular output as expected upon scanning that service.

Any suggestions?

Improve this question
9
  • 1
    Hmm.. you are comparing a scan of localhost to a scan of a remote Internet host on the other side of a few routers and firewalls so there are likely to be many differences in the output. How can you verify nmap's results?
    – adric
    Commented Oct 12, 2012 at 22:18
  • 2
    @adric I would think the most problematic scan between the two should be the Internet-based system. The confusing problem here is that the situation appears entirely reversed.
    – Iszi
    Commented Oct 12, 2012 at 22:51
  • 2
    Please list all switches you used for the scan. -sL will always result in 'unknown' for example ...
    – schroeder ♦
    Commented Oct 12, 2012 at 23:18
  • 1
    It is not advisable to use nmap on windows.
    – user10211
    Commented Oct 13, 2012 at 5:37
  • 2
    @TerryChia There is really no problem using Nmap on Windows. The only exceptions are scanning localhost (which isn't usually necessary anyway) and certain very large and fast scans that may run into resource caps. For 99% of uses, Nmap on Windows is fully supported.
    – bonsaiviking
    Commented Jul 12, 2013 at 13:41

4 Answers 4

Reset to default
7

The problem is with Windows and scanning the local machine. Nmap on Windows does not work the same way as it does on Linux due to differences in how the NIC is accessed. It is not actually connecting to each port from a separate process, but is connecting to itself. This is why the scan results in all ports being listed, and results in the connection to each port being omitted.

As a test, scan port 8 and 18 (omitted in the scan above). Assuming you originally did a default scan, those ports would not be tested. If you specifically test them, they should show up as 'unknown', too.

Improve this answer
4
  • I am curious how nmap is detecting services, if only by port association or actual profiling. Spoofers can emulate various services for example, darknet.org.uk/2018/04/…
    – Tyler
    Commented Feb 22, 2019 at 20:23
  • I never seen this before, now I have this same issue, though only on one Windows 10 machine. The Windows 10 Enterprise machine does not report any unknown ports, and only one open port. What could cause this discrepancy? I started noticing this shortly after being hacked; made me curious if some low level port spoofing is going on here, not much unlike we see here, for unknown reasons: calebcoffie.com/how-to-setup-portspoof
    – Tyler
    Commented Feb 22, 2019 at 20:30
  • 1
    @Tyler nmap documentation explains that it performs a "banner grab" to see what the service is
    – schroeder ♦
    Commented Feb 22, 2019 at 20:42
  • This can result when the npcap service & certain drivers fails to install, the npcap loopback interface then fails to install; see my answer below.
    – Tyler
    Commented Feb 22, 2019 at 23:20
1

This output is expected when scanning from Windows to localhost (127.0.0.1, ::1, or an IP address that belongs to the scanning system itself), but only for Nmap versions released prior to July 2016. Nmap 7.25BETA1 added Windows localhost scanning with the use of the new Npcap packet capture library, so this will not be an issue any more.

The technical reasons for this go way back to Windows XP. In versions of Windows prior to XP Service Pack 2, it was possible for programs to use raw sockets to send the custom probes Nmap uses for SYN scans and OS detection. But then Steve Gibson of GRC.com wrote a popular article claiming that raw sockets would be used to DDoS the entire Internet and should therefore be removed. This of course was incorrect, but in XP SP2, Microsoft removed most forms of raw sockets.

In response to this, Nmap moved to raw Ethernet frame sending via WinPcap (now Npcap), which ironically still allows all the same kind of traffic spoofing that Gibson was worried about. It's not perfect, though: it requires the packet filter driver to be running on the interface used to send the traffic, and it only works on link types that support/require an Ethernet frame header: Ethernet, 802.11 WiFi, etc. Other link types that won't work include PPP tunnels, VPNs, and of course loopback traffic. Loopback traffic isn't supported because it doesn't rise high enough in the OS's internal network stack to allow interception or injection by the WinPcap NDIS driver. Npcap overcomes this obstacle by creating a new loopback interface to force local traffic to go through the full stack where it can be observed and modified.

Improve this answer
0

Skipping SYN Stealth Scan against localhost (127.0.0.1) because Windows does not support scanning your own machine (localhost) this way.

That's the issue. Try another scan technique (other than SYN since we already know it doesn't work), for example, TCP Connect:

nmap -sT 127.0.0.1

You may also try testing with the rest of the techniques explained here: https://nmap.org/book/man-port-scanning-techniques.html

Improve this answer
1
  • Not entirely true; If npcaps loopback device installs properly, you can scan both 'localhost' and '127.0.0.1'. I have posted my tutorial on how to do that if you have the same issues as I did. Now I am able to successfully scan these, previously I got "unknown" on every port.
    – Tyler
    Commented Feb 22, 2019 at 23:46
0

Looks like I have figured out the culprit in my circumstance. This results when the npcap service & the npcap LWF driver fails to install, the npcap loopback interface then fails to install, resulting in problems such as this. My driver finally succeeded installing after temporarily disabling group policy Admin Templates\System\Device Installation\Device Installation Restrictions\Prevent Installation of devices using drivers that match these device setup classes\ (show) {D48179BE-EC20-11D1-B6B8-00C04FA372A7}

This class of driver was specifically blocked from installing, which is disabled as part of windows in built USB DMA attack protection for bitlocker, via Thunderbolt & SBP2 devices:

IEEE 1394 Devices That Support the SBP2 Protocol Class = SBP2 ClassGuid = {d48179be-ec20-11d1-b6b8-00c04fa372a7}

Strangely, even after re-enabling this policy, the installation problem doesn't seem to be persisting; Why? I don't know. This was the first time in months I was able to install Npcap. The only other policy and or setting I had changed was setting group policy enabled "Boot-Start Driver Initialization Policy" to "Good only". Meaning maybe some 'malware' or 'unsigned' driver was blocking the installation (however unlikely; I have performed thorough online and offline virus scans) and online I am only using Windows Defender and never changed my anti-virus settings when this install suceeded.

Anyway, now I am able to scan 127.0.0.1 successfully without any "unknown" ports appearing.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .