What are the possible Context-Based Access Control deployment scenarios?

Now that we have seen in part I and part II of this series how Context-Based Access Control works, the ultimate question is: what is CBAC good for and what are the possible scenarios for CBAC deployment on a network?

As seen in the two previous installments of this Context-Based Access Control tutorial, Context-Based Access Control is an interesting feature that provides good session inspection and can be used to build a stateful inspection firewall.

Remember that this CBAC feature is used on a generic Cisco IOS router so as to have a stateful firewall out of a generic cisco IOS router. The idea is to have network segments like INSIDE where outgoing traffic is inspected and all return traffic is dynamically permitted back in while traffic originating in non-trusted segments like the Internet is denied unless specifically permitted by the network administrator.

Correctly deployed on an edge or border router, Context-Based Access Control will result in better protection for users, hosts and servers in a chosen area against various attack vectors like SYN-flood and others that could originate from a less trusted area. We will remember that traffic inspection is done on flows between two distinct areas. When the candidate CBAC router has three interfaces for example, the CBAC engine would be configured to manage three different inspection directions or area pairs: inside to internet, internet to DMZ and inside to DMZ, for example.

Let it be noted that we chose to use the word “area” instead of “zone” because, in an enhancement effort, Cisco has developed another advanced feature, Zone Based Policy Firewall, that makes it easy to configure a full inspection firewall on routers with more than two areas to manage. With that feature, zone pairs and traffic directions in those zones are easier to configure than with Context-Based Access Control. But let’s not digress, that feature will be covered eventually in some of our future tutorials.

Maintaining and Monitoring CBAC

Put here the GNS files @ 010 - CISCO IOS FIREWALL (STATEFUL) – Context-Based Access Control (CBAC) - debug ip inspect and show command

Various tools and commands exist to maintain and monitor the Context-Based Access Control stateful firewall. Let’s start by looking into the debug command.

We temporary enable the debug tool on the inspection engine by issuing the debug ip inspect icmp command:

After the debug tool is put on the inspection engine, let us do two traceroute tests: one sourced from the outgoing interface FE0/0 (default) and the second sourced from the loopback interface lo1.

From the inside router, every host in the way is sent three probes (by default) and every host in the way sends back three probe responses (one probe response for each probe received).

This is seen on the CBAC router since the debug ip inspect icmp command was previously issued on the CBAC router.

When only one probe is sent to every host/node in the way, the inside router will get only one probe response from the hosts/nodes in the way.

The debug on the CBAC router will show only one probe response coming from every node/host outside.

Were there two outside nodes like outside_router and outside_router_2…

One probe sent to the outermost router from the inside router would get three probe answers:

And the CBAC edge router would see two probe answers, one from the outside_ router and the other from the outermost router outside_router_2 (provided the debug ip inspect icmp command was issued on the CBAC router).

There is however one noticeable difference between the two packets sent by the responding routers. One is sending “Time Exceeded” packets as probe response and the other is sending “Unreachable” packets. The final destination of the ICMP probes is outside_router_2 but since it’s in the path (intermediate node) it will also send probe responses as per the traceroute standard. Due to the traceroute inner workings, intermediate nodes will send back “Time Exceeded” packets as probe responses and final destination nodes like outside_router_2 will send back “unreachable” packets as probe responses. Hence the difference noted in the probe responses seen above.

As a generalization, n probes sent by a probe source to a host m hops away will trigger n*m probe responses. In our case here, one probe sent to the outside_router_2 that is three hops away will trigger three probe responses, but the debug ip inspect icmp on the CBAC router only shows two probe responses because its own probe response is not shown on the debug output since it is not subject to the inspect policy applied on the CBAC router.

Let’s see what output the CBAC router (with debug ip inspect icmp turned on) shows us when performing a ping test.

With one ping probe only:

Here is the ip inspect’s debug output as seen on the CBAC router:

With two ping probes only:

Here is what we see as the debug output:

And with three ping probes:

The CBAC router shows the following output:

