<<

. 4
( 19)



>>

that user is also authorized. RADIUS uses UDP port 1645 or 1812 for authentication and UDP
port 1646 or 1813 for accounting.
RADIUS is widely used by VoIP service providers. It passes login credentials of a session initia-
tion protocol (SIP) endpoint, such as a broadband phone, to a SIP Registrar using digest authenti-
cation, and then to a RADIUS server using RADIUS. RADIUS is also a common authentication
protocol that is utilized by the 802.1X security standard.
The DIAMETER protocol is the planned replacement for RADIUS. DIAMETER uses a new
transport protocol called Stream Control Transmission Protocol (SCTP) and TCP instead of UDP.
Chapter 3: Authentication, Authorization, and Accounting 71




3.3.3 Cisco Secure ACS
Many enterprise-level authentication servers are on the market today. Funk™s Steel-Belted RA-
DIUS server, Livingston Enterprises™ RADIUS Authentication Billing Manager, and Merit Net-
works™ RADIUS servers are well known. While these are reputable companies with popular
products, they lack the ability to combine both the TACACS+ and RADIUS protocols into a single
solution. Fortunately, the Cisco Secure ACS for Windows Server (ACS) is a single solution that of-
fers AAA for both TACACS+ and RADIUS.
Cisco Secure ACS is a highly scalable, high-performance access control server that can be lever-
aged to control administrator access and configuration for all network devices in a network sup-
porting RADIUS or TACACS+ or both. Cisco Secure ACS offers several benefits:

Extends access security by combining authentication, user access, and administrator access


with policy control within a centralized identity networking solution.
Allows greater flexibility and mobility, increased security, and user-productivity gains.



Enforces a uniform security policy for all users, regardless of how they access the network.



Reduces the administrative and management burden when scaling user and network


administrator access to the network.
Cisco Secure ACS uses a central database. It centralizes the control of all user privileges and dis-
tributes them to access points throughout the network. Cisco Secure ACS provides detailed report-
ing and monitoring capabilities of user behavior, access connections, and device configuration
changes. This feature is extremely important for organizations trying to comply with various gov-
ernment regulations. Cisco Secure ACS supports a broad variety of access connections, including
wired and wireless LAN, dialup, broadband, content, storage, VoIP, firewalls, and virtual private
networks (VPNs).
Cisco Secure ACS provides a variety of advanced features:

Automatic service monitoring



Database synchronization and importing of tools for large-scale deployments



LDAP user authentication support



User and administrative access reporting



Restrictions to network access based on criteria such as the time of day and the day of week



User and device group profiles


Cisco Secure ACS is an important component of the Cisco Identity Based Networking Services
(IBNS) architecture. Cisco IBNS is based on port-security standards such as IEEE 802.1X and Ex-
tensible Authentication Protocol (EAP), and extends security from the perimeter of the network to
every connection point inside the LAN. New policy control, such as per-user quotas, VLAN as-
signments, and access control lists (ACLs) can be deployed within this new architecture. This is
due to the extended capabilities of Cisco switches and wireless access points to query Cisco Se-
cure ACS over the RADIUS protocol.
Cisco Secure ACS is also an important component of Cisco Network Admission Control (NAC).
Cisco NAC is an industry initiative sponsored by Cisco. Cisco NAC uses the network infrastruc-
ture to enforce security-policy compliance on all devices seeking to access network computing re-
sources. This limits damage from viruses and worms. With Cisco NAC, customers can choose to
allow network access only to compliant and trusted endpoint devices and restrict the access of
noncompliant devices. NAC is part of the Cisco Self-Defending Network initiative and is the foun-
72 CCNA Security Course Booklet, Version 1.0




dation for enabling NAC on Layer 2 and Layer 3 networks. Future phases extend endpoint and net-
work security interoperation to include dynamic incident-containment capabilities. This innovation
enables compliant system elements to report misuse emanating from rogue or infected systems
during an attack. Infected systems can be dynamically quarantined from the rest of the network to
significantly reduce virus, worm, and blended threat propagation.
Cisco Secure ACS has many high-performance and scalability features:

Ease of use - A web-based user interface simplifies and distributes the configuration for user


profiles, group profiles, and Cisco Secure ACS configuration.
Scalability - Cisco Secure ACS is built to provide large networked environments with support


for redundant servers, remote databases, and database replication and backup services.
Extensibility - LDAP authentication forwarding supports the authentication of user profiles


that are stored in directories from leading directory vendors, including Sun, Novell, and
Microsoft.
Management - Microsoft Windows Active Directory support consolidates Windows


username and password management and uses the Windows Performance Monitor for real-
time statistics viewing.
Administration - Different access levels for each Cisco Secure ACS administrator and the


ability to group network devices together make it easier and more flexible to control the
enforcement and changes of security policy administration for all devices in a network.
Product flexibility - Because Cisco IOS software has embedded support for AAA, Cisco


Secure ACS can be used across virtually any network access server that Cisco sells (the Cisco
IOS software release must support RADIUS or TACACS+). Cisco Secure ACS is available in
three options: Cisco Secure ACS Solution Engine, Cisco Secure ACS Express, and Cisco
Secure ACS for Windows.
Integration - Tight coupling with Cisco IOS routers and VPN solutions provides features


such as multichassis multilink PPP and Cisco IOS software command authorization.
Third-party support - Cisco Secure ACS offers token server support for any one-time


password (OTP) vendor that provides an RFC-compliant RADIUS interface, such as RSA,
PassGo, Secure Computing, ActiveCard, Vasco, or CryptoCard.
Control - Cisco Secure ACS provides dynamic quotas to restrict access based on the time of


day, network use, number of logged sessions, and the day of the week.
Cisco Secure ACS is available as software installed on a Windows Server or on a 1U, rack-mount-
able, security-hardened server, such as ACS Solution Engine or ACS Express. All are server-based
examples of providing AAA services using a remote security database.
The Cisco Secure ACS for Windows option enables the AAA services on a router to contact an ex-
ternal Cisco Secure ACS installed on a Windows server system for user and administrator authenti-
cation.
Cisco Secure ACS Solution Engine is a 1U rack-mountable unit, security-hardened appliance with
a pre-installed Cisco Secure ACS license. It should be used in large organizations where more than
350 users need to be supported. Compared to the Cisco Secure ACS for Windows product, Cisco
Secure ACS Solution Engine reduces the total cost of ownership by eliminating the need to install
and maintain a Microsoft Windows server machine.
Cisco Secure ACS Express is also a 1U rack-mountable unit, security-hardened appliance with a
pre-installed Cisco Secure ACS Express license. The difference is that the ACS Express option is
Chapter 3: Authentication, Authorization, and Accounting 73




intended for commercial (less than 350 users), retail, and enterprise branch office deployments.
ACS Express offers a comprehensive yet simplified feature set, a user-friendly GUI, and a lower
price point that allows administrators to deploy this product in situations where Cisco Secure ACS
for Windows Server or Cisco Secure ACS Solution Engine might not be suitable.
While this chapter focuses on deploying Cisco Secure ACS for Windows Server, the concepts and
features discussed are also available on the ACS Solution Engine and ACS Express.


3.3.4 Configuring Cisco Secure ACS
Before installing Cisco Secure ACS, it is important to prepare the server. Third-party software re-
quirements and the network and port requirements of the server and AAA devices must be consid-
ered.
Third-Party Software Requirements
Software products that are mentioned in the release notes are supported for interoperability by
Cisco. Support for interoperability issues with software products that are not mentioned in the re-
lease notes might be difficult to attain. The most recent version of the Cisco Secure ACS release
notes are posted on Cisco.com.
Keep in mind that in the Cisco Secure ACS application, a client is a router, switch, firewall, or
VPN concentrator that uses the services of the server.
Network and Port Prerequisites
The network should meet specified requirements before administrators begin deploying Cisco Se-
cure ACS:

