Auditing Open Ports with Nessus®

Every major breach starts with a reconnaissance effort, which usually involves a port scan. It’s therefore safe to assume that port scans are the most likely precursor to an attack, and yet results from a port scan are rarely viewed with the same level of urgency as some other high profile vulnerabilities. It’s time to take a different approach and to have a policy-based approach for open ports.

The result from a port scan is just another result buried under a million other results

Port scanning, or rather the technology to scan open ports, has been around for a long time. And although the process to find open ports has evolved and become more sophisticated over time, the basic process to figure out whether a port is really open or not still remains the same. Nessus® covers different aspects of port scanning via TCP, SYN, UDP and netstat through its different port scanning plugins. You can read how these scanners work in-depth in a previous blog. All these plugins bring back information about open ports via different techniques. But if you are like any other security practitioner plugging holes by patching critical vulnerabilities such as Heartbleed or Shellshock, the result from a port scan is just another result buried under a million other results.

If you ask any reconnaissance expert, he or she will tell you that open ports are a dead giveaway. If port 80/443 is not open, hackers will likely not even bother launching web server related attacks. So then why do we keep seeing unnecessary ports open in scan results all the time?

One reason why port scan results do not show up at the top of remediation efforts is because the results almost never carry a flashing red severity. After all, having an open port isn't a vulnerability in itself. But it does open up the possibility for potential misuse in the future, if a new vulnerability is discovered in the service listening on that port at a later point in time. Also, just looking at the result of a port scan result makes it hard to gauge the context around it. For example, you might be surprised to find an odd port 8834 open on a host; but if that host is known to be a Nessus server, it makes complete sense.

One reason why port scan results do not show up at the top of remediation efforts is because the results almost never carry a flashing red severity

Most vendors, including Tenable, will rightly file port scan results under informational items, usually with a blue/green severity. An informational item is just a fact at a given point in time; without context, its value in making a judgment is negligible. It’s therefore easy to ignore such results. But once you add a policy around the same problem, it surely gets everyone's attention.

What if you could define a policy to not allow open ports other than ports 80 and 443 on a web server, or to deny port 23 (Telnet) to be open on any server? And any deviation from this policy would be considered a policy violation. That turns the tables on this issue. Suddenly closing down unused open ports becomes a priority.

The Nessus Unix compliance plugin was recently updated to support this feature across all major Unix/Linux operating systems. The plugin relies on the netstat port scanner for a list of open ports and then flags any open ports that deviate from the pre-defined policy. Support for a similar feature in the Windows compliance plugin is already available.

Example

<custom_item>
type : AUDIT_ALLOWED_OPEN_PORTS
description : "Allowed Open Ports : 22, 80, 443"
port_type : TCP
ports : "22,80,443,808[0-9]"
</custom_item>

<custom_item>
type : AUDIT_DENIED_OPEN_PORTS
description : "Denied Open Ports : 21, 23"
port_type : TCP
ports : "21,23"
</custom_item>

Now that we have taken care of the open ports policy, let’s assume you leveraged this feature and managed to maintain a very good handle on which ports are allowed to open and which ones are not. But then how do you know the service listening on an allowed port is indeed the service that was authorized? In other words, how can you be sure that the service listening on port 80 is an Apache server and not a nefarious backdoor or a rootkit hiding in plain sight? Well, we have just the solution for that: the Unix compliance plugin was also updated to audit the process running on a given port.

Example

<custom_item>
type : AUDIT_PROCESS_ON_PORT
description : "Only sshd should be running on port 22"
port_type : TCP
ports : "22"
name : "sshd"
</custom_item>

Of course, you can combine this with MD5 checks to make sure that the running process is authorized.

Sample Result

Conclusion

Having a good handle on what services are allowed on your network is one of the most prudent things to do to mitigate risks on your network

Having a good handle on what services are allowed on your network is one of the most prudent things to do to mitigate risks on your network. The Unix compliance plugin will help you close the gap between what you think is running and what actually is running. Initial scans with this feature might bring in some surprises. But over time, if you integrate this into your continuous monitoring approach, the risks to your network will be far less than if you don’t take any action against it.