Network Port Fundamentals, Part 1

TCP/IP provides the Internet's foundation, letting computers send and receive information from anywhere in the world, regardless of geography. It's just as easy to access a TCP/IP computer in another country as it is to access a computer next door. In fact, fundamentally the process is identical, although communicating with a foreign computer might take a few milliseconds longer. As a result, anyone in the world can easily and quickly shop at Amazon.com, but this same logical proximity complicates our efforts at securing our computers: Anyone in the world with a computer on the Internet can attempt to maliciously connect to your computer.

As IT professionals, we have to install firewalls and detection systems to identify suspicious traffic. An inspection of packet traits occurs, ferreting out information such as source and destination IP addresses and utilized network ports. Just as vital as IP addresses, network ports provide crucial filtering criteria for separating legitimate traffic from spurious or malicious traffic entering or leaving your network. The majority of Internet network traffic is composed of either TCP or UDP packets, which include network port information that computers use to direct traffic from one application to another. A cornerstone of firewall and network security is a thorough understanding of how computers and network devices such as firewalls use these ports.

Port Authority
Any system administrator can benefit from a basic understanding of how network ports work. If you need to troubleshoot a failed network application or lock down a computer destined for accessing the Internet, instead of calling a network engineer or firewall consultant, you can accomplish the task yourself if you have a fundamental understanding of networking and specifically TCP and UDP ports.

In this article—the first part of a two-part series—I begin by giving you a straightforward description of networking to establish a groundwork for a discussion of network ports. I show you how network ports fit into the larger network model and also how most companies rely on network ports and Network Address Translation (NAT) at their firewall to communicate with the Internet. Finally, I highlight the various touch points in your network where you can identify or filter network traffic based on its network ports. In Part 2, I'll examine some of the actual ports that common applications and OSs use, and I'll explore a few of the tools you can use to discover the ports that are open on your network.

Brief Networking Review
TCP/IP consists of a suite of networking protocols that let computers communicate with one another. A TCP/IP stack is nothing more than pieces of code installed on your OS that make these protocols available. TCP/IP is a standard, which means that TCP/IP applications running on a Windows computer should be able to communicate with a similar application running on a UNIX machine. In the early days of networking, back in 1983, engineers developed the seven-layer OSI model to describe a computer's networking processes, from wire to application. The OSI model consists of the physical, data-link, network, transport, session, presentation, and application layers. If you're working daily with the Internet and TCP/IP, you'll mostly work with the network, transport, and application layers, but to be effective at troubleshooting, you need to recognize and understand the other layers. Although the OSI model is dated, many people still refer to it. For example, when a network engineer speaks of Layer 2 or Layer 3 switches, or when firewall vendors talk about Layer 7 inspection, they're referring to the layers defined in the OSI model.

This article focuses on network ports, which sit at Layer 4—the transport layer. In TCP/IP, these ports are the ones that TCP and UDP use. But before focusing this discussion on just one layer, I want to quickly review the seven OSI layers as they pertain to modern-day TCP/IP networking.

Layers 1 and 2: Physical Cables and MAC Addresses
Layer 1, the physical layer, is the actual medium that carries the signal—for example, copper cable, fiber optic, or radio signals (in the case of Wi-Fi). Layer 2, the data-link layer, describes how data is formatted for transmission across the physical medium. Layer 2 organizes packets into frames and can include basic flow and error control. IEEE 802.3, more commonly known as Ethernet, is the most common Layer 2 standard for today's LANs. A basic network switch is a Layer 2 device that lets multiple computers physically connect and communicate with one another. Sometimes, two computers can't communicate with each other even though the IP addresses look correct: Such a problem might be the result of a corrupt Address Resolution Protocol (ARP) cache, which denotes a Layer 2 problem. Also, some wireless Access Points (APs) support MAC filtering, which permits only NICs with a specific MAC address to connect to the wireless AP.

Layers 3 and 4: IP Addresses and Network Ports
Layer 3, the network layer, provides routing support. In TCP/IP, this routing support is embodied in IP. A packet's IP address resides in Layer 3. Network routers are Layer 3 devices that inspect packets' IP addresses and decide whether to forward the packets to another router or deliver the packets to local computers. If you discover suspicious packets on your network, one of the first items you should check is the packet IP address, to see where the packet originated.

