Context-Based Access Control

Context-Based Access Control

Context-Based Access Control (CBAC) is a component of the Cisco IOS which acts as stateful and application firewall that can filter traffic at Network layer (IP addresses and protocols), Transport layer (ports, TCP and UDP sessions), Session layer (the state of the conversation), and the Application layer (protocols for specific applications, as well as multi-channel applications like FTP).

What CBAC Can Do

Context-Based Access Control works to provide network protection on multiple levels using the following functions:

Traffic Filtering

CBAC intelligently filters TCP and UDP packets based on application-layer protocol session information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. CBAC can inspect traffic for sessions that originate from either side of the firewall, and CBAC can be used for intranet, extranet, and Internet perimeters of your network.

Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer. However, CBAC not only examines the network layer and transport layer information but also examines the application-layer protocol information (such as FTP connection information) to learn about the state of the session. This allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels.

Traffic Inspection

CBAC inspects traffic that travels through the firewall to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall’s access lists to allow return traffic and additional data connections for permissible sessions.

Inspecting packets at the application layer, and maintaining TCP and UDP session information, provides CBAC with the ability to detect and prevent certain types of network attacks such as SYN-flooding. A SYN-flood attack occurs when a network attacker floods a server with onslaught requests for connection and does not complete the connection. The resulting volume of half-open connections can overwhelm the server, causing it to deny service to valid requests. Network attacks that deny access to a network device are called denial-of-service (DoS) attacks.

CBAC helps to protect against DoS attacks in other ways. CBAC inspects packet sequence numbers in TCP connections to see if they are within expected ranges and then drops any suspicious packets. You can also configure CBAC to drop half-open connections, which require firewall processing and memory resources to maintain. Additionally, CBAC can detect unusually high rates of new connections and issue alert messages.

Alerts and Audit Trails

CBAC also generates real-time alerts and audit trails. Enhanced audit trail features use SYSLOG to track all network transactions; recording time stamps, source host, destination host, ports used, and the total number of transmitted bytes, for advanced session-based reporting. Real-time alerts send SYSLOG error messages to central management consoles upon detecting suspicious activity. Using CBAC inspection rules, you can configure alerts and audit trail information on a per-application protocol basis. For example, if you want to generate audit trail information for HTTP traffic, you can specify that in the CBAC rule covering HTTP inspection.

Intrusion Prevention

CBAC provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, SYSLOG messages are reviewed and monitored for specific “attack signatures”. Certain types of network attacks have specific characteristics or signatures. When CBAC detects an attacks, it resets the offending connections and sends SYSLOG information to the SYSLOG server.

What CBAC Can Not Do

CBAC does not provide intelligent filtering for all protocols; it only works for the protocols that you specify. If you do not specify a certain protocol for CBAC, the existing access lists will determine how that protocol is filtered. No temporary openings will be created for protocols not specified for CBAC inspection.

CBAC does not protect against attacks originating from within the protected network unless that traffic travels through a router that has the Cisco IOS Firewall feature set deployed on it. CBAC only detects and protects against attacks that travel through the firewall. This is a scenario in which you might want to deploy CBAC on an intranet-based router.

CBAC protects against certain types of attacks, but not every type of attack. CBAC should not be considered a perfect, impenetrable defense. Determined, skilled attackers might be able to launch effective attacks. While there is no such thing as a perfect defense, CBAC detects and prevents most of the popular attacks on your network.

How CBAC Works

CBAC creates temporary openings in access lists at firewall interfaces. These openings are created when specified traffic exits your internal network through the firewall. The openings allow returning traffic (that would normally be blocked) and additional data channels to enter your internal network back through the firewall. The traffic is allowed back through the firewall only if it is part of the same session as the original traffic that triggered CBAC when exiting through the firewall.

The CBAC Process

A TCP packet exits the internal network through the firewall’s external interface. The TCP packet is the first packet of a Telnet session and TCP is configured for CBAC inspection.

1. The packet reaches the firewall’s external interface.

2. The packet is evaluated against the interface’s existing outbound access list, and the packet is permitted. (A denied packet would simply be dropped at this point.)

