cisco

cisco coming... coming..

Cisco Security Appliance version 6.2

The “Foundation Summary” provides a convenient review of many key concepts in this
chapter. If you are already comfortable with the topics in this chapter, this summary can help
you recall a few details. If you just read this chapter, this review should help solidify some
key facts. If you are doing your final preparation before the exam, this summary provides a
convenient way to review the day before the exam.
Authentication, authorization, and accounting are three separate functions performed by
AAA servers to allow access to resources. Each of these functions has a specific goal. If you
are using AAA, then authenticating the user is key. No access is granted if the requestor is
not authenticated. The use of authorization and accounting are dependant on authentication,
but it is not necessary to configure either authorization or accounting to make authentication
function properly. This list defines each of the components of AAA:
■ Authentication—Identifies the entity (user)
■ Authorization—Gives the user access based on his or her profile
■ Accounting—Maintains a record of user access
Cisco Security Appliance version 6.2 can maintain an internal user database for console
authentication and command authorization or connect to an external AAA server. The
Security Appliance supports RADIUS, TACACS+, SDI, NT, Kerberos, and LDAP
authentication technologies. Figure 17-20 shows the steps that the AAA server takes during
the entire AAA process.
Figure 17-20 AAA Server Steps
Cisco Secure ACS is available for Windows Server and can be configured for TACACS+ and
RADIUS. The Cisco Secure ACS installation on Windows is an easy, step-by-step wizard
installation.
Step 1: User initiates connection to web server and is prompted for username/password.
Step 5: The firewall allows the connection.
Step 2: NAS forwards user
information to AAA for
authentication.
Step 3: AAA servers returns
authentication and authorization to NAS.
Step 4: AAA server logs
the connection (by user).

Cisco Secure ACS Administration Window

Cisco Secure ACS Administration Window
Congratulations! You have completed the installation of Cisco Secure ACS on a Windows
server. Chapter 18, “Configuration of AAA on the Cisco Security Appliance,” shows you
how to configure Cisco Secure ACS.

Service Start Flash Window

Service Start Flash Window
Figure 17-18 Cisco Secure ACS Installation Complete
If you select the option to launch the Cisco Secure ACS administration browser window, the
system launches a window that is similar to Figure 17-19.

Cisco Secure ACS Startup Options

Cisco Secure ACS Startup Options
Cisco Secure ACS displays an activity bar as the Cisco Secure ACS Service is started (see
Figure 17-17). Figure 17-18 shows the final configuration window that appears when the
installation is complete.

Cisco IOS Configuration Options

Cisco IOS Configuration Options
Figure 17-15 Cisco IOS Configuration Explanation
Cisco Secure Access Control Server 531
The installation/configuration of Cisco Secure ACS skips several steps if you do not elect to
configure the Cisco IOS components. Figure 17-16 depicts the window that appears when
the Cisco Secure ACS configuration is nearly complete. This window includes options for
starting the Cisco Secure ACS Service, launching the Cisco Secure ACS Administrator from
your browser, and viewing the Cisco Secure ACS Readme file.

Explanations for Alert Action and Notification Settings

Explanations for Alert Action and Notification Settings
530 Chapter 17: Overview of AAA and the Cisco Security Appliance
Cisco Secure ACS version 3.3 includes an optional NAS Configuration window, shown in
Figure 17-14, to assist you with the initial configuration of the Cisco IOS Software. If you
need further explanation, click the Explain button to review the window shown in Figure
17-15. This option works only when you are using a Cisco IOS router as your NAS. This
option should not be selected when using the Security Appliance as the NAS.

Explanation of Advanced Options

Explanation of Advanced Options
Next, you select from three actions (Restart All, Restart RADIUS/TACACS+, Reboot) for the
AAA server to initiate if a communications failure occurs between the Cisco Secure ACS and
the NAS. These settings also include SMTP settings and the user account for the Cisco Secure
ACS to send an alert to if a failure occurs. Figures 17-12 and 17-13 show the settings window
and the settings explanation window, respectively.

Explanation of Settings

Explanation of Settings
Cisco Secure Access Control Server 527
After you click Next in the NAS Details window, you are prompted to select the advanced
features that you want to appear in the user interface, as shown in Figure 17-10. This allows
you to determine how much (or how little) detail you want to see when working in the
user interface. If you click the Explain button, you see the explanation window shown in
Figure 17-11, which describes each of the available options. These settings can be configured
during the initial configuration (installation), or you can skip this step and change the settings
after Cisco Secure ACS is installed.

