The configuration of the IOS firewall feature set is basically an interaction between extended access lists and inspection rules. Implemented in its simplest and most common form, it’s used on Internet edge routers to block all incoming packets except those returning to sessions initiated from an internal, private network node, as I discussed in ”Cisco’s hidden gem: The Cisco IOS firewall.”

This is all well and good if you find yourself in a network with a simple design, but that’s not the reality for most networks. Oftentimes, complications are added to the mix that require you to use more sophisticated features and options in the IOS firewall software. For instance, what if the same router is performing some type of network address translation (NAT) for both the private network and the Internet? Also, more sophisticated configurations can accommodate Internet hosts that need to initiate communication with your private network. For example, how do you allow your internal e-mail server to receive mail from an Internet-based e-mail server? And for that matter, how do you configure the IOS firewall to allow Internet access to your internal Web server? In this Daily Drill Down, I’ll explain how you can deal with some of these more advanced issues surrounding the Cisco IOS firewall.

Network address translation
In the NAT process, internal private addresses are translated to valid external Internet addresses for two basic reasons: security and routability on the Internet. NAT can be achieved in several ways and generally provides a pool or range of valid Internet addresses to which internal clients can be mapped.

There are basically three types of NAT: static NAT, pooled NAT, and port-level NAT (also called Port Address Translation, or PAT). Static NAT is the easiest to set up, with each host on the internal network mapped to an address on the external network. Pooled NAT defines a group of addresses on the external network that are dedicated to specific internal hosts. PAT maps all internal connections to a specified port bound to a single IP address on the external network.

Cisco routers work well with PAT-type translation. To allow more than one internal host to use this address simultaneously, the router maintains enough information about each session to allow return packets to be routed back to the correct session. In the following examples, I’ll use PAT as the method for address translation.

In this example, I’ve configured PAT by creating a basic access list to allow inside addresses (172.16.1.x) to be translated. Then I configured NAT to use the inside interface as the source, restricted by access list 1, translating these inside addresses to the outside interface address of serial1. The overload parameter allows more than one inside host to use the single outside address of the external interface. Then I designated the respective interfaces as inside and outside. This configuration also falls into the category of dynamic NAT, where translations are created on the fly when internal hosts attempt outside access.

NAT can also be done in a static fashion. What if you wanted to allow Internet e-mail servers to start mail transfers to your internal mail server? You know that as an internal server, your mail server has an internal address in the private space. But Internet mail servers need to be able to send to valid Internet addresses. To make your private mail server seem Internet-visible, perform a static NAT mapping.

In this way, an Internet mail server can transfer mail to your internal server with the router performing address mapping between your e-mail server’s private address and the valid outside address (on port 25 for SMTP). This same principle applies to other internal systems (i.e., Web servers, FTP servers) that may be accessed from the Internet. In terms of security, you’ll also need to allow this sort of traffic in your access list, but I’ll cover that part later.

IP addressing
Another constraint that you may run into is addressing the Internet interface of your firewall edge router. Some broadband provider service offerings require the use of DHCP to acquire your address. Once the address is initially acquired from the provider’s DHCP server, it will generally remain the same as long as the router is not shut down for an extended period of time. For all intents and purposes, it becomes a permanent lease. So you can create DNS records pointing to this address for domain ID, e-mail, and Web access. Cisco began offering DHCP as a client feature in IOS 12.2. Setting it up is easy enough, but it’s important to remember to leave an opening in the inbound access list to receive the DHCP server response. Note this access-list statement to allow incoming DHCP responses to the external interface acting as the DHCP client.

From a security perspective, you’ll want to limit the use of any any as source and destination. Once you initially acquire an address via the ISP’s DHCP server, you can then add that address to the access list entry as the destination. This can be a bit dicey, though, because the address from the DHCP server may actually change. A better option is to add the addresses of the ISP’s DHCP servers as the source. In this way, you would permit DHCP only from the valid DHCP servers, like so.

DHCP also communicates other relevant information, such as DNS, default gateways, etc. You can check this configuration information with the following commands:
Router# show ip domain
Router# show ip name-server
Router# show ip default-gateway

Domain is the actual domain name, and name-server is the actual IP address of the DNS server the router will use to resolve names. However, you won’t see these attributes in your startup configuration, because they are dynamically assigned.

Advanced filtering issues
At this point, you can deal with more advanced issues that will add more functionality and security to your network implementation. First on this list is allowing Internet hosts to initiate sessions through the IOS firewall to internal hosts. For instance, you’ll need to allow Internet mail servers to start transfers with private mail servers, and you’ll also need to allow outside users access to your internal Web server.

