- TCP/IP Primer: How Packet Filtering Works
- TCP and UDP Ports
- TCP's Three-way Handshake
- The Cisco Router as a Packet Filter
- An Alternative Packet Filter: IPChains
- The Cisco ACL
- Effective Uses of Packet-Filtering Devices
- Egress Filtering
- Tracking Rejected Traffic
- Problems with Packet Filters
- Dynamic Packet Filtering and the Reflexive Access List
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
TCP and UDP Ports
The TCP part of TCP/IP stands for Transmission Control Protocol, and it is a reliable transport-oriented way for information to be communicated. User Datagram Protocol (UDP) is an unreliable transport protocol that works well with programs that don't rely on the protocol to make sure their payload gets where it's going. Both TCP and UDP use ports to keep track of communication sessions. Certain ports are set aside as the particular ones through which to contact a server running a given service such as HTTP (port 80), FTP (port 21), Telnet (port 23), DNS (port 53), or SMTP (port 25). (These services and how to secure them are discussed in more detail later.) The original RFC that documents well-known ports is RFC 1700. However, for a more up-to-date informative list of all of TCP's and UDP's server-side ports and the services to which they are assigned, check out this link to the IANA website: http://www.iana.org/assignments/port-numbers. IANA is the Internet Assigned Numbers Authority—the good people who track the number standards for the Internet as we know it.
When a client contacts a server, it randomly picks a source port numbered above 1023 to go out through. Then the client contacts the server on a set port, such as port 23 for Telnet. When the server replies, the information leaves on port 23 and returns to the client on the random greater-than 1023 port from which it left. This port information is the only way that a packet filter can determine the service it is filtering.
For example, you might want to filter out all Telnet traffic; you do so by blocking all traffic directed at TCP port 23. You might also want to allow all HTTP traffic coming to port 80. However, if someone is running a Telnet server on port 80 somewhere on your network, and all you have for protection is the aforementioned packet filter, the traffic passes. Packet-filtering systems don't have the intelligence to look beyond the port number to determine what service is running at the application layer. You need to keep this in mind when constructing filtering rules to block access to a service that you are running on an alternative port. Sometimes, web servers run on alternative ports, such as 8000, 8080, and the like; if you wanted to allow access to said web servers, then creating a packet-filtering rule that allows in standard HTTP traffic on port 80 wouldn't be effective.