User Database Window

User Database Window
In the next window, shown in Figure 17-7, you are prompted to select any of ten possible
choices for the connection type to the NAS. Remember that the Cisco Security Appliance is
acting as the NAS. For this configuration, TACACS+ (Cisco IOS) is selected.
Figure 17-7 NAS Technology (TACACS+ Selected)
526 Chapter 17: Overview of AAA and the Cisco Security Appliance
Next, you need to finish the NAS information to complete the connection between the AAA
server and the NAS. Figure 17-8 shows the NAS Details window. Note the Explain button
in the lower-right corner. Click this button to get an explanation of each of the settings, as
shown in Figure 17-9.
Figure 17-8 NAS Information (RADIUS Selected)
Figure 17-

Installation Directory (Default)

Installation Directory (Default)
In the next window, shown in Figure 17-6, you select whether to authenticate against only
the Cisco Secure ACS user database or the combination of the Cisco Secure ACS database
and the Windows user database. The latter selection lets you use Windows username/
password management and integrate Windows performance monitoring, which provides you
with real-time login statistics.

Cisco Secure ACS Setup Welcome Window

Cisco Secure ACS Setup Welcome Window
The second window, shown in Figure 17-4, prompts you to verify that your system is ready
for this installation. Before this installation, you should verify that your Windows server is
up to date, including Internet Explorer, and that you have connectivity with the NAS. In this
case, the Security Appliance functions as the NAS.
You are prompted to specify the installation directory, as shown in Figure 17-5. You can use
the default directory, C:\Program Files\CiscoSecure ACS v3.2, or select another directory for
the installation.

Installing Cisco Secure ACS Version 3.3 on Windows Server

Installing Cisco Secure ACS Version 3.3 on Windows Server
You can download a 90-day trial version of Cisco Secure ACS from the Cisco Software
Center at Cisco.com. You must register as a user to receive your CCO login. You must have
the CCO login to download software from the software center. The installation of Cisco
Secure ACS is an easy, step-by-step process. It is a good idea to verify that your Windows
server is up to the current patch level. When you are ready to begin the installation, just run
setup.exe. Figure 17-3 shows the initial Cisco Secure ACS installation window.

Cisco Secure ACS Solution Engine Server

Cisco Secure ACS Solution Engine Server
System Specification
CPU 3.2-GHz Pentium 4
Memory 1 GB RAM
Hard drive 80 GB free disk space
Interfaces 2 built-in 100/100 Mbps Ethernet controllers and 1 floppy drive

Minimum Hardware and Operating System Requirements for Cisco Secure ACS

Minimum Hardware and Operating System Requirements
for Cisco Secure ACS
Table 17-2 documents the minimum requirements needed by a system to run Cisco Secure
ACS version 3.3.
Table 17-3 documents the configuration specifications of the Cisco Secure ACS Solution
Engine Server.
Table 17-2 Cisco Secure ACS Version 3.3 System Requirements
System Requirement Type Requirements
Hardware Pentium III Processor, 550 MHz or greater.
256 MB of RAM.
250 MB of available drive space. Additional space is required
if you intend to run the Cisco Secure ACS database on this
system.
Screen resolution of 800×600 pixels and 256-color display.
Operating system Microsoft Windows 2000 Server with Service Pack 4.
Microsoft Windows 2000 Advanced Server with Service Pack
4, without Microsoft Clustering Services installed and
without any other Windows 2000 Advanced Server features
enabled.
Microsoft Windows Server 2003, Enterprise Edition.
Microsoft Windows Server 2003, Standard Edition.
Browser Microsoft Internet Explorer 6.0 Service Pack 1 with
Microsoft Java Virtual Machine.
Netscape Communicator 7.1 for Windows. With Sun Java
Plug-In 1.4.2 04 or later.

Cisco Secure Access Control Server