3. The packet is inspected by CBAC to determine and record information about the state of the packet’s connection. This information is recorded in a new state table entry created for the new connection. If the packet’s application (Telnet in this case) was not configured for CBAC inspection, the packet would simply be forwarded out the interface at this point without being inspected by CBAC.

4. Based on the obtained state information, CBAC creates a temporary access list entry which is inserted at the beginning of the external interface’s inbound extended access list. This temporary access list entry is designed to permit inbound packets that are part of the same connection as the outbound packet just inspected.

5. The outbound packet is forwarded out the interface.

6. Later, when an inbound packet reaches the external interface. This packet is part of the same Telnet connection previously established with the outbound packet. The inbound packet is evaluated against the inbound access list, and it is permitted because of the temporary access list entry previously created.

7. The permitted inbound packet is inspected by CBAC, and the connection’s state table entry is updated as necessary. Based on the updated state information, the inbound extended access list temporary entries might be modified in order to permit only packets that are valid for the current state of the connection.

8. Any additional inbound or outbound packets that belong to the connection are inspected to update the state table entry and to modify the temporary inbound access list entries as required, and they are forwarded through the interface.

9. When the connection terminates or times out, the connection’s state table entry is deleted, and the connection’s temporary inbound access list entries are deleted.

In the process just described above, the firewall access lists are configured as follows:

• An outbound IP access list (standard or extended) is applied to the external interface. This access list permits all packets that you want to allow to exit the network, including packets you want to be inspected by CBAC. In this case, Telnet packets are permitted.
• An inbound extended IP access list is applied to the external interface. This access list denies any traffic to be inspected by CBAC (including Telnet packets). When CBAC is triggered with an outbound packet, CBAC creates a temporary opening in the inbound access list to permit only traffic that is part of a valid, existing session. If the inbound access list had been configured to permit all traffic, CBAC would be creating pointless openings in the firewall for packets that would be permitted anyway.

CBAC Configuration

To illustrate the CBAC configuration, I would use a simple scenario as show in the diagram below: A router (GW) with two interfaces (one internal and one external) placed between two networks, Router R1 belongs to trusted (internal) network and R2 belongs to untrusted (internet). Our goal is to configure the router (GW) to protect the trusted network (typically a company LAN) from the traffic originating from untrusted network (usually Internet).

From the diagram, you can see that there are four logical points where the router can inspect traffic:

1. Inbound Traffic on Internal Interface (FastEthernet0/0)
2. Outbound Traffic on External Interface (FastEthernet0/1)
3. Inbound Traffic on External Interface (FastEthernet0/1)
4. Outbound Traffic on Internal Interface (FastEthernet0/0).

Let’s consider that we first want to allow all traffic passing through the router from internal network (192.168.10.10/24) toward the Internet (202.164.42.0/24). This is already the case, as the router will of course forward all the traffic when no access restrictions have been applied. We also want to deny all traffic flowing from the Internet towards 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 so that the router itself is protected from untrusted traffic as well.
The ACL configuration is given below:

GW#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
GW(config)#ip access-list extended DENY-UNSAFE-TRAFFIC
GW(config-ext-nacl)#deny ip any any
GW(config-ext-nacl)#exit
GW(config)#int fa0/1
GW(config-if)#ip access-group DENY-UNSAFE-TRAFFIC in
GW(config-if)#end

At this point, traffic can freely flow from trusted network towards untrusted network, but is completely blocked in the opposite direction. This is not what you expect since most of the applications on production network relies on bidirectional communication. For instance, if a user on internal network is trying to browse any website on internet, the request will be able to be sent from inside to WebServer but the response from external WebServer will be prohibited by GW router due to ACL configured. Ultimately the user will not be able to establish communication with WebServer. Similarly, if a user on internal LAN want to establish a Telnet session to router R2 which is located on untrusted network, his request will be sent out to R2 without any restriction but the response from R2 will be blocked by ACL placed on GW router.

If you want to allow Web and Telnet traffic initiated from the internal network to return. One option would be to configure a more granular ACL instead of denying all IP traffic, but that would not provide stateful inspection and may open a security hole. Any potential attacker could attack your internal network.

