One of the checks done in a network scan by
Acunetix Vulnerability Scanner is a TCP and UDP port scan. Any open ports detected during the scan will be reported as shown in the screenshot.
In this particular scan, these ports have been detected as being open on the server: 80, 1027, 135, 1457, 3389, 139, 8443. These are all TCP ports, and UDP ports identified by the
Acunetix network scanner are reported separately.
Although you do require ports to be open for users to connect to your services, you should restrict open ports, and ports exposed on the Internet to these services only.
Open ports allow hackers to:
- Configure the service to distribute content: Unused services tend to be left with default configurations, which are not always secure or may be using default passwords.
- Exploit old versions of unused software: Unused services tend to be forgotten, which means that they not get updated. Old versions of software tend to be full of known vulnerabilities.
- Gain better information on your network: Some services give an attacker easy access to certain information, at the very least, they can have a very good guess on the operating system that the server is running, which is already a good head start.
So now that you are armed with the same information that an attacker would have when probing your server, you should do the following:
- Identify the ports that you want to have running on the server. For example, if you are running a web and an FTP server, you will need ports 80 for web, 20 and 21 for FTP.
- If the host being scanned is a firewall, you will need to review any port address translation rules configured in the firewall/router and consult your firewall documentation.
- Identify the processes listening on the ports that the Acunetix network scan has identified. You will need to close these or block them from being exposed on the Internet.
How to identify the processes that are keeping ports open
Windows OS
For Windows operating systems, you can use netstat, which is included with the OS.
- On the scanned server, open command prompt.
- Run the command: netstat -ano. This will list all the network connections on the machine. The last column shows the process ID of the process for the specific network connection.
- You will probably want to filter this down using the ‘find’ command.
For example, if you only want to list the network connections on port 3306, use:
netstat -ano | find “:3306”
This will list a network connection in LISTENING mode and the id of the process that opened the connection. Use “tasklist /SVC /FI “PID eq xxx” to show the name of the process and service for process id xxx.
For example, if you want to list the information about processed id 7424, use:
tasklist /SVC /FI “PID eq 7424
The screenshot below shows the information for the examples used.
Now that you have identified the process and service that is responding to requests on the specific port, you would need to confirm that the service is not required. You can then proceed to either configuring the application to stop listening or stop the service from Windows Services and marking the service as disabled.
If you are not a command line fan, you can download TCPView from
Sysinternals, which gives pretty much the same information as netstat.
Linux OS
Most Linux distributions include the netstat command, however, the switches are different than the one included in Windows. Proceed as follows:
- On the scanned server, open a terminal session.
- Run the command: netstat -tulpn. This will list all daemons (services) listening for both TCP and UDP network traffic on the machine. The last column shows the process id of the process for the specific network connection. If this information is not being displayed, it is most likely because the user you are using does not have sufficient privileges. You may need to use sudo to get access to this information.
- You will probably want to filter this down using the grep command.
For example, if you only want to list the network connections on port 3306, use:netstat -tulpn | grep ":3306"
The screenshot below shows the information for the examples used.
Now that you have identified the process and daemon (service) that is responding to requests on the specific port, you would need to confirm that the service is not required. You can then proceed to either configuring the application to stop listening or stop the daemon.
In order to stop daemons in Debian-flavoured Linux distributions (this would also apply for Ubuntu Server distributions) you can run the command shown in the example below where we are going to be stopping the MySQL daemon. However, you would obviously need to replace the daemon name with the name of the daemon you’d like to stop.
service mysqld stop
or
/etc/init.d/mysqld stop
In cases where programs you are trying to kill are not daemons, you may wish to stop them using pkill.
pkill - INT process-name
Naturally, similar syntaxes exist for other initscript standards used in distributions that are not based on Debian, therefore, it is advised that you consult your distribution’s documentation first.
Frequently asked questions
There are many tools that you can use to perform a port scan, which will give you a list of open ports. You can also use Acunetix Premium integrated with OpenVAS for that purpose. With Acunetix, you will receive a lot of additional security-related information.
If you only want to serve secure traffic via HTTPS and port 443, you should never close port 80. Instead, you should use HSTS – configure your web server to send a Strict-Transport-Security header so that the browser switches to a secure connection.
Open ports allow black-hat hackers to exploit misconfigurations such as default insecure configurations, take advantage of vulnerabilities in services, and learn more about your network. Every unnecessary open port increases the threat landscape.
You should block all the ports that are not used. You should also restrict Internet access to all ports that are used by internal services. Use a vulnerability scanner to establish priorities.
Network security is important but we believe that web security is much more important. Many network services are now run from the cloud and SMBs rarely have complex internal networks that need to be protected. On the other hand, more and more services are web-based. Therefore, we believe you should prioritize web security over network security.
Listen to Mark Ralls talk about the security challenges for SMBs.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