Cisco Secure Access Control Server
Cisco Secure ACS is an AAA server product developed by Cisco that can run on Windows
NT/2000 Server and UNIX, although Cisco has discontinued support for the Windows NT
and UNIX platforms. It supports a number of NASs, including the Cisco Security Appliance.
Cisco Secure ACS supports both RADIUS and TACACS+.
Cisco has replaced the UNIX platform with the Cisco Secure ACS Solution Engine Server.
The server is a standalone 1U server with Cisco Secure ACS 3.3 preinstalled.
With the release of Cisco Secure ACS 3.3, several new features have been added to strengthen
an already powerful AAA server platform:
■ Network Admission Control—Using the Network Admission Control (NAC) feature,
the Cisco Secure ACS will acts as a policy decisions point within NAC deployments.
Policies are created to evaluate the host on several different levels before assigning AAAclient
ACS appropriate for the host’s security state. Through these policies, the ACS can
evaluate the host’s credentials using Cisco Trust Agents. Additionally, policies can be
created to determine the state of the host based on such details as the host’s operating
systems patch level and the antivirus DAT file version.
■ Machine Access Restrictions—The Cisco Secure ACS can help control authorization of
EAP-TLS and Microsoft PEAP users using Machine Access Restrictions (MAR). Users
who authenticate with a Windows external user database that does not pass machine
authentication within a configured length of time can be given authorizations of a user
group, limited authorization, or denial of network access.
■ Network Access Filters—Cisco has added a new shared profile component with ACS 3.3
called Network Access Filters (NAF). NAFs can apply network access restrictions and
can allow ACLs to be downloaded using specific AAA client names, IP addresses, or
specific devices.

Supported AAA Server Technologies

Supported AAA Server Technologies
The Cisco Security Appliance supports six AAA server authentication protocols:
■ Remote Authentication Dial-In User Service (RADIUS)—RADIUS was developed by
Livingston Enterprises as an AAA server. It uses a UDP connection between the client
(NAS) and the server (AAA). RADIUS combines the authentication and authorization
into a single response to a query from the NAS. By default, RADIUS authentication is
performed on TCP port 1645.
■ Terminal Access Controller Access Control System Plus (TACACS+)—TACACS+ was
developed by Cisco Systems as an alternative to RADIUS. TACACS+ uses a TCP
connection between the client and server and divides the authentication and authorization
into separate transmissions. The default port for TACACS+ is TCP port 49.
■ SDI—RSA SecureID uses a username and one-time password to authenticate an end user
or application. This authentication type is used for VPN authentication to the Security
Appliance VPN server.
■ NT—Supports Microsoft Windows NTLM version 1 authentication for VPN
authentication.

■ kerberos—Supports Kerberos authentication for VPN end-user access; 3DES, DES, and
RC4 encryption types are supported through kerberos.
■ Lightweight Directory Access Protocol (LDAP)—Supports LDAP through tunnel-groups
for VPN authentication.

Cut-Through Proxy

Cut-Through Proxy
Cut-through proxy is a feature on the Cisco Security Appliance that allows transparent AAA
services and a seamless connection through the firewall to the destination. It provides
significantly better performance than application-proxy firewalls because it completes user
authentication at the application layer, verifies authorization against the security policy, and
then opens the connection as authorized by the security policy. In other words, the
connection request needs to go up to the application layer only once to be authorized. After
that, all authorized traffic is passed at the lower layers, dramatically increasing the rate at
which it can pass through the firewall.
There are four ways to connect to the Cisco PIX Firewall and activate the cut-through proxy:
■ HTTP
■ FTP
■ Telnet
■ SSH
The firewall responds to each of these connections with a username and password prompt.
Figure 17-1 shows the Telnet user authentication prompt. The user information is either
authenticated against a local database on the PIX Firewall or forwarded to an AAA server
for authentication. After the user is authenticated, the firewall completes the connection that
is requested (if authorized).

AAA and the Cisco Security Appliance

AAA and the Cisco Security Appliance
So how does the Security Appliance factor into the AAA equation? Any user who requests
access or a service that is configured for authentication and who goes through the Security
Appliance is prompted by the firewall for a username and password. If the Security Appliance
has a local database configured for user authentication, it matches this user information
against that database and permits or denies access.
In a Security Appliance, the local database can be used only for console authorization and
command authorization. If the Security Appliance is configured to use a separate AAA server,
it forwards the user information to that server for authentication and authorization. In this
case, the Security Appliance and the AAA server act in a client/server mode, with the Security
Appliance being the client. The Security Appliance acts as a network access server (NAS) but
operates as a client to the AAA server. It is a common practice to configure redundant AAA
servers. It is also possible to configure a local database on the Security Appliance for use
when no other AAA servers can be contacted.
Remember that the AAA server not only authenticates the user but also tells the firewall what
the user is authorized to do. If a user is authorized to access websites via HTTP and attempts
to connect to the same servers over FTP, that connection is dropped at the firewall even
though that user has been authenticated. Additionally, the AAA server should log the fact
that the user attempted to make a connection that was outside the user’s authority. The use
of specific authorization and accounting functions is not a prerequisite for the use of
authentication. It is possible to configure only authentication, which by default authorizes
access to authenticated users.