Another option would be to implement a reflexive ACL, but that would provide only limited stateful inspection. A more powerful solution is to implement CBAC.

CBAC allows us to define an inspection rule for each protocol we want to monitor. In this case, we want to inspect only HTTP, HTTPS and Telnet sessions, so we will create a rule named “SafeTraffic” on GW router.

GW(config)#ip inspect name SAFE-TRAFFIC http
GW(config)#ip inspect name SAFE-TRAFFIC https
GW(config)#ip inspect name SAFE-TRAFFIC telnet

There are additional options per protocol, but I will accept their defaults. Next we need to apply the inspection rule to an interface and in a particular direction.

We need to apply the rule in outbound direction on the external interface because:

1. We want to inspect traffic originating from the trusted network.
2. We want to dynamically adjust the ACL restricting traffic inbound on the external interface.

The rule is applied on interface with the help of ip inspect command in interface configuration mode:

GW(config)#interface fastEthernet 0/1
GW(config-if)#ip inspect SAFE-TRAFFIC out
GW(config-if)#end

Now we have enabled CBAC for HTTP, HTTPS and Telnet traffic on outside interface. Outbound traffic is now being inspected as CBAC sessions and the DENY-UNSAFE-TRAFFIC extended ACL is automatically being modified to permit the legitimate returning traffic.

Verify the CBAC configuration

Lets now check if the rule is working as per our expectation. The router R1 should be able to make HTTP, HTTPS and Telnet session on R2 but the router R2 should not be able to initiate any HTTP, HTTPS or Telnet session since it is located on untrusted network (Internet).

First we will try to make session from R2:

 R2#telnet 192.168.10.10
Trying 192.168.10.10 ...
% Destination unreachable; gateway or host down

R2#telnet 192.168.10.10 80
Trying 192.168.10.10, 80 ...
% Destination unreachable; gateway or host down

R2#telnet 192.168.10.10 443
Trying 192.168.10.10, 443 ...
% Destination unreachable; gateway or host down

Notice that router R2 can not connect to R1 neither using default telnet port 23 nor using port 80 (HTTP) and 443 (HTTPS). This is what we expected from R2.

Now, try the same thing from R1:

R1#telnet 202.164.42.10
Trying 202.164.42.10 ... Open

User Access Verification

Password: ********
R2>enable
Password: *******
R2#
R2#show users
    Line       User       Host(s)              Idle       Location
   0 con 0                idle                 00:03:22
*  2 vty 0                idle                 00:00:00 192.168.10.10

  Interface    User               Mode         Idle     Peer Address

R2#
R2#telnet 202.164.42.10 80
Trying 202.164.42.10, 80 ... Open

q
HTTP/1.1 400 Bad Request
Date: Sat, 12 Sep 2015 13:00:34 GMT
Server: cisco-IOS
Accept-Ranges: none
400 Bad Request
[Connection to 202.164.42.10 closed by foreign host]

R2#telnet 202.164.42.10 443
Trying 202.164.42.10, 443 ... Open

[Connection to 202.164.42.10 closed by foreign host]

If you can see “Trying 202.164.42.10 … Open“, it means the session is established. SInce both R1 and R2 are routers, I could not demonstrate full web connectivity by visiting any website, but using telnet on port 80 and 443 proves that router R1 can make successful Telnet as well as Web connection to router R2 while the reverse is not true. Any session initiated by router R2 towards R1 is being denied by CBAC rule.

The CBAC configuration can be verified with show ip inspect all command.

GW#show ip inspect all
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [unlimited : unlimited] connections
max-incomplete sessions thresholds are [unlimited : unlimited]
max-incomplete tcp connections per host is unlimited. 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
tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes
dns-timeout is 5 sec
Inspection Rule Configuration
 Inspection name SAFE-TRAFFIC
    http alert is on audit-trail is off timeout 3600
    https alert is on audit-trail is off timeout 3600
    telnet alert is on audit-trail is off timeout 3600

Interface Configuration
 Interface FastEthernet0/1
  Inbound inspection rule is not set
  Outgoing inspection rule is SAFE-TRAFFIC
    http alert is on audit-trail is off timeout 3600
    https alert is on audit-trail is off timeout 3600
    telnet alert is on audit-trail is off timeout 3600
  Inbound access list is DENY-UNSAFE-TRAFFIC
  Outgoing access list is not set