In summary,

– The inside router sends three times the first “Echo” and receives one “Echo Reply.”

– Each consecutive “Echo” packet(s) from the inside router receives one “Echo Reply.”

Note how the debug ip inspect tool is a very poweful and information rich tool as shown by the number of additional options we can add to this command to get specific details.

Let’s say we want to see in the debug messages how the inspection engine starts and ends new sessions.

Issuing the command debug ip inspect object-creation will let us see new session creations only.

Let us send two ping probes sourced from lo1 on the inside router to the outside_router_2:

Adding the command debug ip inspect object-deletion will show us the end of sessions as well.

The same ping test triggers the following output where we can see sessions building up and getting torn down upon session termination.

Remember the function of the timers within Context-Based Access Control? Since our ping test is a pure ICMP test, unlike with the TCP sessions, there is no flag in the packets to indicate a session closed by the session initiator (inside router) so the engine relies on the timers to close the session after witnessing session inactivity.

We can see this by enabling the timers debugging with the debug ip inspect timers command and then doing a ping test.

We are now seeing the addition and deletion of sessions and on top of that, we see timers set and expiring:

The usual package of show commands will help us in checking our configurations and seeing what is going on.

Choosing the config option of the show command, we can see on our LAB example that:

  • No audit trail was configured but alerts were.
  • Thresholdings (one-minute and max-incomplete) were not configured. They should absolutely be configured by a conscious administrator.
  • The timeouts are set to the values shown. Adjust them to your liking as an administrator.
  • And finally, the inspection rules for the transit and own-generated traffic.

Choosing the interface option of the show ip inspect command will give us the same information and more, but this time organized “interface-wise”.

We can also view the CBAC settings organized name-wise. Remember that I had named my inspect rule CBAC_INTENSE_SCHOOL but now it is truncated to CBAC_INTENSE_SCH. This should not stand in our way because both _SCH, _SCHO, _SCHOO and SCHOOL are accepted as seen below:

However, the following will not be accepted:

So beware of the name structure.

As for the current sessions on the CBAC engine, they can be displayed with show ip inspect sessions. We first ping from the inside router to have a session open on the CBAC router:

We then check what we see on the CBAC router. The show ip inspect sessions command was repeated multiple times until the timers expire. On the last iteration of the command we don’t see any session open.

Another useful show command is show ip inspect statistics. On our router, with the last tests we have been running, here is what the stats say:

Unless we want to be shown everything, in which case the show ip inspect all is recommended.

Since the Context-Based Access Control setup uses access control lists, another mandatory debugging tool is show access-list:

For example, my ping tests from the outside_router to the inside router’s lo1 will fail with unreachable ICMP messages (shown by the UUUUU probe response).

Show access-lists, before these pings, was not showing any matches for the deny ip any any log statement in my CBAC_INTENSE_SCHOOL_OUTSIDE_IN access list:

However, after the pings, we notice two things:

show access-lists is now announcing 5 matches.

– And the console logs are now displaying a total of 5 ICMP packets denied by the CBAC_INTENSE_SCHOOL_OUTSIDE_IN access list.

A good troubleshooter always utilizes various commands like debug, show, the console logs and even a dedicated syslog server to be able to play the smart detective within the network.

A combination of multiple tools and commands will allow the administrator to quickly and efficiently pinpoint misconfigurations and malfunctioning of the CBAC router.

In this tutorial, our focus was mainly on monitoring and maintaining the Context-Based Access Control stateful firewall. A couple of aspects of this feature have not yet been discussed. These include Port Address Mapping (for applications running on non-standard ports), audit-trail configuration and, for those looking for a challenge, a Context-Based Access Control stateful firewall with three interfaces.

The latter would allow us to understand how the Zone Based Policy Firewall is an enhancement to the Context-Based Access Control stateful firewall as far as the number of interfaces and zones they manage are concerned.

I will recommend the reader to stay put for these final three features coming soon in the last installment of our tutorial for Context-Based Access Control stateful firewall.