Definition of AAA

Definition of AAA
The best way to understand AAA is to look at the three components individually. Each is
distinct and has its own responsibility. AAA is now integrated into nearly every situation that
requires access control. Access control can be applied to users, hosts on a network (such as
servers and workstations), networking components (such as routers, switches, VPN
appliances, and firewalls), and other automated devices that require access and that perform
a function. This chapter discusses AAA as it pertains to a user, but you will see how the
principles can apply to many automated functions. The three components of AAA are as
follows:
■ Authentication—The process of validating an identity. The identity that is being
validated could be a user, a computer, a networking component, and so on.
Authentication is by far the most important step. No access is granted until the requestor
has been authenticated. There are three layers of user authentication:
— What the user knows—This normally is a user password or passphrase.
— What a user has—This normally is a user token or badge issued to the user
by whomever has authority over what the user is attempting to access.
— What a user is—This area includes biometrics, such as checking the user’s
fingerprint or retinal scan against a stored image in the database.
Many organizations do not incorporate all three layers of authentication;
however, it is very common to use a minimum of two layers at one time.
■ Authorization—After the user has been authenticated, he or she is granted access rights
to perform specific functions.
518 Chapter 17: Overview of AAA and the Cisco Security Appliance
■ Accounting—After the user is granted access, the accounting function tracks what tasks
the user performs and saves that information in a log that can be reviewed later.
Accountability of users and their actions is an issue that is becoming increasingly
important in the security of enterprise networks.
The three functions of AAA can be performed by a single server or can be divided among
several servers. Most large enterprise networks create a hierarchy of AAA servers, with the
lower-level servers tending to user functions and the upper-level servers working as a central
point for updating and distributing user information.

Overview of AAA and the Cisco Security Appliance

Overview of AAA and the Cisco Security Appliance
Authentication, authorization, and accounting (AAA) has become an extremely important
component in any network infrastructure. AAA is used in our everyday lives not only for
network security but also for physical security, or any other function that requires access
control. This chapter discusses the AAA process, its components, the responsibilities of each
component, and how the Cisco Security Appliance fits into the equation.

Overview of AAA and the Cisco

Overview of AAA and the Cisco
Security Appliance
This chapter presents authentication, authorization, and accounting, more commonly
known as AAA. It discusses how the Cisco Security Appliance is incorporated with AAA
servers and the relationship between the Cisco Security Appliance and the AAA servers.
This chapter also introduces Cisco Secure Access Control Server (ACS), an AAA server
product offered by Cisco.

show perfmon Command Output

show perfmon Command Output
PIX# show perfmon
PERFMON STATS: Current Average
Xlates 0/s 0/s
Connections 0/s 2/s
TCP Conns 0/s 2/s
UDP Conns 0/s 0/s
URL Access 0/s 2/s
URL Server Req 0/s 3/s
TCP Fixup 0/s 0/s
TCPIntercept 0/s 0/s
HTTP Fixup 0/s 3/s
FTP Fixup 0/s 0/s
AAA Authen 0/s 0/s
AAA Author 0/s 0/s
AAA Account 0/s 0/s

show url-server stats Command Output

show url-server stats Command Output
PIX(config)# show url-server stats
URL Server Statistics:
----------------------
Vendor Websense
URLs total/allowed/denied 2370/1958/412
URL Server Status:
------------------
10.10.10.13 UP

show url-cache Command Output

show url-cache Command Output
PIX# show url-cache stat
URL Filter Cache Stats
----------------------
Size: 128KB
Entries: 1415
In Use: 1
Lookups: 0
Hits: 0

