Auditing Open Ports on Windows Systems Using Nessus

Tenable recently released three new checks used for auditing the configurations of Windows systems. The new configuration auditing options allow users to audit open ports. This post provides details about the three new checks, and describes how Nessus users could use them to maintain tight control over the number of open ports on their Windows systems.

1. AUDIT_ALLOWED_OPEN_PORTS

This check allows users to audit the list of open ports against an "allowed" list of ports that can be open on a target. For example, let’s assume there is a company policy to only allow SMB ports 445 and 139 to be open on a target. The resulting configuration audit would look as follows:

&ltcustom_item&gt

type        : AUDIT_ALLOWED_OPEN_PORTS

description : "Audit TCP Open Ports"

value_type  : POLICY_PORTS

value_data  : "445,139"

port_type   : TCP

&lt/custom_item&gt

The allowed ports should be specified as 'value_data,' and 'value_data' can be an empty string, a single port, or multiple ports separated by a comma. Users can also specify which protocol they want to audit (TCP or UDP). Another interesting feature of this check is the ability to specify a regex in the allowed ports’ ‘value_data’ field:

&ltcustom_item&gt
type        : AUDIT_ALLOWED_OPEN_PORTS
description : "Audit TCP Open Ports"
value_type  : POLICY_PORTS
value_data  : "80,800[0-9]+"
port_type   : TCP
&lt/custom_item&gt

This is useful to audit applications using a range of ports. The example above would check for TCP ports 80 and 8001-8009. Below is a sample result for this check:

2. AUDIT_DENIED_OPEN_PORTS

Instead of checking against an "allowed" list of ports, "AUDIT_DENIED_OPEN_PORTS" checks whether there are any ports that should not be open. For example, if the organizational security policy dictates that Telnet and FTP ports should not be open, the check would look as follows:

&ltcustom_item&gt

type        : AUDIT_DENIED_OPEN_PORTS

description : "Audit Denied TCP Open Ports"

value_type  : POLICY_PORTS

value_data  : "21,23"

port_type   : TCP

&lt/custom_item&gt

Denied ports must be specified as 'value_data,' and 'value_data' can also be an empty string, a single port, or multiple ports separated by a comma and/or use a regex. Below is a sample result for this check:

The two checks above rely on output of 'netstat -ano' or 'netstat -an' (depending on which one is available) to extract the list of open ports.

3. AUDIT_PROCESS_ON_PORT

With the checks we've described so far, you can audit which ports you want to see open and which ones should be closed. However, how do you know what services are running on open ports? For example, if port 80 is an authorized open port on target A, and it’s expected to run IIS server, how do you check to see that IIS is really the service listening on that port? An example of the new AUDIT_PROCESS_ON_PORT is below:

&ltcustom_item&gt
type        : AUDIT_PROCESS_ON_PORT
description : "Audit Process On Port 80"
value_type  : POLICY_TEXT
value_data  : "System" || "foo.exe"
port_type   : TCP
port_no     : "80"
port_option : CAN_BE_CLOSED
&lt/custom_item&gt

The allowed process name should be specified in ‘value_data,’ and multiple processes can be separated by the OR (||) operator. The check also supports the tag ‘port_option,’ which is useful during a scan when it is not certain whether the audited port is going to be open. If ‘port_option’ is not specified, and the port is closed on the target, then the check results in a ‘PID_ON_PORT_FAILURE’ error. The check also supports ‘check_type’, so users can use a ‘check_type’ such as ‘CHECK_NOT_EQUAL’ or ‘CHECK_REGEX’ (and more). Below is an example:

&ltcustom_item&gt
type        : AUDIT_PROCESS_ON_PORT
description : "Process on Port 80 should not be a System Process"
value_type  : POLICY_TEXT
value_data  : "System"
port_type   : TCP
port_no     : "80"
port_option : CAN_BE_CLOSED
check_type :  CHECK_NOT_EQUAL
&lt/custom_item&gt

The example below will check port 5900 and make sure the process listening on that port begins with "foo.":

&ltcustom_item&gt
type        : AUDIT_PROCESS_ON_PORT
description : "Process on Port 5900 can be foo.+"
value_type  : POLICY_TEXT
value_data  : "foo.+"
port_type   : TCP
port_no     : "5900"
port_option : CAN_BE_CLOSED
check_type :  CHECK_REGEX
&lt/custom_item&gt

Below is the sample result for this check:

The auditing of open ports and processes relies on the output of 'netstat -ano' to extract the process ID (PID) associated with the open port, and then uses 'tasklist /svc' to determine the process associated with that PID.

Note: These three new configuration audit checks are available in Windows compliance check v2.0.40 and above.

Tying It All Together with SecurityCenter

This dashboard combines asset filtering and a port summary to display all open ports found by Nessus active scans and the Passive Vulnerability Scanner (PVS) network monitoring. 

It is important to choose your assets and repositories carefully such that only open port data for Internet-facing devices are displayed.  For example, if you had a repository and performed a credentialed netstat port scan, it may report that a certain service was running on an open port. However, a firewall may be blocking that port from the Internet. 

This dashboard can use any vulnerability data. It could be customized to reflect only Nessus scans, PVS sniffs, and other types of combinations. 

Conclusion

Nessus and SecurityCenter provide you with several different ways in which to identify open ports and "exposed" services in your environment. This is a constantly changing variable, new ports and services can be opened as quickly as they are closed, underscoring the importance of continuous monitoring.