Network ports provide crucial information about the applications that access computers on your network. Through an understanding of the applications that use your network and the corresponding network ports they use, you can create pinpoint firewall rules and lock down host computers so that they respond only to legitimate traffic. After you profile your network and put tools in place to distinguish network traffic, you'll be better equipped to spot attackers--possibly based on merely the network traffic they generate. I began this discussion in "Network Port Fundamentals, Part 1," July 2005, InstantDoc ID 46589, providing a TCP/IP port primer as a foundation for network security. In Part 2, I look at some network- and host-based methods you can use to determine which applications are listening on your network. Later in the article, I look at how to assess the actual traffic crossing your network.
Disabling Network Applications
Network attack surface is a general term that describes the susceptibility of your network to an attack. Because many attacks stem from the exploitation of a vulnerable application over the network, you can dramatically lower your network attack surface by reducing the number of applications listening on your network. In other words, turn off unused services, consider installing host-based firewalls that verify legitimate traffic, and deploy a robust access control list (ACL) on your perimeter firewall.
Each open network port represents an application that's listening on your network. For each of your servers connected to your network, you can reduce the attack surface by disabling all non-essential network-enabled services and applications. Windows Server 2003 improves on previous versions of Windows by enabling fewer network services out of the box. However, you'll still want to audit your systems to look for newly installed applications or configuration changes that might have opened unneeded network ports.
Each open port is a potential entry point for intruders, who might exploit a vulnerability
in the host application or surreptitiously access the application by using another user's username and password (or other legitimate authentication method). Either way, an important first step toward securing your network is to simply disable unused network applications.
Port Scanning
Port scanning is the process of actively querying the network ports of a computer or other network device to determine which applications are listening. Learning to discern the results of a port scan and comparing those network-based reports with a host-based port interrogation helps paint a good picture of the traffic crossing your network. Understanding your environment's network topology is important so that you can strategically scan specific areas. For example, scanning your external IP address range provides you with data available to any Internet attacker, so scan your network frequently and close all non-essential network ports you find.
Port scanning your firewall from the outside will also show you any mapped services (e.g., Web, mail) that might reside on internal servers. Don't forget to lock down those servers as well. Configure your favorite port scanner (e.g., Network Mapper--Nmap) to scan the range of UDP or TCP ports you're interested in. Generally, port scanning the TCP protocols is more reliable than port scanning UDP protocols because the connection-oriented nature of TCP provides more feedback when probed. Nmap is available in both Windows and UNIX versions. Running the program for a basic scan is easy, although the program supports much more complicated features as well. (For an in-depth review of Nmap's features, see "Nmap Your Network," February 2002, InstantDoc ID 23655.) To scan my computer for open TCP ports, I ran the command
nmap 192.168.0.161
Figure 1 shows the results of the scan--in this case, an out-of-the-box Windows 2003 computer. This port-scan data shows that there are six open TCP ports:
Port 3389 is used for Remote Desktop, which isn't enabled out of the box but is enabled on my test computer. To close this port, navigate to the System Properties dialog box's Remote tab and clear the Allow users to connect remotely to this computer check box.
Don't forget to scan for open UDP ports and close those that are unnecessary. Using a port scanner in this way tells you which ports are open on your computer and exposed on your network. You can use host-based tools to accomplish a similar review.
Host Scanning
In addition to using a network-based port scanner, you can determine the open ports on a host by issuing the following command (on the host):
netstat -an
This command works with both Windows and UNIX. The Netstat output lists the computer's actively listening ports. On Windows 2003 and Windows XP, you can add the -o parameter to list the corresponding program identifier (PID). Figure 2 shows the Netstat output for the same computer I port scanned earlier. Notice that I've closed some previously open ports.
Firewall Log Auditing
Another useful method for discovering the network applications entering and leaving your network is to increase the logging on your firewall and review this data. Looking at the Deny entries in your firewall logs on the external firewall interface probably won't show much useful information because there's a lot of "noisy
traffic" (e.g., worms, scanners, ping probes) that pollutes the Internet. But if you log allowed packets at your internal interface, you'll be able to see all the network traffic entering and leaving your network.
To view the raw data of traffic using your network, you can install a network sniffer, a tool that plugs into your network and records all network packets it sees. The most popular free network sniffer is the UNIX tool Tcpdump (also available for Windows as Windump), which installs easily on a computer on your network. After you install the software, configure it in promiscuous mode so that it records all traffic, then connect it to a port monitor on your network switch to watch all the traffic transiting your network. (We'll look at how to configure a port monitor in a moment.) Tcpdump is an extremely flexible program that lets you display network traffic based on custom filters and customize the results so that they show only IP and port information or entire packets. Reviewing network dumps in large networks can be overwhelming without the proper filters--but be careful that you don't filter out important data.
Putting It All Together
So far, I've touched on the different methods and tools you can use to discover the applications using your network. Now, let's put it all together and see how to use these tools and methods to determine what network ports are open on your network. You might be surprised how network-chatty the computers on your network really are!
First, I recommend checking out the Microsoft white paper "Service overview and network port requirements for the Windows Server system" (http://support.microsoft.com/defaul.aspx?scid=kb;en-us;832017), which lists the protocols (TCP or UDP) and port numbers used by most of the Windows Server system core services and applications. It also describes these services and the associated network ports they use. Download and print this reference: You'll find that it comes in handy for Windows networking.
Network Sniffer Setup
Earlier, I mentioned that one way to determine which ports applications are using on your network is to use a network sniffer to watch the traffic passing between your computers. To see all this traffic, you need to connect your network sniffer to either a hub or a port monitor on a switch. You can use a hub because every hub port sees all traffic for any computer connected to the hub. However, hubs are older technology, and most companies have migrated to switches, which are good for performance but bad for sniffing: Each switch port receives only traffic destined to the one computer plugged into that port. To sniff the entire network, you want to tap into the traffic destined for every switch port.
To do so, configure a port monitor (aka a span port or mirrored port, depending on the switch vendor) on your switch. On a Cisco Systems' Cisco Catalyst switch, setting up a port monitor is easy. Log on to the switch and enter Enable mode, then enter configure terminal mode and type in the switch port interface number to which you want to send all monitored traffic. Finally, specify each of the ports that you want to monitor. For example, the following commands would monitor the first three Fast Ethernet ports and send a copy of the traffic to the 24th port.
interface FastEthernet0/24 port monitor FastEthernet0/1 port monitor FastEthernet0/2 port monitor FastEthernet0/3 end
In this example, you would plug your network sniffer into port 24 and be able to view all traffic coming from and going to computers plugged into the first three switch ports. To view your new configuration, type
show run
Don't forget to save the new configuration by entering the command
write memory
First-Time Network Assessment
Now, let's walk through an example of assessing the traffic data on a network. If you're using a Linux computer as your network sniffer, you can use a program such as IPTraf in Statistical mode to get a sense of the type and frequency of packets on your network. Then, follow up with Tcpdump to uncover details about the traffic.
Table 1 shows the statistical output of IPTraf on a small Active Directory (AD)based network over a period of 15 minutes. To keep this example short, I ran the test in the evening when no users were accessing the network. So, although this example doesn't show all the Windows ports, it walks through some of the processes for assessing the ports and mapping them to services or applications.
TCP 22. The most heavily used network port is TCP port 22, which I know is used by Secure Shell (SSH), the program I used to connect to the Linux computer running IPTraf.
UDP 138. Second in frequency is UDP port 138, which is used by the NetBIOS Datagram Service. By referencing the aforementioned Microsoft white paper, you'll find that several Windows services use this port, including the Computer Browser service, DFS, the License service, the Messenger service, Net Logon, and the Server service. In fact, you'll find that the port range TCP and UDP 135 to 139 contains a number of Windows-specific ports that many Windows applications use. You'll likely have to keep some of these ports open, which unfortunately allows other Windows applications access.
TCP 80. The third port on the list is TCP port 80, which is used by unencrypted HTTP (Web) traffic. But in Statistics mode, IPTraf doesn't tell me whether this traffic indicates a client accessing a Web server inside my network or just an inside computer accessing a Web server on the Internet. (See the next section for further review of this scenario.)
UDP 137 and UDP 53. UDP ports 137 and 53 are used by Windows name-resolution services--in this case, NetBIOS and DNS.
UDP 67 and UDP 68. UDP ports 67 and 68 are used by the DHCP server to assign dynamic IP addresses.
UDP 123. UDP port 123 is reserved for Network Time Protocol (NTP), or in the case of Windows, Simple Network Time Protocol (SNTP). This protocol synchronizes time between a computer and an NTP server such as a domain controller (DC).
Remaining ports. What about the remaining ports that have only one packet each? To investigate these, I can run the statistics longer to discover trends, or I can run Tcpdump in parallel to catch more data, such as source and destination IP address. Even from an aggregated view such as this one, we can discern information about these packets. For example, each packet is 229 bytes long, suggesting that one application might be hopping around on different network ports, but we need more data to be sure.
Tcpdump
Tcpdump is a terrific command-line network-sniffing tool that records detailed data about the packets on your network. Earlier, we wanted to investigate where HTTP traffic is originating. To do so, we can run the
command
tcpdump -i eth1 -nq proto TCP port 80
In this basic example, we want to know only the IP addresses of computers using HTTP, so we've used parameters to show only TCP port 80 data. The -i eth1 parameter specifies the interface to sniff. In our sample network, eth1 is the NIC connected to the port monitor on the switch.
The -nq parameter is two separate parameters: -n tells Tcpdump not to resolve the host names or service names, and -q instructs Tcpdump to operate in quick (or quiet) mode. Finally, we want to view only data containing TCP port 80 traffic, so we add the command
proto TCP port 80
which limits the amount of data to review.
Figure 3 shows this command's output. You can see that only two computers in the 192.168.0.0 network are communicating on port 80. From this trace, we can deduce that the computer at 192.168.0.112 is attempting to access a Web server located at 192.168.0.7. From this point, we can investigate whether a legitimate Web server resides at this address or otherwise classify the finding. Consult the Tcpdump man page for a listing of all its available parameters. It's a robust program.
Utilizing a network port reference table along with multiple actual scan results of port-scanning your network can help you begin to map out the signatures of normal network traffic transiting your network. You can then start spotting abnormalities.
Creating Firewall Rule Sets
To create firewall rule sets--particularly for more complicated firewall deployments, such as in a demilitarized zone (DMZ)--use all the aforementioned techniques for assessing your network traffic so that you can determine exactly what network ports are in use. From this data, you'll build your firewall rule sets. Use a DMZ to isolate computers that accept direct Internet connections (e.g., front-end mail servers, Web servers) from other servers in your internal network. Because the computers in the DMZ also need to communicate with some computers in your internal network, you'll need to create a firewall rule set that permits such communication.
Let's look at two methods of determining what firewall-rule ACLs we need for an example DMZ. Suppose a Web server in your DMZ needs to retrieve data from a Microsoft SQL Server machine on your internal network. Instead of creating a loose firewall rule that lets the Web server's IP address communicate with the SQL Server system's IP address, put ACLs in place that permit only SQL Serverrelated communication.
One method for creating this ACL is to watch a port monitor and construct the ACL based on the traffic that you witness and validate. To do so, set up a port monitor on your firewall's DMZ interface and enable your network sniffer. At this point, make sure no firewall rules are in place between your DMZ and your internal subnet. Next, generate typical network traffic by using your Web application as its users would. Review the network-sniff data, and record all the unique IP addresses and network port communications. Finally, create and deploy firewall ACLs based on the information you discover. In this example, we expect that the Web server will initiate SQL Server connections to the SQL Server machine. SQL Server uses TCP port 1433, so you'll probably see packets to this port in the network-sniff results. However, if your Web server is a member server whose DCs are on the internal network, you'll probably also see lots of network traffic from Web server to DC. Review the network-sniff results and tailor your firewall-rule ACL to allow all the necessary network traffic.
The second method for discovering the ports that this Web server needs to use to communicate with this SQL Server machine is a trial-and-error approach, which consists of first creating and deploying an ACL that prohibits traffic between the DMZ and the internal network. Begin to use your Web server and watch your firewall logs for denied packets--you'll probably see many. For each denied packet, inspect and validate the source and destination address and network port information, then create ACLs that permit this traffic. Repeat this process until you stop seeing Deny log entries in your firewall from the DMZ to your internal network.
Understanding Equals Security
In this two-part article, I've given you some background about how network ports fit into a larger networking model, coupled with a description of tools you can utilize to discover and monitor the network applications that use your network. With this information--regardless of your IT background--you'll be able to review your network so that you can better understand and secure your piece of the Internet.
