Security

Cisco's hidden gem: The Cisco IOS firewall

If you need a simple-to-use, reliable, inexpensive firewall solution, Cisco's IOS firewall might be just the trick. Robert McIntire explains how this gem works, what it can protect, and how to make it work for you.


For years (and several IOS versions), Cisco has been providing products, features, and command options that facilitate secure networking implementations. One of the less well-known security implementations, the Cisco IOS firewall feature pack, also known as Cisco Secure Integrated Software, is a version of the Cisco IOS with an add-on feature set that can be run on several router platforms.

The protection available with the IOS firewall feature pack is more affordable than many firewall alternatives, including Cisco’s high-end PIX firewall, the company’s hardware-based firewall flagship, and most of the Check Point solutions. (The IOS firewall software license cost may vary, depending on feature set and platform.) It also compares favorably with the strategy of writing access control lists to filter unwanted traffic from the network, which has almost become an art form for the experienced network engineer.

It generally requires more memory than straight-up access control lists (ACLs), both flash and RAM. It also causes a bit of a hit on router processor performance. However, if your router capacity is adequate to handle current and future network traffic, the IOS firewall feature option could be very viable, especially considering the cost associated with a dedicated firewalling product such as the Cisco PIX 500 or the Check Point FireWall-1. In this Daily Drill Down, I’ll discuss the basic protection methods available with this product and how to configure them.

IOS firewall feature set
First of all, a Cisco router can be configured in a fairly secure fashion using plain old ACLs. ACLs can provide very granular packet filtering, but only at layers 2, 3, and 4. You can’t really filter on attributes above the Transport layer with an access list. The IOS firewall does provide this level of traffic filtering and more.

With Context-Based Access Control (CBAC), the main feature in this set, the packet-filtering function has been extended up to the Application layer so the CBAC can continuously check the state of a particular application session. This allows for a more sophisticated level of filtering, especially for application protocols that involve more than one channel. For instance, FTP will initiate the control channel on port 20 and negotiate an FTP-DATA channel on another, somewhat random port number of at least 1024. CBAC also provides the ability to restrict traffic entering the firewall to only sessions initiated from the inside, much like the established option of extended access control lists (also called access lists). It performs this feat by tracking state information for TCP and UDP sessions.

Access lists are applied to the external interface, essentially blocking all incoming traffic. Pretty secure, eh? Then this session state information is used to open inbound holes in the firewall only for the return traffic from sessions started on the inside. So in its originally configured state, all inbound traffic is blocked—that is, until an outbound session is initiated. CBAC can also thwart denial of service (DoS) attacks through several methods. It can detect and drop half-open sessions, sense and warn of a dramatic increase in the number of sessions, drop packets with out-of-range sequence numbers, and drop suspicious fragmented packets. It does this through the use of timeout and threshold settings. Several of these can be configured to customize how the firewall will behave under certain assault scenarios. CBAC can also log network activity, a feature that any good firewall should provide. It provides for a basic level of intrusion detection, as well, allowing for real-time warnings of suspicious network activity that matches well-known attack profiles. For those who choose to restrict Java applets, you’ll be happy to know that this is also an option. Although this option won’t provide extensive filtering of Java files, it’s possible to restrict inline applets that are downloaded through the browser session.

Configuring CBAC
I installed the IOS firewall version 12.2 on a Cisco 2514 series access router. At the time, this router was using an extended ACL to filter incoming traffic on the Internet facing interface. After disconnecting the cable for the external interface, I documented and removed the existing ACL. I then implemented the IOS firewall features as follows.

A common setup is to configure ACLs and CBAC inbound on the external interface of an Internet router to protect a private network from harmful traffic initiated from the Internet. This is a fairly simple configuration for those whose only real concern is to allow in only return traffic from sessions initiated internally. To do so, I added an extended access list to the inbound interface, blocking all the traffic I wanted to inspect, as follows:
Router (config)# Access-list 101 deny tcp any any
Router (config)# Access-list 101 deny udp any any
Router (config)# interface serial0
Router (config-if)# Ip access-group 101 in


The previous statements block all TCP and UDP traffic when applied inbound on the external interface. This provides a blanket form of inspection across all TCP and UDP traffic.

By applying access list 101 to the external interface, I ensured that Internet traffic was intercepted as soon as it reached the Internet router. I could also exercise a more granular level of control by specifying certain application protocols, as the following example demonstrates:
Router (config)# Access-list 101 deny tcp any any eq smtp

The previous statement blocks all SMTP traffic to the internal network. It would need to occur in the access list before the previous TCP blanket statements, or it would have little effect.

Defining the timeout
The next step in this process is to define the timeout and threshold values for CBAC to use when tracking sessions. Several values can be configured to enhance CBAC’s ability to defend against network attacks. Most of the timeout and threshold settings have default values that will generally suffice in a startup scenario. Many of the timeouts and thresholds control how the router responds to DoS attacks. (I’ll save a more in-depth discussion of timer/threshold configuration for another time.)