For full TACACS+ and RADIUS support on Cisco IOS devices, AAA clients must run Cisco


IOS Release 11.2 or later.
Cisco devices that are not Cisco IOS AAA clients must be configured with TACACS+,


RADIUS, or both.
Dial-in, VPN, or wireless clients must be able to connect to the applicable AAA clients.



The computer running Cisco Secure ACS must be able to reach all AAA clients using ping.



Gateway devices between the Cisco Secure ACS and other network devices must permit


communication over the ports that are needed to support the applicable feature or protocol.
A supported web browser must be installed on the computer running Cisco Secure ACS. For


the most recent information about tested browsers, see the release notes for the Cisco Secure
ACS product on Cisco.com.
All NICs in the computer running Cisco Secure ACS must be enabled. If there is a disabled


network card on the computer running Cisco Secure ACS, installing Cisco Secure ACS might
proceed slowly because of delays caused by the Microsoft CryptoAPI.
After successfully installing Cisco Secure ACS, some initial configuration must be performed. The
only way to configure a Cisco Secure ACS server is through an HTML interface.
To access the Cisco Secure ACS HTML interface from the computer that is running Cisco Secure
ACS, use the Cisco Secure icon labeled ACS Admin that appears on the desktop or enter the fol-
lowing URL into a supported web browser: http://127.0.0.1:2002.
The Cisco Secure ACS can also be accessed remotely after an administrator user account is config-
ured. To remotely access the Cisco Secure ACS, enter http://ip_address[hostname]:2002.
After the initial connection, a different port is dynamically negotiated.
74 CCNA Security Course Booklet, Version 1.0




The home page of Cisco Secure ACS is divided into frames. The buttons on the navigation bar rep-
resent particular areas or functions that can be configured:

User Setup



Group Setup



Shared Profile Components



Network Configuration



System Configuration



Interface Configuration



Administration Control



External User Databases



Posture Validation



Network Access Profiles



Reports and Activity



Online Documentation



If the RADIUS options are not displayed, the AAA client that uses the RADIUS protocol must be
added. Additionally, the interface configuration is directly affected by the settings in the network
configuration.
Before configuring a router, switch, or firewall as a TACACS+ or RADIUS client, the AAA client
to the server must be added and the IP address and encryption key specified. The Network Config-
uration page is where the AAA clients are added, deleted, or modified.
To create an AAA client, use the Network Configuration page:
Step 1. Click Network Configuration on the navigation bar. The Network Configuration page ap-
pears.
Step 2. In the AAA Clients section, click Add Entry.
Step 3. Enter the client host name in the AAA Client Hostname field. For example, enter the name
of the router that will be a AAA client to the server. In the Cisco Secure ACS application, a client
is a router, switch, firewall, or VPN concentrator that uses the services of the server.
Step 4. Enter the IP address in the AAA Client IP Address field.
Step 5. Enter the secret key that the client uses for encryption in the Shared Secret field.
Step 6. Choose the appropriate AAA protocol from the Authenticate Using drop-down list.
Step 7. Complete other parameters as required.
Step 8. Click Submit and Apply.
The options that are available from the Interface Configuration navigation button allow the admin-
istrator to control the display of options in the user interface. The specific options displayed de-
pend on whether TACACS+ or RADIUS clients have been added to the server:

User Data Configuration



TACACS+ (Cisco IOS)



RADIUS (Microsoft)

Chapter 3: Authentication, Authorization, and Accounting 75




RADIUS (Ascend)



RADIUS (IETF)



RADIUS (IOS/PIX)



Advanced Options



The User Data Configuration link enables administrators to customize the fields that appear in the
user setup and configuration windows. Administrators can add fields such as phone number, work
location, supervisor name, or any other pertinent information.
The TACACS+ (Cisco IOS) link enables the administrator to configure TACACS+ settings as well
as add new TACACS+ services. Administrators can also configure advanced options that affect
what is displayed in the user interface.
Cisco Secure ACS can be configured to forward authentication of users to one or more external
user databases. Support for external user databases means that Cisco Secure ACS does not require
duplicate user entries to be created in the Cisco Secure user database. In organizations in which a
substantial user database already exists, such as an Active Directory environment, Cisco Secure
ACS can leverage the work already invested in building the database without any additional input.
For most database configurations, except for Windows databases, Cisco Secure ACS supports only
one instance of a username and password. If Cisco Secure ACS is configured to use multiple user
databases with common usernames stored in each, be careful with the database configurations. The
first database to match the authentication credentials of the user is the only one that Cisco Secure
ACS uses for that user. It is for this reason that it is recommended that there be only one instance
of a username in all the external databases.
Use the External User Databases button to configure Cisco Secure ACS to access external data-
bases:
Step 1. Click the External User Databases button from the navigation bar. The External User
Databases window appears with the following links:

Unknown User Policy - Configures the authentication procedure for users that are not located


in the Cisco Secure ACS database.
Database Group Mappings - Configures what group privileges external database users


inherit when Cisco Secure ACS authenticates them. In most cases, when a user is
authenticated by an external user database, the actual privileges are drawn from Cisco Secure
ACS and not the external database.
Database Configuration - Defines the external servers that Cisco Secure ACS works with.



Step 2. Click Database Configuration. The External User Database Configuration pane appears,
displaying the following options:

RSA SecurID Token Server



RADIUS Token Server



External ODBC Database



Windows Database



LEAP Proxy RADIUS Server



Generic LDAP

76 CCNA Security Course Booklet, Version 1.0




Step 3. To use the Windows database as an external database, click Windows Database. The Win-
dows External User Database Configuration pane appears.
The Windows external database configuration has more options than other external database con-
figurations. Because Cisco Secure ACS is native to the Windows operating system, administrators
can configure additional functionality on the Windows External User Database Configuration
pane.
Step 4. To configure the additional Windows database functionality, click Configure from the Ex-
ternal User Database Configuration pane. The Windows User Database Configuration window ap-
pears.
Step 5. If more control over who is able to authenticate to the network is required, the Dialin per-
mission option can also be configured. In the Dialin Permission section, check the Verify that
“Grant dialin permission to user” setting has been enabled from within the Windows User
Manager for users configured for Windows User Database authentication check box. Also
make sure that the Grant dialin permission check box is checked in the Windows profile within
Windows Users Manager.
The Dialin Permissions option of Cisco Secure ACS applies to more than just the dialup connec-
tions. If a user has this option enabled, it applies to any access that user tries to make.
Another option that can be configured using the Windows external database is mapping databases
to domains. Mapping allows an administrator to have the same username across different domains,
all with different passwords.


3.3.5 Configuring Cisco Secure ACS Users and Groups
After Cisco Secure ACS is configured to communicate with an external user database, it can be
configured to authenticate users with the external user database in one of two ways:

By specific user assignment - Authenticate specific users with an external user database.



By unknown user policy - Use an external database to authenticate users not found in the


