IOS Context-Based Access Control (CBAC)
By stretch | Tuesday, March 10, 2009 at 12:00 p.m. UTC
Cisco's Context-Based Access Control (CBAC) is a component of the IOS firewall feature set. Similar to reflexive ACLs, CBAC enables dynamic modification of access lists to allow certain incoming flows by first inspecting and recording flows initiated from the protected internal network. However, whereas reflexive ACLs act solely on L2-L4 protocol attributes, CBAC is able to inspect all the way to the application layer, taking into consideration characteristics of a flow on a per-protocol basis (or context).
Rather than over-analyzing CBAC operation in this article, I offer a simple scenario: a router with exactly two interfaces (one internal and one external) placed between two networks, one trusted (internal) and one untrusted (external). Our goal is to configure the router to protect the trusted network (typically a LAN or enterprise network) from the untrusted network (in our example, the Internet).
From the conceptual illustration, we see that there are four logical points (marked in blue) at which the router can inspect traffic:
- Inbound on the internal interface
- Outbound on the external interface
- Inbound on the external interface
- Outbound on the internal interface
While we can deploy independent, static ACLs at one, some, or all of these points simultaneously, CBAC is configured and operates per interface, dynamically modifying ACL entries facing one direction based on the traffic it sees flowing in the opposite direction.
For example, let's assume we first want to allow by default all traffic traversing the router from the internal LAN (192.168.0.0/24) toward the Internet (for our purposes, 10.0.0.0/8). This is already the case, as the router will of course forward all routable traffic when no access restrictions have been applied. We also want to deny by default all traffic flowing from the Internet toward the LAN; to accomplish this we can use a simple ACL to deny all IP traffic. We'll apply it to the external interface in the inbound direction (versus the internal interface outbound) so that the router itself is protected from untrusted traffic as well.
R1(config)# ip access-list extended DENY_ALL R1(config-ext-nacl)# deny ip any any R1(config-ext-nacl)# exit R1(config)# interface f0/0 R1(config-if)# ip access-group DENY_ALL in
Note that an extended ACL is used here; more on that in a bit.
At this point, traffic can flow uninhibited from our trusted network to the untrusted network, but is completely blocked in the opposite direction. Not great if you favor bidirectional communication.
For instance, assume we now want to allow web access initiated from the internal network to return. One option would be to configure a more granular ACL in place of DENY_ALL, but that would not provide stateful tracking and may open a security hole. Another option would be to implement a reflexive ACL, but that would provide only limited state tracking. A more powerful solution is CBAC.
CBAC allows us to define an inspection rule for each protocol we want to monitor. In this case, we want to track HTTP and HTTPS sessions, so we create the following rule named "Web":
R1(config)# ip inspect name Web http R1(config)# ip inspect name Web https
There are additional options per protocol, but for now we'll accept their defaults. Next we need to apply our inspection rule to an interface and in a particular direction. We apply the rule outbound on the external interface because:
- We want to inspect traffic originating from the trusted network, and
- We want to dynamically adjust the ACL restricting traffic inbound on the external interface.
This is done with the
ip inspect command at interface configuration:
R1(config)# interface f0/0 R1(config-if)# ip inspect Web out
The CBAC configuration can be verified with
show ip inspect all:
R1# show ip inspect all Session audit trail is enabled Session alert is enabled one-minute (sampling period) thresholds are [400:500] connections max-incomplete sessions thresholds are [400:500] max-incomplete tcp connections per host is 50. Block-time 0 minute. tcp synwait-time is 30 sec -- tcp finwait-time is 5 sec tcp idle-time is 3600 sec -- udp idle-time is 30 sec dns-timeout is 5 sec Inspection Rule Configuration Inspection name WEB http alert is on audit-trail is on timeout 3600 https alert is on audit-trail is on timeout 3600 Inspection name Web http alert is on audit-trail is on timeout 3600 https alert is on audit-trail is on timeout 3600 Interface Configuration Interface FastEthernet0/0 Inbound inspection rule is not set Outgoing inspection rule is Web http alert is on audit-trail is on timeout 3600 https alert is on audit-trail is on timeout 3600 Inbound access list is DENY_ALL Outgoing access list is not set
We've now enabled CBAC in one direction for HTTP and HTTPS traffic on this interface. Outbound traffic (going toward the Internet) is tracked as CBAC sessions, and the DENY_ALL extended ACL restricting inbound traffic is automatically modified to accommodate legitimate return traffic. We can see CBAC in action when a host and the trusted network initiates an HTTP connection to a web server on the Internet:
R1# show ip inspect sessions Established Sessions Session 66E4E40C (192.168.0.2:12078)=>(10.0.0.2:80) http SIS_OPEN
From the output of
show ip inspect sessions we can see that the trusted host 192.168.0.2 has opened an HTTP connection to 10.0.0.2. CBAC will continue to track this session until it is closed by either end, or the configured idle timer is reached.
When the session was initiated, CBAC automatically created an entry at the top of the DENY_ALL ACL in preparation for the legitimate return traffic.
We can enable audit trails to generate syslog messages for each CBAC session creation and deletion:
R1(config)# ip inspect audit-trail R1(config)# %FW-6-SESS_AUDIT_TRAIL_START: Start http session: initiator (192.168.0.2:12078) -- responder (10.0.0.2:80)
Or, for even more verbosity, we can debug CBAC object creation:
R1# debug ip inspect object-creation INSPECT Object Creations debugging is on R1# CBAC* OBJ_CREATE: Pak 6621F7A0 sis 66E4E154 initiator_addr (192.168.0.2:12078) responder_addr (10.0.0.2:80) initiator_alt_addr (192.168.0.2:12078) responder_alt_addr (10.0.0.2:80) CBAC OBJ-CREATE: sid 66E684B0 acl DENY_ALL Prot: tcp Src 10.0.0.2 Port [80:80] Dst 192.168.0.2 Port [12078:12078] CBAC OBJ_CREATE: create host entry 66E568DC addr 10.0.0.2 bucket 8 (vrf 0:0) insp_cb 0x66B61C0C
Of course there's far more to CBAC than we've covered here, but hopefully this example provides a decent illustration of the concept.
About the Author
Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.
Posted in Security
March 10, 2009 at 3:17 p.m. UTC
Hey Jeremy! Thanks for making this post. I use CBAC at dozens of sites as the Internet perimeter firewall.
A lot of folks ask what the difference is between reflexive access lists and CBAC is. The most important difference is CBAC has application awareness, so it can modify packets for applications that normally do not work with NAT. For example, FTP uses multiple ports, and imbeds the port number into a FTP packet. So with reflexive ACLs you cannot use active FTP through the firewall. However, CBAC will go inside the packet, see the port that needs to be opened, and open it. PPTP does the same with GRE, and H.323 video imbeds the internal IP address inside the H.323 packet, so CBAC needs to go in there and change the IP address.
In short, reflexive ACLs work great for HTTP and most “normal” traffic, but users will not be happy with just reflexive ACLs for a firewall; you need to use CBAC.
March 10, 2009 at 8:31 p.m. UTC
so... if I have site to site VPN connections, and access lists to allow GRE, I could maybe streamline this by using CBAC ?
ip access-list extended Shader_VPN_1 permit gre host xx.xx.xx.xx host yy.yy.yy.yy
March 10, 2009 at 9:20 p.m. UTC
Nice one Stretch, pretty cool.
March 11, 2009 at 5:23 a.m. UTC
The example you used to explain CBAC was quite awesome. I am sure no one would ever ask the question "What are CBACs?" again.
Thanks a ton.
March 11, 2009 at 7:58 a.m. UTC
Very good and well explained article. Only one point is not accurate any more. CBAC doesn't modify the ACLs any more. All is taken from the session-table which is evaluated earlier then the ACL. If I remember right, it was 12.2(8)T where Cisco made this change under the name "CBAC performance improvements".
Your visualization is great again. You (and Greg Ferro) are my grafics-heros! :-)
March 11, 2009 at 12:26 p.m. UTC
Great article. Now that the mystery of CBAC is solved, I look forward to the sequel on Zone Based Firewalls since that is Cisco's new buzz word. :)
March 11, 2009 at 4:10 p.m. UTC
Great article as usual, Jeremy.
CBAC works great for network perimeters (read: Internet), but, since you can't share inspection information between routers (or can you?), any dual-headed perimeter may block unexpectedly. I'm thinking of something like 2 routers running BGP to the Internet; you may have a preferred route over router A, but the return path may prefer router B which has no record of the session and drop the packet.
March 11, 2009 at 8:47 p.m. UTC
Zone Base Firewalls Replace CBAC :)
March 12, 2009 at 10:32 a.m. UTC
Don't get me started about Zone based firewall, one of the most poorly implemented things in recent years by Cisco. Perticularly it's usage with their GUI tools and DHCP...
March 12, 2009 at 12:34 p.m. UTC
While Zone Firewall will eventually replace and supercede CBAC (CBAC will not receive any new features), currently it does not support every feature (like IOS Firewall Failover, etc.)...
March 12, 2009 at 1:04 p.m. UTC
Articles like this are the reason I hit up this site every morning; clear, concise, well-documented explanations of a non-basic networking concept.
March 12, 2009 at 8:10 p.m. UTC
I have to correct my comment: It was 12.3(4)T and the feature is named "Firewall ACL Bypass".
@Aaron: There is SSO-Support for CBAC. But that's probably not exactly what you are looking for: IOS Firewall Stateful Failover
March 14, 2009 at 12:09 p.m. UTC
Hi Stretch, That was faboulous and I realy liked it like always. My quesiton could be a little out of the topic but believe it's really because of the sheer love for this website. The sidebar seems to be overflowing the sidebar content towards the ( i guess the width of the reight sidebar is something to do with. Can you just fix that, though I tried my best not to write about it , but I have been enjoying packetlife for the content and sometime's for the great simplistic design you have here and that overflowing sidebar just seems to bug me a lot. He he ( Cheers ! ) and thanks as always. 0_o
March 15, 2009 at 5:51 p.m. UTC
Thank's Jeremy!!!! Good stuff!
March 16, 2009 at 2:47 p.m. UTC
As always a very nice article.
March 16, 2009 at 8:16 p.m. UTC
Thank´s for the article!!! Very good.
March 27, 2009 at 3:44 p.m. UTC
Nice work, have been reading your blog for quiet some time. It is really good.
April 1, 2009 at 4:38 p.m. UTC
Very nice, Simply delicious article.
August 11, 2009 at 8:18 p.m. UTC
Nicely documented. I used CBAC on my network and just like the other users here, I started looking at Zone base firewall. It looks intimidating to setup on CLI but I think I can manage it. My question for the users in these forum is regarding VOIP. As some of us are aware, VOIP protocols like H.323 requires you to open up tons of tcp and udp ports in which I am not confortable of of opening these huge holes on my network.. Would zone base firewall help me with this issue? I have looked at CBAC briefly and as far as I can tell CBAC will not be able to help. I believe an ASA can do these but I am curious to know if I can achieve this using zonebase firewall since I am comfortable with my ISR routers. thanks
August 28, 2009 at 7:50 a.m. UTC
Great Article ....
November 3, 2009 at 11:23 p.m. UTC
You helped me secure my router. Thanks!
Under the circumstances, I don't think I'll add my URL. ;)
February 24, 2010 at 11:48 p.m. UTC
R1(config-ext-nacl)# deny ip any any
Not trying to be an as* but this is not necessary because an acl has an identical implicit deny at the end :) Anyway good job with this site.
February 24, 2010 at 11:51 p.m. UTC
@Anon: The ACE is added explicitly in the example for clarity.
February 26, 2010 at 12:59 a.m. UTC
Thanks for such clear and understandable material. This is quite good and it did help me understand this technology. thanks for taking the time to do this.
March 18, 2011 at 2:13 p.m. UTC
great..u make my life easier :)
April 1, 2011 at 8:54 a.m. UTC
That was just.. great ;)
April 29, 2011 at 8:45 p.m. UTC
Hi Jeremy ,
Thanks for article -- got me some way along with trying to figure this out.
My situation is a bit more complex. ( OK for a dumbass )
I have one dynamic IP and using NAT with PAT ( and two Vlans )
Trying to set up FTP ( Active and PASV ) in this situation with CBAC ( not sure if it can be done , I find so much info that seems to be contradictory ? )
I can get it all working with a normal ACL but CBAC FTP breaks it ?
Going around in circles at the moment.
July 25, 2011 at 3:42 p.m. UTC
Thank you for the info. I've been searching the internet for a few hours to discover the low down on the configuration of the firewall relating to the use of access-lists and the IP inspect rules that allow return traffic. I am now confident that I can protect my inside hosts.
Your diagrams are, as Mr. Lammle would say, cool.
I don't want to thank you as many times as Rupert has apologised, but until next time - Thanks
March 10, 2012 at 4:02 p.m. UTC
The best CBAC explanation I found. Very helpful for me
March 30, 2012 at 4:16 a.m. UTC
Thanks for the share J! Can we apply it to f0/1 instead f0/0?
May 24, 2012 at 8:45 p.m. UTC
Someone told me that CBAC is not supported on certain devices like switches. I don't have a lab right now to try it on. Does anyone if this is true or false? I would think anything running K9 code would be fair game to run CBAC but I'm looking for a definitive word. Google didn't give me a strong answer either way.
September 11, 2012 at 12:19 p.m. UTC
it will look something like this on the inside interface
ip access-group 123 out ip inspect TRUSTED in duplex auto speed auto
September 20, 2012 at 6:22 a.m. UTC
Best CBAC explanation I ever read. Very helpful for Beginners especially
December 2, 2012 at 6:34 a.m. UTC
I have a doubt which i need clarification on :
When said that CBAC is able to inspect all the way to the application layer, is this inspection a default feature of CBAC or is it turned on when we specify the (IP INSPECT name IN/OUT) command under the interface.
Also if it is turned based on the IP INSPECT command, then is the application layer reading for that protocol also done in the direction only mentioned in the IP INSPECT command or is it a completely different matter.
Would highly appreciate any help here.
September 16, 2013 at 9:19 a.m. UTC
Thank you so much for this article, great work.
May 16, 2014 at 3:26 p.m. UTC
Thank you for this explanation, it has helped me a lot.
June 27, 2016 at 10:06 a.m. UTC
Thankyou very much