Something to keep in mind is that CBAC does not inspect ICMP, only TCP and UDP. Accordingly, you’ll need to add inbound ACL entries for appropriate ICMP restrictions. Consider adding these ICMP entries to your ACL. They’ll make it possible for those inside your network to ping hosts on the Internet, as well as allow your router to respond to proper ICMP traffic.

Up to this point, I’ve shown you how to configure entries for the extended access list and apply that configuration to the inbound traffic on the external interface. The ACL has entries to block all traffic that I want to inspect with CBAC. Rather than modifying the timeout and threshold settings, I went with the defaults. I recommend starting with the defaults and tuning these as you go. It’s not a good idea to make changes to these settings if you don’t understand how those changes will affect firewall operation. Next, I defined the actual inspection rule that governs which application layer protocols are examined. Let’s look at the inspection rule command structure.

This is a global config mode command. It requires that you specify a name, protocol, alert setting, auditing, and the timeout value in seconds. Now let’s create one of our own.

I’ve named the rule check-tcp, specified TCP as the protocol to inspect, and activated the alert and auditing options. Notice the alert and audit-trail options. This requires a Syslog system to send the information to. Although that configuration is beyond the scope of this Daily Drill Down, I do recommend using auditing for logging of all firewall activity. At this point, I’ll apply the rule to the external interface, Serial1, with the following:
Router (config)# Interface serial1
Router (config-if)# ip inspect check-tcp out


Notice that I have applied the inspection rule outbound on the external interface. It will track sessions started internally and heading out through the external interface, bound for the Internet or some other external network.

If you have difficulty during CBAC configuration, you can disable and reset all related settings using the following global mode command. This won’t remove your extended access list configured on the outside interface. If you turn off inspection, keep in mind that it will most likely halt all traffic entering your private network because the access list is filtering most, if not all, inbound traffic at the external interface. Turning off inspection is as simple as:
Router (config)# no ip inspect

This command will remove all the inspection information from the configuration, including the filter statements and command line that applies it to the interface.

Now that the basic configuration details are out of the way, let’s look at an Internet firewall router configuration with ACLs and CBAC inspection activated.

 

Keeping it pertinent
The above router configuration is abbreviated to only those sections pertinent to our discussion, and they’re not necessarily in the same order in which they would appear in the configuration.

This basic CBAC configuration will allow only limited ICMP information through the firewall router because access list 101 is applied incoming to the external interface. The inspection rule, filter1, will allow internal users to start outbound WWW sessions via HTTP and track the sessions, opening return points in the static, extended access list. This is also true for FTP and SMTP. If, in the future, I choose to allow users RealAudio or NetMeeting access, I would simply add ip inspect name statements, using filter1 as the name.

To change the inspection rule, you can easily add or remove line items. To add statements, simply use the ip inspect name command, using the same user-defined rule name. If you need to remove a line, simply use the no form of the ip inspect name command, as follows:
Router (config)# ip inspect filter1 tcp
Router (config)# no ip inspect filter1 tcp


If at any point you want to check the configuration, you can get CBAC setup details using the show ip inspect command, as in the following.
Router# show ip inspect all

The all parameter will display information such as current configuration of inspection as well as current sessions traversing the firewall.

General firewall configuration recommendations
Simply installing the IOS firewall software does not fully ensure a secure network. The router and CBAC must be configured properly to secure the private network from unwanted access. With this in mind, you’ll want to apply other well-known protections to the firewall router. Among these are broadcast protection and anti-spoofing measures. Some recommended measures are as follows:
No ip directed-broadcast
No icmp redirect
No ip redirect
No service finger
No cdp run
No ip source-route
Access-list 100 deny ip {internal network range} any


Don’t consider this to be a complete list of precautions. This is merely a sample of the types of settings to implement for a secure network environment. You’ll also want to check the Cisco support Web site for current security recommendations for edge routers. For instance, Cisco recently acknowledged a rather serious security issue for routers running the ip http service. I recommend checking the security area of the Cisco support Web site regularly to evaluate any potential vulnerability in your router/IOS combination or configuration attributes.

Conclusion
Although the IOS firewall provides a higher level of security than the standard access list approach, like other firewalls, it shouldn’t be considered invulnerable. A determined hacker may be able to find holes in the most secure of systems. Although I’ve demonstrated the strong security features of CBAC, you may want to consider a dual firewall approach if your security needs are highly demanding.

When implementing CBAC, consider its limitations carefully. For instance, it will only handle inspection of FTP data channels in the range of 1024 to 65535. Also, if you’re using IPSec, plan carefully how it will interact with the IOS firewall router. Keep in mind the strengths and configuration options, as they are plentiful. For example, CBAC can also be used as an extranet protection method when your network is connected to a business partner’s network. In this manner, it would inspect traffic in both directions, protecting both networks from unapproved access. You can also guard against traffic leaving the network by applying inspection to outbound traffic. Keep an eye out for my follow-up Daily Drill Down, in which I’ll examine such advanced features of the Cisco IOS firewall.

Editor's Picks