Netstat output explained | Linux

netstat command, a tool for tracking network connections (among other things) in your system. It is, without a doubt, one of the most useful debugging tools in your arsenal for troubleshooting security and day-to-day network problems.

Using the netstat Command To track what ports are open and what ports have processes listening to them, we use the netstat command. For example:

[root@serverA ~]# netstat -natu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:5335 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
tcp 0 132 192.168.1.4:22 192.168.1.33:2129 ESTABLISHED
udp 0 0 0.0.0.0:32768 0.0.0.0:*
tcp 0 0 ::ffff:192.168.1.4:22 ::ffff:192.168.1.90:40587 ESTABLISHED
udp 0 0 0.0.0.0:631 0.0.0.0:*

By default (with no parameters), netstat will provide all established connections for both network and domain sockets. That means we’ll see not only the connections that are actually working over the network, but also the interprocess communications (which, from a security monitoring standpoint, are not useful). So in the command just illustrated, we have asked netstat to show us all ports (-a)—whether they are listening or actually connected—for TCP (-t) and UDP (-u). We have told netstat not to spend any time resolving IP addresses to hostnames (-n).

In the netstat output, each line represents either a TCP or UDP network port, as indicated by the first column of the output. The Recv-Q (receive queue) column lists the number of bytes received by the kernel but not read by the process. Next, the Send-Q (send queue) column tells us the number of bytes sent to the other side of the connection but not acknowledged.

The fourth, fifth, and sixth columns are the most interesting in terms of system security. The Local Address column tells you your server’s IP address and port number. Remember that your server recognizes itself as 127.0.0.1 and 0.0.0.0, as well as its normal IP address. In the case of multiple interfaces, each port being listened to will show up on all interfaces and, thus, as separate IP addresses. The port number is separated from the IP address by a colon. In the output from the netstat example just shown, the Ethernet device has the IP address 192.168.1.4.

The fifth column, Foreign Address, identifies the other side of the connection. In the case of a port that is being listened to for new connections, the default value will be 0.0.0.0:*. This IP address means nothing, since we’re still waiting for a remote host to connect to us!

The sixth column tells us the state of the connection. The man page for netstat lists all of the states, but the two you’ll see most often are LISTEN and ESTABLISHED. The LISTEN state means there is a process on your server listening to the port and ready to accept new connections. The ESTABLISHED state means just that—a connection is established between a client and server.

Security Implications of netstat’s Output

By listing all of the available connections, you can get a snapshot of what the system is doing. You should be able to explain and account for all ports listed. If your system is listening to a port that you cannot explain, this should raise suspicions. Just in case you haven’t yet memorized all the well-known services and their associated port numbers (all 25 zillion of them!), you can look up the matching information you need in the /etc/services file. However, some services (most notably those that use the portmapper) don’t have set port numbers, but are valid services. To see which process is associated with a port, use the -p option with netstat. Be on the lookout for odd or unusual processes using the network. For example, if the Bourne Again Shell (BASH) shell is listening to a network port, you can be fairly certain that something odd is going on.

Finally, remember that you are mostly interested in the destination port of a connection; this tells you which service is being connected to and whether it is legitimate. The source address and source port are, of course, important, too—for cases where somebody or something has opened up an unauthorized back door into your system. Unfortunately, netstat doesn’t explicitly tell us who originated a connection, but we can usually figure it out if we give it a little thought. Of course, becoming familiar with the applications that you do run and their use of network ports is the best way to determine who originated a connection to where. In general, you’ll find that the rule of thumb is that the side whose port number is greater than 1024 is the side that originated the connection.

Obviously, this general rule doesn’t apply to services typically running on ports higher than 1024, such as X Window (port 6000).

In case of any ©Copyright or missing credits issue please check CopyRights page for faster resolutions.