Nmap Port Issue – Open HTTP-Proxy on 8080 but None Running

nmapport

While executing the following command from my Mac OSX: 

 nmap -PN  server.com

It reports the following: 

Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-18 16:14 EDT
Nmap scan report for server.com (9.9.9.9)
Host is up (0.020s latency).
Not shown: 997 filtered ports

PORT     STATE SERVICE
80/tcp   open  http
443/tcp  open  https
8080/tcp open  http-proxy

The http and https are fine, but I'm befuddled by the http-proxy. We have nothing running on port 8080 on this server: 

# sudo ss -lnp | grep :8080
#

And netstat output: 

# netstat -tnlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      12378/mysqld        
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2441/nginx: master  
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      2441/nginx: master  
tcp6       0      0 :::80                   :::*                    LISTEN      2441/nginx: master  
tcp6       0      0 :::443                  :::*                    LISTEN      2441/nginx: master

This is an Nginx server with no proxying back to anything else, it's just Nginx. What can we do to "close" this non-open port. Is this a bug with Nmap or am I misunderstanding something?

Best Answer

Nmap reports an open TCP port when it receives a SYN/ACK response to a SYN probe on that port, or (in TCP Connect mode, -sT) when a TCP connection to the port is successful. There are several cases where the output of netstat/ss and Nmap may differ:

  1. Something is intercepting traffic to a port and spoofing replies from the intended target. Residential ISPs do this for ports 25, 137, 139, and 445 to avoid worms and spam. Transparent proxies do this for 80 and 443 to intercept web traffic. You can sometimes detect this with Nmap by using the --reason option and looking for differences in the TTL of response packets from known-good ports versus the questionable ones. You could also compare the responses in a packet capture, since other parts of the reply could be different (TCP options, primarily).
  2. The port is being forwarded to a different port on the same system by the firewall. You will not be able to tell from the outside that this is happening, but you could inspect the firewall settings to detect it.
  3. The port is being forwarded to a different system, e.g. as port forwarding on a NAT device. In most cases, the --reason option and other comparisons suggested above will work to detect this. Another approach is to use the qscan NSE script to compare timing of replies to determine if some ports experience a delay due to the additional routing. This can also detect interference like in number 1.
  4. Something on the target is responding as though port 8080 is open, without using the OS to manage the connection. This could be a user-space TCP stack like masscan uses, which uses packet capture to inspect inbound traffic and raw sockets to generate replies.
  5. Something in the OS is preventing ordinary tools from displaying the open port. Commonly referred to as a "rootkit," this is a capability of various remote-access malware designed to hide an infection. The netstat and ss binaries may have been overwritten, or a kernel module may be intercepting the system calls and filtering the return values to hide the port. It would be very unusual to find this on a common port like 8080. Nmap is often used to detect this kind of interference since it reports the actual behavior of the target instead of the internal accounting that the rootkit is falsifying. You have to make sure nothing else is interfering with the scan, though.
Related Topic