You can use show ip inspect sessions command to view the currently established sessions.

GW#show ip inspect sessions
Established Sessions
 Session 694BF90C (192.168.10.10:33956)=>(202.164.42.10:23) telnet SIS_OPEN

Since I had an open telnet connection to router R2, I can see only one established session. If I also establish a new HTTP connection, and repeat the command:

GW#show ip inspect sessions
Established Sessions
 Session 694BF6E4 (192.168.10.10:48726)=>(202.164.42.10:80) http SIS_OPEN
 Session 694BF90C (192.168.10.10:33956)=>(202.164.42.10:23) telnet SIS_OPEN

Now, we can see two sessions (HTTP and Telnet) open. CBAC will continue to inspect this session until it is closed by either end, or the configured idle timer is reached.

Lets see what is going on behind the scenes. When the session was initiated by trusted host (R1), CBAC automatically created two temporary permit entries on the top of the deny ip any any statement in DENY-UNSAFE-TRAFFIC access-list which is applied on external interface to allow the legitimate return traffic.

The access-list will now temporarily look something like:

permit tcp host 202.164.42.10 eq 23 host 192.168.10.10 eq 33956
permit tcp host 202.164.42.10 eq 80 host 192.168.10.10 eq 48726
deny ip any any 

Once the original session is closed, the permit entries are automatically removed from the access-list. Isn’t it amazing?

To see CBAC in action, you can enable audit trails to generate syslog messages for each CBAC session creation and deletion with the help of following command:

GW(config)#ip inspect audit-trail

After enabling audit-trail, you will see following syslog message every time a new session is created and deleted.

*Sep 12 14:15:56.287: %FW-6-SESS_AUDIT_TRAIL_START: Start telnet session: initiator (192.168.10.10:28103) -- responder (202.164.42.10:23)
*Sep 12 14:19:43.699: %FW-6-SESS_AUDIT_TRAIL: Stop telnet session: initiator (192.168.10.10:28103) sent 56 bytes -- responder (202.164.42.10:23) sent 122 bytes

If you want to see more detailed information for every CBAC session, you can enable debugging of CBAC objects, but if you are working on production network, I would not suggest using debug command since it consumes more CPU and memory of router. By the way, you can use following command to enable debugging:

GW#debug ip inspect object-creation
INSPECT Object Creations debugging is on
GW#debug ip inspect object-deletion
INSPECT Object Deletions debugging is on

Once debug is enabled, the GW router will display following message every time an CBAC object is created or deleted as shown below:

*Sep 12 14:12:21.971: FIREWALL* OBJ_CREATE: Pak 68D44F34 sis 694BF90C initiator_addr (192.168.10.10:51915) responder_addr (202.164.42.10:23)
initiator_alt_addr (192.168.10.10:51915) responder_alt_addr (202.164.42.10:23)
*Sep 12 14:12:21.975: FIREWALL OBJ-CREATE: sid 694CFEBC acl DENY-UNSAFE-TRAFFIC Prot: tcp
*Sep 12 14:12:21.975:  Src 202.164.42.10 Port [23:23]
*Sep 12 14:12:21.975:  Dst 192.168.10.10 Port [51915:51915]
*Sep 12 14:12:21.975: FIREWALL OBJ_CREATE: create host entry 69CBB680 addr 202.164.42.10 bucket 78 (vrf 0:0) insp_cb 0x691EFD8C
*Sep 12 14:21:24.563: FIREWALL OBJ_DELETE: delete sis 694BF90C
*Sep 12 14:21:24.563: FIREWALL OBJ-DELETE: sid 694CFEBC on acl DENY-UNSAFE-TRAFFIC Prot: tcp
*Sep 12 14:21:24.563:  Src 202.164.42.10 Port [23:23]
*Sep 12 14:21:24.563:  Dst 192.168.10.10 Port [38890:38890]

Of course there is lot more about CBAC than I have covered here, but hopefully this example provides a decent explanation and real-time use.

Back