Context-Based Access Control

Authentication Proxy and IDS

Have you ever been frustrated—maybe even nervous—because you’re creating access policies based on IP addresses when what you really need to control is users? Most network engineers have. You can lock down a PC based on its IP address—that’ll show ’em, right? Wrong. You can’t prevent someone from easily getting around that one by simply using another machine!

But armed with the Authentication Proxy, you can create policies based on users rather than IP addresses! You can actually configure specific user-based access such as HTTP access to the Internet because the policy follows the user instead of being tied to a single PC. How? No matter where your user actually is, when they attempt to access resources through the firewall, they’re forced to authenticate to the firewall, and so their policy follows them. You get to give each of your users their very own personal access profile that can be stored on a CiscoSecure ACS or other TACACS+ or RADIUS server—way cool!

The IOS Firewall now offers an Intrusion Detection System (IDS) option on midto highrange router platforms. This option is particularly valuable at perimeter points within the network or at peering points between networks. The IDS includes profiles or signatures for 59 common attacks that run the gamut from the breach-of-security types to information-gathering attacks. When a packet matches one of these signatures, the IDS can react with an alarm (CIDS or Syslog server), it can drop the packet, or it can reset the TCP session.

Context-Based Access Control

The Cisco IOS Firewall Context-Based Access Control (CBAC) engine provides secure, perapplication access control across network boundaries. CBAC enhances security for applications that use TCP and UDP well-known ports. It provides this service by scrutinizing source and destination addresses. I’m going to show you how CBAC is both different and better at protecting your network than just running static ACLs. To give CBAC a proper introduction, I need to make sure you’re crystal clear about how different it really is from an ACL—both in its operation and its capabilities.

CBAC in Action

The Internet can be the ultimate source of grief, pain, and destruction, but don’t assume that CBAC doesn’t have applications that can protect you elsewhere as well.

Lots of organizations need internal security and controls as much as they need external security. Okay, well, almost as much. Anyway, you can apply CBAC anywhere you could really use a firewall, internally or externally.

148 Chapter 5 Context-Based Access Control Configuration

For instance, let’s say your company needs a cheap and easy alternative to purchasing and maintaining a firewall. CBAC could really come to the rescue because it comes as part of the package when you purchase the Cisco IOS Firewall set.

Instead of buying separate hardware for individual security problems, the Cisco IOS Firewall provides great value for an all-in-one product. This can give you flexibility in your multiprotocol networks, as well as perimeter security, intrusion detection, and VPN connections, including IPSec, L2TP, and QoS.

And because the Cisco IOS is always being maintained and updated, the CBAC configuration that can be used with a Cisco router will provide many years of investment protection.

CBAC Compared to ACLs

There are many differences between ACLs and CBAC, but at a high level, the main distinctions are that CBAC is stateful, dynamic, and can look farther into packets.

And CBAC is application aware—ACLs are not. In terms of OSI, this means that while ACLs make their decisions based on Layers 3 and 4 data, CBAC can actually look at Application-layer information. This capability makes it possible for CBAC to detect problems such as illegal or inappropriate SMTP commands, whereas an ACL can only permit or block the Transportlayer port.

CBAC keeps state tables where session information is stored and can dynamically create and modify ACLs to control traffic. It can also recognize and help prevent certain types of DoS attacks.

To begin, let’s look at how an ACL works:

1.A packet arrives at an interface with an inbound ACL configured on the router.

2.The packet is compared to successive lines of the ACL, starting with the first line, until a match is made.

3.If a match is made, the packet is acted upon based on the action defined by that line of the ACL.

4.If a match isn’t made, the packet is dropped.

If we were simply discussing ACLs, we could stop here. But if we did, you would miss an important distinction between a firewall and a router. So let’s continue with the next packet:

5.Another packet arrives at an interface with an inbound ACL configured on the router.

6.The packet is compared to successive lines of the ACL, starting with the first line, until a match is made.

7.If a match is made, the packet is acted upon based on the action defined by that line of the ACL.

8.If a match isn’t made, the packet is dropped.

