This tutorial will guide you through the configuration of a context-based access control (CBAC). A CBAC provides advanced traffic filtering and it gives the ability to inspect TCP and UDP packets based on the application-layer protocol session information. CBAC can be configured to permit specified traffic (TCP or UDP) only if the session was initiated from the inside network (secure network). But it’s not limited only to this. CBAC can also inspect the traffic that originates from either side of the router/firewall.

CBAC is a more advanced ACL implementation, as it allows us to examine the application layer of the packet to determine the state of the session.

For more information about CBAC, you can use this resource from the Cisco website. Working details and configuration details are here: Configuring Context-Based Access Control

For this simulation, I created two files:

  • configuring_cbac_init.pkt—This file contains the initial topology and configuration of the routers. The hosts (the PC and the SERVER) have full connectivity and no traffic is filtered.
  • configuring_cbac_final.pkt—This is the final configuration and you should use this to compare what you configured and confirm that you did everything correctly.

Regarding the topology, on the subnets where a PC/SERVER is connected, the router’s interface has an IP address whose last octet is .1 and last octet of the PC’s IP address is .100. The default gateway of the PC is the router’s IP address.

For instance, on the subnet with PC_2, PC_2 has the IP address of 10.10.20.100/24 and R3’s interface IP address is 10.10.20.1/24.

Each router has a loopback address in the form of 1.1.1.X/32, where X is the router number. For instance, the loopback address of R3 is 1.1.1.3/32.

Also, each subnet between the routers is written on the topology and every router is using as the last octet its router number. For instance, on the subnet 10.10.12.0/24, R2 has 10.10.12.2/24 and R1 has 10.10.12.1/24.

All three routers are running OSPF in area 0 so that the end host and the server will have connectivity between them.

The goal of the simulator is configure R3 so that will allow only traffic sent by PC_2 towards SERVER only if the traffic is initiated by PC_2.

We will consider as internal network/secure network the subnet 10.10.20.0/24 (the link between R3 and PC_2).

In order to test, one thing was preconfigured: The SYSLOG functionality was enabled on SERVER to receive CBAC alerts.

Task 1 requirements

  1. Start logging to the host 10.10.10.100.
  2. Configure an ACL on R3 to deny all the traffic, except OSPF traffic. Watch for the sequence order.
  3. Configure the ACL on R3 interface towards R2 on input direction.
  4. Create a CBAC inspection rule to inspect ICMP traffic.
  5. Create a CBAC inspection rule to inspect TELNET traffic.
  6. Configure CBAC to send audit trails.
  7. Configure the inspection rule on R3 interface towards R2 on output direction.

Task 1 verification

    1. Go to SERVER and from the Desktop/Command Prompt tab issue a ping to 10.10.20.100. This should fail. This should be logged on R3 console:
      *Mar 01, 00:25:35.2525: %FW-6-SESS_AUDIT_TRAIL_START: Start icmp session: initiator (10.10.23.3:0) — responder (10.10.10.100:0)
  1. While you are pinging from SERVER to PC_2, go to R3 and use the command “show ip inspect sessions.” You should get this output:
    R3#sh ip inspect sessions

    Established Sessions
    Session 231404928 (10.10.23.3:8)=>(10.10.10.100:0) icmp SIS_OPENING
    R3#

  2. Use the same window to initiate a TELNET session to PC_2. This should fail as well. You should get this message on SERVER command prompt:

    SERVER>telnet 10.10.20.100
    Trying 10.10.20.100 …
    % Connection timed out; remote host not responding
    SERVER>

  3. Go to PC_2 and from the Desktop/Command Prompt tab issue a ping to 10.10.10.100. This should be successful.
  4. While you are pinging from PC_2 to SERVER, go to R3 and use the command “show ip inspect sessions.” You should get this output:

    R3#sh ip inspect sessions
    Established Sessions
    Session 231405224 (10.10.20.100:8)=>(10.10.10.100:0) icmp SIS_OPEN
    R3#

  5. Use the same window to initiate a TELNET session to SERVER. TELNET service is not running on SERVER but the message displayed is different from step b. You should get this message:

    PC>telnet 10.10.10.100
    Trying 10.10.10.100 …
    % Connection refused by remote host
    PC>

  6. Go to PC_2 and from the Desktop/Web Browser tab, put the 10.10.10.100 address in the browser and confirm it’s not working. This is because HTTP traffic isn’t supposed to be inspected.

Task 1 hints:

  1. Use the command “logging 10.10.10.100” to start sending logs to 10.10.10.100
  2. Use the ACL to permit only OSPF traffic and drop any other traffic:

    ip access-list extended FROM_OUTSIDE
    permit ospf any any
    deny ip any any

  3. Use the command under F0/0 on R3 “ip access-group FROM_OUTSIDE in.”
  4. Use the command “ip inspect name INSPECTED_TRAFFIC icmp” to inspect ICMP traffic.
  5. Use the command “ip inspect name INSPECTED_TRAFFIC telnet” to inspect TELNET traffic.
  6. Use the command “ip inspect audit-trail” to start audit trails.
  7. Use the command under F0/0 on R3 “ip inspect INSPECTED_TRAFFIC out.”

As you can see, CBAC is pretty straightforward to configure if you understand how it works. The problems usually appear when the operator forgets to allow specific traffic through the firewall. For instance, is very easy to forget to allow OSPF traffic in the ACL. As you can imagine, this might lead to serious network problems.

Feel free to explore the other knobs available in Packet Tracer.