Skip navigation

The Art of Interpreting Netstat

Reading Netstat's five-column output is something of an art. First, look at the Local Address column. The results that appear there will typically be 0.0.0.0 or 127.0.0.1, or will show the IP address of one of your physical network-interface connections (e.g., NIC, modem). If the application is bound to 0.0.0.0, the program is willing to accept connections coming from any interface. If the application is bound for a specific IP address, the program will accept connections to that port only from that local interface. The 127.0.0.1 address is the local loopback address, which means that the applications will accept connections originating from only the local computer. The 127.0.0.1 address is common for interprocess remote procedure call (RPC) communications and PDA connections. You can typically count on the safety of any 127.0.0.1 connections because malicious software (malware) would never open just a local connection to itself. Therefore, concentrate on the remaining connections.

Related: Using Private Ports and Netstat for Easy Remote Access

Next, most people look at the state. Any session in Listening mode shouldn't have a remote IP address attached with it; however, any session in Established mode (or other active state) should. Typically, the remote IP address will 127.0.0.1 or the address of some external computer. Again, you can ignore the 127.0.0.1 connections, but you should analyze active sessions to remote IP addresses. Are there any you didn’t expect? If so, tie the session to its process identifier (PID) and research the program. Take note of the remote destination port number to see if you can tie it to a well-known protocol (e.g., HTTP).

When you look for malware, the ports to concentrate on are unexplained Established connections to remote Internet addresses, unexplained TCP ports in Listening mode, and unexplained UDP ports. Many UDP ports have a twin entry in the TCP Listening mode because the application opening the port can use UDP or TCP, depending on the situation. If a UDP port doesn't have a matching TCP entry, research it. If a UDP port does have a matching TCP entry, you can concentrate on the TCP port for your research.

See also:  NETSTAT -an displays TCP and UDP when only UDP is bound to the socket

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish