Context-based access control is a firewall software feature that intelligently filters TCP and UDP packets based on application layer protocol session information. 

CBAC can be configured only to allow specified TCP and UDP traffic through a firewall when the connection is initiated from the protected network. (In other words, CBAC can inspect session traffic from an external network.) CBAC can inspect traffic for sessions from inside and outside the firewall. This is the fundamental function of a firewall with the stateful inspection.

Without CBAC, traffic filtering is restricted to access list implementations that examine packets at the network or transport layers. To determine the state of the TCP or UDP session, CBAC examines network layer and transport layer information and application-layer protocol information (such as FTP connection information). This enables support for protocols with multiple channels created due to FTP control channel negotiations. Multiple control channels are utilized by the majority of multimedia protocols as well as certain other protocols such as FTP, RPC, and SQL*Net.

CBAC examines firewall-passed traffic to discover and manage state information for TCP and UDP sessions. This information creates temporary openings in the firewall’s access lists to permit return traffic and additional data connections for authorized sessions (sessions that originated from within the protected internal network).

CBAC operates through deep packet inspection, which is why Cisco’s Internetwork Operating System refers to it as the “IOS firewall” (IOS).

CBAC enables dynamic modification of inbound access lists to permit specific incoming flows, even if a “deny any any” ACL has been implemented, by inspecting and recording flows initiated from the protected internal network. The primary difference between CBAC and reflexive ACLs is that CBAC can inspect all the way up to the application layer (layer 7), taking into account the characteristics of a flow on a per-protocol (or context) basis. In contrast, reflexive ACLs only act on L2-L4 protocol attributes.

CBAC also offers the following advantages:

  • Prevention and detection of denial-of-service.
  • Alerts in real-time and audit trails.

Context-based access control Lab

Context-based access control Explained

The diagram above will show how our lab is set up. We’re going to assume that one interface is in our LAN (e0/1)and the other is in the WAN(e0/0). Initial configuration is listed below:

Initial Configurations

!
hostname PC-1
!
enable secret 5 $1$linM$Iz2Erv0h9LX9pZy/8FEJy.
!
interface Ethernet0/0
ip address 10.1.1.2 255.255.255.0
duplex auto
!
ip route 0.0.0.0 0.0.0.0 10.1.1.254

!
hostname INTRA-NET
!
interface Ethernet0/0
ip address 10.1.1.1 255.255.255.0
duplex auto
!
ip http server
!
ip route 0.0.0.0 0.0.0.0 10.1.1.254
!

!
hostname IOS-FW
!
interface Ethernet0/0
ip address 99.1.1.254 255.255.255.0
duplex auto
!
interface Ethernet0/1
ip address 10.1.1.254 255.255.255.0
duplex auto
!
IP routing

!
hostname WEB-SERVER-1
!
multilink bundle-name authenticated
!
interface Ethernet0/0
ip address 99.1.1.1 255.255.255.0
duplex auto
!
ip http server
!
ip route 0.0.0.0 0.0.0.0 99.1.1.254
!

!
hostname PC-02
!
enable secret 5 $1$5ypE$mIi4DR69VddLm8MygMmCK0
!
interface Ethernet0/0
ip address 99.1.1.2 255.255.255.0
duplex auto
!
ip route 0.0.0.0 0.0.0.0 99.1.1.254

Let’s ping from inside to outside and back again to check the connectivity..

PC-1#ping 99.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/19 ms
PC-1#ping 99.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/12 ms
PC-02#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/10 ms
PC-02#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/7 ms
PC-02#

To protect the network, let’s put an extended access list on the outside-facing interface and block communication from the outside to the inside. I have enabled logging to the console too.

IOS-FW(config)#ip access-list ext BLK-OUT-IN
IOS-FW(config-ext-nacl)#deny ip any any log
IOS-FW(config-ext-nacl)#!
IOS-FW(config-ext-nacl)#int e0/0
IOS-FW(config-if)#ip access-group BLK-OUT-IN in

First, lts ping from outside PC-02 to inside resource and see what happens.

PC-02#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
!--------------------------------------
IOS-FW(config-if)#
*Jan 15 15:48:54.472: %SEC-6-IPACCESSLOGDP: list BLK-OUT-IN denied icmp 99.1.1.2                                      -> 10.1.1.2 (0/0), 1 packet

From the outside, we can’t get to what’s inside. Now let’s try to reach from the inside to the outside and see what happens.

PC-1#ping 99.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!----------------------
IOS-FW(config)#
*Jan 17 12:22:08.286: %SEC-6-IPACCESSLOGDP: list BLK-OUT-IN denied icmp 99.1.1.1 -> 10.1.1.2 (0/0), 1 packet
!----------------------
PC-1#
PC-1#ping 99.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 99.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
!----------------------
IOS-FW(config)#
*Jan 17 12:22:56.848: %SEC-6-IPACCESSLOGDP: list BLK-OUT-IN denied icmp 99.1.1.2 -> 10.1.1.2 (0/0), 1 packet

Even from the inside, we cannot access the external. We do not desire this outcome. CBAC should now be implemented.

IOS-FW(config)#ip inspect name IOS-FW tcp
IOS-FW(config)#ip inspect name IOS-FW udp
IOS-FW(config)#ip inspect name IOS-FW icmp
IOS-FW(config)#
IOS-FW(config)#int e0/0
IOS-FW(config-if)#ip inspect IOS-FW out
IOS-FW(config-if)#

After applying the above ACL, we can reach the outside from the inside. show ip inspect sessions output shows the protocols that should be inspected by CBAC and the corresponding idle timeouts for each protocol.

PC-1#telnet 99.1.1.1 80
Trying 99.1.1.1, 80 ... Open
!--------------------------
IOS-FW#show ip inspect sessions
Established Sessions
 Session C5FA1C48 (10.1.1.2:11796)=>(99.1.1.1:80) tcp SIS_OPEN

!--------------------------
PC-1#ping 99.1.1.2 repeat 1000
Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 99.1.1.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!--------------------------
IOS-FW#show ip inspect sessions
Established Sessions
 Session C5FA1C48 (10.1.1.2:8)=>(99.1.1.2:0) icmp SIS_OPEN
IOS-FW#

but from outside to inside, communication is still blocked.

WEB-SERVER-1#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
!--------------------------
IOS-FW#
*Jan 17 12:49:33.730: %SEC-6-IPACCESSLOGDP: list BLK-OUT-IN denied icmp 99.1.1.1 -> 10.1.1.1 (8/0), 1 packet
!--------------------------
IOS-FW#
*Jan 17 12:50:00.147: %SEC-6-IPACCESSLOGDP: list BLK-OUT-IN denied icmp 99.1.1.1 -> 10.1.1.2 (8/0), 1 packet
IOS-FW#
!--------------------------
WEB-SERVER-1#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
WEB-SERVER-1#

to warp it up, CBAC, which stands for “Context-Based Access Control,” is a firewall for Cisco IOS routers with more features than a simple “access-list.” CBAC can check up to layer 7 of the OSI model and make rules on the fly to let traffic go back. It is similar to the reflexive access list, but one big difference is that the reflexive ACL only checks up to layer 4.

You can check the reflexive access-list lab here