Cisco Secure user database. This method does not require administrators to define users in the
Cisco Secure user database.
Use the External User Databases link to configure the unknown user policy:
Step 1. In the navigation bar, click External User Databases.
Step 2. Click Unknown User Policy.
Step 3. Enable the Unknown User Policy by checking the box in the Unknown User Policy sec-
tion.
Step 4. For each database that administrators want Cisco Secure ACS to use when attempting to
authenticate unknown users, choose the database in the External Databases list and click the right
arrow button to move it to the Selected Databases list. To remove a database from the Selected
Databases list, choose the database, and then click the left arrow button to move it back to the Ex-
ternal Databases list.
Step 5. To assign the order in which Cisco Secure ACS checks the selected external databases
when attempting to authenticate an unknown user, click a database name in the Selected Databases
list and click Up or Down to move it into the desired position. Place the databases that are most
likely to authenticate unknown users at the top of the list.
Step 6. Click Submit.
Chapter 3: Authentication, Authorization, and Accounting 77




After a user is authenticated to an external database, the authorization that takes place is deter-
mined by Cisco Secure ACS. This can complicate things because users that are authenticated by a
Windows server might require different authorization than users that are authenticated by the
LDAP server.
Because of this potential need for different authorizations, place users that are authenticated by the
Windows server in one group and users that are authenticated by the LDAP server in another
group. To do this, use database group mappings.
Database group mappings enable an administrator to map an authentication server, such as LDAP,
Windows, ODBC, and so on, to a group that has been configured in Cisco Secure ACS. For some
databases, a user can belong to only one group. For other databases, such as LDAP and Windows,
support for group mapping by external database group membership is possible.
One of the things that can be configured in a group setup is per group command authorization,
which uses Cisco Secure ACS to authorize which router commands the users that belong to a
group can execute. For example, a group can be permitted to execute any router commands except
show running-config.

Step 1. Click Group Setup in the navigation bar.
Step 2. Choose the group to edit, the Default Group for example, and click Edit Settings.
Step 3. Click Permit in the Unmatched Cisco IOS commands option.
Step 4. Check the Command check box and enter show in the text box. In the Arguments text
box, enter deny running-config.
Step 5. For the Unlisted Arguments option, click Permit.
Adding a user account and configuring user access is a critical task for Cisco Secure ACS:
Step 1. Click User Setup in the navigation bar.
Step 2. Enter a username in the User field and click Add/Edit.
Step 3. In the Edit pane, enter data in the fields to define the user account. Some of the likely
needed fields are the user password fields, TACACS+ enable control, TACACS+ enable password,
and TACACS+ shell authorized commands.
Step 4. Click Submit.
If there are necessary user properties that you do not see, verify the interface configuration. To
modify the user interface, choose Interface Configuration > User Data Configuration.



3.4 Server-Based AAA Authentication
3.4.1 Configuring Server-Based AAA Authentication with
CLI
Unlike Local AAA Authentication, server-based AAA must identify various TACACS+ and RA-
DIUS servers that the AAA service should consult when authenticating and authorizing users.
There are a few basic steps to configure server-based authentication:
Step 1. Globally enable AAA to allow the use of all AAA elements. This step is a prerequisite for
all other AAA commands.
Step 2. Specify the Cisco Secure ACS that will provide AAA services for the router. This can be a
TACACS+ or RADIUS server.
78 CCNA Security Course Booklet, Version 1.0




Step 3. Configure the encryption key needed to encrypt the data transfer between the network ac-
cess server and Cisco Secure ACS.
Step 4. Configure the AAA authentication method list to refer to the TACACS+ or RADIUS
server. For redundancy, it is possible to configure more than one server.
Configure a TACACS+ Server and Encryption Key
To configure a TACACS+ server, use the tacacs-server host ip-address single-connection
command.
The single-connection keyword enhances TCP performance by maintaining a single TCP con-
nection for the life of the session. Otherwise, by default, a TCP connection is opened and closed
for each session. If required, multiple TACACS+ servers can be identified by entering their respec-
tive IP address using the tacacs-server host command.
Next, use the tacacs-server key key command to configure the shared secret key to encrypt the
data transfer between the TACACS+ server and AAA-enabled router. This key must be configured
exactly the same on the router and the TACACS+ server.
Configure a RADIUS Server and Encryption Key
To configure a RADIUS server, use the radius-server host ip-address command. Because
RADIUS uses UDP, there is no equivalent single-connection keyword. If required, multiple RA-
DIUS servers can be identified by entering a radius-server host command for each server.
To configure the shared secret key for encrypting the password, use the radius-server key key
command. This key must be configured exactly the same on the router and the RADIUS server.
Configure Authentication to Use the AAA Server
When the AAA security servers have been identified, the servers must be included in the method
list of the aaa authentication login command. AAA servers are identified using the group
tacacs+ or group radius keywords. For example, to configure a method list for the default login
to authenticate using a RADIUS server, a TACACS+ server, or a local username database, use the
command aaa authentication login default group radius group tacacs+ local-case.


3.4.2 Configuring Server-Based AAA Authentication with
SDM
If using SDM for TACACS+ support, it is necessary to specify a list of available Cisco Secure
ACS servers that provide TACACS+ services for the router:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > AAA
Servers and Groups > AAA Servers.
Step 2. From the AAA Servers pane, click Add. The Add AAA Server window appears. Choose
TACACS+ from the Server Type list box.
Step 3. Enter the IP address or host name of the AAA server in the Server IP or Host field. If the
router has not been configured to use a DNS server, enter a DNS server IP address.
Step 4. The router can be configured to maintain a single open connection to the TACACS+ server
rather than opening and closing a TCP connection each time it communicates with the server. To
do so, check the Single Connection to Server check box.
Step 5. To override AAA server global settings and specify a server-specific timeout value in the
Server-Specific Setup section, enter a value in the Timeout (seconds) field. This field determines
how long the router waits for a response from this server before going on to the next server in the
Chapter 3: Authentication, Authorization, and Accounting 79




group list. If a value is not entered, the router uses the value that is configured in the AAA Servers
Global Settings window. The default setting is five seconds.
Step 6. To configure a server-specific key, check the Configure Key check box and enter the key
that is used to encrypt traffic between the router and this server in the New Key field. Re-enter the
key in the Confirm Key field for confirmation. If this option is not checked and a value is not en-
tered, the router uses the value that was configured in the AAA Servers Global Settings window.
Step 7. Click OK.
An example CLI command that Cisco SDM would generate based on a TACACS+ server at IP ad-
dress 10.0.1.1 and key TACACS+Pa55w0rd is tacacs-server host 10.0.1.1 key
TACACS+Pa55w0rd.

After AAA is enabled and the TACACS+ servers are configured, the router can be configured to
use the Cisco Secure ACS server to authenticate user access to the router. To configure the router
to use the Cisco Secure ACS server for login authentication, a user-defined authentication login
method list must be created, or the default method list must be edited. Keep in mind, the default
method list is automatically applied to all interfaces and lines, except those that have a user-de-
fined method list explicitly applied.
The administrator can use Cisco SDM to configure a user-defined authentication login method list:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Au-
thentication Policies > Login.
Step 2. From the Authentication Login pane, click Add.
Step 3. To create a new authentication login method, choose User Defined from the Name drop-
down list.
Step 4. Enter the authentication login method list name in the Specify field, for example
TACACS_SERVER.
Step 5. Click Add to define the methods that this policy uses. The Select Method List(s) for Au-
thentication Login window appears.
Step 6. Choose group tacacs+ from the method list.
Step 7. Click OK to add group tacacs+ to the method list and return to the Add a Method List for
Authentication Login window.
Step 8. Click Add to add a backup method to this policy. The Select Method List(s) for Authenti-
cation Login window appears.
Step 9. Choose enable from the method list to use the enable password as the backup login au-
thentication method.
Step 10. Click OK to add enable to the method list and return to the Add a Method List for Au-
thentication Login window.
Step 11. Click OK to add the authentication login method list and return to the Authentication
Login screen.
The resulting CLI command that Cisco SDM generates is aaa authentication login
TACACS_SERVER group tacacs+ enable.

