Packet Filtering and Cisco's Way
Ronald McCarty In a few short years, security has moved from a nice-to-have "geek" issue to a daily part of network management; however, despite the move to mainstream IT, security issues have not become easier but rather have become more complex and numerous. Major weaknesses have been found in operating system stacks that allow hackers and "script kiddies" to knock over otherwise stable systems. Major applications are being used in Internet adventures - bearing some of the organization to the Internet. Extranets have moved from technology buzzword to the CIO's nightmare reality. Remote users want to trade in their dial-up networking for secure access through the Internet to take advantage of their cable modems, and of course, users can't live without that latest multi-media application that needs 13 holes poked through the firewall. Because implementing security has become so complicated, no single technology will secure your network properly. However, packet filtering is a solid building block that plays important roles in many security models. Packet filtering allows you to pass or drop traffic at the network layer in your routers based upon the contents of the IP header, and ideally the contents of the TCP and UDP headers. This article will look closely at "simple" packet filtering, not circuit state systems such as those found in Cisco's PIX, or other "full blown" firewalls. Packet Filtering Uses With packet filtering you can: Create choke points in your network - Choke points are generally used to "funnel in" services to a certain host or subnet. For example, you may wish to limit all incoming traffic to just your firewall to further protect other servers that may be on your perimeter network, such as an outbound SMTP server. Stop known harmful activity - By stopping harmful activity to your network, packet filtering can pay off quickly in very simple ways. For example, address spoofing is relatively easy to prevent, and keeps outside hosts from becoming "trusted" based upon IP address. Deny certain activity - Your security policy may not allow certain applications and protocols because of security needs or accounting reasons. For example, you may not want all of your email servers building SMTP connections with Internet servers; rather, these servers should relay through your central server. A filter could ensure that only the central server is allowed to connect on the SMTP port of Internet servers. Allow certain activity - If your security policy requires defining allowed traffic and denying the rest, then your filters will reflect this. You may wish to allow outgoing http traffic from your proxy server, and deny the rest of the traffic in a small remote office. Seal off business units or extranets - Many business relations do not allow a full sharing of resources between those involved; therefore, packet filtering can be used to allow only necessary traffic through. An example would be to allow only telnet sessions from your new logistics partner through to a particular order entry system to allow your operations to make order entries. (Note that this is really allowing certain activity.) Although I've given some of the scenarios where packet filtering is used, these scenarios reflect particular needs, and should not replace a good definition of your own security policy on particular routers. I will limit this discussion to perimeter routers; however, many of these policies can be applied to routers performing other functions (e.g., connecting extranets, access routers, and separating business units). Keep in mind that many organizations do not have the same policies for their packet filtering routers as for their firewalls, because there are often application considerations that must be covered with application firewalls. Formalizing security policies is a very good idea; however, keep in mind that policies should not discourage common sense during a security-related outage. The security administrator needs the freedom during an attack either to stop the attack or to gather evidence of the attack regardless of your security policy. The most common policies can be classified as follows:
Let's cover each of these security policies. Stop Harmful Activity With this type of policy you are only concerned with protecting your network from known attacks. This is the most lenient policy and the easiest to maintain if your organization has a full-time security administrator who keeps up with CERT and vendor advisories. Some of the weaknesses of this policy are: Maintenance - It is easy to fall behind on current security problems that can be fixed with packet filtering. Many security administrators have additional duties that require full-time attention. Denial of service - Denial of service attacks are not covered well with this type of security policy nor with packet filtering in general. Denial of service attacks often rely on poor implementations of protocol stacks or broken applications. Breaking network connectivity - Network connectivity can be broken by overreacting to a security advisory or lack of understanding on what the administrator is filtering. For example, many administrators have found out the hard way that filtering all ICMP can break MTU path discovery, which can affect services including email. Allow Specific Inbound and All Outbound By allowing specific inbound and all outbound, you are defining which external services may initiate a connection with your internal servers. This policy also says that you are very liberal with what your users may do in the Internet or that you are using your firewall to define allowed user activity. This policy is often preferred by those wishing little maintenance of the router, and it is usually adequate for networks that are further protected with a firewall. This policy is often narrowed to deny users free use of UDP, because UDP is a connectionless protocol and cannot be checked to see whether a reply to a packet is initiated by the user. One major advantage of allowing specific inbound traffic is that you only have to concentrate your efforts for denial of service attacks to those affecting the ports and protocols you are using. As was the case with the stopping harmful activity policy, the filters can break related services unbeknownst to the administrator. For example, just allowing outbound SMTP to allow outgoing email mail may not be the optimal choice because many mail transport agents also run the ident daemon to log the identity of the user and machine on which the delivering MTA is running. Not allowing the ident through may be appropriate, but the time will impact performance and, in some connections with poorly connected MTAs, actually keep the SMTP connection from ever happening. Allow Specific Inbound and Specific Outbound The third policy allows only specific inbound and allows only specific outbound. With this policy, you define all activity explicitly. This is the simplest policy to understand and easiest to sell to management; unfortunately, it can also be the hardest to manage in organizations with continual moving business needs. However, this type of policy shines in small or remote environments where an application level firewall cannot be justified. Do not let these classifications override future industry practice, your organizational needs, and common sense. Also keep in mind that stopping harmful activity is a good idea with any policy - I just don't recommend it as a standalone policy. Now that we've covered the policies most often used, and before you fire up your telnet, let's look at the some of the real world issues involved. Packet filtering should not be used as a cure for all security issues. Some administrators rely too much on packet filtering once they learn how to use it; unfortunately, this is caused by a lack of understanding of the level at which the the filters are being used. Here are the major weaknesses of poorly implemented security policies based heavily upon packet filtering without additional investment. Application level firewalls are still needed by most organizations. A good firewall can protect you against application weaknesses. For example, a server running a broken version of Sendmail cannot be protected by the packet filter, because it cannot look at data within the packets. However, a firewall could proxy the connection and (we hope) not have the same weakness as Sendmail, or the firewall could support protocol scanning and recognize the attack being carried out. Packet filtering is harder to manage in complicated networks. A firewall, on the other hand, will likely have a GUI that makes rule changes easier and minimizes mistakes that can affect security. Finally, as the rules become more complicated, the rules become processor intensive, which in the best case slows down your connectivity and in the worst case causes the router to be unstable. Cisco's Way Cisco's implementation of packet filtering supports filtering based upon: Protocol Bits 72-79 of the IP packet contains the protocol number as defined in the Internet Engineering Task Force's Assigned Numbers Standard, RFC 1700. We'll be concentrating on ICMP (1), TCP (6), and UDP (17). Source and Destination Address To be effective, an examination of the source and destination address is necessary. Cisco's IOS looks at the IP header bits 72-79 to determine the source address and bits 128-160 for the destination address. Destination Ports By examining TCP and UDP headers, Cisco IOS can make comparisons with the destination ports. RFC 793 (Transmission Control Protocol) and RFC 768 (User Data Protocol) contain descriptions of the protocols and their headers. These capabilities are not Cisco specific and are supported by most routers and some switches, so our examples can be applied to other routers. The syntax, however, is Cisco specific. Access Control Lists Cisco implements filters using access control lists. Cisco supports two types of access lists: standard and extended. Standard access lists control traffic based only upon the source address and are numbered 1 to 99. Extended lists control traffic based upon source and/or destination address, protocol, and destination port. Extended access control lists are number 100 to 199. We will concentrate on extended access lists. Access control lists are applied to interfaces and should be applied to the interface where the packet is entering the system. This allows the packet to be examined prior to a routing decision and optimizes performance. Cisco routers apply all entries to a particular access list in order and jump out of the access list upon making a match. Therefore, permits should be placed at the beginning of the list to optimize performance. Additionally, Cisco routers have an implicit deny all at the end of access lists. (You will not see the deny all, but the router does.) Here's an example of an extended access list number 101:
access-list 101 permit tcp host 192.168.1.1 host 192.168.2.1 eq www access-list 101 permit tcp host 192.168.1.1 host 192.168.2.1 eq telnet This list, if applied to an "incoming" interface would allow http requests and telnet sessions from 192.168.1.1 to 192.168.2.1. The general format for an access list is:
Access-list [n] [permit | deny] [protocol] [source] [destination] \ where:
99 < n < 200 In this example, permit or deny either allows the packet to pass or drops the packet. Protocol is the protocol number or name, which in our case will be ICMP, TCP, or UDP. Source and destination are either single IP addresses (host 192.168.1.1), or a network and "wild" mask (192.168.1.0 0.0.0.255), or the whole world ("any"). The later examples will clarify networks and the "wild" mask. The operator and port parameter is the comparison operators eq (equal), gt (greater than), lt (less than), and range. The port is the TCP or UDP destination port or, in the case of the range operator, a starting and ending port number. How do you apply the access-list 101 to an incoming interface? Use ip access-group command in the interface configuration mode. For example:
RouterA(config)#interface serial 0 RouterA(config-int)#ip access-group 101 in Notice the in parameter in in the ip access-group 101 command? This tells the router in which direction the access list should be applied. As mentioned, you should filter on the incoming interface before the routing decision is made; therefore, you will not see any ip access-group 101 "out" examples in this article. Note that since there is a deny, all seen by the router in the access-list 101 we just covered, that no other traffic would be routed coming in through serial 0! Keep this in mind when you are managing the routers remotely or using a specify all incoming and outgoing policy; otherwise, you'll find yourself connecting directly to the router through the management port to correct the damage. Before we get to the examples, let's cover a few habits you should form when managing access lists: Use a text editor and terminal program you are comfortable with. Use cut and paste to create access lists. "On the fly" changes can end up creating more chaos than security. Follow this procedure when making changes:
1. Turn off the access group using no ip access-group n in on the interface. 2. Delete the access list in the global configuration using no access-list n. 3. Paste in the new access list. 4. Turn on the access list using the ip access-group n in command.
Now we're ready to tighten down security in our exercise. Figure 1 shows our perimeter network. The router named Router A is our perimeter router that connects us to the Internet. The computer named Charlie is our internal http and ftp proxy/cache server. The cache server has been placed outside the firewall because it will likely run an http/ftp virus checker once the technology has proven itself to the IT department. Snoopie is an email virus checker that will accept all mail for our company. Upon completing the virus check, it will pass the email through the firewall for delivery. Lucie is the application level firewall. Our security policy, based upon the common practices covered as well as modifications to fit our organization, is:
1. ICMP traffic to and from the perimeter network is allowed. 2. Allow specific external initiated TCP connections to the hosts located on the perimeter router, as defined by the function of the particular host. 3. The only other outside initiated traffic allowed through the packet filter is TCP traffic sent in reply to an internal initiated request. 4. All TCP traffic initiated from the perimeter network will be allowed to pass through the perimeter router.
This policy is a modified version of allow specific inbound and allow all outbound traffic. The major modification to the policy is not allowing UDP. Blocking UDP has been a conservative yet understandable security policy in the past. Circuit state policies supported by many popular firewalls have given many organizations the security they've asked for to allow UDP into the organization. Check your firewall documentation to see how much security it gives you for UDP traffic. Now that we've covered our network topology and our security policy for the exercise, let's write our rules in pseudo code. The format when you're designing your filters is not important - understanding what you're doing is the goal.
Serial Interface 0 incoming:
Rule to meet paragraph 1 of our policy: Allow ICMP.
Rule to meet paragraph 2 of our policy: Allow SMTP to Snoopie.
Rule to meet paragraph 3 of our policy: Allow TCP ACK packets.
There are no rules to meet paragraph 4 on the serial interface. Rule 4 applies to outgoing traffic, and as mentioned, we wish to filter at the interface where the traffic enters the router, before a routing decision is made. So, now we can move to the Ethernet side.
Ethernet 0 incoming:
Rule to meet requirements of paragraph 1 of our policy:
Allow ICMP. There are no rules to meet the requirements of paragraphs 2 and 3.
Rule to meet paragraph 4 of our policy: Allow TCP.
Now we can actually create the access lists. We will use access-list 101 for the access list applied to the serial interface and access-list 102 for the Ethernet interface. (RouterA(config)# is the prompt, we enter everything after the prompt.)
RouterA(config)#access-list 101 permit icmp any any This says to pass ICMP traffic from any host on the Internet to any host on our network. Here's the next rule:
RouterA(config)#access-list 101 permit tcp any host 192.168.1.2 eq smtp This tells the router to pass any SMTP traffic from any host on the Internet to Snoopie. We could have used the port number 25 instead of the keyword SMTP. Now, we're looking at something a bit different:
RouterA(config)#access-list 101 permit tcp any 192.168.1.0 0.0.0.255 established Note the "wildcard" mask following the 192.168.1.0. This is actually the XOR of the netmask. If you don't want to go through the binary math to figure the XOR, simply subtract each byte from 255 to create the mask. Our netmask was 255.255.255.0, so we have: 255-255.255-255.255-255.255-0 = 0.0.0.255. A netmask of 255.255.255.252 would mean 255-255.255-255.255-255.255-252 = 0.0.0.3. Also notice the established keyword. This checks the acknowledge bit (139) of the TCP header to verify that the packet is a reply to an internal request. Here are the rules for access-list 102 that will be applied to the Ethernet.
RouterA(config)#access-list 102 permit icmp any any RouterA(config)#access-list 102 permit tcp 192.168.1.0 0.0.0.255 any Nothing different there. To apply these rules to the interface, we need to use the ip access-group command:
RouterA(config)#interface serial 0 RouterA(config-if)#ip access-group 101 in RouterA(config-if)#exit RouterA(config)#interface ethernet 0 RouterA(config-if)#ip access-group 102 in The complete configuration for Router A is shown in the sidebar "Routers A's Configuration". For additional tips and resources, refer to the sidebar "Packet Filtering Tips and Resources". As soon as you enter the ip access-group 101 in command, packet filtering is active for that interface. If you had configured the router remotely through the serial interface, you would have lost connectivity before ever applying the filter to the Ethernet. So, if you are configuring routers remotely, you may wish to give yourself temporary telnet access to the router. As a last resort, always wait a bit before saving the configuration (write memory) to non-volatile memory, then you can always have someone restore the last configuration by cycling the power on the router - not a pretty solution, but a quick one sometimes needed at remote sites. This article has given you a good overview of packet filtering in general as well as some common practices. It has also introduced you to Cisco's implementation of packet filtering using access control lists. By understanding that packet filtering gives you additional security at the network layer, as well as realizing that the payload (application) is not examined by the filtering, you can quickly determine when packet filtering is the right tool for the job and get the job done.
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia.
|