The significant fields in this output are as follows:
■ Size—The size of the cache in kilobytes, set with the url-cache size option
■ Entries—The maximum number of cache entries based on the cache size
■ In Use—The current number of entries in the cache
■ Lookups—The number of times the Cisco Security Appliance has looked for a cache
entry
■ Hits—The number of times the Cisco Security Appliance has found an entry in the cache
You can view more statistics about URL filtering and performance with the show url-server
stats and show perfmon commands. Example 16-3 shows output from show url-server stats.

Viewing Filtering Statistics and Configuration

Viewing Filtering Statistics and Configuration
The show url-cache command with the stat option displays the URL caching statistics.
Example 16-2 demonstrates sample output from this command.

filter url Command Parameters

filter url Command Parameters
Parameter Description
http Specifies that the filtering be applied to port 80
port Specifies that the filtering be applied to whatever port (or port range) is
specified by either port or port-port
local-ip Specifies the source IP addresses for which filtering will be applied
local-mask Specifies the network mask for local-ip (note: using 0.0.0.0 specifies all
hosts)
foreign-ip Specifies the destination IP addresses for which filtering will be applied
foreign-mask Specifies the network mask for foreign-ip (note: using 0.0.0.0 specifies all
hosts)
allow Allows the connection to pass through the firewall without filtering if the
filtering server is unavailable
proxy-block Prevents users from connecting to an HTTP proxy server
longurl-truncate Causes the Cisco Security Appliance to send only the host name or IP
address portion of the URL for evaluation to the URL-filtering server,
when the URL is longer than the maximum length permitted
longurl-deny Denies outbound traffic if the URL is longer than the maximum permitted
cgi-truncate Sends a CGI script as the URL

Filtering Long URLs

Filtering Long URLs
Cisco Security Appliance supports filtering URLs up to 6000 bytes for the Websense URLfiltering
server. The default is 2000 bytes. In addition, Cisco Security Appliance supports the
longurl-truncate and cgi-truncate parameters to allow handling of URL requests longer than
the maximum permitted size. The format for these options is as follows:
filter url [http | port[-port]] local-ip local-mask foreign-ip foreign-mask] [allow]
[proxy-block] [longurl-truncate | longurl-deny | cgi-truncate]
Table 16-4 identifies the major parameters for the filter url command.

Filtering HTTPS and FTP

Filtering HTTPS and FTP
As mentioned in the previous section, HTTPS and FTP filtering can be configured on the
Security Appliance using Websense servers. These new features provide a convenient
mechanism of enforcing access policy in your environment. Just as it does with HTTP
filtering, the Security Appliance sends FTP requests to both the destination and the Websense
server when a user makes an FTP request. If the Websense server denies the connection, the
Security Appliance alters the FTP return code to show that the connection was denied. If the
Websense server permits the connection, the Security Appliance allows the successful FTP
return code to reach the user unchanged.
HTTPS filtering, on the other hand, works by preventing the completion of SSL connection
negotiation if the site is not allowed. The browser displays an error message such as “The
Page or the content cannot be displayed.” The command syntax to enable FTP and HTTPS
filtering is as follows:
filter ftp dest-port localIP local-mask foreign-IP foreign-mask
[allow] [interact-block]
filter https dest-port localIP local-mask foreign-IP foreign-mask [allow]

url-cache Command Parameters

url-cache Command Parameters
Parameter Description
dst Caches entries based on the URL destination address. Select this mode if all
users share the same URL-filtering policy on the N2H2 or Websense server.
src-dst Caches entries based on the source address initiating the URL request and the
URL destination address. Select this mode if users do not share the same URLfiltering
policy on the N2H2 or Websense server.
size kbytes Specifies a value for the cache size within the range 1 to 128 KB.Use the url-cache command to enable URL caching, set the size of the cache, and display
cache statistics.
Caching also stores URL access privileges in memory on the Cisco Security Appliance. When
a host requests a connection, the Cisco Security Appliance first looks in the URL cache for
matching access privileges before it forwards the request to the N2H2 or Websense server.
The clear url-cache command removes url-cache command statements from the
configuration, and the no url-cache command disables caching.

Configuring URL-Filtering Policy