Together with the network layer, Layer 4—the transport layer—is a good starting point for troubleshooting a network problem. On the Internet, Layer 4 contains the TCP and UDP protocols and network port information that associates a packet with a specific application. A computer's network stack relies on a mapping between the TCP or UDP network port and the application to direct network traffic to the application. For example, TCP port 80 maps to a Web server application. This mapping is also known as a service.

TCP and UDP are different. In a nutshell, TCP offers connection-oriented, reliable communication between two applications. Before two applications can begin communicating, they must agree to communicate by performing the TCP three-way handshake. UDP is more of a fire-and-forget protocol. An application using TCP can count on the protocol for reliability, whereas an application using UDP must perform reliability checking itself.

The network port is a number between 1 and 65535 that is specified and known by both of the applications that want to communicate. For example, a client typically makes an unencrypted Web request to a server on destination TCP port 80. A computer typically makes a DNS query to a DNS server on destination UDP port 53. Just as a client and server have a source and destination IP address, they also have a source and destination network port, which might be different. Historically, all port numbers below 1024 have been known as "well known port numbers," registered as such with the Internet Assigned Numbers Authority (IANA). On some OSs, only system processes can use ports in this range. Additionally, organizations can register ports 1024 through 49151 with the IANA to associate a port with their application. This registration has provided structure to avoid conflicts between applications wanting to use the same port numbers, but generally nothing prevents one application from requesting to use a specific port as long as another running program isn't actually using the port.

Historically, a server might listen on a low-numbered port, and the client might initiate a connection from a high-numbered port (i.e., above 1024). For example, a Web client might open a connection to a Web server on destination port 80 but would associate a random source port—say, TCP port 1025. When the Web server responded to the client, it would address the packet to the client with source port 80 and destination port 1025. The combination of an IP address and a port is called a socket, which must be unique on a computer. (For this reason, when you set up a Web server with two separate Web sites on the same computer, you must either use multiple IP addresses—such as address1:80 and address2:80—or instruct the Web server to listen on multiple network ports, such as address1:80 and address1:81. Some Web servers support multiple Web sites on one port by querying the host header, but this function is actually performed by the Web server application higher up the stack at Layer 7.)

As more OSs and applications have become network capable, developers have begun to use ports above 1024 and haven't registered all applications with IANA. To look up a particular network port, you can search the Internet for it and you'll probably quickly find information about any applications that use that port. Alternatively, you can search for "Well Known Ports" and find many sites that list the most common ports.

When you're locking down a computer's network applications or punching holes in a firewall, most of the work is split between classifying and filtering the Layer 3 IP addresses and Layer 4 protocols and network ports. Learn to recognize the top 20 TCP and UDP ports for your environment so that you can promptly discern legitimate from suspicious traffic.

Recognition of and familiarity with network ports extends beyond creating firewall rule sets. For example, some Microsoft security updates describe closing NetBIOS ports to limit the spread of worms that exploit OS vulnerabilities. Knowing how and where you can close these ports can help mitigate risks to your network while you prepare to deploy a critical security update.

Skipping to Layer 7
These days, we don't hear much about Layer 5 (session) and Layer 6 (presentation), but Layer 7—the application layer—is a hot topic among firewall vendors. The latest push in network gateway firewalls is Layer 7 inspection, which describes a firewall's ability to understand how an application uses network protocols. By inspecting the contents of a network packet (aka the payload), a firewall might be able to verify whether the traffic crossing it is legitimate. For example, a Web request includes a GET statement inside the Layer 4 (TCP port 80) packet. If a firewall is Layer 7 aware, it could ensure that the GET statement is proper. For another example, many peer-to-peer (P2P) file-transfer applications can hijack port 80. As a result of this capability, someone could configure P2P software to use a port of his or her choosing—likely one that must remain open on your firewall. If your company requires that employees be able surf the Internet, you must open port 80—but unless your firewall supports Layer 7 inspection, it won't be able to discern legitimate Web traffic from P2P traffic that someone configured to also use port 80.

Firewalls 101

By discussing these network layers, we've set the stage for describing how network applications communicate across firewalls, specifically focusing on the network ports they use. In the next example, consider a Web browser client that's communicating with a Web server on the other side of a firewall—not unlike an employee in your company surfing a Web server somewhere on the Internet.