After the authentication login method lists are created, apply the lists to lines and interfaces on the
router.
80 CCNA Security Course Booklet, Version 1.0




SDM can be used to apply an authentication policy to a router line:
Step 1. Choose Configure > Additional Tasks > Router Access > VTY.
Step 2. From the VTY Lines window, click the Edit button to make changes to the vty lines. The
Edit VTY Lines window appears.
Step 3. From the Authentication Policy list box, choose the authentication policy to apply to the
vty lines. For example, applying the authentication policy named TACACS_SERVER to vty lines
0 through 4 results in the login authentication TACACS_SERVER CLI command.
The CLI can also be used to apply an authentication policy to lines or interfaces with the login
authentication {default | list-name} command in line configuration mode or interface con-
figuration mode.


3.4.3 Troubleshooting Server-Based AAA Authentication
When AAA is enabled, it is often necessary to monitor authentication traffic and troubleshoot con-
figurations.
The debug aaa authentication command is a useful AAA troubleshooting command because it
provides a high-level view of login activity.
The command indicates a status message of PASS when a TACACS+ login attempt is successful.
If the status message returned is FAIL, verify the secret key.
Two other very useful server-based AAA troubleshooting commands include the debug tacacs
and debug radius commands. These commands can be used to provide more detailed AAA de-
bugging information. To disable debugging output, use the no form of these commands.
Similar to the debug aaa command, the debug also indicates status mes-
authentication tacacs
sages of PASS or FAIL.
To see all TACACS+ messages use the debug tacacs command. To narrow the results and display
information from the TACACS+ helper process, use the debug tacacs events command in privi-
leged EXEC mode. The debug tacacs events command displays the opening and closing of a
TCP connection to a TACACS+ server, the bytes read and written over the connection, and the
TCP status of the connection. Use the debug tacacs events command with caution, because it
can generate a substantial amount of output. To disable debugging output, use the no form of this
command.




3.5 Server-Based AAA Authorization and
Accounting
3.5.1 Configuring Server-Based AAA Authorization
While authentication is concerned with ensuring that the device or end user is as claimed, authori-
zation is concerned with allowing and disallowing authenticated users access to certain areas and
programs on the network.
The TACACS+ protocol allows the separation of authentication from authorization. A router can
be configured to restrict the user to performing only certain functions after successful authentica-
tion. Authorization can be configured for both character mode (exec authorization) and packet
Chapter 3: Authentication, Authorization, and Accounting 81




mode (network authorization). Keep in mind that RADIUS does not separate the authentication
from the authorization process.
Another important aspect of authorization is the ability to control user access to specific services.
Controlling access to configuration commands greatly simplifies the infrastructure security in
large enterprise networks. Per-user permissions on the Cisco Secure ACS simplify network device
configuration.
For example, an authorized user can be permitted to access the show version command but not
the configure terminal command. The router queries the ACS for permission to execute the
commands on behalf of the user. When the user issues the show version command, the ACS
sends an ACCEPT response. If the user issues a configure terminal command, the ACS sends a
REJECT response.
TACACS+ by default establishes a new TCP session for every authorization request, which can
lead to delays when users enter commands. Cisco Secure ACS supports persistent TCP sessions to
improve performance.
To configure command authorization, use the aaa authorization {network | exec | commands
command. The service type can specify
level} {default | list-name} method1...[method4]
the types of commands or services:
for exec (shell) commands
commands level

for starting an exec (shell)
exec

for network services (PPP, SLIP, ARAP)
network

When AAA authorization is not enabled, all users are allowed full access. After authentication is
started, the default changes to allow no access. This means that the administrator must create a
user with full access rights before authorization is enabled. Failure to do so immediately locks the
administrator out of the system the moment the aaa authorization command is entered. The
only way to recover from this is to reboot the router. If this is a production router, rebooting might
be unacceptable. Be sure that at least one user always has full rights.
To configure the router to use the Cisco Secure ACS server for authorization, create a user-defined
authorization method list or edit the default authorization method list. The default authorization
method list is automatically applied to all interfaces except those that have a user-defined authori-
zation method list explicitly applied. A user-defined authorization method list overrides the default
authorization method list.
Cisco SDM can be used to configure the default authorization method list for character mode
(exec) access:
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Autho-
rization Policies > Exec.
Step 2. From the Exec Authorization pane, click Add.
Step 3. From the Add a Method List for Exec Authorization window, choose Default from the
Name drop-down list.
Step 4. Click Add to define the methods that this policy uses.
Step 5. From the Select Method List(s) for Exec Authorization window, choose group tacacs+
from the method list.
Step 6. Click OK to return to the Add a Method List for Exec Authorization window.
Step 7. Click OK to return to the Exec Authorization pane.
82 CCNA Security Course Booklet, Version 1.0




The resulting CLI command that Cisco SDM generates is aaa authorization exec default
group tacacs+.

The SDM can also be used to configure the default authorization method list for packet mode (net-
work):
Step 1. From the Cisco SDM home page, choose Configure > Additional Tasks > AAA > Autho-
rization Policies > Network.
Step 2. From the Network Authorization pane, click Add.
Step 3. From the Add a Method List for Network Authorization window, choose Default from the
Name drop-down list.
Step 4. Click Add to define the methods that this policy uses.
Step 5. From the Select Method List(s) for Network Authorization window, choose group tacacs+
from the method list.
Step 6. Click OK to return to the Add a Method List for Network Authorization window.
Step 7. Click OK to return to the Network Authorization pane.
The resulting CLI command that Cisco SDM generates is aaa authorization network default
group tacacs+.



3.5.2 Configuring Server-Based AAA Accounting
Sometimes a company wants to keep track of which resources individuals or groups use. Examples
of this include when one department charges other departments for access, or one company pro-
vides internal support to another company. AAA accounting provides the ability to track usage,
such as dial-in access, to log the data gathered to a database, and to produce reports on the data
gathered.
Although accounting is generally considered a network management or financial management
issue, it is discussed briefly here because it is so closely linked with security. One security issue
that accounting addresses is creating a list of users and the time of day they dialed into the system.
If, for example, the administrator knows that a worker logs in to the system in the middle of the
night, this information can be used to further investigate the purpose of the login.
Another reason to implement accounting is to create a list of changes occurring on the network,
who made the changes, and the exact nature of the changes. Knowing this information helps the
troubleshooting process if the changes cause unexpected results.
Cisco Secure ACS serves as a central repository for accounting information, essentially tracking
events that occur on the network. Each session that is established through Cisco Secure ACS can
be fully accounted for and stored on the server. This stored information can be very helpful for
management, security audits, capacity planning, and network usage billing.
Like authentication and authorization method lists, method lists for accounting define the way ac-
counting is performed and the sequence in which these methods are performed. After it is enabled,
the default accounting method list is automatically applied to all interfaces, except those that have
a named accounting method list explicitly defined.
To configure AAA accounting, use the aaa accounting { network | exec | connection}
{default | list-name} {start-stop | stop-only | none} [broadcast] method1...[method4]
global configuration mode command. The network, exec, and connection parameters are com-
monly used keywords.
Chapter 3: Authentication, Authorization, and Accounting 83




As with AAA authentication, either the keyword default or a list-name is used.
Next, the record type, or trigger, is configured. The trigger specifies what actions cause accounting
records to be updated. Possible triggers are none, start-stop, stop-only.
For example, to log the use of EXEC sessions and network connections, use the global configura-
tion commands.
R1(config)# aaa accounting exec default start-stop group tacacs+
R1(config)# aaa accounting network default start-stop group tacacs+
84 CCNA Security Course Booklet, Version 1.0