Configuring URL-Filtering Policy
You must identify and enable the URL-filtering server before you use the following filtering
commands. If all URL-filtering servers are removed, any associated filtering commands are
also removed. The filter url command enables you to prevent outbound users from accessing
URLs that you designate as inadmissible. The syntax for filtering URLs is as follows:
filter url port [except] local-ip local-mask foreign-ip foreign-mask [allow]
[proxy-block] [longurl-truncate | longurl-deny] [cgi-truncate]
Example 16-1 Displaying the URL-Filtering Server Information
pixfw# show url-server
url-server (inside) vendor n2h2 host 10.10.10.13 port 4005 timeout 5 protocol TCP
Filtering URLs 505
With URL filtering enabled, the Cisco Security Appliance stops outbound HTTP, HTTPS,
and FTP traffic until a URL-filtering server permits the connection. If the primary URLfiltering
server and the secondary server do not respond, then outbound web traffic (port 80)
stops until the URL-filtering server comes back online. However, the allow option causes the
Cisco Security Appliance to forward HTTP traffic without filtering when the URL-filtering
server(s) is unavailable.
The following example filters all HTTP traffic:
filter url http 0 0
You can make an exception to URL-filtering policies by using the except parameter in the
filter url command. For example:
pixfw(config)#filter url http 0 0 0 0
pixfw(config)#filter url except 10.10.10.20 255.255.255.255 0 0
This policy filters all HTTP traffic with the exception of HTTP traffic that originates from
host 10.10.10.20.
Websense database version 4 contains the following enhancements:
■ URL filtering allows the Cisco Security Appliance to check outgoing URL requests
against the policy defined on the Websense server.
■ Username logging tracks the username, group, and domain name on the Websense
server.
■ Username lookup lets the Cisco Security Appliance use the user authentication table to
map the host’s IP address to the username.
There are instances in which the web server replies to a user HTTP request faster than the
URL-filtering servers. In these instances, the url-cache command provides a configuration
option to buffer the response from a web server if its response is faster than that from the
N2H2 or Websense URL-filtering server. This prevents the web server’s response from being
loaded twice, improving throughput. The syntax of the url-cache command is as follows:

Identifying the URL-Filtering Server

Identifying the URL-Filtering Server
The url-server command designates the server that is running the N2H2 or Websense URLfiltering
application. The Security Appliance allows you to configure a maximum of 16 URL
servers (with the first one entered being the primary URL server), and you can use only one
URL-filtering server at a time, either N2H2 or Websense. Configuration is performed both
on the Security Appliance and the URL-filtering server. You can identify more than one URLfiltering
server by entering the url-server command multiple times. The primary URL-filtering
504 Chapter 16: Content Filtering on the Cisco Security Appliance
server is the first server that you identify. The syntax for identifying an N2H2 URL-filtering
server is as follows:
url-server [(if-name)] vendor n2h2 host local-ip [port number]
[timeout seconds] [protocol {TCP | UDP}]
The default protocol is TCP. The timeout parameter in the url-server command is the
maximum idle time permitted before the Security Appliance switches to the next URLfiltering
server you specified. The default time is 5 seconds.
The following example identifies an N2H2 URL-filtering server with an IP address of
10.10.10.13:
pixfw(config)#url-server (inside) vendor n2h2 host 10.10.10.13
The default port used by the N2H2 server to communicate with the Cisco Security Appliance
via TCP or UDP is 4005.
The syntax for identifying a Websense URL-filtering server is as follows:
url-server [(if-name)] vendor websense host local-ip [timeout seconds]
[protocol {TCP | UDP} version{1 | 4}]
The following example identifies a Websense URL-filtering server with an IP address of
10.10.10.14:
pixfw(config)# url-server (inside) vendor websense host 10.10.10.14
To view the URL-filtering server, use the show url-server command, as shown in
Example 16-1.

Filtering URLs

Filtering URLs
Most organizations today have human resources policies that specify indecent materials
cannot be brought into the workplace. Similarly, most organizations have network security
policies that prohibit users from visiting websites that are categorized as indecent or
inappropriate to the business mission of the organization.
Using other content-filtering vendor products, the Cisco Security Appliance enforces network
security policy as it relates to URL filtering. When a user issues an HTTP request to a website,
the Cisco Security Appliance sends the request to the web server and to the URL-filtering
server at the same time. If the policy on the URL-filtering server permits the connection, the
Cisco Security Appliance allows the reply from the website to reach the user who issued the
original request. If the policy on the URL-filtering server denies the connection, the Cisco
Security Appliance redirects the user to a block page, indicating that access was denied.
The PIX Firewall works in conjunction with two types of URL-filtering application servers:
■ Websense Enterprise—Supported by Cisco Security Appliance Version 5.3 and later
■ N2H2 Sentian—Supported by Cisco Security Appliance Version 6.2