Most Internet firewalls operate at Layers 3 and 4, to inspect and permit or deny inbound and outbound network traffic. Generally, you'll program ACLs that define the IP addresses and network ports of traffic that you want to allow or deny. For example, when you want to surf the Web, you launch your browser and point it to a Web site. Your computer initiates this outbound communication through a series of IP packets that consist of a header and a payload. The header contains routing information and other packet attributes. Firewall rules are often based on the routing information and typically include the source and destination IP addresses (Layer 3) and the packet's protocol (Layer 4). For a Web surfer, the destination IP address is that of a Web server, and the protocol and destination port are—by default—TCP 80. The source IP address is the Web surfer's computer address, and the source port is usually a dynamically assigned number greater than 1024. The payload is independent of the header and is created by the user's application; in this case, the payload is a request for the Web server to return a Web page.

Your firewall inspects the outbound traffic and permits it if the firewall's rule set allows it. Many companies permit all traffic outbound from their network. Although this assumption simplifies configuration and deployment, it weakens security by not controlling what leaves the network. For example, a Trojan horse might infect a computer on your network and send information about your computer to some other computer across the Internet. Creating ACLs that block such outgoing information is a good idea.

In contrast to the way many firewalls treat outbound traffic, most are strictly configured to block inbound traffic. Typically, firewalls permit inbound traffic in only two cases. The first case is traffic that's in response to an outbound request that you've initiated. For example, if you point your browser to a Web page, the firewall permits the HTML and other code that makes up that Web page to enter your network. The second case is if you host an internal service on the Internet, such as a mail server or Web or FTP site. Hosting such a service is typically referred to as port forwarding or server publishing. The implementation of port forwarding differs according to the firewall vendor, but all implementations are based on the same concept. You define a service, such as TCP port 80 for a Web server, and an internal server to host the service. If your firewall receives packets on its external interface that match this service, port forwarding tells your firewall to send them to the specified computer on the network inside the firewall. Port forwarding is used in conjunction with NAT, which I describe next.

NAT Basics
NAT lets multiple computers in a company share a small, public IP address space. Your company's DHCP server might allocate an IP address from one of the blocks of private, non-Internet-routable IP addresses (specified in Request for Comments—RFC—1918). Many companies might also use the same private IP address space. (Examples of private IP subnets are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.) Routers on the Internet discard any received packets that are destined to one of these addresses. NAT is a firewall feature that lets companies that use these private IP addresses communicate with other computers on the Internet. Your firewall knows how to translate traffic to and from these private internal IP addresses so that each computer can access the Internet.

Figure 1 shows basic NAT communication between a client and a Web server. In Step 1, Internet-bound traffic originating from a computer on your corporate network goes to your firewall's internal interface. The firewall receives the packet and adds an entry into a connection-tracking table that manages the address translation. The firewall then substitutes its external public IP address for the packet's private source address and sends the packet to its destination on the Internet, as Step 2 shows. The destination computer receives the packet, processes it, and sends a response back to your firewall, as Step 3 shows. When your firewall receives this packet, it looks up the original sender in the connection table, replaces the destination IP address with the appropriate private IP address, and sends the packet to the original computer, as Step 4 shows. Because your firewall sends packets out on behalf of all your internal computers, it also changes the source network port, and this information is also stored in the firewall connection-tracking table. The firewall must do this to ensure that its outbound sockets remain unique.

Understanding how NAT works is important because NAT changes the IP address and network ports of traffic on your network, and understanding it helps you troubleshoot problems. For example, you'll understand why the same traffic can have different IP addresses and network ports on your firewall's outside and inside interfaces.

Foundation First, Structure Second
An understanding of networking fundamentals from an application, firewall, and port perspective isn't just for network engineers any more. These days, it's rare to find a computer system that isn't networked, and even if you're a systems administrator, you'll find yourself much more ready to jump in to solve a problem if you understand even the basics of how applications use network ports to communicate across the Internet.

In Part 2 of this two-part series, I'll look at tools that help you discover applications on your network by investigating the network ports in use. I'll do this by interrogating a computer over the network (port scanning) and locally (host scanning) to find the applications that are listening and available on the network. Also, I'll look at firewall logs to see the application network traffic actually crossing the network and take a peek at some of the different network ports Windows and UNIX applications use.