You’ve got to have the Cisco IOS firewall set in the IOS to make use of Context-based Access control (CBAC), and the funny thing is, it’s rare to hear someone even Cisco differentiate between the two. People usually just refer to the Cisco IOS firewall and leave it at that. But what is it? Well, the CBAC’s job is to scrutinize any and all traffic that’s attempting to come through the firewall so it can find out about and control the state information for TCP and UDP sessions. And it uses that very information it’s gathered to determine whether to create a temporary pathway into the firewall’s access lists.
To make this happen, just configure ip inspect lists in the same direction the traffic is flowing. If you don’t do this, any return traffic won’t be able to get back through, which will negatively impact any session connections originating from inside the internal network in a big way.
Take a look at the picture below, which illustrates in a very simple way how the Cisco IOS firewall (CBAC) works.
A router that’s configured with the Cisco IOS firewall will process traffic in the following manner:
- First, if the inside ACL approves, the router will get all inside packets sent to it.
- Next, the approved traffic is subjected to the firewall’s ip to inspect the process, which adds the approved connection’s state information into the state table.
- Finally, the traffic passes through the IP inspect the process, which then creates a dynamic ACL entry and puts it into the outside ACL so that the return traffic will be allowed to pass back through the router.
We have this set on all of my routers, but to be able to do that you must also have the Cisco IOS firewall feature set up. We have the configuration set up this way because the authentication proxy is a good thing to have on your side. This is true because it authenticates inbound users, outbound users, or both. Those who would normally be blocked by an ACL can just bring up a browser to get through the firewall and then authenticate on a TACACA+ or RADIUS server.
Monitoring Access lists
Again, it’s always good to be able to verify a router’s configuration. The following table lists the commands that can be used to verify the configuration.
|Show access-list||Displays all access lists and their parameters configured on the router. This command does not show you which interface the list is set on.|
|Show access-list 110||Shows only the parameters for the access-list 110. This command does not show you the interface the list is set on.|
|Show ip access-list||Shows only the IP access lists configured on the router.|
|Show ip interface||Shows which interfaces have access lists set.|
|Show running-config||Shows the access lists and which interfaces have access lists set.|
|Show mac access-group||Displays MAC address lists applied to all layer 2 interfaces or the specified layer 2 interfaces (used on layer 2 switches only).|
We’ve already used the show running-config command to verify that a named access-list was in the router as well as a MAC access list on a layer 2 switch. So now let’s take a look at the output from some of the other commands.
The show access-list command will list all access lists on the router, whether they’re applied to an interface or not.
Lab_A#show access-list Standard IP access list 10 Deny 172.16.40.0, wildcard bits 0.0.0.255 Permit any Standard IP access list BlockSales Deny 172.16.40.0, wildcard bits 0.0.0.255 Permit any Extended IP access list 110 Deny tcp any host 172.16.30.5 eq ftp Deny tcp any host 172.16.30.5 eq telnet Permit ip any any Lab_A#
First, notice that both access-list 10 and our named access-list appear on this list. Second, notice that even though we entered actual numbers of TCP ports in access-list 110, the show command gives us the protocol names rather than TCP ports for readability. (hey, not everyone has them all memorized!)
Here’s the output of the show ip interface command:
lab_A#show ip interface e1 Ethernet1 is up, line protocol is up Internet address is 172.16.30.1/24 Broadcast address is 255.255.255.255 Address determined by non-volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is BlockSales Inbound access list is not set proxy ARP is enabled Security level is default Split horizon is enabled ICMP redirects are always sent ICMP unreachables are always sent ICMP mask replies are never sent IP fast switching is disabled IP fast switching on the same interface is disabled IP null turbo vector IP multicast fast switching is disabled IP multicast distributed fast switching is disabled Router discovery is disabled IP output packet accounting is disabled IP access violation accounting is disabled TCP/IP header compression is disabled RTP/IP header compression is disabled Probe proxy name replies are disabled Policy routing is disabled Network address translation is disabled Web cache redirect is disabled BGP policy mapping is disabled Lab_A#
Be sure to notice the bold line indicating that the outgoing list on this interface is Block Sales but the inbound access list isn’t set.
As we’ve already mentioned, you can use the show running-config command to see any and all access lists. However, on a layer 2 switch, you can verify your interface configurations with the show mac access-group command.
S1#sh mac access-group Interface FastEthernet0/1: Inbound access-list is not set Outbound access-list is not set Interface FastEthernet0/2: Inbound access-list is not set Outbound access-list is not set S1#
Depending on how many interfaces you set your MAC access lists on, you can use the interface command to view individual interfaces.
S1#sh mac access-group interface f0/6 Interface FastEthernet0/6: Inbound Outbound access-list is not setaccess-list is Todd_MAC_List