Chapter Summary
Refer to Packet Refer to
Tracer Activity Lab Activity
for this chapter for this chapter




Your Chapter Notes
Chapter 3: Authentication, Authorization, and Accounting 85
86 CCNA Security Course Booklet, Version 1.0
CHAPTER 4

Implementing Firewall Technologies




Chapter Introduction
As networks continued to grow over time, they were increasingly used to transfer and store sensi-
tive data. This intensified the need for stronger security technologies, which led to the invention of
the firewall. The term firewall originally referred to a fireproof wall, usually made of stone or
metal that prevented flames from spreading between connected structures. Similarly, in network-
ing, firewalls separate protected from non-protected areas. This prevents unauthorized users from
accessing protected network resources.
Initially, basic Access Control Lists (ACLs), including standard, extended, numbered and named,
were the only means of providing firewall protection. Other firewall technologies began to mature
in the late 1990s. Stateful firewalls use tables to track the real-time state of end-to-end sessions.
Stateful firewalls take into account the session-oriented nature of network traffic. The first stateful
firewalls used the “TCP established” option for ACLs. Later, reflexive ACLs were used to dynami-
cally reflect certain types of inside-to-outside traffic upon the return of that traffic. Dynamic ACLs
were developed to open a hole in the firewall for approved traffic for a finite period of time. Time-
based ACLs were created to apply ACLs during certain times of the day on specified days of the
week. With the proliferation of ACL types, it became more and more important to be able to verify
the proper behavior of these ACLs with show and debug commands.
Today there are many types of firewalls in existence, including packet-filtering, stateful, applica-
tion gateway (proxy), address-translation, host-based, transparent, and hybrid firewalls. Modern
network design must carefully include proper placement of one or more firewalls to protect those
resources that must be protected while allowing secure access to those resources that must remain
available.
In a hands-on lab for the chapter, Securing Administrative Access Using AAA and RADIUS, learn-
ers use CLI and SDM to configure and test local authentication with and without AAA. Central-
ized authentication using AAA and RADIUS is also explored. The lab is found in the lab manual
on Academy Connection at cisco.netacad.net.
A Packet Tracer activity, Configure IP ACLs to Mitigate Attacks, provides learners additional prac-
tice implementing the technologies introduced in this chapter. In particular, learners configure
ACLs to ensure that remote access to routers is available only from management stations. Edge
routers are configured with ACLs to mitigate common network attacks and these ACLs are tested
for proper operation.
In a second Packet Tracer activity, Configuring Context-Based Access Control (CBAC), learners
configure and IOS firewall with CBAC on a perimeter router. CBAC functionality is verified with
ping, Telnet, and HTTP.
The last Packet Tracer activity for the chapter, Configuring a Zone-Based Policy Firewall (ZPF),
has learners configure a ZPF policy on a perimeter router. ZPF functionality is verified with ping,
Telnet and HTTP.
Packet Tracer activities for CCNA Security are found on Academy Connection at cisco.netacad.
net.
88 CCNA Security Course Booklet, Version 1.0




