Firewall Feature Set and CBAC with Cisco Routers

Firewall Feature Set and CBAC with Cisco Routers [www.truman.net]

Cisco FWFS is available for most models of their routers, but because it can be very taxing on the routers, it is advisable to install it only where you need it. The control you have over sessions of communication inbound to your secure network is much better than relying on common ACLs. Even extended ACLs that are designed to filter down to port and flags (ie. possibly you permit established TCP ) are pale in comparison to the security enhancement of Context Based Access Control.

Setting this up in IOS in strait forward and you should find it easy to fine tune. In my examples here, you will see I am also using Network Address Translation. This is not required to make CBAC work, but could be looked at as an additional layer of security.

Hardware and Software

For this test I used a 2514 router with two 10BaseT interfaces. The IOS is 12.0(5)T. The full name of the image is : c2500-io-l.120-5.T.bin.

At this point we have a very basic layout. Since on Ethernet 1, I am running an address that is private as specified in RFC1918, I can not route it on the global Internet. The address must be translated into my public (although fictional) address of 1.2.3.1. You could easily define a pool of addresses for using NAT. In this case, for testing purposes it was not necessary to do this.

Define Network Address Translation

interface Ethernet0
ip nat outside

interface Ethernet1
ip nat inside

At this point we have specified which interfaces are doing NAT, and what will be considered "Inside" and "Outside". The Inside in this example will be our Secure Net, while the Outside is the public address of Ethernet 0. Next we need to define the global nat statement. Its looks like this:

ip nat inside source list secure-list interface Ethernet0 overload

NAT is almost fully setup now. In the previous global config line we defined a list called "secure-list". This list will be setup just like how an ACL is done. It will provide a means of permitting or denying particular networks, ports, or protocols to be sent throught the NAT process. Basically, it is this list of who gets NAT'd.

Our list looks like this :

ip access-list extended secure-list
permit tcp 192.168.2.0 0.0.0.255 any
permit udp 192.168.2.0 0.0.0.255 any
permit icmp 192.168.2.0 0.0.0.255 any

We are allowing protocols TCP, UDP, and ICMP from our Secure Net to be translated through NAT.

Begin Locking the Network Down

Our default policy will be to deny everything. CBAC works by permitting traffic and tracking sessions. When you watch a session as it leaves your interface, you will know which ports and sequence numbers are associated with it. CBAC will automatically open pinholes in your rulesets to allow established traffic back in, as well as track non-stateful protocols like UDP. Another big plus for CBAC is the inspecting of ftp sessions. Since both active and passive have been big headaches for many firewall admins, many have opened holes in their networks that are gaping wide. CBAC can allow data to return back in to specific hosts for specific ports while downloading a file via FTP. When you finish downloading, the ports close back up.

First we define a ruleset to permit a few icmp messages into our network, then we block everything.

access-list 111 permit icmp any any time-exceeded
access-list 111 permit icmp any any packet-too-big
access-list 111 permit icmp any any unreachable
access-list 111 deny ip any any log

Now that we have this ACL, we need to place it on an interface.

interface Ethernet0
ip access-group 111 in

At this point, any communication from the Internet to our Secure Net is denied except for the few ICMP messages that we allow in first. Next we need to setup our CBAC to do handle our dynamic ACLs.

CBAC and defining the IP inspection

Now we need to actually setup the ip inspection. This will be a list of the protocols to watch. As they are watched by the router, the ACLs will become dynamic to allow the return traffic. Here is how we define them :

ip inspect name secure-inspect tcp
ip inspect name secure-inspect udp
ip inspect name secure-inspect ftp
ip inspect name secure-inspect realaudio

You will notice that CBAC allows you to define both transport protocols like UDP and TCP as well as more specific application protocols like FTP and RealAudio. Just like an ACL, you need to apply the ip inspect name to an interface with a direction. Our example looks like this :

interface Ethernet0
description to Internet
ip inspect secure-inspect out

Since the secure-inspect ruleset is applied outbound, our packets that leave out of this interface will be 'inspected'.

Watching it in Action

You can watch the dynamic ACLs as they are created and removed by typing 'sh ip access-list 111'. We use '111' here since it is the default deny statement applied to our Ethernet0. You may also want to view the sessions that are being inspected at any given time. You can view these by running 'show ip inspect sessions'. This will show you the current Established Sessions and the Sessions that are timing out.

Additional Info

Cisco CBAC documentation

Originally published on truman.net. See the archived copy. The original page carried no date; this is the date it was first archived.