Filtering ActiveX Objectss

Filtering ActiveX Objects
The filter activex command filters out ActiveX objects and other HTML usages
from inbound packets. These controls include custom forms, calendars, and extensive thirdparty
forms for gathering or displaying information. The syntax for filtering ActiveX objects
is as follows:
filter activex port local-ip local-mask foreign-ip foreign-mask
Note that if the HTML tags split across network packets or if
the code in the tags is longer than the number of bytes in the maximum transmission unit
(MTU), Cisco Security Appliance cannot block the tag.

Filtering Java Applets

Filtering Java Applets
The filter java command filters out Java applets that return to the Cisco Security Appliance
from an outbound connection. The user still receives the HTML page, but the web page
source for the applet is commented out so that the applet cannot execute. The syntax for filter
java is
filter java port[-port] local-ip mask foreign-ip-mask
The following example specifies that Java applet blocking applies to web traffic on port 80
from local subnet 10.10.10.0 and for connections to any foreign host:
filter java http 10.10.10.0 255.255.255.0 0 0

Filtering ActiveX Objects and Java Applets

Filtering ActiveX Objects and Java Applets
ActiveX objects and Java applets are designed to make the browsing experience more
interactive. Based on the Component Object Model (COM), ActiveX objects are written for
a specific platform of Microsoft Windows. When the user displays a page containing ActiveX
or Java, the browser downloads the control dynamically. ActiveX objects are native
programs, so they can do all the things that local programs can do. For example, they can
read and write to the hard drive, execute programs, perform network administration tasks,
and determine which system configuration they are running on. While ActiveX objects and
Java applets can perform powerful tasks, they can also be used maliciously to damage
systems.
One way to prevent the threats posed by ActiveX objects and Java applets is to disallow
ActiveX objects and Java applets at the browser or user level. Users can configure their web
browsers not to run ActiveX objects or Java applets. Although you can disable ActiveX
objects and Java applets within the browser, this requires a great deal of effort for a large
enterprise network. In these cases, it is easier to prevent the ActiveX objects and Java applets
from reaching the browser.
When configured for filtering, the Cisco PIX Firewall filters ActiveX objects and Java applets
from HTML web pages before those pages reach the browser. Java applet and ActiveX object
filtering of HTML files is performed by selectively replacing the and
tags and the tags with comments.

Content Filtering on the Cisco

Content Filtering on the Cisco
Security Appliance
Up to now, you focused on how to configure the Security Appliance and how to protect
against unwanted traffic from outside in. This chapter focuses specifically on outbound
traffic and content filtering—traffic moving from inside out.
More and more companies today have some form of network policy in place. Websites
that are not related to their business or that are otherwise considered inappropriate are
prohibited for use by their employees. This chapter discusses how the Cisco Security
Appliance mitigates some of the threats posed by Java applets and ActiveX objects and
how the Cisco Security Appliance enforces URL filtering.
How to Best Use This Chapter
Users on your network frequently surf the Internet looking for information. Some
websites contain content that is not appropriate for a business environment. Besides
inappropriate content, many attacks also originate from traffic brought into your
network by internal users surfing the Internet via ActiveX objects and Java applets.
Filtering ActiveX objects and Java applets along with restricting access to specific URLs
is an important aspect in your overall network security policy. Test yourself with the “Do
I Know This Already?” quiz and see how familiar you are with the content filtering
functionality available on Security Appliances.

Address Translation Exemption Window

Address Translation Exemption Window
Using ASDM for VPN Configuration 493
As shown at the bottom of Figure 15-36, a checkbox option is available
to enable split tunneling. A split tunnel allows the VPN client to access
the networks protected by the VPN headend via the VPN tunnel and the
Internet in clear data (outside the VPN tunnel) simultaneously.
Step 11 At this point, the remote-access VPN configuration is complete.

Transform Set Window (IPSec Encryption and Authentication)

Transform Set Window (IPSec Encryption and Authentication)
Step 10 (Optional) The Address Translation Exemption window, shown in Figure
15-36, identifies local hosts/networks that are to be exempted from address
translation. By default, the Security Appliance hides the real IP address of
internal networks from outside hosts through dynamic or static NAT. The
security provided by NAT helps to minimize the risk of being attacked by
untrusted outside hosts, but it is inappropriate for those who have been
authenticated and protected by VPN.