4.1 Access Control Lists
4.1.1 Configuring Standard and Extended IP ACLs with
CLI
Access control lists (ACLs) are widely used in computer networking and in network security for
mitigating network attacks and controlling network traffic. Administrators use ACLs to define and
control classes of traffic on networking devices based on various parameters. These parameters are
specific to Layer 2, 3, 4, and 7 of the OSI model.
Virtually any type of traffic can be defined explicitly by using an appropriately Numbered ACL.
For example, in the past, the Ethernet type field of an Ethernet frame header was used to define
certain types of traffic. An Ethernet type of 0x8035 indicated a reverse address resolution protocol
(RARP) frame. Numbered ACLs with a range of 200-299 were used to control traffic according to
Ethernet type.
It was also common to create ACLs based on MAC addresses. An ACL numbered 700-799 indi-
cates traffic is classified and controlled based on MAC addresses.
After the type of classification is specified, control parameters required for that ACL can be set.
For example, an ACL numbered 700-799 could be used to block a client with a specific MAC ad-
dress from associating with a predetermined access point.
Today, when classifying traffic, the most common types of parameters used in security-related
ACLs involve IPv4 and IPv6 addresses as well as TCP and UDP port numbers. For example, an
ACL can permit all users with a specific IP network address to download files from the Internet
using secure FTP. That same ACL can be used to deny all IP addresses from traditional FTP access.
Standard ACLs
ACLs numbered 1-99 or 1300-1999 are standard IPv4 and IPv6 ACLs. Standard ACLs match
packets by examining the source IP address field in the IP header of that packet. These ACLs are
used to filter packets based solely on Layer 3 source information.
Standard ACLs permit or deny traffic based on source address. This is the command syntax for
configuring a standard numbered IP ACL:
Router(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
The first value specifies the ACL number. For standard ACLs, the number range is 1 to 99. The
second value specifies whether to permit or deny the configured source IP address traffic. The
third value is the source IP address that must be matched. The fourth value is the wildcard mask to
be applied to the previously configured IP address to indicate the range.
Extended ACLs
Extended ACLs match packets based on Layer 3 and Layer 4 source and destination information.
Layer 4 information can include TCP and UDP port information. Extended ACLs give greater
flexibility and control over network access than standard ACLs. This is the command syntax for
configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr
[source-wildcard] [operator operand] destination-addr [destination-wildcard]
[operator operand] [established]
Similar to standard ACLs, the first value specifies the ACL number. ACLs numbered 100-199 or
2000-2699 are extended ACLs. The next value specifies whether to permit or deny according to
the criteria that follows. The third value indicates protocol type. The administrator must specify IP,
Chapter 4: Implementing Firewall Technologies 89




TCP, UDP, or other specific IP sub-protocols. The source IP address and wildcard mask determine
where traffic originates. The destination IP address and its wildcard mask are used to indicate the
final destination of the network traffic. Although the port parameter is defined as optional, when
the destination IP address and mask are configured, the administrator must specify the port num-
ber to match, either by number or by a well-known port name, otherwise all traffic to that destina-
tion will be dropped.
All ACLs assume an implicit deny, meaning that if a packet does not match any of the criteria
specified in the ACL, the packet is denied. Once an ACL is created, at least one permit statement
should be included or all traffic will be dropped once that ACL is applied to an interface.
Both standard and extended ACLs can be used to describe packets entering or exiting an interface.
The list is searched sequentially. The first statement matched stops the search through the list and
defines the action to be taken.
Once the standard or extended numbered IP ACL is created, the administrator must apply it to the
appropriate interface.
This is the command to apply the ACL to an interface:
Router(config-if)# ip access-group access-list-number {in | out}
This is the command to apply the ACL to a vty line:
Router(config-line)# access-class access-list-number {in | out}
It is possible to create a named ACL instead of a numbered ACL. Named ACLs must be specified
as either standard or extended.
Router(config)# ip access-list [standard | extended] name_of_ACL
Executing this command places a user into subconfiguration mode where permit and deny com-
mands are entered. The permit and deny commands have the same basic syntax as those in the
numbered IP ACL commands.
A standard named ACL can use deny and permit statements.
Router(config-std-nacl)# deny {source [source-wildcard] | any}
Router(config-std-nacl)# permit {source [source-wildcard] | any}
An extended named ACL offers additional parameters.
Router(config-ext-nacl)# {permit | deny} protocol source-addr [source-wildcard]
[operator operand] destination-addr [destination-wildcard] [operator operand]
[established]
Advantages for using named ACLs include that an administrator can delete a specific entry in a
named ACL by going into ACL subconfiguration mode and prefacing the command with the no
parameter. Using the no parameter with a numbered ACL entry results in the entire ACL being
deleted. An administrator can also add entries in the middle of a named ACL. With a numbered
ACL, commands can only be added to the end of the ACL.
Once the ACL statements are created, the administrator activates the ACL on an interface with the
ip access-group command, specifying the name of the ACL.

Router(config-if)# ip access-group access-list-name {in | out}
An ACL can also be used to permit or deny specific IP addresses from gaining virtual access. Stan-
dard ACLs allow restrictions to be enforced on the originator source IP address or IP address
range. An extended ACL does the same but can also enforce the access protocol such as port 23
(Telnet) or port 22 (SSH). The access-class extended ACL only supports the any keyword as the
destination. The access list must be applied to the vty port.
Router(config-line)# access-class access-list-name {in | out}
90 CCNA Security Course Booklet, Version 1.0




At the end of an ACL statement, the administrator has the option to configure the log parameter.
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0
0.0.0.255 eq 22 log
If this parameter is configured, the Cisco IOS software compares packets and finds a match to the
statement. The router logs it to any enabled logging facility, such as the console, the internal buffer
of the router, or a syslog server. Several pieces of information are logged:

Action - permit or deny



Protocol - TCP, UDP, or ICMP



Source and destination addresses



For TCP and UDP - source and destination port numbers



For ICMP - message types



Log messages are generated on the first packet match and then at five minute intervals after that
first packet match.
Enabling the log parameter on a Cisco router or switch seriously affects the performance of that
device. When logging is enabled, packets are either process- or fast-switched. The log parameter
should be used only when the network is under attack and an administrator is trying to determine
who the attacker is. In this instance, an administrator should enable logging for the period required
to gather the appropriate information and then disable logging.
Several caveats should be considered when working with ACLs:

Implicit deny all - All Cisco ACLs end with an implicit “deny all” statement. Even if this


statement is not apparent in an ACL, it is there.
Standard ACL packet filtering - Standard ACLs are limited to packet filtering based on


source addresses only. Extended ACLs might need to be created to fully implement a security
policy.
Order of statements - ACLs have a policy of first match. When a statement is matched, the


list is no longer examined. Certain ACL statements are more specific than others and,
therefore, must be placed higher in the ACL. For example, blocking all UDP traffic at the top
of the list negates the statement for allowing SNMP packets, which use UDP, that is lower in
the list. An administrator must ensure that statements at the top of the ACL do not negate any
statements found lower.
Directional filtering - Cisco ACLs have a directional filter that determines whether inbound


packets (toward the interface) or outbound packets (away from the interface) are examined.
An administrator should double-check the direction of data that an ACL is filtering.
Modifying ACLs - When a router compares a packet to an ACL, the ACL entries are


examined from the top down. When a router locates a statement with matching criteria, the
ACL processing stops and the packet is either permitted or denied based on the ACL entry.
When new entries are added to an ACL, they are always added to the bottom. This can render
new entries unusable if a previous entry is more general. For example, if an ACL has an entry
that denies network 172.16.1.0/24 access to a server in one line, but the next line down
permits a single host, host 172.16.1.5, access to that same server, that host will still be denied.
This is because the router matches packets from 172.16.1.5 to the 172.16.1.0/24 network and
denies the traffic without reading the next line. When a new statement renders the ACL
unusable, a new ACL must be created with the correct statement ordering. The old ACL
Chapter 4: Implementing Firewall Technologies 91




should be deleted, and the new ACL assigned to the router interface. If using Cisco IOS
Release 12.3 and later, sequence numbers can be used to ensure that a new statement is being
added to the ACL in the correct location. The ACL is processed top-down based on the
sequence numbers of the statements (lowest to highest).
Special packets - Router-generated packets, such as routing table updates, are not subject to


outbound ACL statements on the source router. If the security policy requires filtering these
types of packets, inbound ACLs on adjacent routers or other router filter mechanisms using
ACLs must do the filtering task.

Now that the syntax and guidelines for standard and extended IP ACLs are defined, what are some
specific scenarios for which ACLs provide a security solution?


4.1.2 Using Standard and Extended IP ACLs
Determining whether to use standard or extended ACLs is based on the overall objective of the en-
tire ACL. For example, imagine a scenario in which all traffic from a single subnet, 172.16.4.0,
must be denied access to another subnet, but all other traffic should be permitted.
In this case, a standard ACL can be applied outbound on interface Fa0/0:
R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255
R1(config)# access-list 1 permit any
R1(config)# interface FastEthernet 0/0
R1(config-if)# ip access-group 1 out
All hosts on subnet 172.16.4.0 are blocked from going out on interface Fa0/0 to subnet 172.16.3.0.
These are the access-list command parameters:

The 1 parameter indicates that this ACL is a standard list.



The deny parameter indicates that traffic matching the selected parameters is not forwarded.



The 172.16.4.0 parameter is the IP address of the source subnet.



The 0.0.0.255 parameter is the wildcard mask. Zeros (0) indicate positions that must match


in the anding process; ones (1) indicate positions that will be ignored. The mask with zeros (0)
in the first three octets indicates those positions must match. The 255 indicates the last octet
will be ignored.
The permit parameter indicates that traffic matching the selected parameters is forwarded.



The any parameter is an abbreviation for the IP address of the source. Indicates a source


address of 0.0.0.0 and a wildcard mask of 255.255.255.255; all source addresses will match.

Because of the implicit deny at the end of all ACLs, the command access-list 1 permit any
must be included to ensure that only traffic from the 172.16.4.0 subnet is blocked and that all other
traffic is allowed.
As compared to standard ACLs, extended ACLs allow for specific types of traffic to be denied or
permitted. Imagine a scenario in which FTP traffic from one subnet must be denied on another
subnet. In this case, an extended ACL is required because a specific traffic type is filtered.
R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21
R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20
R1(config)# access-list 101 permit ip any any
92 CCNA Security Course Booklet, Version 1.0




In this ACL, FTP access is denied from subnet 172.16.4.0/24 to subnet 172.16.3.0/24. All other
traffic is allowed. TCP port 21 is used for FTP program commands. TCP port 20 is used for FTP
data transfer. Both ports are denied.
A permit ip any any statement is required at the end of the ACL; otherwise, all traffic is denied
because of the implicit deny.
In this example, the best placement of the ACL is inbound on the Fa0/1 interface. This ensures that
the unwanted FTP traffic is dropped before wasting router processing resources.
Router(config)# interface fastethernet 0/1
Router(config-if)# ip access-group 101 in
Keep in mind, with this ACL, a permit any any statement overrides the implicit deny all statement
at the end of every ACL. This means that all other traffic, including FTP traffic originating from
the 172.16.4.0/24 network destined for any network other than the 172.16.3.0/24 network, would
be permitted.


4.1.3 Topology and Flow for Access Control Lists
The direction of traffic through a networking device is defined by the ingress (inbound) and egress
(outbound) interfaces for the traffic. Inbound traffic refers to traffic as it enters into the router,
prior to the routing table being accessed. Outbound traffic refers to traffic that entered the router
and has been processed by the router to determine where to forward that data. Prior to the data
being forwarded out of that interface, an outbound ACL is examined.
Depending on the type of device and the type of ACL configured, the return traffic can be dynami-
cally tracked.
In addition to flow, it is important to keep the placement of ACLs in mind. Placement depends on
the type of ACL being used.
Extended ACL placement - Extended ACLs are placed on routers as close as possible to the
source that is being filtered. Placing Extended ACLs too far from the source is inefficient use of
network resources. For example, packets can be sent a long way only to be dropped or denied.
Standard ACL placement - Standard ACLs are placed as close to the destination as possible.
Standard ACLs filter packets based on the source address only. Placing these ACLs too close to the
source can adversely affect packets by denying all traffic, including valid traffic.
Most often, ACLs are used to prevent a majority of traffic from entering a network. At the same
time they selectively permit some more secure types of traffic, such as HTTPS (TCP port 443), to
be used for business purposes. This generally requires using Extended ACLs and a clear under-
standing of which ports must be blocked versus permitted.
The Nmap program can be used to determine which ports are open on a given device. For exam-
ple, an ACL blocks POP3 traffic from downloading email through the Internet from a mail server
on the company network, but allows email to be downloaded from a workstation inside the com-
pany network. The output of an Nmap scan on the POP3 server depends on where the scan origi-
nates. If the scan is done from a PC inside the network, the POP3 port appears open (TCP port
110).
After an ACL is applied to an interface, it is important to verify that it is functioning as intended,
that is, traffic that should be denied is denied and valid traffic is permitted.
While the log option shows matches of logged packets as they happen, it can be an excessive re-
source burden on the networking device. The log option is best used on an interim basis to verify
or troubleshoot configuration of an ACL.
Chapter 4: Implementing Firewall Technologies 93




The show ip access-list command can be used as a basic means of checking the intended effect
of an ACL. With this command, only the number of packets matching a given access control entry
(ACE) is recorded.
The show command can be used to view which interfaces have ACLs applied.
running-config


4.1.4 Configuring Standard and Extended ACLs with SDM
ACLs can be configured from the CLI or using SDM.
Standard and Extended ACLs can be configured using Cisco Router and Security Device Manager
(SDM). The SDM window has two frames. The About Your Router frame contains hardware and
software details. The Configuration Overview frame provides current router configuration details,
including interface, firewall, VPN, routing, and IPS information.
The Configure button at the top of the SDM application window opens the Task list. Click the
Additional Tasks button to access the page for configuring ACLs.
Rules define how a router responds to a particular kind of traffic. Using Cisco SDM, an adminis-
trator can create access rules that cause the router to deny certain types of traffic while permitting
other types. Cisco SDM provides default rules that an administrator can use when creating access
rules.
An administrator can also view rules that were not created using Cisco SDM, called external rules,
and rules with syntax that Cisco SDM does not support, which are called unsupported rules.
The SDM Rules (ACLs) Summary window provides a summary of the rules in the router configu-
ration and access to other windows to create, edit, and delete rules. To access this window, choose
Configure > Additional Tasks > ACL Editor. These are the types of rules that Cisco SDM man-
ages:

Access Rules - Govern the traffic that can enter and leave the network. An administrator can


apply access rules to router interfaces and to vty lines.
NAT Rules - Determine which private IP addresses are translated into valid Internet IP


addresses.
IPsec Rules - Determine which traffic is encrypted on secure connections.



NAC Rules - Specify which IP addresses are admitted to the network or blocked from the


network.
Firewall Rules - Specify the source and destination addresses and whether the traffic is


permitted or denied.
QoS Rules - Specify traffic that belongs to the quality of service (QoS) class to which the


rule is associated.
Unsupported Rules - Not created using Cisco SDM and not supported by Cisco SDM. These


rules are read only and cannot be modified using Cisco SDM.
Externally-defined Rules - Not created using Cisco SDM, but supported by Cisco SDM.


These rules cannot be associated with any interface.
SDM Default Rules - Predefined rules that are used by Cisco SDM wizards.


Cisco SDM refers to ACLs as access rules. Using Cisco SDM, an administrator can create and
apply standard rules (Standard ACLs) and extended rules (Extended ACLs). These are the steps for
configuring a standard rule using Cisco SDM:
Step 1. Choose Configure > Additional Tasks > ACL Editor > Access Rules.
94 CCNA Security Course Booklet, Version 1.0




Step 2. Click Add. The Add a Rule window appears. Only interfaces with a status of up/up will be
listed in the drop-down list.
Step 3. In the Add a Rule window, enter a name or number in the Name/Number field.
Step 4. From the Type drop-down list, choose Standard Rule. Optionally, enter a description in
the Description field.
Step 5. Click Add. The Add a Standard Rule Entry window appears.
Step 6. From the Select an action drop-down list, choose Permit or Deny.
Step 7. From the Type drop-down list, choose an address type:

A Network - Applies to all IP addresses in a network or subnet.



A Host Name or IP Address - Applies to a specific host or IP address.



Any IP address - Applies to any IP address.



Step 8. Depending on what was selected from the Type drop-down list, these additional fields
must be completed:

IP Address - If A Network was selected, enter the IP address.



Wildcard Mask - If A Network was selected, specify a wildcard mask from the Wildcard


mask drop-down list or enter a custom wildcard mask.
Hostname/IP - If A Host Name or IP Address was selected, enter the name or the IP


address of the host. If a host name is entered, the router must be configured to use a DNS
server.
Step 9. (Optional) Enter a description in the Description field. The description must be less than
100 characters.
Step 10. (Optional) Check the Log matches against this entry. Depending on how the syslog set-
tings are configured on the router, the matches are recorded in the local logging buffer, sent to a
syslog server, or both.
Step 11. Click OK.
Step 12. Continue adding or editing rule entries until the standard rule is complete. If at anytime
the order of the rule entries in the Rule Entry list needs to be rearranged, use the Move Up and
Move Down buttons.
After the Rule Entry list is complete, the next step is to apply the rule to an interface. These are the
steps for applying a rule to an interface:
Step 1. From the Add a Rule window, click Associate. The Associate with an Interface window
appears.
Step 2. From the Select an Interface drop-down list, choose the interface to which this rule will be
applied. Only interfaces with a status of up/up will be listed in the drop-down list.
Step 3. From the Specify a Direction section, click either Inbound or Outbound. If the router is
to check packets inbound to the interface, click Inbound. If the router is to forward the packet to
the outbound interface before comparing it to the entries in the access rule, click Outbound.
Step 4. If a rule is already associated with the designated interface in the desired direction, an in-
formation box appears with the following options:

Cancel the operation.

Chapter 4: Implementing Firewall Technologies 95




Continue with the operation by appending the new rule entries to the access rule that is


already applied to the interface.
Disassociate the existing rule from the interface and associate the new rule instead.


To view the IOS commands generated by SDM and sent to the router, view the running-configura-
tion file by selecting View from the menu bar followed by Running Config.
To configure ACLs that can handle two-way traffic typical of TCP-based applications, there are
several IOS solutions.


4.1.5 Configuring TCP Established and Reflexive ACLs
Over time, engineers have created more sophisticated types of filters based on increasingly precise
parameters. Engineers have also expanded the range of platforms and the range of ACLs which
can be processed at wire speed. These improvements to platforms and ACLs allow network secu-
rity professionals to implement cutting-edge firewall solutions without sacrificing network per-
formance.
In a modern network, a network firewall must be placed between the inside of the network and the
outside of the network. The basic idea is that all traffic from the outside should be blocked from
entering the inside unless it is explicitly permitted by an ACL, or if it is returning traffic initiated
from the inside of the network. This is the fundamental role of a network firewall, whether it is a
dedicated hardware device or a Cisco router with IOS Firewall.
Many common applications rely on TCP, which builds a virtual circuit between two endpoints.
The first generation IOS traffic filtering solution to support the two-way nature of TCP virtual cir-
cuits was the TCP established keyword for extended IP ACLs. Introduced in 1995, the TCP
established keyword for extended IP ACLs enabled a primitive network firewall to be created on
a Cisco router. It blocked all traffic coming from the Internet except for the TCP reply traffic asso-
ciated with established TCP traffic initiated from the inside of the network.
The second generation IOS solution for session filtering was reflexive ACLs. Reflexive ACLs were
introduced to the IOS in 1996. These ACLs filter traffic based on source and destination addresses,
and port numbers, and keep track of sessions. Reflexive ACL session filtering uses temporary fil-
ters which are removed when a session is over.
The TCP established option and reflexive ACLs are examples of complex ACLs.
This is the syntax for the TCP established option in a numbered extended IP ACL.
Router(config)# access-list {100-199} {permit | deny} protocol source-addr
[source-wildcard] [operator operand] destination-addr [destination-wildcard]
[operator operand] [established]
The established keyword forces the router to check whether the TCP ACK or RST control flag is
set. If the ACK flag is set, the TCP traffic is allowed in. If not, it is assumed that the traffic is asso-
ciated with a new connection initiated from the outside.
Using the established keyword does not implement a stateful firewall on a router. No stateful in-
formation is maintained to keep track of traffic initiated from the inside of the network. All that the
established parameter does is allow any TCP segments with the appropriate control flag. The
router does not keep track of conversations to determine whether the traffic is return traffic associ-
ated with a connection initiated from inside the network.
Therefore, using the established keyword to allow return traffic into a network opens a hole in
the router. Hackers can take advantage of this hole by using a packet generator or scanner, such as
Nmap, to sneak TCP packets into a network by masquerading them as returning traffic. Hackers
96 CCNA Security Course Booklet, Version 1.0




accomplish this by using the packet generator to set the appropriate bit or bits in the TCP control
field.
The established option does not apply to UDP or ICMP traffic, because UDP and ICMP traffic
does not rely on any control flags as used with TCP traffic.
Despite the security hole, using the established keyword does provide a more secure solution
since a match occurs only if the TCP packet has the ACK or RST control bits set.
R1(config)# access-list 100 permit tcp any eq 443 192.168.1.0 0.0.0.255 estab-
lished
R1(config)# access-list 100 permit tcp any 192.168.1.3 0.0.0.0 eq 22
R1(config)# access-list 100 deny ip any any
R1(config)# interface s0/0/0
R1(config-if)# ip access-group 100 in
If the keyword established were left off, then any TCP traffic with source port 443 would be per-
mitted. With the keyword, only traffic from source port 443 with the ACK TCP control flag set is
permitted.
As is typical with a firewall configuration, all incoming traffic is denied unless explicitly permitted
(SSH, port 22, traffic in this case) or unless it is associated with traffic initiated from the inside of
the network (HTTPS traffic in this case). Any TCP source port 443 traffic initiated from outside
the network with the appropriate control flag set is allowed in.
Reflexive ACLs were introduced to Cisco IOS in 1996, about a year after the TCP established
option became available. Reflexive ACLs provide a truer form of session filtering than is possible
with TCP established. Reflexive ACLs are much harder to spoof because more filter criteria
must be matched before a packet is permitted through. For example, source and destination ad-
dresses and port numbers are checked, not just ACK and RST bits. Also, session filtering uses tem-
porary filters that are removed when a session is over. This adds a time limit on a hacker™s attack
opportunity.
The established keyword is available only for the TCP upper layer protocol. The other upper
layer protocols, such as UDP and ICMP, must either permit all incoming traffic or define all possi-
ble permissible source and destination, host and port address pairs for each protocol.
The biggest limitation of standard and extended ACLs is that they are designed to filter unidirec-
tional rather than bidirectional connections. Standard and extended ACLs do not keep track of the
state of a connection. If someone inside sends traffic to the Internet, it is difficult to safely allow
the returning traffic back into the network without opening a large hole on the perimeter router.
Reflexive ACLs were developed for this reason. Reflexive ACLs allow an administrator to perform
actual session filtering for any type of IP traffic.
Reflexive ACLs work by using temporary access control entries (ACEs) inserted into an extended
ACL, which is applied on the external interface of the perimeter router. When the session ends or
the temporary entry times out, it is removed from the ACL configuration of the external interface.
This reduces network exposure to DoS attacks.
To make this work, a named extended ACL examines the traffic as it exits the network. The ACL
can be applied inbound on an internal interface or outbound on the external interface. ACEs exam-
ine traffic associated with new sessions using the reflect parameter. Based on these statements
(using reflect), the connection ACEs are built dynamically to permit return traffic. Without the
reflect statements, return traffic is dropped by default. For example, an administrator could set
up the ACL statements to examine only HTTP connections, thus allowing only temporary reflexive
ACEs to be created for HTTP traffic.
Chapter 4: Implementing Firewall Technologies 97




As traffic is leaving the network, if it matches a permit statement with a reflect parameter, a tem-
porary entry is added to the reflexive ACL. For each permit-reflect statement, the router builds a
separate reflexive ACL.
A reflexive ACE is an inverted entry: the source and destination information is flipped. For exam-
ple, a reflexive ACE is created if a user on a workstation with IP address 192.168.1.3 telnets to
209.165.200.5, where the source port number is 11000.
R1(config-ext-nacl)# permit host 209.165.200.5 eq 23 host 192.168.1.3 eq 11000
Any temporary reflexive ACEs that are created contain the permit action to allow the returning
traffic for this session.
To configure a router to use reflexive ACLs involves just a few steps:
Step 1. Create an internal ACL that looks for new outbound sessions and creates temporary reflex-
ive ACEs.
Step 2. Create an external ACL that uses the reflexive ACLs to examine return traffic.
Step 3. Activate the Named ACLs on the appropriate interfaces.
This is the syntax for the internal ACL.
Router(config)# ip access-list extended internal_ACL_name
Router(config-ext-nacl)# permit protocol source-addr [source-mask] [operator
operand] destination-addr [destination-mask] [operator operand] [established]
reflect reflexive_ACL_name [timeout seconds]
For example, these are the commands for matching internal users surfing the Internet with a web
browser and relying on DNS.
R1(config)# ip access-list extended internal_ACL
R1(config-ext-nacl)# permit tcp any any eq 80 reflect web-only-reflexive-ACL
R1(config-ext-nacl)# permit udp any any eq 53 reflect dns-only-reflexive-ACL timeout 10
Cisco IOS creates two reflexive ACEs that maintain session information for outbound web connec-
tions (web-only-reflexive-ACL) and DNS queries (dns-only-reflexive-ACL). Notice that a 10-sec-
ond timeout for DNS queries is set.
After building the internal extended Named ACL, which creates the reflexive ACEs, the temporary
entries need to be referenced as traffic flows back into the network. This is done by building a sec-
ond extended Named ACL. In this Named ACL, use the evaluate statement to reference the re-
flexive ACEs that were created from the internal ACL.
Router(config)# ip access-list extended external_ACL_name
Router(config-ext-nacl)# evaluate reflexive_ACL_name
Continuing the example with HTTP and DNS traffic, this syntax creates an external ACL that de-
nies all traffic originating from the outside, but permits return HTTP and DNS traffic.
R1(config)# ip access-list extended external_ACL
R1(config-ext-nacl)# evaluate web-only-reflexive-ACL
R1(config-ext-nacl)# evaluate dns-only-reflexive-ACL
R1(config-ext-nacl)# deny ip any any
The last step is to apply the ACLs.
R1(config)# interface s0/0/0

<<

. 4
( 19)



>>