Checking network ports

If there are any concerns about allowing the system to receive network traffic, such as having vulnerable services being automatically started by default, then fix those problems. For example, Microsoft Windows 2000 was widely noted for having lots of network services running, many of which were typically rather unnecessary. In contrast, OpenBSD runs very few services, and so it does not have a lot of services, running by default, that need to be disabled.


netstat -na | more

(Then press “ ” (the space bar) to move to through the screens.)

This will show quite a bit of information about network connections. First, let's look at some typical connections. In general, don't worry too much about the following:

Some remote access protocols

A TCP connection in the “state” of “LISTEN”, which is listening to traffic expected of an SSH server. This presumes that the SSH server is authorized, which is often the case on a brand new installation. Typically, a server listening on TCP port 22 is an SSH server that is using the well-known TCP port that is recognized by IANA.

Reason why it may be safe

SSH is typically set up to require authentication before allowing a remote user to do other interesting tasks.


Active connections with the foreign address specifying UDP port 123, which indicates that the local system is communicating with the Network Time Protocol

Reason why it may be safe

If a malicious server provides incorrect time, that could be a problem. However, that ought to be the maximum extent of how much damage a remote system can accomplish with NTP software.


An “Active Internet connection” showing a “Local Address” listening to UDP port number of 514, and a “Foreign Address” of “*.*”.

(Some systems might identify this as the “shell” protocol. Umm, that name seems less ideal/clear/informative. The protocol being used is the syslog protocol.)

Why it's safe

This means that the system is listening for syslog traffic, but nobody is reporting anything. The syslog protocol is generallly written by people who think about security, so that is not very likely to lead to a system vulnerability.

Loopback connections
any connection where the “Local Address” is referencing the loopback interface, and has a “Foreign Address” of “*.*”. For instance, if the “Local Address” starts with IPv4's “127” followed by a period, or IPv6's “::1”, possibly followed by a port number), then the system is only listening to local traffic. Also, if there is an address within the fe80::/10 address range, and if that address includes “%lo” as part of the address, then that address does seem to be using a loopback interface.
Reason why it may be safe
If the line represents a loopback interface being used, then that line does not represent the risk of the system listening to traffic from a remote system on a network. If a local user may be providing an attack, then this does represent a possible attack. However, if the local system is trusted, then this is not likely to be a source of an attack. Many times, IT departments can have a relatively easy time maintaining sufficient control over a particular computer; that can be much easier than maintaining control over a local network.

Note that these are general recommendations, and are not guaranteeing safety. Malicious software could be listening to a TCP port that is used by a commonly trusted protocol. However, if the system is still in a trustworthy state, the above guidelines are meant to help indicate whether the software listening to network traffic is likely to be an unnecessary and widely vulnerable service.

If there are other TCP connections that are in the “state” of being “ESTABLISHED”, or other TCP connections that are in the “state” of “LISTEN”ing for new TCP connections, or other UDP conversations, then it may be worthwhile to learn just what those protocols are. (The UDP conversations might be referred to as a “connection”, even though UDP is generally considered to be a “connectionless” protocol.) To learn more about a connection, consider reviewing: