Introduction to the Cisco IOS Firewall Authentication Proxy

Secure IDS sensor would; it can spot and react to potentially inappropriate or malicious packets. It can even be added into the CSIDS Director for inclusion in a centralized IDS monitoring system. I’m not going to get into the whole “should-you-or-should-you-not-profile” debate. Just know that in network security, you profile suspicious elements. It makes sense not to pat down a Mother Teresa packet while the shoe-bomber packet gets to breeze right through unquestioned!

How does this work? Well, the IOS Firewall IDS bases its profiling capabilities on IDS signatures that delineate the types of traffic that may be nasty. You, as the administrator, get to choose which signatures to deploy and how you want to react when patterns of network traffic match the signature. These IDS protections can be used against internal or external attacks and can be executed in conjunction with the other IOS Firewall features we’ve been discussing.

I’m going to show you how to configure the IOS Firewall IDS, but first, I’m going to start things off by giving you a brief operational overview and pointing out a few other IDS considerations. Then, I’ll take you through the process of enabling the IOS Firewall IDS and manipulating the various available signatures. Finally, I’ll show you how to create audit rules and verify your configuration.

Introduction to the Cisco IOS Firewall Authentication Proxy

Back in Chapter 1, “Introduction to Network Security,” I stressed how seriously important it is that you create a solid security policy to protect your network (and your job!). This is because the IOS Firewall Authentication Proxy allows you to create and apply access control policies to individuals instead of to addresses. When your users move around, their access policies follow them, regardless of which IP address they happen to be using at any given moment. This technology helps you permit Sales Exec A to use the same username and password to log on to the docked laptop at her desk or to dial up from home or anywhere else. And unless Sales Exec A gives away her username and password, no one else gets to log in and pretend to be her or access her individual rights.

With the IOS Firewall Authentication Proxy in place, users are forced to authenticate before access through the IOS Firewall is granted. When the user attempts to initiate communications through the IOS Firewall, they’ll be queried for a username and password, which are then sent to an external AAA server running either TACACS+ or RADIUS. The server responds to the firewall’s request with a user profile that defines the specific rights and limitations for that individual user’s access and is adopted by the firewall for the duration of the communication.

In order to authenticate to the firewall, users must initiate an HTTP session through it. When they do that, an HTTP window appears that’s used for authentication, such as the one you see in Figure 6.1.

180 Chapter 6 Cisco IOS Firewall Authentication and Intrusion Detection

F I G U R E 6 . 1 User authentication screen

Users must initiate HTTP and successfully authenticate before other traffic types will be allowed—no HTTP first, no Telnet. After authentication, the user’s profile dynamically modifies ACLs on the router to allow the user the specified access. If the user exceeds the idle timer (60 minutes by default), they have to re-authenticate and establish a new HTTP session before they can continue. Remember Sales Exec A? Let’s say she took her work home, logged onto the Internet, and left the room before the idle time default elapsed. Now suppose she has a daughter who wanders into the room, sits down at her mom’s computer, and accesses some chat room that way as well. This could be a problem, right? The good news is that you can change that default setting. I’ll show you how later in this chapter.

There are four easy steps to setting up the IOS Firewall Authentication Proxy:

1.Configure the AAA server (CSACS, etc.).

2.Configure AAA on the router.

3.Configure the IOS Firewall Authentication Proxy on the router.

4.Test and verify functionality.

As you can see, the first two steps merely get AAA up and running on the router and server. Once you do that, you add the IOS Firewall Authentication Proxy configuration to the router, then test and verify its functionality. Like I said, it’s easy.

Okay, let’s walk through these four steps, once again using the same setup for the corporate network that you’ve been using throughout this book, which is illustrated in the following graphic:

In order to understand this chapter’s material, you’re going to configure the CSACS server at 192.168.254.253, and configure the Lab_B perimeter router.

Configuring the AAA Server

As I said, the AAA server can be either a TACACS+ or a RADIUS server—you have lots of options here. The IOS Firewall Authentication Proxy supports the following TACACS+ servers:

182 Chapter 6 Cisco IOS Firewall Authentication and Intrusion Detection

The first step in setting up the IOS Firewall Authentication Proxy is to configure the AAA server to support it. You’ll use the CSACS for Windows server from the corporate network example for that, and you’ll start by selecting Interface Configuration from the navigation bar to configure TACACS+, as illustrated in Figure 6.2.

F I G U R E 6 . 2 Interface configuration for TACACS+

Next, select Group Setup from the navigation bar and edit the settings for your group. Select the Auth-Proxy and Custom Attributes check boxes, then add your ACL using the appropriate syntax (I’ll cover that in a minute), as shown in Figure 6.3.

F I G U R E 6 . 3 Group setup for TACACS+

When configuring the ACLs in the AAA server, you use syntax that’s similar but not identical to what you use in a router. The similarities make it almost intuitive, but it’s also easy to make a mistake if you’re not careful. For instance, the following output shows an example of an ACL that allows all traffic after authentication:

proxyacl#1=permit ip any any

priv-lvl=15