Okay, this sounds familiar to our understanding of access lists. Let’s continue with one more packet:

9.Another packet arrives at an interface with an inbound ACL configured on the router.

10.The packet is compared to successive lines of the ACL, starting with the first line, until a match is made.

11.If a match is made, the packet is acted upon based on the action defined by that line of the ACL.

12.If a match isn’t made, the packet is dropped.

What’s up with this? Why we are doing this stupid, redundant review of how an ACL works? The answer—and a key distinction between a firewall (CBAC) and a simple ACL—lies in this question: What effect does the first packet through the ACL have on the third packet through the ACL? The answer to this question clarifies why CBAC is a much more powerful guardian for your network.

When a router runs with ACLs, every packet arrives “fresh” at the router, with each packet being subject to the exact same set of rules. A traditional ACL is static—that is, every packet is treated equally, regardless of any other packets that have preceded it through the router. That’s the point I was making with the preceding steps—each packet arrives individually at the ACL, and each packet is evaluated and either permitted or denied without any regard whatsoever to any packet that preceded it. Not so with CBAC. CBAC is smarter than that.

With CBAC, the rules for packets passing through the router can change depending on what has already happened; the fate of a packet can depend on what previous packets have done. This is what I mean when I say that CBAC is stateful. Think state-dependent if it helps.

CBAC monitors the state of network connections and traffic by keeping a state table of all inspected traffic; CBAC changes the access rules based on this data. An ACL can evaluate only one measly packet at a time, whereas a firewall (or CBAC) can evaluate trends of packets and respond appropriately to the type of trend it has identified. So with CBAC, what happens to the third packet through the router totally depends on what the two preceding packets did.

Clearly, this means that CBAC can identify and respond to problems that ACLs could never hope to—such as DoS attacks. An ACL can permit or deny TCP SYN requests, but CBAC can count the number of half-open TCP connections and make decisions about any new SYN requests dynamically! Plus, CBAC can evaluate Application-layer information by monitoring control channels and Application-layer conversations, so it can detect inappropriate commands. It literally parses the Application-layer header to extract this information. ACLs can’t do that.

Now, all this discussion is not intended to make you think that ACLs are useless and that if you use them, you might as well put your data out on a public FTP server. Just don’t freak out— I’m not telling you this to convince you to dump your ACLs. I’m just explaining how very different a stateful firewall is from an ACL. ACLs certainly do have their place—they’re included in standard IOS. CBAC will definitely cost you a few bucks more for IOS images.

150 Chapter 5 Context-Based Access Control Configuration

CBAC-Supported Protocols

CBAC is a strong tool and can help you monitor and log sessions created and used with many protocols. There are several protocols you can use with CBAC to monitor and log sessions.

CBAC can be configured to inspect either all TCP or UDP conversations or to focus on specific protocols. In operation, CBAC sits behind the ACLs and lets the ACL do its work first, so if a packet is dropped by an ACL, it’s never inspected by CBAC. Packets that do pass through are inspected, and CBAC makes necessary changes to the state table for TCP and UDP sessions. The information in the state table is then used to make temporary modifications to ACLs that will serve to permit return traffic, or perhaps additional connections associated with a particular protocol—for example, FTP data connections. These temporary openings in the firewall are removed when they’re no longer needed and are never saved to NVRAM.

The choice is yours—you get to decide whether to have CBAC inspect specific protocols or have it examine all TCP and/or UDP traffic. You also get to pick the interface and direction where the inspection will be applied to the protocols you’ve selected. Once CBAC monitors a protocol, it only allows return traffic to permissible sessions already in the state table.

Some protocols such as FTP use two channels when they communicate—one for control information and one for data exchange. CBAC monitors only the control channel. It reads the actual Application-layer commands and their responses so it can protect against certain types of Application-layer attacks. CBAC also tracks TCP sequence numbers, guarding against the types of attacks that manipulate them.

You can tell CBAC to inspect all TCP or UDP sessions, or you can get really specific and configure it to act as a watchdog for any of these particular protocols: