Why is Nessus report HTTP running a web server on port 80 when I'm sure that it isn't?

Question

From a Nessus scan I have the following output regarding HTTP and the use of port 80:

Info        N/A         43111   HTTP Methods Allowed (per directory)
Info        N/A         24260   HyperText Transfer Protocol (HTTP) Information

Port 80 is disabled on the target and I'm certain HTTP is not running on another port and HTTP cannot be used to access the web page, only HTTPS.

My question is about why the Nessus results are it still saying that HTTP is accessible. Perhaps the web server is not configured correctly to disable HTTP, or it's just mentioning that a server is running and it could be HTTP or HTTPS?

Answer 1

TL;DR

Security scans often require human evaluation to rule out false positives and false negatives. You also have to read the actual definitions of your tool's results to understand what's being said, and to determine whether a given result is material or not, and if so what level of threat or vulnerability it represents (if any).

From what you posted, Nessus is simply reporting that something that looks like the HTTP protocol appears to be responding on that port, and suggesting that you look more closely at it. It may or may not be a web server, and may or may not represent an actual vulnerability.

Analysis and Recommendations

Specifically, Nessus Plugin Nessus Plugin ID 24260 says:

This test is informational only and does not denote any security problem.

While Nessus Plugin ID 43111 says:

Note that the plugin output is only informational and does not necessarily indicate the presence of any security vulnerabilities.

In both cases, these are either false positives or simply an indicator that you need to evaluate the system more closely to understand what's going on. The most likely scenarios (but certainly not the only ones) are that:

1. Something is listening on port 80, whether or not it's a web server.
2. Something is redirecting from port 80, e.g. a web server that redirects from port 80 to port 443.
3. You have a proxy, firewall, or other network control that is returning HTTP headers as a response.

Some of your follow-up actions should include:

1. Reviewing your web server configuration.
2. Checking the host directly (rather than remotely) using:

• ip, netstat, or lsof to find open ports;
• iptables, pf, or ufw firewall rules;
• any honeypots, tarpits, or similar utilities that may be running locally; or - using other utilities to see whether the port is truly open or not.

1. Taking a closer look at the source of the plugin (when available) to see how it's determining that this issue exists.
2. Looking at the network architecture to see if the problem lies elsewhere.
3. Assuming that the port or plugin is truly opening and providing valid results, determine whether or not this report item represents a material vulnerability. The plugins say they may not, so this may simply be informational, but there's insufficient data in your question to make that determination for you.