IKE Policy Window

IKE Policy Window
Step 9 Specify the encryption and authentication algorithms used by the IPSec
VPN tunnel, as shown in Figure 15-35.
492 Chapter 15: Adaptive Security Device Manager

Address Pool Window

Address Pool Window
Step 7 (Optional) Configure the DNS and WINS addresses that can be pushed
down to the remote client, as shown in Figure 15-33.
Using ASDM for VPN Configuration 491
Figure 15-33 Attributes Pushed to Client Window
Step 8 Specify the encryption and authentication algorithms used by IKE
(Phase 1), as shown in Figure 15-34.

AAA Server Group Window

AAA Server Group Window
Step 6 Create a pool of local addresses that can be used to assign dynamic
addresses to remote-access VPN clients. Enter a descriptive identifier
for the address pool. Figure 15-32 shows a sample configuration for the
remote sales group in the Address Pool window.

Client Authentication Window

Client Authentication Window
Extended Authentication (XAuth) is a feature within the IKE protocol.
XAuth lets you deploy IPSec VPNs using TACACS+ or RADIUS as your
user authentication method. This feature, which is designed for VPN
clients, provides user authentication by prompting users for a username
and password and verifies them with the information stored in your
TACACS+ or RADIUS database. XAuth is negotiated between IKE
Phase 1 (the IKE device authentication phase) and IKE Phase 2 (the
IPSec SA negotiation phase). If XAuth fails, the IPSec security
association is not established, and the IKE security association is
deleted. The AAA server must be defined before XAuth will work on
the Cisco Security Appliance. You can define the AAA server using the
New button. This opens the AAA Server Group window, where you can
define the location of the AAA server, the group name, and the protocol
used for AAA.
Step 5 Define the location of the AAA server, the group name, and the protocol
used for AAA, as shown in Figure 15-31.

VPN Client Group Window

VPN Client Group Window
A preshared key is a quick and easy way to set up communications with
a limited number of remote peers. To use this method of authentication,
exchange the preshared key with the remote access user through a
secure and convenient method, such as an encrypted e-mail message.
Step 4 Use the Client Authentication window, shown in Figure 15-30, to
require VPN client users to authenticate from a AAA server for access
to the private network on your PIX Firewall. Client authentication
through a AAA server is optional and is not required for VPN client
access to the private network.

Remote Access Client Window

Remote Access Client Window
488 Chapter 15: Adaptive Security Device Manager
Step 3 Create a VPN client group to group remote-access users who are using
the Cisco VPN client. The attributes associated with a group are applied
and downloaded to the clients that are part of a given group. The
Group Password is a preshared key to be used for IKE authentication.
Figure 15-29 shows the VPN Client Group window with Cisco ASA as
a group name and the Pre-shared Key radio button selected for IKE

VPN Wizard with Remote-Access VPN Selected

VPN Wizard with Remote-Access VPN Selected
Step 2 In the Remote Access Client window, shown in Figure 15-28, identify
the type of remote-access client that will use the current VPN tunnel to
connect to your local Cisco PIX Firewall. The options are as follow:
• Cisco VPN Client—Select to support remote-access clients using
Cisco VPN Client v3.x or higher (Cisco Unified VPN Client
Framework).
• Cisco VPN 3000 Client—Select to support remote-access clients
using Cisco VPN 3000 Client, Release 3.0 or higher.

Using ASDM to Create a Remote-Access VPN

Using ASDM to Create a Remote-Access VPN
With a remote-access VPN, your local Cisco Security Appliance provides secure connectivity
between individual remote users and the LAN resources protected by your local Security
Appliance. To start the VPN Wizard, go to the wizard’s menu on ASDM and select the VPN
Wizard option:
Step 1 From the opening window of the ASDM VPN Wizard, shown in Figure
15-27, select the Remote Access VPN radio button to create a remoteaccess
VPN configuration. This configuration enables secure remote
access for VPN clients, such as mobile users. A remote-access VPN
allows remote users to securely access centralized network resources.
When you select this option, the system displays a series of panels that
let you enter the configuration required for this type of VPN. In Figure
15-27, the outside interface is selected as the interface on which the
current VPN tunnel will be enabled.