Cisco Secure Integrated Firewall Software

Peter J. Welcher

Introduction

This month we'll take a look at new Cisco IOS features encompassing security. Some of the features greatly extend the former Firewall Feature Set (say that tongue twister three times rapidly!), so there's a new marketing name: Cisco Secure Integrated Software (CSIS). At this time the rumor is that "firewall" will soon somehow make it back into the title, describing what the features actually do.

Cisco has an interesting approach here. Routers are ubiquitous in networks. Therefore routers form a natural and readily available platform for security. This can be combined with security on dedicated firewall or network intrusion detection systems for a (more) comprehensive solution. To obtain the benefits of this approach, you pay Cisco some extra money to obtain the CSIS build of the Cisco IOS software, upgrade your router to it, and configure it.

Our approach for this article is simple: what IS Cisco Secure Integrated (Firewall) Software, what are its components, what does each component do, how do we configure it, and a summary.

My source for information in writing this article is primarily:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/index.htm

What's In Cisco Secure Integrated (Firewall) Software?

The major features in the CSIS IOS image are:

Context Based Access Control
Intrusion Detection System
Firewall Authentication Proxy
Port to Application Mapping

Let's take a look at each of these in turn.

Context Based Access Control

Context Based Access Control (CBAC) performs traffic filtering based on application level protocol information. It does so using stateful filters, whereby selected outbound traffic creates a temporary opening in the filter for replies to return through. This means that CBAC is examining more than transport layer TCP or UDP ports. With FTP, it tracks the application as it opens ports for data connections, and allows the replies back through the firewall. With UDP, it tracks application ports and allows replies. With other application protocols, it tracks multiple connections created by negotiation on a control channel. Multimedia protocols, SQL*Net, and RPC are examples of such traffic. CBAC can also perform Java blocking, based on server address. It does not do Java nor Active X content filtering.

The inspection by CBAC also allows it to prevent certain Denial of Service (DoS) attacks. For example, it detects and prevents SYN flooding, badly out of sequence TCP packets, large numbers of halfpenny connections, and high rates of new connections.

The protocols CBAC can look for include any TCP or UDP sessions, and the following applications (initially): CU-SeeMe (only the White Pine version), FTP, H.323 (such as NetMeeting, ProShare), HTTP (Java blocking), Java, Microsoft NetShow, UNIX R-commands (such as rlogin, rexec, and rsh), RealAudio, RPC (Sun and Microsoft RPC, but not DCE RPC), SMTP, SQL*Net, StreamWorks, TFTP, VDOLive.

The basic features (above) are supported on the 800, uBR900, 1600, 1700, 2500, 2600, 3600, 7100 and 7200 series router platforms.

Intrusion Detection System

The Cisco IOS Intrusion Detection System detects 59 common attack signatures. It will send an alarm, drop the offending packet, and (for TCP) send Reset to both ends of the connection, if configured to do so. The alarm may be sent to a syslog server or to a Cisco NetRanger Director (central management graphical interface).

The list of signatures (and their numeric codes) can be found at the following documentation links.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/ios_ids.htm#xtocid20565127

Cisco IOS IDS is available on the Cisco 2600, 3600, 7100, and 7200 series routers.

Firewall Authentication Proxy

The Firewall Authentication Proxy feature allows Web-based logins to a RADIUS or TACACS+ server, without special client software. A dynamic access list from the AAA (RADIUS or TACACS+) server then can be used to specify per-user permissions and settings. For example, this might be used to provide different levels of access to internal devices to intranet and extranet users.

This feature is supported on the Cisco 2600, 3600, 7100, and 7200 series routers.

See also the Lock-And-Key feature (written up in another article), for telnet authentication that behaves similarly.

http://www.netcraftsmen.net/welcher/papers/lockkey.htm

Caution: the dynamic access list really is for the IP address of the user. Other users on the same machine and spoofed packets sourced from that address will also be allowed through the firewall by the dynamic access list.

Caution: there are browser dependencies to authentication proxy. See the documentation for details.

Port to Application Mapping

Port to Application Mapping allows you to over-ride the system defaults per-application and per-host or subnet. That means you can, for instance, configure the router to tell it that FTP or HTTP is operating on a non-standard port. CBAC will then be able to watch the application-specific traffic on that port to monitor for other ports opened and used by the application.

The one limitation to Port to Application Mapping (PAM) is that you cannot simply redefine ports already defined as system defaults. For example, FTP normally uses port 21. While you can tell CSIS that on some hosts FTP is using another port, say 421, you cannot tell CSIS that port 21 is in use for HTTP. What you can do is redefine system ports for some selected hosts, by using an access list.

Configuring CSIS

There are enough commands for configuring this that we don't have the space to go over the detailed syntax. So we'll have to settle for examples with some in-line comments.

CBAC Inspection

We start by configuring what outbound traffic to inspect, in order to be able to allow replies back in through the firewall router. (Note that the list is probably shorter than you would use in a real firewall, depending on your needs and preferences.) The inspection rules list will be named "myrules". We'll create an audit trail UDP connections.

ip inspect name myrules tcp
ip inspect name myrules udp audit-trail on
ip inspect name myrules smtp
ip inspect name myrules ftp timeout 120
ip inspect name myrules h323 timeout 30
ip inspect name myrules realaudio timeout 30
!
! Inspect some Sun RPC programs
ip inspect name myrules rpc program-number 100052
ip inspect name myrules rpc program-number 100053
!
! Keep a tight handle on fragments, max of 120 packets under reassembly
! at one time with timeout of 5 seconds
ip inspect name myrules fragment max 120 timeout 5
!
! Block Java from hosts on 192.16.20.0 /24
ip inspect name myrules http java-list 80
access-list 80 permit 192.16.20.0 0.0.0.255

We need to apply the inspection rule on an interface where it is applied in a direction that allows inspection of outbound traffic.

interface serial 0
ip address 192.16.70.1 255.255.255.0
ip inspect myrules out

If we have a reason to do so, we might instead configure:

interface ethernet 0
ip address 192.16.100.1 255.255.255.0
ip inspect myrules in

The point is that traffic leaving the site goes into the Ethernet interface and out the serial interface.

Once we've set up to monitor outbound traffic, we need a filter on inbound traffic. We'll deny all TCP and UDP traffic early in the list. We then permit certain ICMP traffic. We end with an explicit deny all other IP traffic. This example comes straight from the configuration guide. Strictly speaking, the deny TCP and UDP aren't needed, but they may make the list more efficient (general rule: catch much of your traffic at the top of an access list, to save linear search time). The point to allowing the ICMP messages is that some are useful error message replies to our users. We need to allow the packet-too-big message or ICMP MTU discovery will break, meaning that our users might experience occasional odd FTP or other errors.

access-list 105 deny TCP any any
access-list 105 deny UDP any any
access-list remark Our Ethernet subnet should not be the source of a packet from
access-list remark the Internet! Block spoofing
access-list 105 deny 192.16.100.0 0.0.0.255 any
access-list remark Denial of Service
access-list 105 deny host 255.255.255.255 any
access-list remark Permit necessary ICMP replies
access-list 105 permit icmp any any echo-reply
access-list 105 permit icmp any 192.16.100.0 0.0.0.255 time-exceeded
access-list 105 permit icmp any 192.16.100.0 0.0.0.255 traceroute
access-list 105 permit icmp any 192.16.100.0 0.0.0.255 unreachable
access-list remark Permit ICMP MTU discovery
access-list 105 permit icmp any 192.16.100.0 0.0.0.255 packet-too-big
access-list 105 deny ip any any

interface serial 0
ip access-group 105 in
no ip directed-broadcast

Adding this to our above configuration gets basic CBAC configured. The inspect command will cause temporary access list entries to be added to access list 105. If we had instead (or additionally) applied access list 105 outbound on Ethernet 0, the temporary entries would still be added.

Intrusion Detection

We will treat email to more than 20 recipients as spam and block it. We will also configure to send notifications to NetRanger Director, and also send them as syslog messages. The rmtaddress below specifies the remote Director address(es), localaddress the router's interface address. Preference is the priority of that particular route to the Director (primary = 1, secondary = 2).

! Specify global audit parameters
ip audit smtp spam 20
ip audit notify log
!
! Set up NetRanger Director parameters
ip audit notify nr-director
ip audit po local hostid 55 orgid 123
ip audit po remote hostid 14 orgid 123 rmtaddress 192.16.100.30 localaddress 192.16.100.1 preference 1
ip audit po remote hostid 14 orgid 123 rmtaddress 192.16.100.30 localaddress 192.16.70.1 preference 2

We also need to create a set of audit rules. In case of info message the action is to just send the message. In case of an attack message, send the alarm, drop the packet, and send resets. We apply the audit rules on interface s0 inbound.

ip audit name AUDIT-RULE info action alarm
ip audit name AUDIT-RULE attack action alarm drop reset
!
interface s0
ip audit AUDIT-RULE in

Instead we could set up the audit rules to filter out alarms for packets from a specific source, using an access-list:

ip audit name AUDIT.1 info list 90 action alarm
ip audit name AUDIT.1 attack list 90 action alarm drop reset
!
access-list 90 deny 172.16.16.16
access-list 90 permit any

This technique is useful if you're constantly getting false alarms due to network management or other traffic from specific hosts.

You can turn off DoS alarms for specific signatures.

ip audit signature 1234 disable

The list of numeric signatures can be found at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/ios_ids.htm#xtocid2056515

You can also apply filtering access lists to disabling DoS signatures, to turn them off for specific hosts or subnets. There may be a performance price to doing so:

ip audit signature 2345 list 91
ip audit signature 3456 list 91

Authentication-Proxy

Let's say we wish to use authentication proxy to authenticate our VPN users coming in from the Internet (probably IPSec encrypted, but going into all that is a topic for another article).

To turn on authentication proxy, you first need to enable (at least) basic AAA (RADIUS or TACACS+).

aaa new-model
aaa authentication login default tacacs+ radius
! New command to provide the authentication alternatives for default auth-proxy logins
aaa authorization auth-proxy default tacacs+ radius
! Define the TACACS+ server and key
tacacs-server host 192.16.100.20
tacacs-server key cisco
! Define the RADIUS server and key
radius-server host 192.16.100.21
radius-server key cisco

You then need to enable the HTTP server in the router. (Note: at the time of this writing, there has reportedly been a Cisco bug/security advisory about the HTTP server not doing safety checks on arguments, workaround for now is disabling it). In addition to enabling the router HTTP server, we specify web (HTTP) authentication via AAA.

ip http server
ip http authentication aaa

If desired, you can use an HTTP access class to further restrict web access (by source address) to the router.

We can then set up the global authentication proxy timeout and give a name to the HTTP authentication method. (Possibly to allow for other means of authentication in the future, for example telnet or FTP?). We apply the HTTP authentication method to the interface where the inbound web traffic should trigger authentication, namely Serial0.

ip auth-proxy auth-cache-time 60
ip auth-proxy name OurPeople http

interface s0
ip auth-proxy OurPeople

If you only want to authenticate for certain IP addresses, an access list can be specified in the ip auth-proxy name command.

One gotcha with this is if you have access lists between the AAA server and the router you configure this on. Your Web traffic has to initially get into the router, to allow authentication to then open up more ports. You also need for the router to be able send AAA to the AAA server and get replies back. In our example here, we definitely need to allow Web access to or through the router by adding the following line near the top of our access list:

access-list 105 permit tcp any 192.16.100.0 0.0.0.255 eq http
access-list 105 permit tcp any 192.16.70.1 0.0.0.0 eq http

There is a fairly comprehensive example of configuring authentication proxy, IPSec, NAT, and CBAC at

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iosfw2/iosfw2_1.htm#xtocid1618142

Use show ip access-lists to examine any temporary access list entries. There is also a debug ip auth-proxy command.

PAM

The following sample shows how to do port mapping.

! Map HTTP to port 21 for hosts 192.16.1.0 through .15
ip port-map http 21 list 40
access-list 40 permit 192.16.1.0 0.0.0.15

! Map HTTP globally to port 8080 for other hosts
ip port-map http 8080
! Map FTP globally to port 8021
ip port-map ftp 8021

To check your port mappings, there is the following command:

show ip port-map [appl_name | port port_num]

Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .