Context-Based Access Control (CBAC

The Context-Based Access Control (CBAC) feature of the Cisco IOS® Firewall Feature Set actively inspects the activity behind a firewall. CBAC specifies what traffic needs to be let in and what traffic needs to be let out by using access lists (in the same way that Cisco IOS uses access lists). However, CBAC access lists include ip inspect statements that allow the inspection of the protocol to make sure that it is not tampered with before the protocol goes to the systems behind the firewall.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). The issue with CBAC is that it takes lot of configurations when you have multipe interfaces this issues is solved by Zone base firewal which we will also discussed.

In this network we are running ospf in all the routers and there is full reachability between all the routers.

Lets verify that R3 has a complete routing table and can reach R loopbac.

Le us say that now we want to allow all traffic from the internal network to the external network but deny all traffic from the opposite direction unless it was a return traffic initiated from the internal network. Our solution is to use CBAC. Le us configure CBA on R2 F0/0.

R2(config)# ip access-list extended BLOCK_ALL

R2(config-ext-nacl)#permit ospf any any

R2(config-ext-nacl)#deny ip any any

R2(config-ext-nacl)#exi

R2(config)#int fastEthernet 0/0

R2(config-if)# ip access-list extended BLOCK_ALL

R2(config-ext-nacl)#

Since we are running OSPF we must allow ospf traffic otherwise our links will be down. With this configuration the internatl network can reach the external network but the return traffic will be block to alleviate this we call in CBAC.

R2(config)#ip inspect name ICMP icmp

R2(config)#int fastEthernet 0/0

R2(config-if)#ip inspect name ICMP icmp

Let us test.

From the above show command it is seen that the trusted host 192.168.23.3 has open an ICMP connection to 1.1.1.1. CBAC will then track the session until it is closed or the configured idle timer is reached.

Audit trail can also be enable to generate syslog messages for the CBAC session.

R2(config)#ip inspect audit-trail

R2(config)#

May 22 12:14:15.367: %FW-6-SESS_AUDIT_TRAIL_START: Start icmp session: initiator (192.168.23.3:8) -- responder (1.1.1.1:0)

Let us visit R2 and see whats happen at its end.

This is due to the fact that traffic originating from the router itself is not by default included in the inspection rule applied to the external interface. To fix this, we can  append the router-traffic argument to our inspection rule or use the local policy configuration.

R2(config)#ip inspect name ICMP icmp router-traffic

Now we can see that R2 can ping R1. We can also fix this issue by using local policy map.

R2(config)#ip access-list extended ALLOW_LOCAL

R2(config-ext-nacl)#permit ip any any

R2(config-ext-nacl)#exi

R2(config)#route-map LOCALTRAFFIC permit 10

R2(config-route-map)#match ip address ALLOW_LOCAL

R2(config-route-map)#set interface loopback 0

R2(config-route-map)#exi

R2(config)#ip local policy route-map LOCALTRAFFIC

With this configuration, local ping  traffic will re-enter the router and hit the outgoing inspection rule, thereby triggering a reflected entry.