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:
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.
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.
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.
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:
- Inbound Traffic on Internal Interface (FastEthernet0/0)
- Outbound Traffic on External Interface (FastEthernet0/1)
- Inbound Traffic on External Interface (FastEthernet0/1)
- 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 (18.104.22.168/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:
- We want to inspect traffic originating from the trusted network.
- 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 22.214.171.124 Trying 126.96.36.199 ... 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 188.8.131.52 80 Trying 184.108.40.206, 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 220.127.116.11 closed by foreign host] R2#telnet 18.104.22.168 443 Trying 22.214.171.124, 443 ... Open [Connection to 126.96.36.199 closed by foreign host]
If you can see “Trying 188.8.131.52 … 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)=>(184.108.40.206: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)=>(220.127.116.11:80) http SIS_OPEN Session 694BF90C (192.168.10.10:33956)=>(18.104.22.168: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.
permit tcp host 22.214.171.124 eq 23 host 192.168.10.10 eq 33956 permit tcp host 126.96.36.199 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 (188.8.131.52: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 (184.108.40.206: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 (220.127.116.11:23) initiator_alt_addr (192.168.10.10:51915) responder_alt_addr (18.104.22.168: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 22.214.171.124 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 126.96.36.199 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 188.8.131.52 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.