I’ve discussed the static NAT mapping necessary to make this happen. Along with that, you’ll need to make an opening in your outside ACL to allow the specific traffic type to flow. In this example, I’ve added entries to the access list to allow inbound traffic from the Internet to a specific server hosting the Web page and e-mail service. These statements are order-sensitive within the ACL. Naturally, they will need to be placed before the blanket TCP filter mentioned in the first part of this Daily Drill Down. And, of course, you’ll need to add another static mapping for the Web server.

The next thing to think about is inspecting this incoming traffic using the Context-Based Access Control (CBAC) feature for session inspection. To do so, I’ll configure the following rule for inbound e-mail:
Router (config)# ip inspect name rule2 smtp
Router (config)# interface e1
Router (config-if)# ip inspect rule2 in

So far, I’ve dealt with security from the perspective of limiting inbound traffic, but what about outbound? In “Cisco’s hidden gem: The Cisco IOS firewall,” no restrictions were applied on the internal interface, allowing all traffic on the local network to exit. In an ideal world, this level of trust is a given, but to ensure network security, you may want to limit what type of traffic can exit your network. To do so, you can create and apply an ACL to the internal interface, as in this example.

What I’ve done here is block FTP traffic from leaving the internal network. Keep in mind that your NAT configuration is also helpful here. Remember that in setting up NAT, I created an access list specifying the source address pool to be translated to the public address pool, which, in this case, is the single external address on the router. This means that only valid internal addresses in this range will make it outside the private network.

Avoiding attack with timers and thresholds
The IOS firewall avoids certain types of network attacks through the use of timer and threshold values. The denial of service (DoS) attack creates false, half-open sessions in an effort to consume host, bandwidth, or router resources, thereby denying access to hosts or networks. You can configure CBAC on the router to control and respond to these half-open sessions. The types of settings basically have to do with the total number of sessions and the number of new sessions per time period. The following is a list of settings that can be used to customize the way the router responds to suspected DoS attacks:
Router (config)#  ip inspect tcp synwait-time 20
Router (config)# ip inspect max-incomplete high 100
Router (config)# ip inspect max-incomplete low 50
Router (config)# ip inspect one-minute high 100
Router (config)# inspect one-minute low 50

In the first statement, I set the time the router will wait for a connection attempt to complete, known as SYN wait. In the next two statements, I set the high and low value for the maximum number of incomplete connections. When the high value is reached, the router begins dropping the oldest half-open connections until it reaches the low value for incomplete sessions. The last two statements deal with the rate of connections. Here, I’ve configured the router to handle no more than 100 new connection attempts per minute. This is by no means a complete list of such values; rather, it’s a sampling of those directly associated with session initiation.

In terms of setting timers and thresholds, you need some frame of reference other than defaults and minimum and maximum values. If you’re setting a timeout for half-open sessions initiated by outside hosts, how do you determine reasonably what value to use? What if you could determine an average time for a full session handshake? Then you could use this figure as a starting point. Also, keep in mind that by lowering the timeout value, you tighten the window of opportunity for hosts to complete the handshake connection process. This could be a good thing or a bad thing. For a site that does not normally experience many externally initiated sessions, it’s good because it doesn’t allow sessions to remain in limbo for long, thereby protecting router resources. If you do have a bit of inbound traffic, you’ll want to be sure to set this value to at least the average time. Otherwise, you may end up terminating legitimate sessions before the full handshake process can be completed. One way to get a sense of what normal values are for your network would be to log the information and analyze it. From this data, you could determine normal or average values and apply this information to the session thresholds and timers. But to view session information in an ad hoc fashion from the Cisco router interface, you can execute the following command:
Router# show ip inspect sessions

And to view the current configuration of IP inspection and the associated values, try the following command:
Router# show ip inspect config

Conclusion
Remember that as you make changes to your network configuration, you’ll most likely be adding statements to the access list that guards the external interface of your IOS firewall router. As you add these statements, remember that they can be sensitive to sequence. For example, an entry to allow incoming e-mail from Internet mail servers will need to occur before a blanket TCP deny statement. Another thing to consider is that CBAC will inspect sessions coming from the inside or outside. This bidirectional control opens a whole new door with respect to network security—not just for Internet protections but also between different companies and networks. In this way, the inspect feature provides complementary security to the traditional access-list filtering. You can now check packets at the application level and by application.

Throughout this Daily Drill Down, I’ve displayed the more notable protection features available with the Cisco IOS firewall software. This should by no means be considered a complete configuration guide. You can configure a long list of features to provide specific forms of protection for diverse security needs. A more complete list of features is available with thorough documentation on the Cisco support Web site.