CSI

Cisco SAFE Implementation

Version 1.1

Student Guide

Copyright

2003, Cisco Systems, Inc. All rights reserved.

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Web site at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica Croatia Czech
Republic Denmark Dubai, UAE Finland France Germany Greece Hong Kong SAR Hungary
India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia Mexico The Netherlands
New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania Russia Saudi Arabia
Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine
United Kingdom United States Venezuela Vietnam Zimbabwe

Copyright 2003, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the
Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ
Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy,
ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We
Work, Live, Play, and Learn, Discover All Thats Possible, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press,
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the
Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast,
StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc.
and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)
Printed in the USA

Contact VSEC Training

VSEC Training values your opinion. Let us know what you think about this course, any
suggestions you have for this course, or any inaccuracies that you find in the course material.
Send an e-mail to [email protected]. We greatly appreciate your assistance.

Credits
Lead Course Developer

Steve Hanna

Contributing Course Developer

Jamey Brooks, Danny Rodriguez

Editors

Kayce M. Clark, Erin R. Stanley

Manager, Documentation

Ed Rivera

Additional Contributors

Jarrett Cravey, Jeanne Jackson, Randy Rivera,

Jagdeep Kang

About the Course Developers

Steven Hanna is an Education Specialist at Cisco Systems, Inc. where he designs and develops
training on the Cisco network security products. Steven has over seven years of experience in
the education field, having been an earth science teacher, a technical instructor, an instructor
mentor, and a course developer.
Having over ten years experience in the IT field in general, Steven has worked as a network
engineer or in an educational role for Productivity Point International, Apple Computer, MCI,
Schlumberger Oilfield Services, 3M, and Tivoli Systems among others. He graduated from the
University of Texas at Austin with degrees in Geology, Political Science, and Education. He
currently holds certifications from the State of Texas, Novell, Microsoft, Legato, Tivoli, and
Cisco.
Jamey Brooks is a consulting Education Specialist at Cisco Systems, Inc. where he designs
and develops training on the Cisco network security products. Jamey has over 10 years
experience in the technology field specializing in LAN, WAN, and Security technologies.
Previously, Jamey held the positions of Team Lead, Design and Implementation, and Manager
of Internet Operations at Citizens Communications, a national local exchange carrier. Prior to
that he was Manager of Global Networks for Concert, a global communications company.
Jamey also is a member of the Information Systems Security Association.
Danny Rodriguez is currently an Education Specialist with Cisco Systems Internet Learning
and Solutions Group. Danny is the author of the Cisco Secure Intrusion Detection System
(CSIDS) and the Cisco Secure Intrusion Detection System Host Sensor (CSIHS) courses.
Danny has also taught security courses, including IDS, to Cisco engineers and customers, and
holds certifications as a Cisco Certified Network Associate (CCNA), a Cisco Certified Design
Associate (CCDA), and a Cisco Qualified Specialist (CQS) Cisco Security Specialist 1 (CSS1).
Prior to becoming an Education Specialist, Danny was a member of the Cisco Security
Consulting Services organization. As a Network Security Engineer, Danny performed Security
Posture Assessments for Fortune 500 companies. The Security Posture Assessments were indepth, external and internal network assessments. He also was responsible for the

administration and security of the Security Consulting Services assessment network, which
was used to perform external security assessments of the Cisco customer networks.

Table of Contents

COURSE INTRODUCTION

1-1

Overview
Course Objectives
Lab Topology Overview

1-1
1-2
1-7

SECURITY FUNDAMENTALS

2-1

Overview
Objectives
Need for Network Security
Network Security Policy
The Security Wheel
Network Attack Taxonomy
Management Protocols and Functions
Summary
Lab ExerciseVulnerabilities and Threats

2-1
2-2
2-3
2-10
2-13
2-18
2-58
2-65
Lab 2-1

ARCHITECTURAL OVERVIEW

3-1

Overview
Objectives
SAFE Architectural Overview
Design Fundamentals
Safe Axioms
Summary

3-1
3-2
3-3
3-7
3-13
3-32

THE CISCO SECURITY PORTFOLIO

4-1

Overview
Objectives
Cisco Security Portfolio Overview
Secure ConnectivityVirtual Private Network Solutions
Secure ConnectivityThe 3000 Concentrator Series
Secure ConnectivityCisco VPN-Optimized Routers
Perimeter Security FirewallsCisco PIX Firewall and Cisco IOS Firewall
Intrusion ProtectionIDS
IdentityAccess Control Solutions
Security ManagementVMS and CSPM
Cisco AVVID
Summary

Copyright

2003, Cisco Systems, Inc.

Table of Contents

4-1
4-2
4-3
4-7
4-11
4-17
4-23
4-30
4-36
4-41
4-44
4-48

SAFE SMALL NETWORK DESIGN

5-1

Overview
Objectives
Small Network Design Overview
Small Network Corporate Internet Module
Small Network Campus Module
ImplementationISP Router
ImplementationIOS Firewall Features and Configuration
ImplementationPIX Firewall
Summary
Lab ExerciseSAFE Small Network Design Implementation

SAFE SMR MIDSIZE NETWORK DESIGN

6-1

Overview
Objectives
Midsize Network Corporate Internet Module
Midsize Network Corporate Internet Module Design Guidelines
Midsize Network Campus Module
Midsize Network Campus Module Design Guidelines
Midsize Network WAN Module
ImplementationISP Router and Edge Router
ImplementationIOS Firewall
ImplementationPIX Firewall
ImplementationNIDS
ImplementationVPN Concentrator
ImplementationLayer 3 Switch
Summary
Lab ExerciseMedium Network Design Implementation

REMOTE USER NETWORK IMPLEMENTATION

Cisco SAFE Implementation 1.1

6-1
6-3
6-4
6-11
6-21
6-26
6-30
6-32
6-37
6-42
6-44
6-83
6-91
6-99
Lab 6-1

7-1

Overview
Objectives
Design Overview
Key Devices and Threat Mitigation
Software Access Option
Remote Site Firewall Option
VPN Hardware Client Option
Remote Site Router Option
Summary
Lab ExerciseRemote User Network Design Implementation
Lab ExerciseCase Study

vi

5-1
5-2
5-3
5-4
5-11
5-14
5-18
5-48
5-73
Lab 5-1

Copyright

7-1
7-2
7-3
7-6
7-10
7-21
7-36
7-43
7-61
Lab 7-1
Lab 8-1

2003, Cisco Systems, Inc.

Course Introduction
Overview
This chapter includes the following topics:
Course objectives
Course agenda
Participant responsibilities
General administration
Graphic symbols
Participant introductions
Cisco security career certifications
Lab topology overview

Course Objectives
This section introduces the course and the course objectives.

Course Objectives
Upon completion of this course, you will be able to
perform the following tasks:
Describe in detail the four basic types of threats that may
be encountered in todays network environment.
Explain how to provide a framework for implementing
security features in the network infrastructure.
Demonstrate first-hand knowledge of the tools and
techniques used to exploit security vulnerabilities.
Discuss the SAFE design philosophy and how it impacts
the decision-making process.
Recognize why routers, switches, hosts, networks, and
applications are targets.
List the general process for hardening network-attached
devices.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-3

Course Objectives (cont.)

Describe the security tools and devices Cisco offers.
Identify the functions of the modules and key devices
described in the SAFE Extending the Security Blueprint to
Small, Midsize, and Remote-User Networks whitepaper.
Identify the specific threats described in the SAFE Extending
the Security Blueprint to Small, Midsize, and Remote-User
Networks whitepaper.
Describe the mitigation roles of Cisco devices described in the
SAFE Extending the Security Blueprint to Small, Midsize, and
Remote-User Networks whitepaper.
Implement specific configurations to apply the mitigation roles
described in the SAFE Extending the Security Blueprint to
Small, Midsize, and Remote-User Networks whitepaper.
Recommend alternative devices that can fulfill the same
mitigation roles described in the SAFE Extending the Security
Blueprint to Small, Midsize, and Remote-User Networks
whitepaper.
2003, Cisco Systems, Inc. All rights reserved.

1-2

Cisco SAFE Implementation 1.1

CSI 1.11-4

Copyright

2003, Cisco Systems, Inc.

Course Agenda
Day 1

Chapter 1Course Introduction

Chapter 2Security Fundamentals
Lunch
LabVulnerabilities and Threats
Chapter 3Architectural Overview
Chapter 4The Cisco Security Portfolio

Day 2

Chapter 5SAFE Small Network Design

Lunch
Chapter 5SAFE Small Network Design (cont.)
LabSAFE Small Network Design Implementation

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-5

Course Agenda (cont.)

Day 3
Chapter 6SAFE SMR Midsize Network Design
LabMedium Network Design Implementation
Lunch
Chapter 7Remote User Network Implementation
LabRemote User Network Design Implementation

Day 4
Lab 8Case Study

2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.11-6

Course Introduction

1-3

Participant Responsibilities

Student responsibilities
Complete prerequisites
Participate in lab exercises
Ask questions
Provide feedback

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-7

General Administration

Class-related
Sign-in sheet

Participant materials

Length and times

Site emergency
procedures

Break and lunch room

locations
Attire

2003, Cisco Systems, Inc. All rights reserved.

1-4

Facilities-related

Cisco SAFE Implementation 1.1

Restrooms
Telephones/faxes

CSI 1.11-8

Copyright

2003, Cisco Systems, Inc.

Graphic Symbols

IOS Router

PIX Firewall

Network
Access Server

Policy Manager

Hub

Modem

VPN 3000

CA
Server

Ethernet Link

IDS Sensor

Catalyst 6500
with IDS Module

PC

Laptop

Network
Cloud

2003, Cisco Systems, Inc. All rights reserved.

VPN Tunnel

IOS Firewall

Server
Web, FTP, etc.

Switch
CSI 1.11-9

Participant Introductions

Your name
Your company
Pre-requisites skills
Brief history
Objective

2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.11-10

Course Introduction

1-5

Cisco Security Career Certifications

Expand Your Professional Options
and Advance Your Career

Cisco Certified Security Professional (CCSP) Certification

Professional-level recognition in designing
and implementing Cisco security solutions
Expert
CCIE

Professional
CCSP

Associate
CCNA
Network Security

Required
Exam

Recommended Training through

Cisco Learning Partners

9E0-111 or
642-521

Cisco Secure PIX Firewall Advanced 3.1

9E0-121 or
642-511

Cisco Secure Virtual Private Networks 3.1

640-100 or
642-501

Securing Cisco IOS Networks 1.0

9E0-100 or
642-531

Cisco Secure Intrusion Detection System 3.0

Cisco Secure Intrusion Detection System 4.0

9E0-131 or
642-541

Cisco SAFE Implementation 1.1

www.cisco.com/go/ccsp

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-11

Cisco Security Career Certifications

Enhance Your Cisco Certifications
and Validate Your Areas of Expertise
Cisco Firewall, VPN, and IDS Specialists

Cisco Firewall Specialist

Required
Exam

Recommended Training through

Cisco Learning Partners

640-100 or
642-501

Securing Cisco IOS Networks 1.0

9E0-111 or
642-521

Cisco Secure PIX Firewall Advanced 3.1

Pre-requisite: Valid CCNA certification

Cisco VPN Specialist

Cisco IDS Specialist

2003, Cisco Systems, Inc. All rights reserved.

1-6

Cisco SAFE Implementation 1.1

Required
Exam

Recommended Training through

Cisco Learning Partners

640-100 or
642-501

Securing Cisco IOS Networks 1.0

9E0-121 or
642-511

Cisco Secure Virtual Private Networks 3.1

Pre-requisite: Valid CCNA certification

Required
Exam

Recommended Training through

Cisco Learning Partners

640-100 or
642-501

Securing Cisco IOS Networks 1.0

9E0-100 or
642-531

Cisco Secure Intrusion Detection System 3.0

Cisco Secure Intrusion Detection System 4.0

Pre-requisite: Valid CCNA certification

www.cisco.com/go/training

CSI 1.11-12

Copyright

2003, Cisco Systems, Inc.

Lab Topology Overview

This section details the lab topology that is used in this course.

Lab Visual Objective

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24
.150

.10P e0/1

Branch

brP
.1 e0/0

10.2.P.0/24

RBB
.1

10.2.P.11

Branch

.2

.150

172.16.P.0/24

Super
Server
WWW
FTP

PSS
WWW
FTP
.10

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP
.2 e0

priv

.1 e4

.1 e2

.5

.1 e1

.50
.4

DMZ
.5

pP

10.0.P.0 /24

pub
172.18.P.0/24

cP
.100

RTS

sensorP

Student

10.0.P.11

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-14

Each pair of students will be assigned a pod.

Note

Copyright

The P in a command indicates your pod number.

2003, Cisco Systems, Inc.

Course Introduction

1-7

Lab Visual ObjectiveCase Study

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24

.10P e0/1

.150

brP

Branch
10.3.P.0/24

RBB

.1 e0/0

pub 10.3.P.5

cP

priv 10.2.P.1

.1

Branch

192.168.P.0/24

10.2.P.11

10.2.P.0/24

172.16.P.0/24

Super
Server
WWW
FTP

PSS
WWW
FTP

.2 e0
.1 e2
.50

.1 e1

.10

pP .1 e4 172.18.P.0/24 .5 e0/1
.1 e5

DMZ
drP

172.19.P.0/24 .5 e0/0
10.0.P.0 /24

.100

RTS

Student

10.0.P.11

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.11-15

Each pair of students will be assigned a pod.

Note

1-8

The P in a command indicates your pod number.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals
Overview
This chapter describes security fundamentals. It includes the following topics:
Objectives
Need for network security
Network security policy
The security wheel
Network attack taxonomy
Management protocols and functions
Summary

Objectives
This section lists the chapters objectives.

Objectives
Upon completion of this chapter, you will be able
to perform the following tasks:

Describe the need for network security.

Identify the components of a complete security policy.
Explain how security is an ongoing process.
Describe the four types of security threats.
Describe common attack methods and techniques used
by hackers.
List the general recommendations for mitigating common
attack methods and techniques.
Identify the security issues implicit in common
management protocols.

2003, Cisco Systems, Inc. All rights reserved.

2-2

Cisco SAFE Implementation 1.1

CSI 1.12-2

Copyright

2003, Cisco Systems, Inc.

Need for Network Security

Over the past few years, Internet-enabled business, or e-business, has drastically improved
companies efficiency and revenue growth. E-business applications such as e-commerce, supplychain management, and remote access enable companies to streamline processes, lower
operating costs, and increase customer satisfaction. Such applications require mission-critical
networks that accommodate voice, video, and data traffic, and these networks must be scalable
to support increasing numbers of users and the need for greater capacity and performance.
However, as networks enable more and more applications and are available to more and more
users, they become ever more vulnerable to a wider range of security threats. To combat those
threats and ensure that e-business transactions are not compromised, security technology must
play a major role in todays networks.

The Closed Network

Closed network
PSTN

Remote site

Frame relay
X.25 leased
line

PSTN

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-4

The closed network typically consists of a network designed and implemented in a corporate
environment, and provides connectivity only to known parties and sites without connecting to
public networks. Networks were designed this way in the past and thought to be reasonably
secure because of no outside connectivity.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-3

The Network Today

Open network
Mobile
and
remote
users

Internet

Internet-based
intranet (VPN)

PSTN

2003, Cisco Systems, Inc. All rights reserved.

Remote
site

Internet-based
extranet (VPN)

Partner
site

CSI 1.12-5

Networks of today are designed with availability to the Internet and public networks, which is a
major requirement. Most of todays networks have several access points to other networks both
public and private; therefore, securing these networks has become fundamentally important.

2-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Threat CapabilitiesMore
Dangerous and Easier to Use
Packet forging/
spoofing

High

Stealth diagnostics
Back
doors

Sweepers
Sniffers

Exploiting known
vulnerabilities

Self replicating
code

Hijacking
sessions
Disabling
audits

Technical
knowledge
required

Password
cracking

Password
guessing

Low

1980

2003, Cisco Systems, Inc. All rights reserved.

Sophistication
of hacker tools

1990

2000
CSI 1.12-6

With the development of large open networks there has been a huge increase in security threats
in the past twenty years. Not only have hackers discovered more vulnerabilities, but the tools
used and technical knowledge required to hack a network have become simpler. There are
downloadable applications available that require little or no hacking knowledge to implement.
There are also inherent applications for troubleshooting a network that when used improperly
can pose severe threats.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-5

The Role of Security is Changing

The need for security is
becoming more important
because of the following
reasons:

Required for e-business

Required for communicating
and doing business safely in
potentially unsafe environments
Result has been that networks
require development and
implementation of a corporatewide security policy

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-7

Security has moved to the forefront of network management and implementation. It is necessary
for the survival of many businesses to allow open access to network resources, and ensure that
the data and resources are as secure as possible.
The need for security is becoming more important because of the following:
Required for e-businessThe importance of e-business and the need for private data to
traverse public networks has increased the need for network security.
Required for communicating and doing business safely in potentially unsafe environments
Todays business environment requires communication with many public networks and
systems which increases the need for as much security as is possible when this type of
communication is required.
Networks require development and implementation of a corporate-wide security policy
Establishing a security policy should be the first step in migrating a network to a secure
infrastructure.

2-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The E-Business Challenge

Internet
business
value

E-commerce

Supply chain

Workforce
optimization

Internet
access

Corporate
intranet

Customer care

E-learning

Internet
presence

Business security
requirements

Defense-in-depth
Multiple components
Integration into e-business
infrastructure
Comprehensive blueprint

Expanded access
heightened security risks
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-8

Security must be a fundamental component of any e-business strategy. As enterprise network

managers open their networks to more users and applications, they also expose these networks to
greater risk. The result has been an increase in the business security requirements.
The Internet has radically shifted expectations of companies abilities to build stronger
relationships with customers, suppliers, partners, and employees. Driving companies to become
more agile and competitive, e-business is giving birth to exciting new applications for ecommerce, supply-chain management, customer care, workforce optimization, and e-learning
applications that streamline and improve processes, speed up turnaround times, lower costs, and
increase user satisfaction.
E-business requires mission-critical networks that accommodate ever-increasing constituencies
and demands for greater capacity and performance. These networks also need to handle voice,
video, and data traffic as networks converge into multiservice environments.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-7

Legal and Governmental

Policy Issues

Organizations that operate

vulnerable networks will face
increasing and substantial
liability.
US Federal legislation
mandating security includes the
following:
GLB financial
services legislation
Government Information
Security Reform Act
HIPAA

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-9

The legal ramifications of breaches in data confidentiality and integrity can also be extremely
costly for organizations. The US Government has enacted and is currently developing
regulations to control the privacy of electronic information. The existing and pending regulations
generally stipulate that organizations in violation could face a range of penalties. The following
are some examples:
Gramm-Leach Bliley (GLB) ActIncludes several privacy regulations for US financial
institutions. These institutions could face a range of penalties from termination of their FDIC
insurance to up to US $1 million in monetary penalties.
Government Information Security Reform Act of 2000Agencies must undergo annual selfassessments and independent assessments of their security practices and policies, which are
required for submission.
The Health Insurance Portability and Accountability Act (HIPPA) of 1996 (Public Law 104191)Part of a broad Congressional attempt at incremental healthcare reform. The
administrative simplification aspect of that law requires the United States Department of
Health and Human Services (DHHS) to develop standards and requirements for maintenance
and transmission of health information that identifies individual patients. These standards are
designed to do the following:

2-8

Improve the efficiency and effectiveness of the healthcare system by standardizing the
interchange of electronic data for specified administrative and financial transactions
Protect the security and confidentiality of electronic health information

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Even if an external hacker is the perpetrator of an attack, the company storing that information
can potentially be found negligent by the courts if the information was not adequately
safeguarded. Furthermore, companies that suffer breaches in data integrity might be required to
defend against lawsuits initiated by customers who are negatively affected by the incorrect or
offensive data and seek monetary or punitive damages.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-9

Network Security Policy

A security policy can be as simple as an acceptable use policy for network resources or it can be
several hundred pages in length and detail every element of connectivity and associated policies.

What Is a Security Policy?

A security policy is a formal statement of

the rules by which people who are given
access to an organizations technology and
information assets must abide.
(RFC 2196, Site Security Handbook)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-11

According to the Site Security Handbook (RFC 2196), A security policy is a formal statement
of the rules by which people who are given access to an organizations technology and
information assets must abide. It further states, A security policy is essentially a document
summarizing how the corporation will use and protect its computing and network resources.

2-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Why Create a Security Policy?

To create a baseline of your current security posture

To set the framework for security implementation
To define allowed and not allowed behaviors
To help determine necessary tools and procedures
To communicate consensus and define roles
To define how to handle security incidents

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-12

Security policies provide many benefits and are worth the time and effort needed to develop
them. Developing a security policy:
Provides a process to audit existing network security.
Provides a general security framework for implementing network security.
Defines which behavior is and is not allowed.
Helps determine which tools and procedures are needed for the organization.
Helps communicate consensus among a group of key decision makers and define
responsibilities of users and administrators.
Defines a process for handling network security incidents.
Enables global security implementation and enforcement. Computer security is now an
enterprise-wide issue and computing sites are expected to conform to the network security
policy.
Creates a basis for legal action if necessary.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-11

What Should the

Security Policy Contain?
Statement of authority and scope
Acceptable use policy
Identification and authentication policy
Internet use policy
Campus access policy
Remote access policy
Incident handling procedure

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-13

The following are some of the key policy components:

Statement of authority and scopeThis section specifies who sponsors the security policy
and what areas the policy covers.
Acceptable use policyThis section specifies what the company will and will not allow
regarding its information infrastructure.
Identification and authentication policyThis section specifies what technologies,
equipment, or combination of the two the company will use to ensure that only authorized
individuals have access to its data.
Internet access policyThis section specifies what the company considers ethical and
proper use of its Internet access capabilities.
Campus access policyThis section specifies how on-campus users will use the companys
data infrastructure.
Remote access policyThis section specifies how remote users will access the companys
data infrastructure.
Incident handling procedureThis section specifies how the company will create an
incident response team and the procedures it will use during and after and incident occurs.

2-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The Security Wheel

Cisco is serious about network security, and about its implications for the critical infrastructures
on which this and other developed nations depend. This section summarizes the view that
network security is a continuous process.

Network Security
Is a Continuous Process
Network security is a
continuous process
built around a security
policy:
Step 1: Secure

Secure

Improve

Security
Policy

Monitor

Step 2: Monitor
Step 3: Test
Step 4: Improve

2003, Cisco Systems, Inc. All rights reserved.

Test

CSI 1.12-15

After setting appropriate policies, a company or organization must methodically consider

security as part of normal network operations. This could be as simple as configuring routers to
not accept unauthorized addresses or services, or as complex as installing firewalls, intrusion
detection systems, centralized authentication servers, and encrypted virtual private networks.
After developing a security policy, secure your network using a variety of point products
(firewalls, intrusion detection, and so on.). Before you can secure your network, however, you
need to combine your understanding of your users, the assets needing protection, and the
networks topology.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-13

Secure the Network

Implement security
solutions to stop or
prevent unauthorized
access or activities,
and to protect
information:
Authentication
Encryption

Secure

Improve

Security
Policy

Monitor

Test

Firewalls
Vulnerability patching
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-16

The following are solutions identified to secure a network:

AuthenticationThe recognition of each individual user, and the mapping of their identity,
location, and the time to policy; and the authorization of their network services and what
they can do on the network.
EncryptionA method for ensuring the confidentiality, integrity, and authenticity of data
communications across a network. The Cisco solution combines several standards, including
the Data Encryption Standard (DES).
FirewallsA firewall is a set of related programs, located at a network gateway server, that
protects the resources of a private network from users from other networks.
Vulnerability patchingThe identification and patching of possible security holes that
could compromise a network.

2-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Monitor Security
Detects violations to
the security policy
Involves system
auditing and
real-time intrusion
detection
Validates the security
implementation in
Step 1

2003, Cisco Systems, Inc. All rights reserved.

Secure

Improve

Security
Policy

Monitor

Test

CSI 1.12-17

To ensure that a network remains secure, it is important to monitor the state of security
preparation. Network vulnerability scanners can proactively identify areas of weakness, and
IDSs can monitor and respond to security events as they occur. Using security monitoring
solutions, organizations can obtain unprecedented visibility into both the network data stream
and the security posture of the network.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-15

Test Security

Validates
effectiveness of
the security policy
through system
auditing and
vulnerability
scanning

2003, Cisco Systems, Inc. All rights reserved.

Secure

Improve

Security
Policy

Monitor

Test

CSI 1.12-18

Testing security is as important as monitoring. Without testing the security solutions in place, it
is impossible to know about existing or new attacks. The hacker community is an ever-changing
environment. You can perform this testing yourself or outsource it to a third party such as the
Cisco Security Posture Assessment (SPA) group.
The Cisco SPA is a premium network vulnerability assessment providing comprehensive insight
into the security posture of a customers network. Delivered by highly expert Cisco Network
Security Engineers (NSEs), the Cisco SPA includes an operational, granular analysis of largescale, distributed service provider networks from the perspective of an outside hacker.

2-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Improve Security
Use information from
the monitor and test
phases to make
improvements to the
security
Improve
implementation.
Adjust the security
policy as security
vulnerabilities and risks
are identified.

2003, Cisco Systems, Inc. All rights reserved.

Secure

Security
Policy

Monitor

Test

CSI 1.12-19

Monitoring and testing provides the data necessary to improve network security. Administrators
and engineers should use the information from the monitor and test phases to make
improvements to the security implementation as well as adjust the security policy as
vulnerabilities and risks are identified.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-17

Network Attack Taxonomy

This section provides an overview of various network attacks and affects.

Variety of Attacks

Internet
Ex
ex tern
p lo al
i ta
ti o
n

Network attacks can

be as varied as the
systems that they
attempt to penetrate.

2003, Cisco Systems, Inc. All rights reserved.

Dial-in
exploitation

Internal
exploitation

Compromised
host

CSI 1.12-21

Without proper protection, any part of any network can be susceptible to attacks or unauthorized
activity. Routers, switches, and hosts can all be violated by professional hackers, company
competitors, or even internal employees. In fact, according to several studies, more than half of
all network attacks are waged internally. The Computer Security Institute (CSI) in San Francisco
estimates that between 60 and 80 percent of network misuse comes from inside the enterprises
where the misuse has taken place. To determine the best ways to protect against attacks, IT
managers should understand the many types of attacks that can be instigated and the damage that
these attacks can cause to e-business infrastructures.

2-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Network Security Threats

There are four general categories of
security threats to the network:
Unstructured threats
Structured threats
External threats
Internal threats

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-22

There are four general threats to network security:

Unstructured threatsThese threats primarily consist of random hackers using various
common tools, such as malicious shell scripts, password crackers, credit card number
generators, and dialer daemons. Although hackers in this category may have malicious
intent, many are more interested in the intellectual challenge of cracking safeguards than
creating havoc.
Structured threatsThese threats are created by hackers who are more highly motivated and
technically competent. Typically, such hackers act alone or in small groups to understand,
develop, and use sophisticated hacking techniques to penetrate unsuspecting businesses.
These groups are often involved with the major fraud and theft cases reported to law
enforcement agencies. Occasionally, organized crime, industry competitors, or statesponsored intelligence collection organizations hire such hackers.
External threatsThese threats consist of structured and unstructured threats originating
from an external source. These threats can have malicious and destructive intent, or simply
be errors that generate a threat.
Internal threatsThese threats are typically from disgruntled former or current employees.
Although internal threats may seem more ominous than threats from external sources,
security measures are available for reducing vulnerabilities to internal threats and responding
when attacks occur.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-19

Specific Attack Types

All of the following can be used
to compromise your system:

Packet sniffers
IP weaknesses
Password attacks
DoS or DDoS
Man-in-the-middle attacks
Application layer attacks
Trust exploitation
Port redirection
Virus
Trojan horse
Operator error

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-23

There are many common attacks that can occur against a network. Any of the following can be
used to compromise your system:
Packet sniffers
IP weaknesses
Password attacks
Denial of service (DoS) or distributed denial of service (DDoS)
Man-in-the-middle attacks
Application layer attacks
Trust exploitation
Port redirection
Virus
Trojan horse
Operator error

2-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Specific Attack Types (cont.)

CAM table flooding
VLAN hopping
ARP/MAC poisoning
ARP spoofing
Private VLAN attacks
Multicast brute-force failover
DHCP Starvation

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-24

CAM table flooding

VLAN hopping
ARP/MAC poisoning
ARP spoofing
Private VLAN attacks
Multicast brute-force failover
DHCP Starvation

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-21

Packet Sniffers
Host A

Router A

Router B

Host B

A packet sniffer is a software application that uses a network

adapter card in promiscuous mode to capture all network packets.
The following are the packet sniffer features:
Packet sniffers exploit information passed in clear text. Protocols that
pass information in the clear include the following:
Telnet
FTP
SNMP
POP
HTTP
Packet sniffers must be on the same collision domain.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-25

A packet sniffer is a software application that uses a network adapter card in promiscuous mode
(a mode in which the network adapter card sends all packets received on the physical network
wire to an application for processing) to capture all network packets that are sent across a LAN.
Several network applications distribute network packets in clear text; that is, the information sent
across the network is not encrypted. Because the network packets are not encrypted, they can be
processed and understood by any application that can pick them up off the network and process
them.
A network protocol specifies how packets are identified and labeled, which enables a computer
to determine whether a packet is intended for it. Because the specifications for network
protocols, such as TCP/IP, are widely published, a third party can easily interpret the network
packets and develop a packet sniffer. (The real threat today results from the numerous freeware
and shareware packet sniffers that are available, which do not require the user to understand
anything about the underlying protocols.)

2-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Packet Sniffer Example

There are two primary types of packet

sniffers:
General purpose sniffers
Sniffers designed for attack purpose

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-26

A packet sniffer can provide its user with meaningful and often sensitive information, such as
user account names and passwords. If you use networked databases, a packet sniffer can provide
an attacker with information that is queried from the database, as well as the user account names
and passwords used to access the database. One serious problem with acquiring user account
names and passwords is that users often reuse their login names and passwords across multiple
applications.
In addition, many network administrators use packet sniffers to diagnose and fix network-related
problems. Because in the course of their usual and necessary duties these network administrators
(such as those in a payroll department) work during regular employee hours, they can potentially
examine sensitive information distributed across the network.
Many users employ a single password for access to all accounts and applications. Because
attackers know and use human characteristics (attack methods known collectively as social
engineering attacks), such as using a single password for multiple accounts, they are often
successful in gaining access to sensitive information.
There are two primary types of packet sniffers:
General purpose

Captures all packets

Included with some operating systems

Freeware and shareware versions available

Designed for attack purpose

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-23

2-24

Captures first 300 to 400 bytes

Typically captures login sessions (File Transfer Protocol [FTP], rlogin, and Telnet)

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Packet Sniffer Mitigation

Host A

Router A

Router B

Host B

The following techniques and tools can be used to mitigate sniffers:

AuthenticationA first option for defense against packet sniffers is to
use strong authentication, such as one-time passwords.
Switched infrastructureDeploy a switched infrastructure to counter
the use of packet sniffers in your environment.
Antisniffer toolsUse these tools to employ software and hardware
designed to detect the use of sniffers on a network.
CryptographyThe most effective method for countering packet
sniffers does not prevent or detect packet sniffers, but rather renders
them irrelevant.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-27

The following techniques and tools can be used to mitigate packet sniffers:
AuthenticationUsing strong authentication is a first-option for defense against packet
sniffers. Strong authentication can be broadly defined as a method of authenticating users
that cannot easily be circumvented. A common example of strong authentication is one-time
passwords (OTPs).
An OTP is a type of two-factor authentication. Two-factor authentication involves using
something you have combined with something you know. Automated teller machines
(ATMs) use two-factor authentication. A customer needs both an ATM card and a personal
identification number (PIN) to make transactions. With OTPs you need a PIN and your
token card to authenticate to a device or software application. A token card is a hardware or
software device that generates new, seemingly random, passwords at specified intervals
(usually 60 seconds). A user combines that random password with a PIN to create a unique
password that works only for one instance of authentication. If a hacker learns that password
by using a packet sniffer, the information is useless because the password has already
expired. Note that this mitigation technique is effective only against a sniffer implementation
that is designed to grab passwords. Sniffers deployed to learn sensitive information (such as
mail messages) would still be effective.
Switched infrastructureThis can be used to counter the use of packet sniffers in your
network environment. For example, if an entire organization deploys switched Ethernet,
hackers can gain access only to the traffic that flows on the specific port to which they
connect. A switched infrastructure obviously does not eliminate the threat of packet sniffers,
but it can greatly reduce their effectiveness.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-25

Antisniffer toolsEmploying software and hardware designed to detect the use of sniffers
on a network. Such software and hardware does not completely eliminate the threat, but like
many network security tools, they are part of the overall system. These so-called
antisniffers detect changes in the response time of hosts to determine if the hosts are
processing more traffic than their own. One such network security software tool, which is
available from Security Software Technologies, is called AntiSniff.
CryptographyRendering packet sniffers irrelevant, which is the most effective method for
countering packet snifferseven more effective than preventing or detecting packet sniffers.
If a communication channel is cryptographically secure, the only data a packet sniffer will
detect is cipher text (a seemingly random string of bits) and not the original message. The
Cisco deployment of network-level cryptography is based on IPSec, which is a standard
method for networking devices to communicate privately using IP. Other cryptographic
protocols for network management include Secure Shell Protocol (SSH) and Secure Sockets
Layer (SSL).

2-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IP Spoofing
IP spoofing occurs when a hacker inside or outside a network
impersonates the conversations of a trusted computer.
Two general techniques are used during IP spoofing:
A hacker uses an IP address that is within the range of
trusted IP addresses.
A hacker uses an authorized external IP address that is
trusted.
Uses for IP spoofing include the following:
IP spoofing is usually limited to the injection of malicious
data or commands into an existing stream of data.
If a hacker changes the routing tables to point to the spoofed
IP address, then the hacker can receive all the network
packets that are addressed to the spoofed address and reply
just as any trusted user can.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-28

An IP spoofing attack occurs when an attacker outside your network pretends to be a trusted
computer, either by using an IP address that is within the range of IP addresses for your network
or by using an authorized external IP address that you trust and to which you wish to provide
access to specified resources on your network.
Normally, an IP spoofing attack is limited to the injection of data or commands into an existing
stream of data passed between a client and server application or a peer-to-peer network
connection. To enable bi-directional communication, the attacker must change all routing tables
to point to the spoofed IP address. Another approach the attacker could take is to simply not
worry about receiving any response from the applications. For example, if an attacker is
attempting to get a system to mail him or her a sensitive file, application responses are
unimportant.
However, if an attacker manages to change the routing tables to point to the spoofed IP address,
he can receive all the network packets that are addressed to the spoofed address and reply just as
any trusted user can. Like packet sniffers, IP spoofing is not restricted to people who are external
to the network.
Although not as common, IP spoofing can also gain access to user accounts and passwords, and
it can also be used in other ways. For example, an attacker can emulate one of your internal users
in ways that prove embarrassing for your organization; the attacker could send e-mail messages
to business partners that appear to have originated from someone within your organization. Such
attacks are easier when an attacker has a user account and password, but they are possible by
combining simple spoofing attacks with knowledge of messaging protocols.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-27

IP Spoofing Mitigation
The threat of IP spoofing can be reduced, but not
eliminated, through the following measures:

Access controlThe most common method for preventing IP

spoofing is to properly configure access control.
RFC 2827 filteringPrevent any outbound traffic on your
network that does not have a source address in your
organizations own IP range.
Additional authentication that does not use IP-based
authenticationExamples of this include the following:
Cryptographic (recommended)
Strong, two-factor, one-time passwords

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-29

The threat of IP spoofing can be reduced, but not eliminated, through the following measures:
Access controlThe most common method for preventing IP spoofing is to properly
configure access control. To reduce the effectiveness of IP spoofing, configure access
control to deny any traffic from the external network that has a source address that should
reside on the internal network. Note that this helps prevent spoofing attacks only if the
internal addresses are the only trusted addresses. If some external addresses are trusted, this
method is not effective.
RFC 2827 filteringYou can prevent users of your network from spoofing other networks
(and be a good Internet citizen at the same time) by preventing any outbound traffic on your
network that does not have a source address in your organization's own IP range.
This filtering denies any traffic that does not have the source address that was expected on a
particular interface. For example, if an ISP is providing a connection to the IP address
15.1.1.0/24, the ISP could filter traffic so that only traffic sourced from address 15.1.1.0/24
can enter the ISP router from that interface. Note that unless all ISPs implement this type of
filtering, its effectiveness is significantly reduced.
Additional AuthenticationThe most effective method for mitigating the threat of IP
spoofing is the same as the most effective method for mitigating the threat of packet sniffers:
namely, eliminating its effectiveness. IP spoofing can function correctly only when devices
use IP address-based authentication; therefore, if you use additional authentication methods,
IP spoofing attacks are irrelevant. Cryptographic authentication is the best form of additional
authentication, but when that is not possible, strong two-factor authentication using OTP can
also be effective.

2-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

DoS
DoS attacks focus on making a service
unavailable for normal use. They have the
following characteristics:

Different from most other attacks because they are

generally not targeted at gaining access to your network
or the information on your network
Require very little effort to execute
Among the most difficult to completely eliminate

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-30

DoS attacks are different from most other attacks because they are not targeted at gaining access
to your network or the information on your network. These attacks focus on making a service
unavailable for normal use, which is typically accomplished by exhausting some resource
limitation on the network or within an operating system or application. These attacks require
little effort to execute because they typically take advantage of protocol weaknesses or the
attacks are carried out using traffic that would normally be allowed into a network. DoS attacks
are among the most difficult to completely eliminate because of the way they use protocol
weaknesses and native traffic to attack a network.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-29

DDoS Example
1. Scan for systems to hack.
4. The client
issues
commands
to handlers
that control
agents in a
mass attack.

Client
system
2. Install software
to scan,
compromise, and
infect agents.

Handler
systems

3. Agents are loaded with remote control attack software.

Agent
systems
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-31

DDoS attacks are the next generation of DoS attacks on the Internet. This type of attack is not
newUDP and TCP SYN flooding, Internet Control Message Protocol (ICMP) echo request
floods, and ICMP directed broadcasts (also known as smurf attacks) are similarbut the scope
certainly is new. Victims of DDoS attacks experience packet flooding from many different
sources, possibly spoofed IP source addresses, that bring their network connectivity to a grinding
halt. In the past, the typical DoS attack involved a single attackers attempt to flood a target host
with packets. With DDoS tools, an attacker can conduct the same attack using thousands of
systems.
In the figure the hacker uses their terminal to scan for systems to hack. When the handler
systems are accessed, the hacker then installs software on them to scan for, compromise, and
infect Agent systems. When the Agent systems are accessed the hacker then loads remote control
attack software to carry out the DoS attack.

2-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

DoS Mitigation
The threat of DoS attacks can be reduced
through the following three methods:

Antispoof featuresProper configuration of

antispoof features on your routers and firewalls
Anti-DoS featuresProper configuration of
anti-DoS features on routers and firewalls
Traffic rate limitingImplement traffic rate
limiting with the networks ISP

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-32

When involving specific network server applications, such as a HTTP server or a File Transfer
Protocol (FTP) server, these attacks can focus on acquiring and keeping open all the available
connections supported by that server, effectively locking out valid users of the server or service.
DoS attacks can also be implemented using common Internet protocols, such as TCP and ICMP.
While most DoS attacks exploit a weakness in the overall architecture of the system being
attacked rather than a software bug or security hole, some attacks compromise the performance
of your network by flooding the network with undesired, and often useless, network packets and
by providing false information about the status of network resources.
The threat of DoS attacks can be reduced through the following three methods:
Antispoof featuresProper configuration of antispoof features on your routers and firewalls
can reduce your risk. This configuration includes RFC 2827 filtering at a minimum. If
hackers cannot mask their identities, they might not attack.
Anti-DoS featuresProper configuration of anti-DoS features on routers and firewalls can
help limit the effectiveness of an attack. These features often involve limits on the amount of
half-open connections that a system allows open at any given time.
Traffic rate limitingAn organization can implement traffic rate limiting with its ISP. This
type of filtering limits the amount of nonessential traffic that crosses network segments at a
certain rate. A common example is to limit the amount of ICMP traffic allowed into a
network because it is used only for diagnostic purposes. ICMP-based DDoS attacks are
common.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-31

Password Attacks
Hackers can implement
password attacks using
several different
methods:
Brute-force attacks
Trojan horse programs
IP spoofing
Packet sniffers

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-33

Password attacks can be implemented using several different methods, including brute-force
attacks, Trojan horse programs (discussed later in the chapter), IP spoofing, and packet sniffers.
Although packet sniffers and IP spoofing can yield user accounts and passwords, password
attacks usually refer to repeated attempts to identify a user account, password, or both. These
repeated attempts are called brute-force attacks.
Often a brute-force attack is performed using a program that runs across the network and
attempts to log in to a shared resource, such as a server. When an attacker successfully gains
access to a resource, he or she has the same rights as the user whose account has been
compromised to gain access to that resource. If this account has sufficient privileges, the attacker
can create a back door for future access, without concern for any status and password changes to
the compromised user account.

2-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Password Attack Example

L0phtCrack can take
the hashes of
passwords and
generate the clear text
passwords from them.
Passwords are
computed using two
different methods:
Dictionary cracking
Brute force
computation

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-34

Just as with packet sniffers and IP spoofing attacks, a brute-force password attack can provide
access to accounts that can be used to modify critical network files and services. An example
that compromises your networks integrity is an attacker modifying the routing tables for your
network. By doing so, the attacker ensures that all network packets are routed to him or her
before they are transmitted to their final destination. In such a case, an attacker can monitor all
network traffic, effectively becoming a man in the middle.
The following are the two different methods for computing passwords with L0phtCrack:
Dictionary crackingThe password hashes for all of the words in a dictionary file are
computed and compared against all of the password hashes for the users. This method is
extremely fast and finds very simple passwords.
Brute force computationThis method uses a particular character set such as AZ, or AZ
plus 09 and computes the hash for every possible password made up of those characters. It
will always compute the password if it is made up of the character set you have selected to
test. The downside is that time is required for completion of this type of attack.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-33

Password Attacks Mitigation

The following are mitigation techniques:

Do not allow users to use the same password on multiple

systems.
Disable accounts after a certain number of unsuccessful
login attempts.
Do not use plain text passwords. An OTP or a
cryptographic password is recommended.
Use strong passwords. Strong passwords are at least
eight characters long and contain uppercase letters,
lowercase letters, numbers, and special characters.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-35

The following are password attack mitigation techniques:

Do not allow users to have the same password on multiple systemsMost users will use the
same password for each system they access, and often personal system passwords will be the
same as well.
Disable accounts after unsuccessful loginsThis helps to prevent continuous password
attempts.
Do not use plain text passwordsUse of either an OTP or encrypted password is
recommended.
Use strong passwordsMany systems now provide strong password support and can
restrict a user to only the use of strong passwords. Strong passwords are at least eight
characters long and contain uppercase letters, lowercase letters, numbers, and special
characters.

2-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Man-in-the-Middle Attacks
Host A

Host B

Data in clear text

Router A

Router B

A man-in-the-middle attack requires that the hacker have access

to network packets that come across a network.
A man-in-the-middle attack is implemented using the following:
Network packet sniffers
Routing and transport protocols
Possible man-in-the-middle attack uses include the following:
Theft of information
Hijacking of an ongoing session
Traffic analysis
DoS
Corruption of transmitted data
Introduction of new information into network sessions
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-36

A man-in-the-middle attack requires that the attacker have access to network packets that come
across the networks. Such attacks are often implemented using network packet sniffers and
routing and transport protocols. The possible uses of such attacks are theft of information,
hijacking of an ongoing session to gain access to your internal network resources, traffic analysis
to derive information about your network and its users, denial of service, corruption of
transmitted data, and introduction of new information into network sessions.
An example of a man-in-the-middle attack could be someone who is working for your ISP, who
can gain access to all network packets transferred between your network and any other network.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-35

Man-in-the-Middle Mitigation

A man-in-the-middle attack
can only see cipher text

IPSec tunnel

Host A

Router A

ISP

Host B

Router B

Man-in-the-middle attacks can be effectively mitigated

only through the use of cryptography (encryption).

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-37

Man-in-the-Middle attack mitigation is achieved, as shown in the figure, by encrypting traffic in

an IPSec tunnel, which would only allow the hacker to see cipher text.

2-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Application Layer Attacks

Application layer attacks have
the following characteristics:

Exploit well known

weaknesses, such as
protocols, that are intrinsic to
an application or system (for
example, sendmail, HTTP, and
FTP)
Often use ports that are
allowed through a firewall (for
example, TCP port 80 used in
an attack against a web server
behind a firewall)
Can never be completely
eliminated, because new
vulnerabilities are always
being discovered

2003, Cisco Systems, Inc. All rights reserved.

7
6
5
4
3
2
1

Application
Presentation
Session
Transport
Network
Deata link
Physical

CSI 1.12-38

Application-layer attacks can be implemented using several different methods:

One of the most common methods is exploiting well known weaknesses in software
commonly found on servers, such as sendmail, PostScript, and FTP. By exploiting these
weaknesses, attackers can gain access to a computer with the permissions of the account
running the application, which is usually a privileged, system-level account.
Trojan horse program attacks are implemented using programs that an attacker substitutes
for common programs. These programs may provide all the functionality that the normal
program provides, but also include other features that are known to the attacker, such as
monitoring login attempts to capture user account and password information. These
programs can capture sensitive information and distribute it back to the attacker. They can
also modify application functionality, such as applying a blind carbon copy to all e-mail
messages so that the attacker can read all of your organizations e-mail.
One of the oldest forms of application-layer attacks is a Trojan horse program that displays a
screen, banner, or prompt that the user believes is the valid login sequence. The program
then captures the information that the user enters and stores or e-mails it to the attacker.
Next, the program either forwards the information to the normal login process (normally
impossible on modern systems), or simply sends an expected error to the user (for example,
Bad Username/Password Combination), exits, and starts the normal login sequence. The
user, believing that they have incorrectly entered the password (a common mistake
experienced by everyone), re-enters the information and is allowed access.
One of the newest forms of application-layer attacks exploits the openness of several new
technologies: the HTML specification, web browser functionality, and HTTP. These attacks,

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-37

which include Java applets and ActiveX controls, involve passing harmful programs across
the network and loading them through a users browser.

2-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Application Layer Attacks Mitigation

Some measures you can take to reduce your risks
are as follows:
Read operating system and network log files, or have
them analyzed by log analysis applications.
Subscribe to mailing lists that publicize vulnerabilities.
Keep your operating system and applications current
with the latest patches.
IDSs can scan for known attacks, monitor and log
attacks, and in some cases, prevent attacks.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-39

The following are some measures you can take to reduce your risks for application layer attacks:
Read operating system and network log files or have them analyzedIt is important to
review all logs and take action accordingly.
Subscribe to mailing lists that publicize vulnerabilitiesMost application and operating
system vulnerabilities are published on the Web at various sources.
Keep your operating system and applications current with the latest patchesAlways test
patches and fixes in a non-production environment. This prevents downtime and errors from
being generated unnecessarily.
Intrusion detection systems (IDSs) can scan for known attacks, monitor and log attacks, and
in some cases, prevent attacksThe use of IDSs can be essential to identifying security
threats and mitigating some of those threats, and, in most cases, it can be done automatically.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-39

Network Reconnaissance

Network reconnaissance refers to the

overall act of learning information about a
target network by using publicly available
information and applications.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-40

Network Reconnaissance refers to the overall act of learning information about a target network
by using publicly available information and applications. When hackers attempt to penetrate a
particular network, they often need to learn as much information as possible about the network
before launching attacks. Examples include DNS queries, ping sweeps, and port scans:
Domain Name System (DNS) queriesReveals such information as who owns a particular
domain and what addresses have been assigned to that domain.
Ping sweepsPresents a picture of the live hosts in a particular environment.
Port scansCycles through all well known ports to provide a complete list of all services
running on the hosts.

2-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Network Reconnaissance Example

Sample IP address query

Sample domain name query

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-41

The figure demonstrates how existing Internet tools can be used for network reconnaissance (for
example, an IP address query or a Domain Name query).
DNS queries can reveal such information as who owns a particular domain and what addresses
have been assigned to that domain. Ping sweeps of the addresses revealed by the DNS queries
can present a picture of the live hosts in a particular environment. After such a list is generated,
port scanning tools can cycle through all well known ports to provide a complete list of all
services running on the hosts discovered by the ping sweep. Finally, the hackers can examine the
characteristics of the applications that are running on the hosts. This can lead to specific
information that is useful when the hacker attempts to compromise that service.
IP address queries can reveal information such as who owns a particular IP address or range of
addresses and what domain is associated to them.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-41

Network Reconnaissance Mitigation

Network reconnaissance cannot be prevented

entirely.
IDSs at the network and host levels can usually
notify an administrator when a reconnaissance
gathering attack (for example, ping sweeps and
port scans) is under way.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-42

If ICMP echo and echo-reply is turned off on edge routers (for example, ping sweeps can be
stopped, but at the expense of network diagnostic data), port scans can still be run without full
ping sweeps They simply take longer because they need to scan IP addresses that might not be
live.
IDSs at the network and host levels can usually notify an administrator when a reconnaissance
gathering attack is underway. This allows the administrator to better prepare for the coming
attack or to notify the ISP who is hosting the system that it is launching the reconnaissance
probe.

2-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Trust Exploitation
A hacker
leverages existing
trust relationships
Several trust
models exist
Windows
Domains
Active
directory
Linux and
UNIX
NFS
NIS+

2003, Cisco Systems, Inc. All rights reserved.

SystemA Trusts SystemB

SystemB Trusts Everyone
SystemA Trusts Everyone
SystemA
User = psmith; Pat Smith

Hacker
gains
access to
SystemA

SystemB Compromised by hacker

User = psmith; Pat Smith

Hacker
User = psmith; Pat Smithson

CSI 1.12-43

While not an attack in and of itself, trust exploitation refers to an attack where an individual
takes advantage of a trust relationship within a network. The classic example is a perimeter
network connection from a corporation. These network segments often house DNS, SMTP, and
HTTP servers. Because they all reside on the same segment, a compromise of one system can
lead to the compromise of other systems because they might trust other systems attached to their
same network. Another example is a system on the outside of a firewall that has a trust
relationship with a system on the inside of a firewall. When the outside system is compromised,
it can leverage that trust relationship to attack the inside network.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-43

Trust Exploitation Mitigation

SystemA
User = psmith; Pat Smith

Hacker
blocked

Hacker
User = psmith; Pat Smithson

2003, Cisco Systems, Inc. All rights reserved.

SystemB
Compromised
by a hacker
User = psmith; Pat
Smith

Systems on the
outside of a firewall
should never be
absolutely trusted by
systems on the inside
of a firewall.
Such trust should be
limited to specific
protocols and should
be validated by
something other than
an IP address where
possible.

CSI 1.12-44

You can mitigate trust and exploitation-based attacks through tight constraints on trust levels
within a network. Systems on the outside of a firewall should never be absolutely trusted by
systems on the inside of a firewall. Such trust should be limited to specific protocols and should
be authenticated by something other than an IP address where possible.

2-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Port Redirection
Port redirection is a type
of trust-exploitation
attack that uses a
compromised host to
pass traffic through a
firewall that would
otherwise be dropped.
It is mitigated primarily
through the use of
proper trust models.
Antivirus software and
host-based IDS can help
detect and prevent a
hacker installing port
redirection utilities on
the host.

Attacker

Source: Attacker
Destination: A
Port: 22

Source: Attacker
Destination: B
Port: 23

Compromised
Host A

Source: A
Destination: B
Port: 23

Host B

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-45

Port redirection attacks are a type of trust exploitation attack that uses a compromised host to
pass traffic through a firewall that would otherwise be dropped. Consider a firewall with three
interfaces and a host on each interface. The host on the outside can reach the host on the public
services segment (commonly referred to as a Demilitarized Zone [DMZ]), but not the host on the
inside. The host on the public services segment can reach the host on both the outside and the
inside. If hackers were able to compromise the public services segment host, they could install
software to redirect traffic from the outside host directly to the inside host. Though neither
communication violates the rules implemented in the firewall, the outside host has now achieved
connectivity to the inside host through the port redirection process on the public services host.
An example of an application that can provide this type of access is netcat.
Port redirection can primarily be mitigated through the use of proper trust models, which are
network specific (as mentioned earlier). Assuming a system under attack, a host-based IDS can
help detect and prevent a hacker installing such utilities on a host.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-45

Unauthorized Access

Unauthorized access includes any unauthorized attempt to access a private

resource:
Not a specific type of attack
Refers to most attacks executed in networks today
Initiated on both the outside and inside of a network
The following are mitigation techniques for unauthorized access attacks:
Eliminate the ability of a hacker to gain access to a system
Prevent simple unauthorized access attacks, which is the primary function
of a firewall
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-46

While not a specific type of attack, unauthorized access attacks refer to the majority of attacks
executed in networks today. In order for someone to brute-force a Telnet login, they must first
get the Telnet prompt on a system. Upon connection to the Telnet port, the hacker might see the
message authorization required to use this resource. If the hacker continues to attempt access,
the hackers actions become unauthorized. These kinds of attacks can be initiated both on the
outside and inside of a network.
Mitigation techniques for unauthorized access attacks are very simple. They involve reducing or
eliminating the ability of a hacker to gain access to a system using an unauthorized protocol. An
example would be preventing hackers from having access to the Telnet port on a server that
needs to provide web services to the outside. If a hacker cannot reach that port, it is very difficult
to attack it. The primary function of a firewall in a network is to prevent simple unauthorized
access attacks.

2-46

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Virus and Trojan Horses

Viruses refer to malicious software that are attached to

another program to execute a particular unwanted
function on a users workstation. End-user workstations
are the primary targets.
A Trojan horse is different only in that the entire
application was written to look like something else, when
in fact it is an attack tool. A Trojan horse is mitigated by
antivirus software at the user level and possibly the
network level.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-47

The primary vulnerabilities for end-user workstations are viruses and Trojan horse attacks.
Viruses refer to malicious software that is attached to another program to execute a particular
unwanted function on a users workstation. An example of a virus is a program that is attached
to command.com (the primary interpreter for windows systems), which deletes certain files and
infects any other versions of command.com that it can find.
A Trojan horse is different only in that the entire application was written to look like something
else, when in fact it is an attack tool. An example of a Trojan horse is a software application that
runs a simple game on the users workstation. While the user is occupied with the game, the
Trojan horse mails a copy of itself to every user in the users address book. Then other users
receive the game and play it, thus spreading the Trojan horse.
These kinds of applications can be contained through the effective use of antivirus software at
the user level and potentially at the network level. Antivirus software can detect most viruses
and many Trojan horse applications and prevent them from spreading in the network. Keeping
up-to-date with the latest developments in these sorts of attacks can also lead to a more effective
posture against these attacks. As new virus or Trojan applications are released, enterprises need
to keep up-to-date with the latest antivirus software, and application versions.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-47

CAM Table Overflow

A C?

A C?

MAC A

Port 2
Destination C is not in
the CAM table. The
switch forwards the
frame out all ports.

MAC B

Port 3
A C?
MAC D

When a layer 2 switch receives a frame, the switch looks in the CAM
table for the destination MAC address. If an entry exists for the MAC
address in the table, the switch forwards the frame according to the
table. If the MAC address does not exist in the table, the switch
forwards the frame out every port on the switch until a response is
received and the table is updated.
An attacker typically floods the switch with invalid MAC addresses
until the CAM table fills up causing the switch to eventually flood all
ports with incoming trafficessentially acting like a hub.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-48

CAM tables are limited in size. If enough entries are entered into the CAM table before other
entries are expired, the CAM table fills up to the point that no new entries can be accepted. Once
that occurs, the switch floods all ports with incoming traffic because it cannot find the port
number for a particular MAC address in the CAM table. The switch, in essence, acts like a hub.
In May of 1999 the tool macof was released. It was written in approximately 100 lines of PERL
code and was later ported to C and incorporated into the dsniff package. This tool floods a
switch with randomly generated MAC addresses. Once the switchs CAM table fills up with the
randomly generated MAC addresses, the switch begins to forward all frames it receives to every
port.

2-48

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

CAM Table Overflow Attack Mitigation

A

A C?

MAC A

C?
Port 2

Specify the
allowed MAC
addresses

MAC B

Port 3

C?
MAC D

The CAM table flood attack can be mitigated by

configuring port security on the switch.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-49

Configuring port security on the switch can mitigate the CAM table flood attack, so that when an
invalid MAC is detected on the port, the switch can either block the offending MAC address or
shut down the port. This option provides for either of the following:
Specifying the MAC addresses on a particular switch port.
Specifying the number of MAC addresses that can be learned by a switch port.
Note

Copyright

If the attacker does not maintain the flood of invalid source MAC addresses, the switch
eventually times out older MAC address entries from the CAM table and begins to act like a
switch again.

2003, Cisco Systems, Inc.

Security Fundamentals

2-49

VLAN Hopping
Double
encapsulation
example

The frame is
encapsulated with
two 802.1q headers

The first switch strips

the first header

The frame is forwarded

out all ports with inner
802.1q tag

The frame is forwarded

out all ports with the
inner 802.1q tag

There are two types

of VLAN hopping attacks:
Double Tagging
Switch Spoofing
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-50

There are three common forms of VLAN hopping attacks:

Switch SpoofingIn a VLAN hopping attack the attacker configures a system to spoof itself
as a switch. This requires that the attacker be capable of emulating either InterSwitch Link
(ISL) or 802.1q signaling along with Dynamic Trunk Protocol (DTP) signaling. Using this
method an attacker can make a system appear to be a switch with a trunk port. If successful
the attacking system then becomes a member of all VLANs.
Double TaggingAnother version of this attack involves encapsulating the transmitted
frames with two 802.1q headers in order to forward the frames to the wrong VLAN. The
first switch to encounter the double encapsulated frame (1) strips the first encapsulation layer
off the frame and forwards the frame. The result is that the frame is forwarded with the inner
802.1q tag out all of the switch ports (2) including trunk ports configured with the native
VLAN of the attacker.

2-50

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VLAN Hopping Attack Mitigation

Several modifications to the VLAN
configuration are required to mitigate
VLAN hopping.
Dedicate VLAN identities for all trunk ports
Disable unused ports
Place unused ports in an unused VLAN
Set all user ports to non-trunking mode

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-51

Mitigating VLAN hopping attacks requires several modifications to the VLAN configuration.
One of the more important elements is to use dedicated VLAN identities for all trunk ports. You
should also disable all unused switch ports and place them in an unused VLAN, and set all user
ports to non-trunking mode by explicitly setting DTP on those ports to off.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-51

MAC Spoofing Attack

A
Destination MAC: A

1
ARP (A)

Switch Port
1
2
3
Host

A,B

2
Destination MAC: A

MAC spoofing attacks use a known MAC address

and IP address of a host on a remote VLAN to try
and get the target switch to forward frames from
the attacker.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-52

MAC spoofing attacks involve the use of a known MAC address and IP address of a host on a
remote VLAN in order to try and get the target switch to forward frames from the attacker. By
sending a single frame with the victims source Ethernet address the attacker overwrites the
CAM table entry so that the switch forwards packets destined for the victim to the attacker. Until
the victim sends traffic it will not receive any traffic. When the victim sends out traffic the CAM
table entry is re-written once more so that it moves back to the original port.
The figure shows how ARP poisoning works in detail. In the example, the switch learned
initially that host A is on port 1, host B is on port 2, and host C is on port 3. Host B sends out an
ARP broadcast identifying itself as host As IP address but host Bs MAC address or another
packet with the same IP address/MAC address combination. This traffic causes the frame to
move the location of Host A in its CAM table from port 1 to port 2. Traffic from Host C
destined to Host A is now visible to Host B. In order to correct this situation, Host A must send
out traffic on the switch port in order for the switch to re-learn the location of Host As MAC
address.

2-52

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

MAC Spoofing Attack Mitigation

A
Destination MAC: A

1
ARP (A)

Switch port
1
2
3
Host

The associate
MAC address to
a specific port

Destination MAC: A

Using the port security commands on the

switch mitigates MAC spoofing attacks.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-53

Use the port security commands to mitigate MAC spoofing attacks. The port security command
provides the capability to specify the MAC address of the system connected to a particular port.
The command also provides the ability to specify an action to take should a port security
violation occur.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-53

ARP Spoofing Attack

An attacker
attaches his MAC
address to another
stations IP address
The hold-down
timers can mitigate
this attack

2003, Cisco Systems, Inc. All rights reserved.

192.168.0.1
MAC A

1
B

192.168.0.2
MAC B

192.168.0.1
MAC B

CSI 1.12-54

A similar attack to the ARP/MAC poisoning attack is an ARP spoofing attack where an attacker
that lies within an ARP domain attaches their MAC address to another stations IP address. As
with the ARP/MAC poisoning attack this causes the switch or router to write the new MAC
information into the system ARP table and forward traffic destined for the IP address to the
attacker.
Hold-down timers in the interface configuration menu can be used to mitigate ARP spoofing
attacks. The hold-down timer sets the length of time an entry will stay in the ARP cache.

2-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Private VLAN Attacks

SRC: A1 DST: C2
Router
MAC: C
IP: 3

Attacker
MAC: A
IP: 1

SRC: A1 DST: C2
ARP (A)

Target
MAC: B
IP: 2

SRC: A1 DST: B2
SRC: A1 DST: B2

It is possible to attack PVLANs in an attempt to circumvent

their traffic isolation capabilities. One example is the following:
Proxy attacksUses a proxy to bypass access restrictions
to a private VLAN.
Private VLAN attacks can be mitigated through the use of ACLs
and VACLs on the router port.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-55

While PVLANs are a common mechanism to restrict communications between systems on the
same logical IP subnet it is not a full-proof mechanism. Private VLANs work by limiting which
ports within a VLAN can communicate with other ports in the same VLAN. Isolated ports within
a VLAN can communicate only with promiscuous ports. Community ports can communicate
only with other members of the same community and promiscuous ports. Promiscuous ports can
communicate with any port.
In a proxy attack against private VLANs frames are forwarded to a host on the network
connected to a promiscuous port such as a router. This attack allows for only unidirectional
traffic because any attempt by the target to send traffic back will be blocked by the PVLAN
configuration. If both hosts are compromised then static ARP entries could be used to allow bidirectional traffic.
In the previous figure, the attacker sends a packet with the source IP and MAC address of his
machine, a destination IP of the target system, but a destination MAC address of the router. The
switch forwards the frame to the routers switch port. The router, doing its job of routing traffic,
rewrites the destination MAC address as that of the target and sends the packet back out. Now
the packet has the proper format and is forwarded to the target system.
Configure access control lists (ACLs) on the router port in order to mitigate PVLAN attacks.
Virtual ACLs (VACLs) can also be used to help mitigate the effects of PVLAN attacks.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-55

Other Layer 2 Attacks

Spanning Tree Protocol ManipulationBy attacking the
Spanning-Tree Protocol, the network attacker hopes to
spoof his or her system as the root bridge in the
topology.
CDP attacksThe information sent through CDP is
transmitted in clear text and unauthenticated. Although
some management requires CDP, it should only be used
where appropriate in order to mitigate CDP attacks.
DHCP StarvationA DHCP Starvation attack broadcasts
DHCP requests with spoofed MAC addresses. The
techniques that mitigate CAM table flooding also mitigate
DHCP Starvation by limiting the number of MAC
addresses on a switch port.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-56

By attacking the Spanning-Tree Protocol, the network attacker hopes to spoof his or her system
as the root bridge in the topology. To do this the network attacker broadcasts out Spanning-Tree
Protocol Configuration/Topology Change Bridge Protocol Data Units (BPDUs) in an attempt to
force spanning-tree recalculations. The BPDUs sent out by the network attackers system
announce that the attacking system has a lower bridge priority. If successful, the network
attacker can see a variety of frames. By transmitting spoofed Spanning-Tree Protocol packets,
the network attacker causes the switches to initiate Spanning-Tree recalculations. This causes the
two connections to the network attackers system to forward packets. To mitigate Spanning-Tree
Protocol manipulation, use the root guard and the BPDU guard enhancement commands to
enforce the placement of the root bridge in the network as well as enforce the Spanning-Tree
Protocol domain borders.
The Cisco Discovery Protocol (CDP) runs at layer 2 and enables Cisco devices to identify
themselves to other Cisco devices. However, the information sent through CDP is transmitted in
clear text and unauthenticated. CDP is necessary for management applications and cannot be
disabled without impairing some network management applications. However, CDP can be
selectively disabled on interfaces where management is not being performed. When disabling
CDP on the router it is important to disable it globally and for each interface.
A DHCP starvation attack works by broadcasting DHCP requests with spoofed MAC addresses.
If enough requests are sent the attacker can exhaust the address space available to the DHCP
servers for a period of time. The attacker can then set up a rogue DHCP server on their system
and respond to new DHCP requests from clients on the network. Because DHCP responses
typically include default gateway and DNS server information, the attacker can supply his own
system as the default gateway and DNS server resulting in a man-in-the-middle attack.
The techniques that mitigate CAM table flooding also mitigate DHCP starvation by limiting the
number of MAC addresses on a switch port. As implementation of RFC 3118 (Authentication
2-56

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

for DHCP Messages) increases, DHCP starvation attacks will become more difficult. Finally,
DHCP option 82 (DHCP Relay Agent Information Option) helps to mitigate this attack by
enabling a DHCP relay agent to include information about itself when forwarding clientoriginated DHCP packets to a DHCP server. The server can use this information to implement IP
address or other parameter-assignment policies.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-57

Management Protocols and Functions

The protocols used to manage your network can in themselves be a source of vulnerability. This
section examines common management protocols and how they can be exploited.

Configuration Management
Configuration management protocols include SSH, SSL,
and Telnet.
Telnet issues include the following:
The data within a Telnet session is sent as clear text,
and may be intercepted by anyone with a packet sniffer
located along the data path between the device and the
management server.
The data may include sensitive information, such as
the configuration of the device itself, passwords, and
so on.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-58

If the managed device does not support any of the recommended protocols, such as SSH and
SSL, Telnet may have to be used (although this protocol is not highly recommended). The
network administrator should recognize that the data within a Telnet session is sent as clear text,
and may be intercepted by anyone with a packet sniffer located along the data path between the
managed device and the management server. The clear text may include important information,
such as the configuration of the device itself, passwords, and other sensitive data.

2-58

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Configuration Management
Recommendations
When possible, the following practices are
advised:

Use IPSec, SSH, SSL, or any other encrypted and

authenticated transport.
ACLs should be configured to allow only management
servers to connect to the device. All attempts from other
IP addresses should be denied and logged.
RFC 2827 filtering at the perimeter router should be used
to mitigate the chance of an outside attacker spoofing the
addresses of the management hosts.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-59

Regardless of whether SSH, SSL, or Telnet is used for remote access to the managed device,
access control lists (ACLs) should be configured to allow only management servers to connect to
the device. All attempts from other IP addresses should be denied and logged. RFC 2827
filtering at the ingress router should also be implemented to mitigate the chance of an attacker
from outside the network spoofing the addresses of the management hosts.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-59

SNMP
SNMP is a network management protocol that can be used to retrieve
information from a network device. The TCP and UDP ports SNMP
uses are 161 and 162.
The following are SNMP issues:
SNMP uses passwords, called community strings, within each
message as a very simple form of security. Most implementations
of SNMP on networking devices today send the community string
in clear text.
SNMP messages may be intercepted by anyone with a packet
sniffer located along the data path between the device and the
management server, and the community string may be
compromised.
An attacker could reconfigure the device if read-write access via
SNMP is allowed.
The following are SNMP recommendations:
Configure SNMP with only read-only community strings.
Set up access control on the device you wish to manage via SNMP
to allow only the appropriate management hosts access.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-60

SNMP is a network management protocol that can be used to retrieve information from a
network device (commonly referred to as read-only access) or to remotely configure parameters
on the device (commonly referred to as read-write access). SNMP uses passwords, called
community strings, within each message as a very simple form of security. Unfortunately, most
implementations of SNMP on networking devices today send the community string in clear text
along with the message. Therefore, SNMP messages may be intercepted by anyone with a packet
sniffer located along the data path between the device and the management server, and the
community string may be compromised.
When the community string is compromised, an attacker could reconfigure the device if readwrite access via SNMP is allowed. Therefore, it is recommended that you configure SNMP with
only read-only community strings. You can further protect yourself by setting up access control
on the device you wish to manage via SNMP to allow only the appropriate management hosts
access.

2-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Logging
Logging issues include the following:

Syslog is sent as clear text between the managed device

and the management host on UDP port 514.
Syslog has no packet-level integrity checking to ensure
that the packet contents have not been altered in transit.
There is a potential for the Syslog data to be falsified by
an attacker.
An attacker can send large amounts of false Syslog data
to a management server in order to confuse the network
administrator during an attack.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-61

Syslog, which is information generated by a device that has been configured for logging, is sent
as clear text between the managed device and the management host. Syslog has no packet-level
integrity checking to ensure that the packet contents have not been altered in transit. An attacker
may alter Syslog data in order to confuse a network administrator during an attack.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-61

Logging Recommendations
When possible, the following practices are
advised:
Encrypt Syslog traffic within an IPSec tunnel.
When allowing Syslog access from devices on the
outside of a firewall, you should implement RFC 2827
filtering at the perimeter router.
ACLs should also be implemented on the firewall in order
to allow Syslog data from only the managed devices
themselves to reach the management hosts.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-62

Where possible, Syslog traffic may be encrypted within an IPSec tunnel in order to mitigate the
chance of its being altered in transit. Where the Syslog data cannot be encrypted within an IPSec
tunnel because of cost or the capabilities of the device itself, the network administrator should
note that there is a potential for the Syslog data to be falsified by an attacker.
When allowing Syslog access from devices on the outside of a firewall, RFC 2827 filtering at the
egress router should be implemented. This scenario will mitigate the chance of an attacker from
outside the network spoofing the address of the managed device, and sending false Syslog data
to the management hosts.
ACLs should also be implemented on the firewall in order to allow Syslog data from only the
managed devices themselves to reach the management hosts. This scenario prevents an attacker
from sending large amounts of false Syslog data to a management server in order to confuse the
network administrator during an attack.

2-62

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

TFTP
Many network devices use TFTP for transferring
configuration or system files across the network. TFTP
uses port 69 for both TCP and UDP.
The following are TFTP issues:
TFTP uses UDP for the data stream between the device
and the TFTP server.
TFTP sends data in clear text. The network
administrator should recognize that the data within a
TFTP session may be intercepted by anyone with a
packet sniffer located along the data path between the
requesting host and the TFTP server.
When possible, TFTP traffic should be encrypted within
an IPSec tunnel in order to mitigate the chance of its
being intercepted.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-63

Many network devices use TFTP for transferring configuration or system files across the
network. TFTP uses UDP for the data stream between the requesting host and the TFTP server.
As with other management protocols that send data in clear text, the network administrator
should recognize that the data within a TFTP session might be intercepted by anyone with a
packet sniffer located along the data path between the device and the management server. Where
possible, TFTP traffic should be encrypted within an IPSec tunnel in order to mitigate the chance
of its being intercepted.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-63

NTP
NTP is used to synchronize the clocks of various devices across a network. It
is critical for digital certificates, and for correct interpretation of events within
Syslog data. NTP uses port 123 for both UDP and TCP connections.
The following are NTP issues:
An attacker could attempt a DoS attack on a network by sending bogus NTP
data across the Internet in an attempt to change the clocks on network
devices in such a manner that digital certificates are considered invalid.
An attacker could attempt to confuse a network administrator during an
attack by disrupting the clocks on network devices.
Many NTP servers on the Internet do not require any authentication of
peers.
The following are NTP recommendations:
Implement your own master clock for the private network synchronization.
Use NTP Version 3 or above as these versions support a cryptographic
authentication mechanism between peers.
Use ACLs that specify which network devices are allowed to synchronize
with other network devices.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-64

Network Time Protocol (NTP) is used to synchronize the clocks of various devices across a
network. Synchronization of the clocks within a network is critical for digital certificates, and for
correct interpretation of events within Syslog data.
A secure method of providing clocking for the network is for the network administrator to
implement their own master clock for the private network synchronized to Coordinated
Universal Time (UTC) via satellite or radio. However, clock sources are available to synchronize
to via the Internet, if the network administrator does not wish to implement their own master
clock because of costs or other reasons.
An attacker could attempt a DoS attack on a network by sending bogus NTP data across the
Internet in an attempt to change the clocks on network devices in such a manner that digital
certificates are considered invalid. Further, an attacker could attempt to confuse a network
administrator during an attack by disrupting the clocks on network devices. This scenario would
make it difficult for the network administrator to determine the order of Syslog events on
multiple devices.
Version 3 and above of NTP supports a cryptographic authentication mechanism between peers.
The use of the authentication mechanism as well as ACLs that specify which network devices
are allowed to synchronize with other network devices is recommended to help mitigate against
such a scenario. The network administrator should weigh the cost benefits of pulling clock
information from the Internet with the possible risk of doing so and allowing it through the
firewall. Many NTP servers on the Internet do not require any authentication of peers. Therefore,
the network administrator must trust that the clock itself is reliable, valid, and secure.

2-64

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Summary
This section summarizes the information you learned in this chapter.

Summary
The need for network security has increased as networks have
become more complex and interconnected.
The following are the components of a complete
security policy:
Statement of authority and scope
Acceptable use policy
Identification and authentication policy
Internet use policy
Campus access policy
Remote access policy
Incident handling procedure
The Security Wheel details the view that security is an ongoing
process.
The Security Wheel includes four phases: secure, monitor, test,
and improve.
2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.12-66

Security Fundamentals

2-65

Summary (cont.)
The following are the four types of security threats:
Structured
Unstructured
Internal
External
The following are common attack methods and techniques
used by hackers:
Packet sniffers
IP weaknesses
Password attacks
DoS or DDoS
Man-in-the-middle attacks
Application layer attacks
Trust exploitation
Port redirection

2003, Cisco Systems, Inc. All rights reserved.

2-66

Cisco SAFE Implementation 1.1

CSI 1.12-67

Copyright

2003, Cisco Systems, Inc.

Summary (cont.)
Virus
Trojan horse
Operator error
CAM table overflow
VLAN hopping
MAC spoofing
ARP spoofing
Private VLAN attacks
Spanning Tree protocol manipulation
CDP attacks
DHCP Starvation
Management protocols can in themselves be a source of
vulnerability
2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.12-68

Security Fundamentals

2-67

2-68

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Lab ExerciseVulnerabilities and Threats

Complete the following lab exercise to practice what you learned in this chapter.

Objectives
In this lab exercise you will complete the following tasks:
Port scan a host using a command line utility.
Scan a network using a vulnerability scanner to discover network services and
vulnerabilities.
Analyze network traffic with Ethereal.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals Lab 2-1

Visual Objectives
The following figure displays the configuration you will complete in this lab exercise.

Lab Visual Objective

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24

brP
.1 e0/0

10.2.P.0/24

.150

.10P e0/1

Branch

RBB
10.2.P.11

Branch

PSS,
WWW,
and FTP

172.16.P.0/24

.10

Super server,
WWW, and FTP

.1
.2

e0/1

172.30.P.0/24

.150

e0/0

192.168.P.0/24

rP
.2 e0

pP
.1 e4

.1 e2

private
.5

.1 e1

.50
.4

DMZ
.5

10.0.P.0 /24

public
172.18.P.0/24

cP
.100

RTS

sensorP

Student

Remote: 10.1.P.11
Local: 10.0.P.11

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.12-1

Task 1Port Scan a Host Using a Command Line Utility

Complete the following steps to port scan a host using netcat:
Step 1

Launch the netcat icon on the Student PC. A DOS command prompt window opens.

Step 2

Obtain the netcat usage information. The usage information provides you with the various
command line options available.

Step 3

Port scan the target host or devices as specified by the instructor:

(where P = pod number)

Lab 2-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 2Scan a Network Using a Vulnerability Scanner to Discover

Network Services and Vulnerabilities
Complete the following steps on the student PC to scan the public services segment server for
services and vulnerabilities:
Step 1

Launch the BluesPortScan icon on your desktop.

Step 2

Enter the IP address for the public services segment server in the Start field: 172.16.P.50.
(where P = pod number)

Step 3

Enter the IP address for the public services segment server in the End field: 172.16.P.50.
(where P = pod number)

Step 4

Click the Show List button. The Ports to Scan window opens.

Step 5

Click the Check All button on the right side of the window.

Step 6

Close the window.

Step 7

Ensure that the Scan ports from list check box is selected.

Step 8

Click the Start scan button.

Step 9

When the scan has completed, view the results in the main window.

Task 3Analyze Network Traffic with Ethereal

Complete the following steps to analyze network traffic with Ethereal:
Step 1

Double-click the Ethereal icon on your desktop.

Step 2

Choose Capture>Start. The Capture Preferences window opens.

Step 3

Click OK to start capturing the traffic.

Step 4

Click STOP when told to by the instructor. The Ethereal window is populated with the network
traffic that has been captured. Examine the traffic to see what type of information is available.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals Lab 2-3

Lab 2-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Architectural Overview
Overview
This chapter introduces and gives an overview of the SAFE Extending the Security Blueprint to
Small, Midsize, and Remote-User Networks (SAFE SMR) architecture. It includes the following
topics:
Objectives
SAFE architectural overview
Design fundamentals
Safe axioms
Summary

Objectives
This section lists the chapters objectives.

Objectives
Upon completion of this chapter, you will be
able to perform the following tasks:
Discuss the SAFE design philosophy and how it
impacts the decision making process.
Recognize why routers, switches, hosts,
networks, and applications are targets.
List the general guidelines for securing these
devices.

2003, Cisco Systems, Inc. All rights reserved.

3-2

Cisco SAFE Implementation 1.1

CSI 1.13-2

Copyright

2003, Cisco Systems, Inc.

SAFE Architectural Overview

SAFE emulates as closely as possible the functional requirements of todays networks. This
section provides an architectural overview of the SAFE SMR white paper.

SAFE SMR Goals

Provides best practice
information for securing
small, midsize, and
remote-user networks
Provides a defense-indepth approach focusing
on the expected threats
and their mitigation
(failure of one system is
not likely to compromise
network resources)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-4

SAFE serves as a guide to network designers considering the security requirements of their
network. SAFE takes a defense-in-depth approach to network security design. This type of
design focuses on the expected threats and their methods of mitigation, rather than on Put the
firewall here, put the intrusion detection system there. This strategy results in a layered
approach to security where the failure of one security system is not likely to lead to the
compromise of network resources. SAFE is based on Cisco products and those of Cisco partners.
SAFE SMR focuses heavily on threats encountered in networks today. Network designers who
understand these threats can better decide where and how to deploy mitigation technologies.
Without a full understanding of the threats involved in network security, deployments tend to be
incorrectly configured, are too focused on security devices, or lack threat response options. By
taking the threat-mitigation approach, SAFE SMR should provide network designers with
information for making sound network security choices.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-3

Key Components of a
SAFE Network
Identity

Authentication,
digital certificates

Perimeter
security

ACLs, Firewalls

Secure
connectivity

Security
monitoring

VPN Tunneling,
encryption

Intrusion detection,
scanning

Security
management

Policy management,
device management

Internet

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-5

The key components of a SAFE network are fundamental to the success of an implementation.
These key components are broken down as follows:
IdentityAuthentication and digital certificates
Perimeter securityAccess Control Lists (ACLs) and firewalls
Secure connectivityVPN tunneling and encryption
Security monitoringIntrusion detection and scanning
Security managementPolicy management, device management, and directory services
The SAFE Blueprint identifies these components as fundamental in protecting all networks
including small, midsize, and remote access networks.

3-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Principles

SP
edge

PSTN
module

SAFE SMR uses the

same principles as
SAFE Enterprise only
scaled for smaller
networks.

Medium network/
branch edge
Corporate Internet module

Medium network/
branch campus
Campus module

Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or
ATM
module

FR/ATM

Public
services

WAN module

Corporate
servers

SAFE SMR is based

on threat mitigation
that is independent of
specific devices
used.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-6

SAFE SMR principles were developed to take the same principles of SAFE Enterprise and size
them appropriately for smaller networks. This includes branches of larger enterprises as well as
standalone, small-to-midsize security deployments. It also includes information on remote user
networks, such as teleworkers and mobile workers. For further information on SAFE Enterprise,
please refer to SAFE: A Security Blueprint for Enterprise Networks, which can be found on the
Cisco website.
The principles are not necessarily device-specific; however, the design considerations used for
this course are based on Cisco products and those of its partners.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-5

SAFE SMR Assumptions

SAFE SMR assumes

the following:
That a security
policy is already in
place
That a secure
environment is not
guaranteed
That the application
and operating
system are secure

SP edge

Medium network/branch edge

PSTN module

Corporate Internet module

Medium network and

branch campus
Campus module
Management
server

PSTN

Corporate
users

ISP edge
module
Public
services

Internet
Frame or ATM
module

WAN module

Corporate
servers

FR/ATM

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-7

SAFE SMR makes the following assumptions:

The security policy is already in placeCisco does not recommend deploying security
technologies without an associated policy.
SAFE does not guarantee a secure environmentFollowing the guidelines in this course or
the SAFE Blueprint does not guarantee a secure environment, nor does it guarantee that you
will prevent all penetrations. However, you can achieve reasonable security by doing the
following:

Establishing a good security policy

Staying up-to-date on the latest developments in the hacker and security communities

Maintaining and monitoring all systems with sound system-administration practices

Following the guidelines of this course

Application and operating system vulnerabilities are not comprehensively coveredProper

application and operating system monitoring and maintenance is understood as one of the
fundamentals of network security and is therefore not covered in-depth in this course.

3-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Fundamentals
Implementation decisions vary, depending on the network functionality required. This section
covers the SAFE SMR design objectives that guide the decision making process.

SAFE SMR Environment

SAFE SMR uses the following design objectives:

Security and attack mitigation is based on policy.

Security implementation must be throughout the
infrastructure (not just on specialized security devices).
Deployment must be cost-effective.
Management and reporting must be secure.
Users and administrators of critical network resources
must be authenticated and authorized.
Intrusion detection must be used for critical resources
and subnets.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-9

SAFE SMR uses the following objectives, which are based on the SAFE SMR Blueprint:
Security and attack mitigation is based on policyA properly implemented security policy
without proper security practices can be less effective at mitigating the threat to enterprise
resources than a comprehensive security product implementation without an associated
policy. Cisco assumes that a security policy has been developed and implemented
appropriately.
Security implementation must be throughout the infrastructureIt is important to
understand that network security extends far beyond a simple perimeter. It is necessary to
take an overall approach to network security, including all types of threats.
Deployment must be cost-effectiveAt many points in the network design process, you
need to choose between using integrated functionality in a network device and using a
specialized functional appliance. Integrated functionality is a major consideration in the
implementation of a SAFE SMR network for cost-effectiveness.
Management and reporting must be secureCisco recommends that management of devices
inside the private network use out-of-band management whenever necessary. Other
circumstances such as location, budget, and so on affect this decision, as well as when
Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-7

devices outside the network require management and reporting. In these cases in-band
management may be necessary.
Users and administrators of critical network resources must be authenticated and
authorizedIts always necessary to ensure users and administrators are accessing network
resources with appropriate authentication and authorization such as Digital Certificates,
TACACS+ and Key Exchange.
Intrusion detection must be used for critical resources and subnetsDeployment of intrusion
detection is necessary to mitigate many of the expected threats discussed in this course.

3-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

SAFEA Security Architecture

The following
guidelines were
used in developing
the architecture:
If the first line of
defense is
compromised, the
attack must be
detected and
contained by the
second line of
defense.
Proper security and
good network
functionality must be
balanced.

External dial-in HIDS

threat
Internet

Router

Internal IP
Threat
Personal
firewall

HIDS on PCs
WAN
Critical
Critical
resources
IDS Sensors

Second line of
defense

Wireless threat

First line of defense

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-10

First and foremost SAFE SMR is a security architecture. SAFE SMR must prevent most attacks
from successfully affecting valuable network resources. However, in being secure, the network
must continue to provide critical services that users expect.
The following guidelines are used when developing the architecture:
If the first line of defense is compromised, the attack must be detected and contained by the
second line of defense.
Proper security and good network functionality must be balanced.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-9

SAFE SMR Resiliency

SAFE Enterprise with resiliency example

SAFE SMR is
designed without
resiliency
resiliency is
covered in SAFE
Enterprise

Remote
access VPN

Site-to-Site
VPN
PSTN
Traditional dial
access servers

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-11

Unlike SAFE Enterprise, SAFE SMR is designed without resiliency. The approach taken for
SAFE SMR is to provide a security architecture without resilient and redundant practices for
both cost savings and ease of integration. Those interested in designing secure networks in a
resilient environment should concentrate on the SAFE Enterprise method of design.

3-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Integrated

Functionality
General integrated
advantages
Can be implemented on
existing equipment
Better interoperability
Can reduce overall cost
General standalone
appliance advantages
Increased depth of
functionality
Increased performance
when required

SAFE SMR integrated

functionality example
ISP edge module

ISP

VPN
Software
Client
with
personal
firewall

Authenticate
remote site,
terminate IPSec,
and personal
firewall and virus
scanning for local
attack mitigation

Software
access option
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-12

The advantages to integrated functionality are as follows:

Can be implemented on existing equipmentMany devices such as routers and firewalls can
provide multiple functions including routing and packet filtering.
Better interoperabilityA router running the IOS Firewall function is less likely to
introduce problems into the network than two separate devices.
Can reduce overall costIt is less expensive to integrate functionality into a single device
rather than purchasing two separate devices.
The advantages to standalone appliances are as follows:
Increased depth of functionalityA standalone appliance can provide functionality that is
not available in an integrated product.
Increased performance when requiredA standalone appliance can provide bandwidth and
throughput advantages to the network.
Throughout the SAFE SMR architecture, both integrated systems and appliances are used. When
the example design requirements used for the development of the architecture did not dictate a
specific choice, the developers of SAFE SMR opted to go with integrated functionality in order
to reduce the overall cost of the solution.
Integrated functionality is often attractive because you can implement it on existing equipment,
or because the features can interoperate with the rest of the device to provide a better functional
solution. Appliances are often used when the depth of functionality required is very advanced or
when performance needs require using specialized hardware.
Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-11

SAFE SMR Module Concept

SAFE SMR uses a green
field or from scratch
module approach, which
has the following
advantages:

The architecture
addresses security
relationships between
the various functional
blocks of the network.
Security can be
implemented on a
module-by-module
basis instead of
attempting the entire
architecture in a single
phase.
Modules can and
should be combined
to achieve desired
functionality.
2003, Cisco Systems, Inc. All rights reserved.

Medium network modules

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

Public
services

WAN module

Corporate
servers

FR/ATM

CSI 1.13-13

Although it is true that most networks cannot be easily dissected into clear-cut modules, the
green field or from scratch modular approach provides a guide for implementing different
security functions throughout the network. Engineers are not expected to design their networks
identical to the SAFE implementation, but rather use a combination of the modules described
and integrate them into the existing network. The advantages to the approach taken are as
follows:
The architecture addresses security relationships between the various functional blocks of
the network.
Security can be implemented on a module-by-module basis instead of attempting the entire
architecture in a single phase.
Modules can and should be combined to achieve desired functionality.
The diagram in the figure is an example of a SAFE medium network and its respective modules,
which include the campus module, corporate Internet module, and the various edge modules.

3-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Safe Axioms
This section covers the Axioms used by SAFE SMR.

A Target-Rich Environment
SAFE SMR is based on the following axioms:

Routers are targetsRouters control access from every

network to every network.
Switches are targetsLike routers, switches (both Layer 2 and
Layer 3) have their own set of security considerations.
Hosts are targetsHost are the most likely target during an
attack.
Networks are targetsNetwork attacks are among the most
difficult attacks to deal with.
Applications are targetsApplications are coded by human
beings (mostly) and, as such, are subject to numerous errors
and vulnerabilities.
IDSsIDSs act as alarm system in the physical world.
Secure management and reportingIf you are going to log it,
read it.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-15

The following are axioms for when identifying appliances and applications that are primary
network targets:
Routers are targetsRouter security is a critical element in any security deployment.
Switches are targetsUnlike routers, not as much information is available about the security
risks in switches and what can be done to mitigate those risks. Most of the risks associated
with routers are applicable to switches as well.
Hosts are targetsA host presents some of the most difficult challenges from a security
perspective and is the most likely target during an attack. There are numerous hardware
platforms, operating systems, and applications, all of which have updates, patches, and fixes
available at different times.
Networks are targetsThe attacks on networks are most difficult because, typically, they
take advantage of an intrinsic characteristic in the way your network operates.
Applications are targetsAttacks on applications can be benign or malignant. It is the
malignant attacks that require the most attention.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-13

Intrusion detection systems (IDSs)When an IDS detects something that it considers an

attack; it can either take corrective action itself or notify a management system for actions by
the administrator.
Secure management and reportingLogging and reading information from many devices
can be challenging. It is important to be able to identify priority events. Then you can take
action for those events and deal with them appropriately.

3-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Routers Are Targets

Router security is a
critical element in
any security
deployment:

Routers advertise
networks and filter
who can use them.
Routers are
potentially a
hackers best friend.
Routers provide
access and,
therefore, you
should secure them
to reduce the
likelihood that they
can be directly
compromised.

2003, Cisco Systems, Inc. All rights reserved.

Medium network modules

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

Public
services

WAN module

Corporate
servers

FR/ATM

Routers are targets

CSI 1.13-16

Routers control access from network to network. They advertise networks and filter that can use
them, and they are potentially a hackers best friends. Because of this, router security is a critical
element in any security deployment. It is important for security professionals to be completely
up to date on current router documentation and possible threats to routers. The following URL
can provides the most current Cisco documentation:
http:/www.cisco.com/warp/public/707/21.html.
The figure indicates the location of the routers in the SAFE SMR network example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-15

Routers Are Targets

General Guidelines
Corporate Internet module

The following are general

guidelines:
Lock down Telnet access to a
router.
Lock down SNMP access to a
router.
Control access to a router
through the use of TACACS+.
Turn off unneeded services.
Log at appropriate levels.
Authenticate routing updates.

Public
services
WAN module

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-17

The following guidelines should be followed when securing routers:

Lock down Telnet access to a routerInteractive Telnet access is available not only on the
standard Telnet TCP port (port 23), but on a variety of higher-numbered ports as well. All
interactive access mechanisms use the IOS teletype (TTY) abstraction (in other words, they
all involve sessions on lines of one sort or another). Local asynchronous terminals and
dialup modems use standard lines, known as TTYs. Remote network connections, regardless
of the protocol, use virtual TTYs, or virtual teletypes (VTYs). The best way to protect a
system is to make certain that appropriate controls are applied on all lines, including both
VTY lines and TTY lines.
Lock down Simple Network Management Protocol (SNMP) access to a routerSNMP is
widely used for router monitoring, and frequently for router configuration changes as well.
Unfortunately, version 1 of the SNMP protocol, which is the most commonly used, uses a
very weak authentication scheme based on a community string, which is a fixed password
transmitted over the network without encryption. If at all possible, use SNMP version 2,
which supports a Message Digest 5 (MD5)-based digest authentication scheme, and allows
for restricted access to various management data. If you must use SNMP version 1, you
should be careful to choose unobvious community strings (not, for example, public or
private). If at all possible, you should avoid using the same community strings for all
network devices; use a different string or strings for each device, or at least for each area of
the network. Do not make a read-only string the same as a read-write string. If possible,
periodic SNMP version 1 polling should be done with a read-only community string; readwrite strings should be used only for actual write operations.
Control access to a router through the use of Terminal Access Controller Access Control
System Plus (TACACS+)TACACS+ is a protocol providing detailed accounting
3-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

information and flexible administrative control over authentication and authorization

processes to control unauthorized access. TACACS+ is facilitated through authentication,
authorization, and accounting (AAA).
Turn off unneeded servicesAs a general rule, any unnecessary service should be disabled
in any router that is reachable from a potentially hostile network. The following services are
sometimes useful, but should be disabled if they are not actively being used:

Finger

Network Time Protocol (NTP)

Cisco Discovery Protocol (CDP)

Log at appropriate levelsIt is necessary to log information on the router (for example,
access logs, faults, and warnings).
Authenticate routing updatesIf you are using a dynamic routing protocol that supports
authentication, it is a good idea to enable that authentication. This prevents some malicious
attacks on the routing infrastructure, and can also help to prevent damage caused by
misconfigured rogue devices on the network.
The figure identifies the location of the router in the SAFE SMR network example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-17

Switches Are Targets

Medium network modules
PSTN module

Most of the security

concerns detailed in
the Routers Are
Targets section
also apply to
switches.

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

Public
services

WAN module

Corporate
servers

FR/ATM

Switches are
targets
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-18

Like routers, switches (both Layer 2 and Layer 3) have their own set of security considerations.
Unlike routers, not as much information is available about the security risks in switches and
what can be done to mitigate those risks. Most of the security techniques detailed in the
preceding section, Routers Are Targets, apply to switches.
The figure identifies the location of the switches in the SAFE SMR example.

3-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Switches Are Targets

General Guidelines
The following are general guidelines:

Corporate Internet module

Ports without any need to trunk should

have any trunk settings set to off.
If you are using older versions of
software for your Ethernet switch,
make sure that trunk ports use a VLAN
number not used anywhere else in the
switch.
Disable all unused ports on a switch.
Avoid using VLANs as the sole
method of securing access between
two subnets.
Private VLANs provide some added
security to specific network
applications (not available on most
low-end switches).

2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

CSI 1.13-19

The following guidelines are in addition to router-specific guidelines and apply to both Layer 2
and Layer 3 switches:
Ports without any need to trunk should have trunk settings set to offThis prevents a host
from becoming a trunk port and receiving all traffic that would normally reside on a trunk
port.
If you are using older versions of software for your Ethernet switch, make sure that trunk
ports use VLAN number not used anywhere else in the switchThis prevents packets
tagged with the same VLAN as the trunk port from reaching another VLAN without
crossing a layer 3 device.
Disable all unused ports on a switchThis prevents hackers from plugging in to unused
ports and communicating with the rest of the network.
Avoid using VLANs as the sole method of securing access between two subnetsThe
capability for human error, combined with the understanding that VLANs and VLANtagging protocols were not designed with security in mind, makes their use in sensitive
environments inadvisable.
Private VLANs provide some added security to specific network applications (not available
on most low-end switches)They work by limiting which ports within a VLAN can
communicate with ports in the same VLAN.
The figure identifies the location of the switches in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-19

Hosts Are Targets

The host presents some of
the most difficult
challenges from a security
perspective:
There are numerous
hardware platforms,
operating systems, and
applications, all of
which have updates,
patches, and fixes
available at different
times.
Hosts are extremely
visible within the
network.
Hosts are the most
successfully
compromised devices.
As the complexity of a
host system increases,
so does the likelihood of
a security breech.
2003, Cisco Systems, Inc. All rights reserved.

Medium network modules

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

Public
services

WAN module

Corporate
servers

FR/ATM

Hosts are
targets
CSI 1.13-20

Being the most likely target during an attack, the host presents some of the most difficult
challenges from a security perspective. There are numerous hardware platforms, operating
systems, and applications, all of which have updates, patches, and fixes available at different
times.
Because hosts provide the application services to other hosts that request them, they are
extremely visible within the network. For example, many people have visited
www.whitehouse.gov, which is a host, but few have attempted to access s2-0.whitehouseisp.net,
which is a router. Because of this visibility, hosts are the most frequently attacked devices in any
network intrusion attempt.
In part because of the aforementioned security challenges, hosts are also the most successfully
compromised devices. For example, a given web server on the Internet might run a hardware
platform from one vendor, a network card from another, an operating system from still another
vendor, and a web server that is either open source or from yet another vendor. Additionally, the
same web server might run applications that are freely distributed via the Internet, and might
communicate with a database server that starts the variations all over again. That is not to say
that the security vulnerabilities are specifically caused by the multisource nature of all of this,
but rather that as the complexity of a system increases, so does the likelihood of a failure.
The figure identifies the location of the hosts in the SAFE SMR example.

3-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Hosts Are Targets

General Guidelines
Corporate Internet module

The following are general

guidelines:
Pay careful attention to each of the
components within the system.
Keep any systems up-to-date with
the latest security patches and
updates.
Pay attention to how these patches
affect the operation of other system
components.
Evaluate all updates on test
systems before you implement
them in a production environment.

2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

CSI 1.13-21

The following are guidelines that can be a major factor in maintaining a secure environment for
hosts:
Pay careful attention to each of the components within the systemThese components
include hardware and software.
Keep any systems up-to-date with the latest patches, fixes, and so onBecause patches and
fixes are being created constantly for software and hardware. It is a good rule to practice
according to your organizations change management policy on affected hosts.
Pay attention to how these patches affect the operation of other system componentsRead
release notes and updates on all changes prior to implementation.
Evaluate all updates on test systems before you implement them in a production
environmentThis practice ensures that changes are successful and also inhibits possible
affects to other components.
The figure identifies the location of the hosts in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-21

Networks Are Targets

Network attacks
typically take
advantage of an
intrinsic characteristic
in the way your
network operates.
These attacks include
the following:
ARP
MAC-based Layer 2
attacks
Sniffers
DDoS attacks

Medium network modules

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

Public
services

WAN module

Corporate
servers

FR/ATM

Networks are targets

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-22

Network attacks are among the most difficult attacks to deal with because they typically take
advantage of an intrinsic characteristic in the way your network operates. These attacks include:
Address Resolution Protocol (ARP)Identifies network component addresses for further
attack.
Media Access Control (MAC)-based Layer 2 attacksIdentifies the MAC layer address for
further attack.
SniffersA software application that uses a network adapter card in promiscuous mode to
capture all network packets that are sent across a particular collision domain.
Distributed denial of service (DDoS) attacksCauses multiple machines to simultaneously
send spurious data to an IP address. The following are common forms of DDoS attacks:

Internet Control Message Protocol (ICMP) floods

Transmission Control Protocol (TCP) SYN floods

UDP floods

The figure identifies the location of the networks in the SAFE SMR example.

3-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Networks Are Targets

General Guidelines
Corporate Internet module

The following are general

guidelines:
Have the ISP configure rate
limiting on the outbound
interface of companies site.
Correctly flag traffic as
undesirable.
Follow filter guidelines
outlined in RFC 1918 and
2827.

2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

CSI 1.13-23

One approach to limiting a network attack is to follow filtering guidelines for networks outlined
in RFC 1918 and RFC 2827:
RFC 1918This RFC provides background on the allocation of IP addresses for private
Internets. It also provides implementation guidelines for companies that want to implement
IP but do not want full connectivity to the Internet.
RFC 2827This RFC provides an effective and straightforward method for using ingress
traffic filtering to prohibit denial of service (DoS) attacks, which use forged IP addresses to
be propagated from behind an ISPs aggregation point. Collectively, if ISPs worldwide were
to implement the guidelines in RFC 2827, source address spoofing would be greatly
diminished. Although this strategy does not directly prevent DDoS attacks, it does prevent
such attacks from masking their source, which makes tracing back to the attacking networks
much easier. Ask your ISP about which DDoS mitigation options they make available to
their customers.
The figure identifies the location of the networks in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-23

Error! Not a valid link.

Applications are subject to numerous problems that can be benign or malignant. Security issues
involve the following:
How an application makes calls to other applications or the operating system itself
The privilege level at which the application runs
The degree of trust that the application has for the surrounding systems
The method the application uses to transport data across the network
Applications are coded by human beings (mostly) and, as such, are subject to numerous errors.
These errors can be benign (for example, an error that causes your document to print
incorrectly), or malignant (for example, an error that makes the credit card numbers on your
database server available via anonymous FTP). It is the malignant problems that need careful
attention.
The figure identifies the location of the applications in the SAFE SMR example.

3-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Applications Are Targets

General Guidelines
The following are general
guidelines:

Corporate Internet module

Ensure that commercial and

public domain applications
are up-to-date with the latest
security fixes.
Complete code review on
applications and customdeveloped applications to
ensure that the applications
are not introducing any
security risks caused by poor
programming.

2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

CSI 1.13-25

Care needs to be taken to ensure that commercial and public domain applications are up-to-date
with the latest security fixes. Public domain applications, as well as custom-developed
applications, also require code review to ensure that the applications are not introducing any
security risks caused by poor programming. IDSs can help mitigate some of the attacks launched
against applications and other functions within the network.
With any system or application changes it is necessary to review release notes and
documentation, follow your organizations change management policies, and test in a nonproduction environment prior to implementation.
The figure identifies the location of the applications in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-25

IDSs
IDSs can respond to an
attack in two ways:
Take corrective
action itself
Notify a management
system for actions by
the administrator
There are two types of
IDSs:
Host-based (HIDS)
Often better at
preventing specific
attacks
Network-based
(NIDS)Allows a
perspective of the
overall network

Medium network modules

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module
Public
services

Internet
Frame or ATM
module

Corporate
servers

WAN module

FR/ATM

NIDS

2003, Cisco Systems, Inc. All rights reserved.

HIDS

CSI 1.13-26

IDSs act like an alarm system in the physical world. When an IDS detects something that it
considers an attack, it can either take corrective action itself or notify a management system for
actions by the administrator. Some systems are more or less equipped to respond to and prevent
such an attack.
Host-based intrusion detection can work by intercepting operating system and application calls
on an individual host. It can also operate by after-the-fact analysis of local log files. The former
approach allows better attack prevention, whereas the latter approach dictates a more passive
attack-response role. Because of the specificity of their role, host-based IDSs (HIDSs) are often
better at preventing specific attacks than network-based IDSs (NIDSs), which usually issue only
an alert upon discovery of an attack.
However, that specificity causes a loss of perspective to the overall network. This is where NIDS
excels. Ideally, Cisco recommends a combination of the two systemsHIDS on critical hosts
and NIDS looking over the whole networkfor a complete IDS.
Several factors need to be considered when choosing between the types of IDSs to implement:
Budget
Number of devices needing to be monitored
Topology of the network
Number of personnel required to respond to attacks
The figure identifies the location of the IDSs in the SAFE SMR example.

3-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IDSsGeneral Guidelines
The following are general
guidelines:

Corporate Internet module

Tune the implementation to

decrease false positives.
Generally use shunning only on
TCP traffic, as it is more difficult to
spoof than UDP.
Keep the shun length short.
Because TCP traffic is more difficult
to spoof, you should consider using
TCP resets more often than
shunning.
Consider outsourcing your IDS
management to a third party
because of the need for constant
monitoring.

2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

CSI 1.13-27

The following guidelines can aid an administrator in preventing attacks and unnecessary work:
Tune the implementation to decrease false positivesFalse positives are alarms caused by
legitimate traffic or activity. False negatives are attacks that the IDS fails to see. When the
IDS is tuned, you can configure it more specifically as to its threat-mitigation role.
Generally use shunning only on TCP traffic, as it is more difficult to spoof than UDP
Shunning is the use of access control filters and should be carefully implemented.
Keep the shun length shortKeeping the shun length short eliminates blocking traffic from
a valid address that has been spoofed previously.
Because TCP traffic is more difficult to spoof, you should consider using TCP resets more
often than shunningTCP resets operate only on TCP traffic and terminate an active attack
by sending a TCP reset to both the attacking and attacked host.
Consider outsourcing your IDS management to a third party because of the need for constant
monitoringIT staff are often overworked (particularly in smaller organizations).
The figure identifies the location of the IDSs in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-27

Secure Management and Reporting

General Guidelines
The following are out-of-band management guidelines for the
architecture:
Should provide the highest level of security. It should mitigate the
risk of passing insecure management protocols over the
production network.
Should keep clocks on hosts and network devices in sync.
Should record changes and archive configurations.
The following are in-band management guidelines:
Decide if the device really needs to be managed or monitored.
Use IPSec when possible.
Use SSH or SSL instead of Telnet.
Decide if the management channel needs to be open at all times.
Keep clocks on hosts and network devices in sync.
Record changes and archive configurations.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-28

The following are out-of-band secure management guidelines for the architecture:
Should provide the highest level of security. It should mitigate the risk of passing insecure
management protocols over the production network.
Should keep clocks on hosts and network devices in sync.
Should record changes and archive configurations.
The following are in-band secure management guidelines:
Decide if the device really needs to be managed or monitored.
Use IPSec when possible.
Use SSH or SSL instead of Telnet.
Decide if the management channel needs to be open at all times.
Keep clocks on hosts and network devices in sync.
Record changes and archive configurations.
Even though out-of-band management is recommended for devices in SAFE Enterprise, SAFE
SMR recommends in-band management because the goal is cost-effective security deployment.
In the SAFE SMR architecture, management traffic flows in-band in all cases, and is made as
secure as possible using tunneling protocols and secure variants to insecure management
3-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

protocols (for example, Secure Shell Protocol [SSH] is used whenever possible instead of
Telnet). With management traffic flowing in-band across the production network, it becomes
very important to follow more closely the axioms mentioned earlier in the chapter.
To ensure that log messages are time-synchronized to one another, clocks on hosts and network
devices must be in sync. For devices that support it, Network Time Protocol (NTP) provides a
way to ensure that accurate time is kept on all devices. When dealing with attacks, seconds
matter because it is important to identify the order in which a specified attack occurred.
NTP is used to synchronize the clocks of various devices across a network. Synchronization of
the clocks within a network is critical for digital certificates, and for correct interpretation of
events within Syslog data. A secure method of providing clocking for the network is for the
network administrator to implement their own master clock. The private network should then be
synchronized to Coordinated Universal Time (UTC) via satellite or radio. However, clock
sources are available which synchronize via the Internet if the network administrator does not
wish to implement their own master clock because of costs or other reasons.
An attacker could attempt a DoS attack on a network by sending bogus NTP data across the
Internet in an attempt to change the clocks on network devices in such a manner that digital
certificates are considered invalid. Further, an attacker could attempt to confuse a network
administrator during an attack by disrupting the clocks on network devices. This scenario would
make it difficult for the network administrator to determine the order of Syslog events on
multiple devices.
Version 3 and above of NTP supports a cryptographic authentication mechanism between peers.
The use of the authentication mechanism, as well as ACLs that specify which network devices
are allowed to synchronize with other network devices, is recommended to help mitigate against
such a scenario.
The network administrator should weigh the cost benefits of pulling the clock from the Internet,
with the possible risk of doing so and allowing it through the firewall. Many NTP servers on the
Internet do not require any authentication of peers. Therefore, the network administrator must
trust that the clock itself is reliable, valid, and secure. NTP uses UDP port 123.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-29

Secure Management and Reporting

Logging and reading information from many
devices can be very challenging. The following
issues must be considered:

Identify which logs are most important.

Separate important messages from notifications.
Ensure that logs are not tampered with in transit.
Ensure that time stamps match each other when multiple
devices report the same alarm.
Identify what information is needed if log data is required
for a criminal investigation.
Identify how to deal with the volume of messages that
can be generated when a system is under attack.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.13-29

Logging and reading information from many devices can be very challenging. The following
issues must be considered:
Identify which logs are most important.
Separate important messages from notifications.
Ensure that logs are not tampered with in transit.
Ensure that time stamps match each other when multiple devices report the same alarm.
Identify what information is needed if log data is required for a criminal investigation.
Identify how to deal with the volume of messages that can be generated when a system is
under attack.
Each of these issues are company-specific and require the input of management as well as the
network and security teams to identify the priorities of reporting and monitoring. The
implemented security policy should also play a large role in answering these questions.
From a reporting standpoint, most networking devices can send Syslog data that can be
invaluable when troubleshooting network problems or security threats. You can send this data to
your Syslog analysis host from any devices whose logs you wish to view. This data can be
viewed in real-time or via on-demand, and in scheduled reports. Depending on the device
involved, you can choose various logging levels to ensure that the correct amount of data is sent
to the logging device. You also need to flag device log data within the analysis software to
permit granular viewing and reporting. For example, during an attack the log data provided by
Layer 2 switches might not be as interesting as the data provided by the IDS.
3-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

To ensure that log messages are time-synchronized to one another, clocks on hosts and network
devices must be in sync. For devices that support it, NTP provides a way to ensure that accurate
time is kept on all devices. When dealing with attacks, seconds matter because it is important to
identify the order in which a specified attack occurred.
Configuration change management is another issue related to secure management. When a
network is under attack, it is important to know the state of critical network devices and when
the last known modifications occurred. Creating a plan for change management should be a part
of your comprehensive security policy, but, at a minimum, you should record changes using
authentication systems on the devices, and archive configurations via FTP or TFTP.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-31

Summary
This section summarizes the information you learned in this chapter.

Summary
SAFE SMR is a design philosophy for
implementing security on a network.
SAFE SMR serves as a guide to network
designers considering the security requirements
of their network.
Routers, switches, hosts, networks, and
applications are targets identified in SAFE SMR.
Each target identified in SAFE SMR should be
hardened using the guidelines provided.

2003, Cisco Systems, Inc. All rights reserved.

3-32

Cisco SAFE Implementation 1.1

CSI 1.13-31

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

Overview
This chapter introduces and gives an overview of a Cisco security portfolio. It includes the
following topics:
Objectives
Cisco security portfolio overview
Secure connectivityVirtual Private Network solutions
Secure connectivityThe 3000 Concentrator series
Secure connectivityCisco VPN-optimized routers
Perimeter security firewallsCisco PIX Firewall and Cisco IOS Firewall
Intrusion protectionIDS
IdentityAccess control solutions
Security managementVMS and CSPM
Cisco AVVID
Summary

Objectives
This section lists the chapters objectives.

Objectives
Upon completion of this chapter, you will
be able to perform the following tasks:
List the devices that are part of the Cisco
security portfolio.
Understand the basic guidelines to use for
product selection.
Be aware of the Cisco AVVID program.

2003, Cisco Systems, Inc. All rights reserved.

4-2

Cisco SAFE Implementation 1.1

CSI 1.14-2

Copyright

2003, Cisco Systems, Inc.

Cisco Security Portfolio Overview

Successfully using network technologies requires an increased need to protect valuable data and
network resources from corruption and intrusion. The Cisco security solutions provide the
services necessary to achieve this. This section covers the security solutions that Cisco offers.

Cisco Security Solutions

Secure
connectivity

VPN
Cisco VPN
Concentrators

Perimeter
security

Intrusion
protection

Identity

Firewalls

Intrusion
detection
scanning

Authentication

Cisco PIX
Firewalls

Cisco PIX
Firewalls
Cisco IOS
VPN

Cisco IDS
Sensors
network-, host-,
and switch-based

Cisco Access
Control Server

Cisco PIX
Firewalls

Cisco IOS
Firewall

Cisco IOS
IDS

2003, Cisco Systems, Inc. All rights reserved.

Security
management

Policy
CiscoWorks
VPN and
security
management
solution
Cisco Secure
Policy Manager

CSI 1.14-4

Cisco offers a wide variety of security solutions:

Secure connectivityVirtual private network (VPN)

Cisco VPN Concentrators

Cisco PIX Firewalls

Cisco IOS VPN

Perimeter securityFirewalls

PIX Firewalls

Cisco IOS Firewalls

Intrusion protectionIntrusion detection scanning

Copyright

Cisco Network-based Intrusion Detection System (NIDS) Sensor

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-3

Cisco IOS-based intrusion detection

Cisco Intrusion Detection System Module (IDSM)

PIX Firewall-based intrusion detection

IdentityAuthenticationCisco Secure Access Control Server (ACS)

Security managementPolicy

CiscoWorks2000 VPN/Security Management Solution (VMS)

Cisco Secure Policy Manager (CSPM)

Cisco offers a wide variety of value-added benefits:

Breadth of solutionsCisco offers the widest range of security and VPN products available
in the market today. These products span multiple technology categoriesincluding
firewalls, intrusion detection systems, Concentrators, and routersand are scaled to meet
your business needs from enterprise gateways to remote-office connections that permit you
to deploy customized network security solutions from a single partner.
Industry leadership and recognitionThe PIX Firewall family has gained worldwide market
leadership, according to the IDC analyst group. The Cisco IDS is the market leader,
according to Frost & Sullivan. Cisco access control lists (ACLs) represent the most widely
deployed security technology in the world. In addition, the Cisco VPN 3060 Concentrator
was named Hardware Product of the Year by Network Computing magazine.
Non-stop technical supportCisco security and VPN products receive the same legendary
technical support as other Cisco networking gear, permitting users to gain assistance day or
night. Few other security or VPN companies are large enough to provide such critical, fulltime assistance. Cisco support and service also includes the tools, expertise, and resources
needed to quickly install, maintain, and enhance Cisco security and VPN products to protect
the business network as effectively as possible.
Unsurpassed interoperabilityInstead of deploying a patchwork of different security
technologies from different vendors promising interoperability, Cisco provides you with the
confidence that all its Cisco security and VPN products have been thoroughly tested for
compatibility. In addition, the Security Associate program provides a formal, third-party
testing ground for other vendors to prove their interoperability with Cisco products, as
opposed to making you rely on ambiguous marketing claims.
Unsurpassed integrationCisco owns and controls the industry and has, therefore, built its
security into the router infrastructure, which is the very foundation of the Cisco network. No
other vendor has such a unique perspective and ability to provide you security at the core of
the network.
4-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Management prowessCisco provides a reliable, available, and proven foundation for

managing your networks efficiently and cost effectively.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-5

SAFE Blueprint and Ecosystem

Secure
e-commerce

Secure supply chain

management

Solutions
Secure intranet for
workforce optimization

Ecosystem

Integration partners
Security Associate solutions
Cisco programs and services

Directory
2003, Cisco Systems, Inc. All rights reserved.

Service control
Infrastructure
Appliances or clients

Operations

Applications

Cisco AVVID
system
architecture
CSI 1.14-5

Cisco has opened its Cisco Architecture for Voice, Video, and Integrated Data (AVVID)
architecture and SAFE Blueprint to key third-party vendors to create a security solutions
ecosystem to spur development of best-in-class multiservice applications and products. The
Cisco AVVID architecture and SAFE Blueprint provide interoperability for third-party hardware
and software using standards-based media interfaces, application-programming interfaces
(APIs), and protocols. This ecosystem is offered through the Security and VPN Associate
Program, an interoperability solutions program that provides Cisco customers with tested and
certified, complementary products for securing their businesses. The ecosystem enables
businesses to design and roll out secure networks that best fit their business model and enable
maximum agility.

4-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure ConnectivityVirtual Private Network

Solutions
Cisco has developed and acquired products and solutions that are optimized for secure
connectivity. This section describes these products and solutions, and the security they provide.

Secure Connectivity

Secure Connectivity provides the

following:
Data privacy, encryption, and VPN
Extends network reach
Cost-effective, high-bandwidth
connectivity

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-7

Secure connectivity provides the following:

Data privacy, encryption, and VPN

Provides security over untrusted public networks

Provides enhanced transport security for private networks

Extended network reach

Teleworkers

New or small sites

Partner connectivity

Cost-effective, high-bandwidth connectivity

Copyright

Reduces transport costs

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-7

4-8

Enables fast broadband telecommuters and remote site connectivity

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

OverviewVPNs
Home office
Intranet VPNLow
cost, tunneled
connections with
rich VPN services,
which lead to cost
savings and new
applications

Remote office
POP

Main
office

VPN
POP
Extranet VPN
Extends WANs to
business partners,
which leads to new
applications and
business models

Remote access
VPNCost saving

Business partner
Mobile worker

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-8

VPN solutions are provided for the following types of implementation:

Intranet VPNLinks corporate headquarters to remote offices over a shared, prioritized
network, and offers an extremely cost-effective alternative to dedicated WANs. Intranet
VPNs need to scale easily as the organization grows.
Extranet VPNLinks network resources with third-party vendors and business partners,
extending elements of the corporate intranet beyond the organization. To keep pace with
rapidly changing business climates, extranet VPN access needs to be able to be turned on
and off on the fly.
Remote access VPNConnects telecommuters and mobile users securely and costeffectively to corporate network resources from anywhere in the world over any access
technology. Because this traffic may run on un-trusted segments outside the service
providers network, it must be encrypted to ensure privacy and security.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-9

VPN SolutionsChoices
Remote access

Site-to-site

Firewall-based

Large enterprise, SP

3060, 3080
Concentrators

7200 and higher

series routers

PIX Firewall 525,

535

Medium enterprise

3030
Concentrator

7100, 3600 series

routers

PIX Firewall 515

Small
business/branch
office
SOHO market

3015, 3005
Concentrator

3600, 2600, 1700

series routers

PIX Firewall 515,

506

VPN 3000 Client

3002 Hardware
Client

SOHO, 800, 900

series routers

PIX Firewall 506,

501

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-9

Cisco provides VPN solutions for all network sizes. The information in the figure indicates the
platforms that can support each size network most effectively. You can use this information as a
starting point to choose what device best fits your environment.

4-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure ConnectivityThe 3000 Concentrator

Series
The Cisco Virtual Private Network (VPN) 3000 Series Concentrator is a family of purpose-built,
remote access VPN platforms and client software that incorporates high availability, high
performance and scalability with the most advanced encryption and authentication techniques
available today.

Cisco VPN 3000 Concentrator Series

The following are the Cisco VPN 3000
Concentrator Series features and uses:

Primarily used for remote access

Includes a standards-based VPN Client and management
GUI
Allows mobile workers and telecommuters broadband
connectivity over cable and DSL
Uses RADIUS for authentication
Performs split tunnelingcorporate and Internet
Implements behind the Internet access router and is
parallel to the PIX Firewall

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-11

The following are the features and uses for the Cisco VPN 3000 Concentrator Series:
Primarily used for remote access
Includes a standards-based VPN Client and management GUI
Allows mobile workers and telecommuters broadband connectivity over cable and DSL
Uses Remote Access Dial-In User Service (RADIUS) for authentication
Split tunnelingcorporate and Internet
Implements behind the Internet access router and is parallel to the PIX Firewall
With the Cisco VPN 3000 Series Concentrator, customers can take advantage of the latest VPN
technology to vastly reduce their communications expenditures. It is the only scalable platform
to offer field-swappable and customer-upgradeable components. These components, called
Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-11

Scalable Encryption Processing (SEP) modules, enable users to easily add capacity and
throughput.

4-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Models

Simultaneous users
Performance (Mbps)
Encrytpion cards
Memory (Mb)
Upgradable
Dual power supply
Redundancy
Site-to-site tunnels

2003, Cisco Systems, Inc. All rights reserved.

3005
100
4
0
64
No
No
No
100

3015
100
4
0
128
Yes
Optional
Yes
100

3030
1500
50
1
128
Yes
Optional
Yes
500

3060
5000
100
2
256
Yes
Optional
Yes
1,000

3080
10,000
100
4
256
N/A
Yes
Yes
1,000

CSI 1.14-12

The Cisco VPN 3000 Series Concentrator includes models to support a range of enterprise
customers, from small businesses with 100 or fewer remote access users, to large organizations
with up to 10,000 simultaneous remote users. The Cisco VPN Client is provided with all
versions of the Cisco VPN 3000 Series Concentrator, and includes unlimited distribution
licensing. The Cisco VPN 3000 Series Concentrator is available in both non-redundant and
redundant configurations. The table in the figure can assist an engineer in choosing the most
scaleable, cost effective, and redundant solution for their network.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-13

The Cisco Unified Client Framework

Connectivity between all clients
and all Cisco central-site VPN
gear
Centralized push policy
technology
Simplifies user experience
Provides more control for
companies
Reduces complexity of VPN
deployments
Implemented across all Cisco
VPN Concentrators, IOS Routers,
and PIX Firewalls
Includes non-Windows
operating systems (Linux,
Mac, and Solaris)
Substantial savings
Reduced support expense
Consolidated hardware
Reduced administration in the
central site at the central site
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-13

The Cisco unified VPN Client strategy is a new framework with a specification to enable VPN
connectivity between all desktop, laptop, and personal digital assistant clients and the full range
of Cisco VPN-enabled Concentrators, routers, and firewalls. Using push policy capabilities,
the unified VPN Client framework allows customers to centrally manage security policies, while
easily delivering large-scale VPN connectivity to remote users. All of the Cisco IPSec-based
VPN products for the enterprise and service providers support the unified VPN Client
framework.

4-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco VPN 3002 Hardware VPN Client

Cisco VPN Client

Single user

3002

Cable modem
Home office
3002

DSL modem
Small office

Internet

Cisco VPN 30xx

Easy deployment
Centralized policy push

3002

ISDN modem

Two 10/100, and 8-port hub version

DHCP client and server
PAT (external and tunnel)
Client and network extension modes

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-14

Based on the unified VPN Client framework, the Cisco VPN 3002 Hardware Client combines
the best features of a software client, including scalability and ease-of-deployment, with the
stability and independence of a hardware platform. The Cisco VPN 3002 Hardware Client works
with all operating systems and does not interfere with the operation of the PC because it is a
separate hardware appliance.
The Cisco VPN 3002 Hardware Client is a small, highly cost-effective appliance. It is ideal for
organizations where thousands of remote end-users might be tunneling into corporate networks
from large numbers of geographically dispersed branch or home office sites.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-15

Remote Access Wireless VPN

Main office
Cisco VPN 30xx

Internet

Mobile
Certicom
client

Aironet client
Cisco VPN 3000 Client

2003, Cisco Systems, Inc. All rights reserved.

Aironet client
CSI 1.14-15

Remote access wireless VPN solutions are available for the VPN Concentrator via the Cisco
AVVID partner program. With release 3.0, all Cisco VPN 3000 Concentrators support Elliptic
Curve Cryptography or ECC. This is a new Diffie-Hellman (DH) group that allows for much
faster processing of keying information by devices with limited processing power such as
Personal Digital Assistants (PDAs) and Smart Phones. Cisco VPN 3000 Concentrators can now
securely terminate tunnels from IP-enabled wireless devices, allowing a whole new class of users
to securely access enterprise information while preserving the investment in VPN termination
equipment in the enterprise data center.

4-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure ConnectivityCisco VPN-Optimized

Routers
This section describes the solutions provided by Cisco routers for secure connectivity.

Cisco VPN-Optimized Routers

The following are the Cisco VPN-optimized router
features:

Is used for site-to-site VPNs

Includes SOHO, 800 and 7000 series models
Replaces and augments private networks that use
A leased line
Frame relay
ATM
Connects remote, branch office and central sites
Enables customers to avoid exorbitant 800 number costs
as well as modem technology
Implements at the WAN edge

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-17

Site-to-site VPNs are an alternative WAN infrastructure that are used to connect branch offices,
home offices, or business partners sites to all or portions of a companys network. VPNs do not
inherently change private WAN requirements, such as support for multiple protocols, high
reliability, and extensive scalability, but instead meet these requirements more cost-effectively
and with greater flexibility. Site-to-site VPNs use the most pervasive transport technologies
available today, such as the Internet or service providers IP networks, by employing tunneling
and encryption for data privacy and Quality of Service (QoS) for transport reliability.
The following are the Cisco VPN-optimized router features:
Is used for site-to-site VPNs
Includes SOHO, 800 and 7000 series models
Replaces and augments private networks that use

Copyright

A leased line

Frame relay

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-17

ATM

Connects remote, branch office, and central sites

Enables customers to avoid exorbitant 800 number costs as well as modem technology
Implements at the WAN edge

4-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Site-to-Site VPN Scalability

and Features Summary

Scalability
Network resiliency
Bandwidth optimization and QoS
Deployment flexibility

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-18

Cisco VPN-optimized routers include high-performance, hardware-based IPSec encryption,

multiple WAN interfaces, and the entire Cisco IOS Software feature set. Using Cisco IOS
Software, Cisco VPN Routers also provide a comprehensive feature set to meet the most diverse
networking requirements, including support for routing, multiprotocol, and multicast across the
VPN, as well as enhanced features like firewall capabilities and QoS.
The following are Site-to-Site VPN scalability and features summary for Cisco VPN optimized
routers:
ScalabilityUp to 140 Mbps of 3DES throughput and 3000 tunnels
Network resiliency

Dynamic Route RecoveryUsing routing protocols through IPSec-secured GRE tunnels

Dynamic Tunnel RecoveryUsing IPSec (IKE) keepalives

Bandwidth optimization and QoS

Application-aware bandwidth allocation, queuing, policing, and traffic shaping

Ensures quality of latency-sensitive traffic

Deployment flexibility

Copyright

Interface flexibility for combined WAN+VPN or behind-edge VPN

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-19

4-20

Use as standalone VPN device or integrated multi-function device

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco Site-to-Site VPN Solutions

Scalability for Every Site
Cisco 1700 Series

VPN-optimized
router connecting
remote offices at
T1/E1 speeds

Remote
office

Cisco 7000 Series

VPN-optimized routers for

dedicated VPN head-end and
hybrid private WAN and VPN
connectivity

Main office
Regional
office

Internet

Cisco 2600 and 3600

Series

VPN-optimized routers
connecting branch
and regional offices at
nxT1/E1 speeds

2003, Cisco Systems, Inc. All rights reserved.

Cisco SOHO, 800 and 900

Series
Small office/
home office

VPN-optimized routers for

ISDN, DSL, and cable
connectivity
CSI 1.14-19

Site-to-Site VPNs are best constructed using a wide variety of Cisco VPN Routers. VPN Routers
provide scalability through optional encryption acceleration. The Cisco VPN Router portfolio
provides solution for small office/home office (SOHO) access through central-site VPN
aggregation, including platforms for fast-emerging cable and digital subscriber line (DSL) access
technologies.
The following provides recommendations for scalability for Site-to-Site VPN solutions:
Remote officeCisco 1700 Series, which is a VPN-optimized router connecting remote
offices at T1/E1 speeds
Regional officeCisco 2600 and 3600 Series, which are VPN-optimized routers connecting
branch and regional offices at nxT1/E1 speeds
Small Office/Home Office (SOHO)Cisco 800 and 900 Series, which are VPN-optimized
routers for ISDN, DSL, and cable connectivity
Main OfficeCisco 7000 Series, dedicated VPN head-end and hybrid private WAN and
VPN connectivity

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-21

VAMFor Cisco 7100,7200 and 7400

Series Routers
Hardware acceleration for
IPsec encryptionUp to 145 Mbps of VPN
performance and 5000 tunnels
RSAFaster tunnel-recovery key generation
and authentication
IPPCP LZS compression

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-20

The VPN Acceleration Module (VAM) is a single-width acceleration module. It provides highperformance, hardware-assisted tunneling and encryption services suitable for VPN remote
access, site-to-site intranet, and extranet applications. It also provides platform scalability and
security while working with all services necessary for successful VPN deploymentssecurity,
QoS, firewall and intrusion detection, service-level validation, and management. The VAM offloads IPSec processing from the main processor, thus freeing resources on the processor engines
for other tasks.

4-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Perimeter Security FirewallsCisco PIX Firewall

and Cisco IOS Firewall
This section describes the Cisco perimeter security solutions.

Perimeter SecurityPIX Firewall

The following are the PIX Firewall
features and uses:
Typically used for site-to-site VPNs
Limited IDS
Dedicated hardware appliance
Restricts access to network resources
Implemented at the physical perimeter
between customer Intranet and the
other companys Intranet
Determines whether traffic crossing in
either direction is authorized
Little or no impact on network
performance
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-22

Globally networked businesses rely on their networks to communicate with employees,

customers, partners, and suppliers. While immediate access to information and communication is
an advantage, it raises concerns about security-protecting access to critical network resources.
Network administrators need to know who is accessing what resources and establish clear
perimeters to control that access. An effective security policy balances accessibility with
protection. Security policies are enforced at network perimeters. Often people think of a
perimeter as the boundary between an internal network and the Internet, but a perimeter can be
established anywhere within a private network, or between your network and a partners
network. A solid perimeter security solution enables communications across it as defined by the
security policy, yet protects network resources from breaches or attacks. It controls multiple
network entry and exit points. It also increases user assurance by implementing multiple layers
of security.
The following are the PIX Firewall features and uses:
Typically used for site-to-site VPNs
Limited IDS
Dedicated hardware appliance
Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-23

Restricts access to network resources

Implemented at the physical perimeter between customer intranet and the other companys
intranet
Determines whether traffic crossing in either direction is authorized
Little or no impact on network performance

4-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PIX Firewall Family

Price

PIX 535-UR

PIX 525-UR
PIX 515E-UR

PIX 506E

Gigabit Ethernet

PIX 501

SOHO

ROBO

SMB

Enterprise

SP

Functionality
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-23

The Cisco PIX Firewall series delivers strong security in an easy-to-install, integrated hardware
and software firewall appliance that offers outstanding performance. The PIX Firewall family
spans the entire user application spectrum, from compact, plug-and-play desktop firewalls for
small and home offices to carrier-class gigabit firewalls for the most demanding enterprise and
service provider environments. PIX Firewalls deliver superior performance of up to 500,000
simultaneous connections and nearly 1.7 Gbps aggregate throughput.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-25

VAC
The VAC uses
Large enterprise and
complex, high-traffic
environments
100 Mbps pf 3DES and
SHA
The VAC requires
Version 5.3 or higher
A PIX Firewall 515, 520,
525, or 535 (available as a
PCI slot)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-24

The VPN Accelerator Card (VAC) for the PIX Firewall series provides high-performance,
tunneling and encryption services suitable for site-to-site and remote access applications. This
hardware-based VPN accelerator is optimized to handle the repetitive but voluminous
mathematical functions required for IPSec. Offloading encryption functions to the card not only
improves IPSec encryption processing, but also maintains high-end firewall performance. As an
integral component of the Cisco virtual VPN solution, the VAC provides platform scalability
and security while working seamlessly with services necessary for successful VPN
deploymentsencryption, tunneling, and firewall.
The VAC, which fits in a PCI slot inside the PIX Firewall chassis, encrypts data using the 56-bit
Data Encryption Standard (DES) or 168-bit Triple-Data Encryption Standard (3DES) algorithms
at speeds up to 100 Mbps. A PIX Firewall equipped with a VAC supports as many as 2,000
encrypted tunnels for concurrent sessions with mobile users or other sites. In addition to
encryption, the card handles a variety of other IPSec-related taskshashing, key exchange, and
storage of security associationsthat free the PIX Firewall main processor and memory to
perform other perimeter security functions. The following are features of the VAC:
EncryptionDES and 3DES encryption are very CPU-intensive, potentially impacting
firewall performance in high-throughput configurations. The VAC makes it possible to send
DES- or 3DES-encrypted data at high speed while still providing the full range of perimeter
security services available from the PIX Firewall.
AuthenticationRivest, Shamir, and Adleman (RSA) and Diffie-Hellman are CPU-intensive
protocols that are used when a new IPSec tunnel is established. RSA authenticates the
remote device while DH exchanges keys that will be used for DES or 3DES encryption. The
VAC implements these protocols in specialized hardware ensuring fast tunnel setup and high
overall encryption throughput.
4-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

TunnelingThe PIX Firewall and VAC support IPSec tunneling protocols, which enables
high-performance and flexible network designs for both remote access and site-to-site VPNs.
Site-to-site solutions can be designed with the PIX Firewall, or combinations of PIX
Firewalls with Cisco VPN appliances or VPN-enabled multi-service routers. Remote access
solutions can use the Cisco VPN Client or other third-party clients supporting the IPSec
tunneling protocol.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-27

Perimeter SecurityIOS Firewall

The following are the IOS
Firewall features and uses:

Integrated software solution

Limited IDS
Add on module to Cisco IOS
software
Cost effective
Highly scalable
Home office to enterprise
Intranet protection
Familiar Cisco IOS
configuration
CBAC
Proxy

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-25

As network security becomes increasingly critical to securing business transactions, businesses

must integrate security into the network design and infrastructure. Security policy enforcement is
most effective when it is an inherent component of the network.
Cisco IOS Software runs on more than 80 percent of Internet backbone routers, making it the
most fundamental component of todays network infrastructure. Cisco IOS Software-based
security offers the best solution for end-to-end Internet, intranet, and remote access network
security.
The Cisco IOS Firewall is a security-specific option for Cisco IOS Software. It integrates robust
firewall functionality and intrusion detection for every network perimeter and enriches existing
Cisco IOS security capabilities. It adds greater depth and flexibility to existing Cisco IOS
security solutionssuch as authentication, encryption, and failoverby delivering state-of-theart security features, such as stateful, application-based filtering; dynamic per-user
authentication and authorization; defense against network attacks; Java blocking; and real-time
alerts. When combined with Cisco IOS IPSec software and other Cisco IOS software-based
technologies, such as Layer 2 Tunneling Protocol (L2TP) and QoS, the Cisco IOS Firewall
provides a complete, integrated VPN solution.

4-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS FirewallCBAC
The following are the
CBAC features:
Stateful inspection

The user Initiates

an IP session.

User

A state table maintains

session state
information
ACL entries are
dynamically created
and deleted

2003, Cisco Systems, Inc. All rights reserved.

The return traffic for the users

IP session is permitted.
The other IP
traffic is blocked.

IOS Firewall
using CBAC

CSI 1.14-26

Context-based access control (CBAC) intelligently filters TCP and UDP packets based on
application-layer protocol session information, and can be used for intranets, extranets, and the
Internet. You can configure CBAC to permit specified TCP and UDP traffic through a firewall
only when the connection is initiated from within the network you want to protect (that is,
CBAC can inspect traffic for sessions that originate from the external network). However, while
this example discusses inspecting traffic for sessions that originate from the external network,
CBAC can inspect traffic for sessions that originate from either side of the firewall.
Without CBAC, traffic filtering is limited to access control list (ACL) implementations that
examine packets at the network layer, or at most, the transport layer. However, CBAC examines
not only network layer and transport layer information, but also examines the application-layer
protocol information (such as FTP connection information) to learn about the state of the TCP or
UDP session. This allows support of protocols that involve multiple channels created as a result
of negotiations in the control channel. Most of the multimedia protocols as well as some other
protocols (such as FTP, Remote Procedure Call [RPC], and SQL*Net) involve multiple
channels.
CBAC inspects traffic that travels through the firewall to discover and manage state information
for TCP and UDP sessions. This state information is used to create temporary openings in the
firewalls ACLs to allow return traffic and additional data connections for permissible sessions
(sessions that originated from within the protected internal network).
CBAC also provides the following benefits:
Java blocking
DoS prevention and detection

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-29

Real-time alerts and audit trails

4-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Intrusion ProtectionIDS
This section provides an overview and product information for the Cisco Intrusion Detection
System (IDS).

OverviewIntrusion Detection
Deployment Scenarios
Business
partner

Extranet IDS
Monitors partner
traffic where
trust is implied
but not assured

Intranet and Internal

IDSProtects data
centers and critical
assets from internal
threats

Users

Corporate
office

Data
center

NAS

Internet IDS
Complements the
firewall and VPN by
monitoring traffic for
malicious activity

Internet

Remote access IDS

Hardens perimeter
control by monitoring
remote users

DMZ
servers

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-28

The Cisco IDS is an enterprise-class, network-based intrusion detection system. Designed to

address the increased requirements for security visibility, denial-of-service (DoS) protection,
antihacking detection, and e-commerce business defenses, the Cisco IDS family leads the market
in innovative security monitoring solutions. Sensor devices detect unauthorized activity
traversing the network, such as attacks by hackers, by analyzing traffic in real time, enabling
users to quickly respond to security breaches. When unauthorized activity is detected, Cisco IDS
Sensors can send alarms to a management console with details of the activity, and can control
other systems, such as routers, to terminate the unauthorized sessions.
There are four recommended deployment scenarios:
Extranet IDSIDS deployment to an extended network
Internet IDSIDS deployment to a public network
Intranet and internal IDSIDS deployment to an internal network
Remote access IDSIDS deployment to a remote-access network

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-31

Cisco IDS SolutionsMultiple

Platform Integration
Network SensorsOverlays
network protection
Switch SensorProvides
integrated switch protection
Router SensorProvides
integrated router protection
Firewall SensorProvides
integrated firewall protection
Comprehensive management
Provides robust system
management and monitoring

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.14-29

Cisco IDS solutions include the following:

NIDSThe complete line of market-leading Cisco IDS 4200 Series appliances deliver
performance-optimized intrusion protection within an integrated, turnkey solution.
IDSMThe award-winning Catalyst 6500 IDS Module (IDSM) is designed to protect
switched environments by integrating full-featured IDS functionality directly into the
network infrastructure allowing the user to monitor traffic directly off the switch backplane.
IOS IDSCisco IOS Routers deliver integrated intrusion protection along with feature-rich
networking services.
Firewall IDSIntegration of IDS functionality into the Cisco PIX 500 Series Firewalls
provide protection from a variety of common network-based attacks.
Comprehensive managementCisco offers a broad set of comprehensive, enterprise-class
security management and monitoring options for Cisco IDS, which meets any deployment
scale and requirements.

4-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Cisco IDSs provide the following:

Real-time security monitoringInvolves packet capture and analysis.
Most effective attack recognition, which is signature-basedWhen the Cisco IDS analyzes
network data, it looks for patterns of misuse. Patterns can be as simple as an attempt to
access a specific port on a specific host, or as complex as sequences of operations distributed
across multiple hosts over an arbitrary period of time. The first type of pattern is termed an
atomic pattern; the second, a composite pattern.
Blocking and shunningThe Cisco IDS uses a network device to deny entry to a specific
network host or an entire network. To implement shunning, the Sensor dynamically
reconfigures and reloads a network devices ACLs. This type of automated response by the
Sensor should only be configured for attack signatures with a low probability of falsepositive detection, such as an unambiguous SATAN attack.
Scalability and remotely manageableThe Cisco IDS solutions provide a robust solution
that is scalable to even the largest enterprise networks.
High performanceDepending on the needs of a network, the Cisco IDS portfolio is
designed provide above-industry standard performance for each platform, whether it be hostbased or network-based.
Low cost of operationDelivering the lowest cost-of-ownership with network-integrated
and hardware-based solutions, Cisco reduces the cost of advanced intrusion protection.
Ease of installation and useBecause of the management platforms and menu-based
configuration tools, the Cisco IDS is easily configured and maintained.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-33

Error! Not a valid link.

The following are the Cisco IDS appliance features and uses:
System flexibility and deployment enhancements focus
Signature definition and distribution enhancements
An active update mechanism
Comprehensive signature language
Alarm summarization
Active response extensions
Shunning with the PIX Firewall
Shunning with Catalyst switches
Secure administration
Enhanced filtering
The complete line of market-leading Cisco IDS 4200 Series appliances delivers performanceoptimized intrusion protection within an integrated, turn-key solution.

4-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

The Cisco IDS 4200 Series Sensors are purpose-built, high-performance network security
appliances that protect against unauthorized, malicious activity traversing the network (for
example, attacks by hackers). Cisco IDS Sensors analyze traffic in real time, enabling users to
quickly respond to security breaches.
The IDSM is a switching module that is easy to install and maintain in the Catalyst 6000 family
switch. The IDSM performs network sensingreal-time monitoring of network packets through
packet capture and analysis. The IDSM captures network packets and then reassembles and
compares this data against a rule set indicating typical intrusion activity. Network traffic is either
copied to the IDSM based on security VLAN access control lists (VACLs) in the switch or is
routed to the IDSM via the switchs Switched Port Analyzer (SPAN) port feature. Both methods
allow user-specified kinds of traffic based on switch ports, VLANs, or traffic type to be
inspected. The figure provides a feature overview of the IDS appliances.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-35

IdentityAccess Control Solutions

This section describes the available Cisco access control solutions.

Cisco Secure ACSFeatures

The following are the Cisco
Secure ACS features and uses:

Key component used with

firewall, dial-up access servers,
and routers
Implement at network access
points to authenticate remote or
dial-in users
Implement at WAN extranet
connections to audit activities
and control authentication and
authorization for business
partner connections

1 2 3
4 5 6
7 8 9
0

2003, Cisco Systems, Inc. All rights reserved.

1 2 3
4 5 6
7 8 9
0

CSI 1.14-34

The features and uses of the Cisco Secure Access Control Server (ACS) are as follows:
Key component used with firewall, dial-up access servers, and routers.
Implement at network access points to authenticate remote or dial-in users.
Implement at WAN extranet connections to audit activities and control authentication and
authorization for business partner connections.
You can leverage the same Cisco Secure ACS access framework to control administrator access
and configuration for all network devices in your network that are enabled by RADIUS and
Terminal Access Controller Access Control System Plus (TACACS+). Advanced features of the
Cisco Secure ACS include the following:
Automatic service monitoring
Database synchronization and importation of tools for large-scale deployments
Lightweight Directory Access Protocol (LDAP) user authentication support
User and administrative access reporting

4-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Restrictions such as time of day and day of week

User and device group profiles

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-37

Error! Not a valid link.

Cisco Secure Access Control Server (ACS) features include the following:
Easy-to-use GUI
Full RADIUS and TACACS+ user and administrator access control
High performance (500+ authorizations per second)
Supports LDAP, Novell Directory Services (NDS), Open Database Connectivity (ODBC)
datastores
Scalable data replication and redundancy services
Full accounting and user reporting features

4-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

The Cisco Secure ACS is a high-performance, highly scalable, centralized user access control
framework. Cisco Secure ACS offers centralized command and control for all user
authentication, authorization, and accounting activities. Cisco Secure ACS also distributes those
controls to hundreds or thousands of access gateways in your network. Authentication verifies
user identity. Authorization configures integrity, such as user access rights. Accounting assists
with auditing by logging user activities.
With Cisco Secure ACS you can manage and administer user access for the following:
Cisco IOS Routers
VPNs
Firewalls, and dial and broadband DSL
Cable access solutions
Voice over IP (VoIP)
Cisco wireless solutions
Cisco Catalyst switches via IEEE 802.1x access control
Network devices enabled by TACACS+
Network devices enabled by RADIUS
The authentication methods employed are:
Static passwords
One time passwords
RADIUS
TACACS+

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-39

Security ManagementVMS and CSPM

This section describes the Cisco security management solutions.
Error! Not a valid link.

The goal of security management is to control access to network resources according to local
guidelines so that the network cannot be sabotaged (intentionally or unintentionally) and so that
sensitive information cannot be accessed by those without appropriate authorization. A security
management subsystem, for example, can monitor users logging on to a network resource and
can refuse access to those who enter inappropriate access codes.
Security management subsystems work by partitioning network resources into authorized and
unauthorized areas. For some users, access to any network resource is inappropriate, mostly
because such users are usually company outsiders. For other (internal) network users, access to
information originating from a particular department is inappropriate. Access to Human
Resource files, for example, is inappropriate for most users outside the Human Resources
department.
Security management subsystems perform several functions. They identify sensitive network
resources (including systems, files, and other entities), and determine mappings between
sensitive network resources and user sets. They also monitor access points to sensitive network
resources and log inappropriate access to sensitive network resources.

4-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

CSPM is a scalable, powerful, policy-based security management system for Cisco firewalls,
IPSec VPN routers, and Sensors. With CSPM, Cisco customers can define, distribute, enforce,
and audit network-wide security policies from a central location. CSPM streamlines the tasks of
managing complicated network security elements, such as perimeter access control, IDSs,
Network Address Translation (NAT)- and IPSec-based VPNs. As the management cornerstone
of the Cisco end-to-end security product line, CSPM can dramatically simplify firewall, IDS,
and VPN deployment in enterprise and service provider networks.
The CSPM GUI enables administrators to visually define high-level security policies for
multiple Cisco firewalls and VPN routers. These policies can be distributed throughout the
network from a central location, thus completely eliminating the costly, time-consuming practice
of manually implementing security configurations on a command-by-command and device-bydevice basis. CSPM also provides basic system auditing functions, including real-time alarm
notification and a Web-based reporting system.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-41

Error! Not a valid link.

CiscoWorks VPN/Security Management Solution (VMS) is a management solution suite that

provides a comprehensive solution for VPN and security management. CiscoWorks VMS is
made up of a set of Web-based applications for configuring, monitoring, and troubleshooting
enterprise VPNs, firewalls, and network IDSs.
The following are the VMS features and uses:
One stop for configuring, monitoring, and troubleshooting the following:

VPN

Firewall

NIDS

An integrated management solution

Provides web-based management
Features for configuring and monitoring firewall security
Used for large-scale deployments

4-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco AVVID
This section discusses Cisco Architecture for Voice, Video, and Integrated Data (AVVID).
Error! Not a valid link.

The Internet is creating tremendous business opportunities for Cisco and Cisco customers.
Internet business solutions such as e-commerce, supply chain management, e-learning, and
customer care are dramatically increasing productivity and efficiency.
Cisco AVVID is the one enterprise architecture that provides the intelligent network
infrastructure for todays Internet business solutions. As the industrys only enterprise-wide,
standards-based network architecture, Cisco AVVID provides the roadmap for combining
customers business and technology strategies into one cohesive model.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-43

Error! Not a valid link.

Cisco AVVID can be viewed as a framework to describe a network optimized for the support of
Internet business solutions, and as a best practice or roadmap for network implementation. The
following are the different parts of the Cisco AVVID architecture:
Clients
Network platforms
Intelligent network services
Internet middleware layer
Internet business integrators
Internet business solutions

4-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

With Cisco AVVID, customers have a comprehensive roadmap for enabling Internet business
solutions and creating a competitive advantage. There are four Cisco AVVID benefits:
IntegrationBy leveraging the Cisco AVVID architecture and applying the network
intelligence inherent in IP, companies can develop comprehensive tools to improve
productivity.
IntelligenceTraffic prioritization and intelligent networking services maximize network
efficiency for optimized application performance.
InnovationCustomers have the ability to adapt quickly in a changing business
environment.
InteroperabilityStandards-based APIs enable open-integration with third-party developers,
providing customers with choice and flexibility.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-45

Error! Not a valid link.

The Cisco AVVID program changes frequently with new partners and products being introduced
on an ongoing basis. The links in the figure can be used to get the latest information about the
AVVID program and products offered.

4-46

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Summary
This section summarizes the information you learned in this chapter.
Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-47

SAFE Small Network Design

Overview
The following are the sections covered in this chapter.
Objectives
Small network design overview
Small network corporate Internet module
Small network campus module
ImplementationISP router
ImplementationIOS Firewall features and configuration
ImplementationPIX Firewall
Summary
Lab exercise

Objectives
This section lists the chapters objectives.

Objectives
Identify the functions of modules and the key devices in a
small network.
Understand specific threats and mitigation roles of Cisco
devices.
Implement specific configurations to apply mitigation
roles:
Pix Firewall configuration
Configure IOS Firewall features
Recommend alternative devices.

2003, Cisco Systems, Inc. All rights reserved.

5-2

Cisco SAFE Implementation 1.1

CSI 1.15-2

Copyright

2003, Cisco Systems, Inc.

Small Network Design Overview

This section provides an overview of the SAFE: Extending the Security Blueprint to Small,
Midsize, and Remote-User Networks (SAFE SMR) small network design.

SAFE Design for Small Networks

SP edge

Small network or branch edge

Corporate Internet module

ISP

Isolated service
network

Small network
or branch campus
Campus module
Management
Server

Public
services

Firewall

2003, Cisco Systems, Inc. All rights reserved.

Corporate
users
Corporate
servers

CSI 1.15-4

The small network design has two modules:

Corporate Internet ModuleHas connections to the Internet and also terminates virtual
private network (VPN) and public services (Domain Name System [DNS], HTTP, File
Transfer Protocol [FTP], Simple Mail Transfer Protocol [SMTP]) traffic.
Campus ModuleContains the Layer 2 switching and all the users, as well as the
management and intranet servers. (Most of the discussion in this chapter for this design is
based on the small network operating as the head-end for a corporation. Specific design
changes when used as a branch are also included.)

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-3

Small Network Corporate Internet Module

This section discusses the Corporate Internet Module.

Small Network Corporate Internet

Module Components and Key Devices
The following are
key devices:
Servers
SMTP
DNS
FTP or HTTP
Firewall or IOS
Firewall router
Layer 2 switch
HIDS

IOS Firewall or
PIX Firewall

Servers

Layer 2
switch

Public
services

ISP

ISP router

To campus

One or the
other
IOS Firewall or
PIX Firewall

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-6

The Corporate Internet Module provides internal users with connectivity to Internet services and
Internet users access to information on public servers. VPN access is also provided to remote
locations and telecommuters. This module is not designed to serve e-commerce type
applications.
The following are key devices in the Corporate Internet Module:
SMTP serverActs as a relay between the Internet and the intranet mail servers.
DNS serverServes as authoritative external DNS server for the small network. It relays
internal requests to the Internet.
FTP or HTTP serverProvides public information about the organization.
Firewall or IOS Firewall routerProvides network-level protection of resources and stateful
filtering of traffic and provides differentiated security for remote access users. It
authenticates trusted remote sites and provides connectivity using IPSec tunnels.
Layer 2 switch (with private VLAN support)Provides Layer 2 connectivity for devices.
HIDS
5-4

Provides host-level intrusion detection.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats
and Mitigation Roles
The following threats can be expected:

Unauthorized accessMitigated through filtering at the

firewall
Application layer attacksMitigated through HIDSs on
the public servers
Virus and Trojan horse attacksMitigated through virus
scanning at the host level
Password attacksLimited services available to brute
force (operating systems and IDSs can detect the threat)
DoSUse CAR at the ISP edge and the TCP setup
controls at the firewall to limit exposure

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-7

There are publicly addressable servers that are the most likely points of attacks. The following
are expected threats to those publicly addressable servers:
Unauthorized accessMitigated through filtering at the firewall
Application layer attacksMitigated through Host-based Intrusion Detection Systems
(HIDSs) on the public servers
Virus and Trojan horse attacksMitigated through virus scanning at the host level
Password attacksLimited services available to brute force (operating systems and IDSs
can detect the threat)
Denial of service (DoS)Use committed access rate (CAR) at the ISP edge and TCP setup
controls at the firewall to limit exposure
From a threat perspective, a small or midsize network is like most networks connected to the
Internet: there are internal users who need access out and external users who need access in.
Several common threats can generate the initial compromise that a hacker needs to further
penetrate the network with secondary exploits.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-5

Expected Threats
and Mitigation Roles (cont.)
IP spoofingRFC 2827 and 1918 filtering at the ISP edge
router and at the firewall in the corporate Internet module
Packet sniffersSwitched infrastructure and an HIDS to
limit exposure
Network reconnaissanceAn HIDS detects recon, and
protocols are filtered to limit effectiveness
Trust exploitationRestrictive trust model and private
VLANs to limit trust-based attacks
Port redirectionRestrictive filtering and an HIDS to limit
attacks

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-8

IP spoofingRFC 2827 and 1918 filtering at the ISP edge and local firewall
Packet sniffersSwitched infrastructure and an HIDS to limit exposure
Network reconnaissanceHIDS detects recon; protocols filtered to limit exposure
Trust exploitationRestrictive trust model and private VLANs to limit
trust-based attacks
Port redirectionRestrictive filtering and an HIDS to limit attacks
Though statistics vary on the percentage, it is an established fact that most attacks come from the
internal network. Disgruntled employees, corporate spies, visiting guests, and inadvertent
bumbling users are all potential sources of such attacks. When designing security, you must be
aware of the potential for internal threats.
There is also the risk of threat to the publicly addressable hosts that are connected to the Internet.
These systems will likely be attacked with application-layer vulnerabilities and DoS attacks.

5-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Small Network Attack Mitigation Roles

for the Corporate Internet Module
Stateful packet
filtering, basic layer
7 filtering, host DoS
mitigation, and
spoof mitigation

HIDS local attack

mitigation

Private VLANs

ISP

Public
services

Spoof mitigation and

rate-limiting

One or the
other

To campus
Stateful packet
filtering, basic layer
7 filtering, host DoS
mitigation, and
spoof mitigation

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-9

The attack mitigation roles for each device in the SAFE SMR Small Network Corporate Internet
Module are as follows:
ISP Router

Spoof mitigation

Rate-limiting

Firewall

Stateful packet filtering

Basic Layer 7 filtering

Host DoS mitigation

Spoof mitigation

Layer 2 switches (with private VLAN support)

Private VLANs

HIDS

Copyright

HIDS local attack

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-7

Mitigation

At the ingress of the firewall, RFC 1918 and RFC 2827 filtering are provided as a verification of
the ISPs filtering. Because of the enormous security threat fragmented packets create, the
firewall is configured to drop most fragmented packets. Any legitimate traffic lost due to
filtering is considered acceptable when compared to the risk of allowing such traffic to traverse
the network. Traffic destined to the firewall from outside the network is limited to IPSec traffic
and necessary routing protocols.
The firewall provides connection-state enforcement and detailed filtering for sessions initiated
through the firewall. From a filtering standpoint, in addition to limiting traffic on the public
services segment to relevant addresses and ports, filtering in the opposite direction also takes
place. If an attack compromises one of the public servers (by circumventing the firewall and
HIDS), that server should not be able to further attack the network. To mitigate this type of
attack, specific filtering prevents any unauthorized requests from being generated by the public
servers to any other location. As an example, the Web server should be filtered so that it cannot
originate requests of its own, but merely respond to requests from clients. This setup helps
prevent a hacker from downloading additional utilities to the compromised device after the
initial attack. It also helps stop unwanted sessions from being triggered by the hacker during the
primary attack. An attack that generates an Xwindows terminal session from the Web server
through the firewall to the hackers machine is an example of such an attack. In addition, private
VLANs on the Demilitarized Zone (DMZ) switch prevent a compromised public server from
attacking other servers on the same segment. This traffic is not even detected by the firewall, a
fact that explains why private VLANs are critical. Finally, publicly addressable servers have
some protection against TCP SYN floods through mechanisms such as the use of half-open
connection limits on the firewall.
From a host perspective, each of the servers on the public services segment has host intrusion
detection software to monitor against any rogue activity at the operating system level, as well as
activity in common server applications (HTTP, FTP, SMTP, and so forth). The DNS host should
be locked down to respond only to desired commands and eliminate any unnecessary responses
that might assist hackers in network reconnaissance. This includes preventing zone transfers
from anywhere except legitimate secondary DNS servers. For mail services, the firewall itself
filters SMTP messages at Layer 7 to allow only necessary commands to the mail server.
Firewalls and firewall routers generally have some limited network-based intrusion detection
system (NIDS) capability within their security functions. This capability affects the performance
of the device, but does provide some additional attack visibility in the event you are under
attack. Remember that you are trading performance for attack visibility. Many of these attacks
can be dropped without the use of an IDS, but the monitoring station will not be aware of the
specific attack being launched.
The VPN connectivity is provided through the firewall or firewall and router. Remote sites
authenticate each other with pre-shared keys, and remote users are authenticated through the
access control server in the Campus Module.

5-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines and Alternatives

The following guidelines and alternatives are
available:
IOS Firewall versus PIX Firewall
WAN connectivity requires a router
A PIX Firewall for xDSL or a cable modem
RFC 1918 and RFC 2827 filtering
Alternatives would be geared toward increasing network
capacity (a Concentrator could be used)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-10

The SAFE SMR Small Network Design alternatives represent the ultimate in scaled-down,
security-conscious network design, where all the security and VPN services are compressed into
a single device. There are two choices when deciding how to implement this network design:
Use a router with firewall and VPN functionalityThis setup yields the greatest flexibility
for the small network because the router will support all the advanced services (Quality of
Service [QoS], routing, multi-protocol support, and so on) that may be necessary in todays
networks.
Use a dedicated firewall instead of the routerThis setup places some restrictions on the
deployment. First, firewalls are generally Ethernet-only, requiring some conversion to the
appropriate WAN protocol. In todays environments, most cable and Digital Subscriber Line
(DSL) routers and modems are provided by the service provider and can be used to connect
to the firewall over Ethernet. If WAN connectivity on the device is required (such as with a
circuit from a telco provider), then a router must be used. Using a dedicated firewall does
have the advantage of easier configuration of security services, and a dedicated firewall can
provide improved performance when doing firewall functions. Whatever the selection of
device, stateful inspection is used to examine traffic in all directions, ensuring that only
legitimate traffic crosses the firewall. Before the traffic even reaches the firewall, ideally,
some security filtering has already occurred at the ISP. Remember that routers tend to start
out permitting traffic, whereas firewalls tend to deny traffic by default.
Any deviation from the SAFE SMR Small Network Design would be geared toward increasing
the capacity of the network, or separating the various security functions onto distinct devices. In
doing this, the design starts to look more and more like the medium network design discussed
later in this chapter. Instead of adopting the complete medium design, you might consider the

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-9

addition of a dedicated remote access Cisco VPN Concentrator to increase the manageability of
the remote-user community.

5-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Small Network Campus Module

The following section discusses the campus module.

Small Network Campus

Module Key Devices
The following are key devices:
Layer 2 switch
Corporate servers
SMTP or POP3
File and print
User workstations
Management host
HIDS
Syslog
Tacacs+ or Radius

2003, Cisco Systems, Inc. All rights reserved.

Management
host

User
workstations
Corporate
servers

To the
corporate
Internet module

Layer 2
switch

CSI 1.15-12

The Campus Module contains end-user workstations, corporate intranet servers, management
servers, and the associated Layer 2 infrastructure required to support the devices. Within the
small network design, this Layer 2 functionality has been combined into a single switch.
The following are key devices for the SAFE SMR Small Network Campus Module:
Layer 2 switch (with private VLAN support)Provides Layer 2 services to user
workstations
Corporate serversProvides e-mail (SMTP and POP3) services to internal users, as well as
delivering file, print, and DNS services to workstations
User workstationsProvides data services to authorized users on the network
Management hostProvides HIDS, Syslog, Terminal Access Control System Plus
(TACACS+) or Remote Access Dial-In User Service (RADIUS), and general configuration
management

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-11

Expected Threats
and Mitigation Roles
You can expect the
following threats:

Packet sniffers
Virus and Trojan horse
applications
Unauthorized access
Application layer attacks
Trust exploitation
Port redirection

2003, Cisco Systems, Inc. All rights reserved.

HIDS local
attack
mitigation
Management
server

To corporate
Internet
module

Host virus
scanning

HIDS local
attack
mitigation

Corporate
users
Corporate
servers

Private
VLANs

CSI 1.15-13

The following are expected threats and mitigation of those threats to the SAFE SMR Small
Network Campus Module:
Packet sniffersA switched infrastructure limits the effectiveness of sniffing
Virus and Trojan horse applicationsHost-based virus scanning prevents most viruses and
many Trojan horses
Unauthorized accessThis type of access is mitigated through the use of host-based
intrusion detection and application access control
Application layer attacksOperating systems, devices, and applications are kept up-to-date
with the latest security fixes, and they are protected by an HIDS
Trust exploitationPrivate VLANs prevent hosts on the same subnet from communicating
unless necessary
Port redirectionAn HIDS prevents port redirection agents from being installed
Attack mitigation roles for the SAFE SMR Small Network Campus Module include the
following:
Private VLANs
HIDS local attack mitigation

5-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Host virus scanning

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-13

Design Guidelines and Alternatives

The following guidelines and alternatives are
available:

Private VLANs can be enabled in order to mitigate

trust-exploitation attacks between the devices.
Because there are no Layer 3 services within the campus
module, it is important to note that this design places an
increased emphasis on application and host security due
to the open nature of the internal network.
Alternatives involve setting a small filtering router or
firewall between the management stations and the rest of
the network.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-14

The primary functions of the campus switch are to switch production and management traffic
and to provide connectivity for the corporate and management servers and users. Within the
switch, private VLANs can be enabled to mitigate trust-exploitation attacks between the devices.
For instance, the corporate users might need to be able to talk to the corporate servers but may
not have any requirement to communicate with each other.
Because there are no Layer 3 services within the campus module, it is important to note that the
SAFE SMR Small Network Campus Module Design places an increased emphasis on
application and host security because of the open nature of the internal network. Therefore, an
HIDS was also installed on key systems within the campus, including the corporate servers and
management systems.
Setting a small filtering router or firewall between the management stations and the rest of the
network can improve overall security. This setup allows management traffic to flow only in the
specific direction deemed necessary by the administrators. If the level of trust within the
organization is high, an HIDS can potentially be eliminated, though this is not recommended.

5-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ImplementationISP Router
The following section details the implementation of the ISP router.

ISP Router
Implementation Commands
Spoof mitigation
rate-limiting
Management
Server

ISP

Public
Services

Corporate
Users

Firewall

The following are necessary mitigation roles and

implementation commands:
Spoof mitigation and RFC filtering
access-list
access-group
Rate-limiting
rate-limit

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-16

The primary function of the customer-edge router in the ISP is to provide connectivity to the
Internet or ISP network. The egress of the ISP router rate limits nonessential traffic that exceeds
pre-specified thresholds in order to mitigate DDoS attacks. At the egress of the ISP router, RFC
1918 and RFC 2827 filtering is configured to mitigate source-address spoofing of local networks
and private address ranges.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-15

Implementation CommandsSpoof
Mitigation and RFC Filtering
router(config)#

--- ---
- -
- - -
- -

The access-list command enables you to specify if an IP address is
permitted or denied access to a port or protocol.

---

router(config-if)#

-- --- ---

The access-group command binds an ACL to an interface.

--
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-17

Cisco provides basic traffic filtering capabilities with access control lists (ACLs). ACLs can be
configured for all routed network protocols (IP, AppleTalk, and so on) to filter the packets of
those protocols as the packets pass through a router.
You can configure ACLs at your router to control access to a network: ACLs can prevent certain
traffic from entering or exiting a network.
ACLs should be used in IOS Firewall routers, which are often positioned between your internal
network and an external network (for example, the Internet). You can also use ACLs on a router
positioned between two parts of your network, to control traffic entering or exiting a specific
part of your internal network.
To provide the security benefits of ACLs, you should at a minimum configure ACLs on border
routersrouters situated at the edges of your networks. This provides a basic buffer from the
outside network, or from a less controlled area of your own network into a more sensitive area of
your network.
On these routers, you should configure ACLs for each network protocol configured on the router
interfaces. You can configure ACLs so that inbound traffic, outbound traffic, or both are filtered
on an interface.
ACLs must be defined on a per-protocol basis. In other words, you should define ACLs for
every protocol enabled on an interface if you want to control traffic flow for that protocol.
For inbound ACLs, after receiving a packet, the Cisco IOS Software checks the source address
of the packet against the ACL. If the ACL permits the address, the software continues to process
the packet. If the ACL rejects the address, the software discards the packet and returns an ICMP
host unreachable message.
5-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

For outbound ACLs, after receiving and routing a packet to a controlled interface, the software
checks the source address of the packet against the ACL. If the ACL permits the address, the
software sends the packet. If the ACL rejects the address, the software discards the packet and
returns an ICMP host unreachable message.
When you apply an ACL that has not yet been defined to an interface, the software acts as if the
ACL has not been applied to the interface and accepts all packets. Remember this behavior if
you use undefined ACLs as a means of security in your network.
The syntax for the access-list command is as follows:
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range timerange-name]
access-list-number

Number of an ACL. This is a decimal number from 100 to 199 or

from 2000 to 2699.

dynamic dynamic-name

(Optional.) Identifies this ACL as a dynamic ACL. Refer to lockand-key access documented in the "Configuring Lock-and-Key
Security (Dynamic Access Lists)" chapter in the Cisco IOS
Security Configuration Guide.

timeout minutes

(Optional.) Specifies the absolute length of time, in minutes, that

a temporary ACL entry can remain in a dynamic ACL. The default
is an infinite length of time and allows an entry to remain
permanently. Refer to lock-and-key access documented in the
"Configuring Lock-and-Key Security (Dynamic Access Lists)"
chapter in the Cisco IOS Security Configuration Guide.

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an Internet protocol. It can be one of the

keywords eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim,
tcp, or udp, or an integer in the range from 0 to 255 representing
an IP number. To match any IP (including ICMP, TCP, and UDP),
use the ip keyword. Some protocols allow further qualifiers
described below.

source

Number of the network or host from which the packet is being

sent. There are three alternative ways to specify the source:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-17

source-wildcard

Wildcard bits to be applied to source. Each wildcard bit 0

indicates the corresponding bit position in the source. Each
wildcard bit set to 1 indicates that both a 0 bit and a 1 bit in the
corresponding position of the IP address of the packet will be
considered a match to this ACL entry.
There are three alternative ways to specify the source wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format.
Place1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.
Wildcard bits set to 1 need not be contiguous in the source
wildcard (for example, a source wildcard of 0.255.0.64 would be
valid).

The syntax for the access-group command is as follows:

ip access-group {access-list-number | access-list-name}{in | out}

5-18

access-list-number

Number of an ACL. This is a decimal number from 1 to 199 or

from 1300 to 2699.

access-list-name

Name of an IP ACL as specified by an ip access-list command.

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ImplementationIOS Firewall Features and

Configuration
The following section details the implementation of the IOS Firewall features and configuration.

The Cisco IOS Firewall

Stateful packet filtering, basic
Layer 7 filtering, host DoS
mitigation, spoof mitigation,
authenticate remote site,
authenticate remote users, and
terminate IPSec
Public
services

ISP

To campus

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-19

The primary function of the IOS Firewall is to provide connection-state enforcement and
detailed filtering for sessions initiated through the IOS Firewall. The IOS Firewall also acts as a
termination point for site-to-site IPSec VPN tunnels for both remote site production and remote
site management traffic.
There are multiple segments off the IOS Firewall. The first is the public services segment, which
contains all the publicly addressable hosts. The second is for remote access VPN and dial-in,
which are discussed in a later chapter. Publicly addressable servers have some protection against
TCP SYN floods through mechanisms such as the use of half-open connection limits on the IOS
Firewall.
From a filtering standpoint, in addition to limiting traffic on the public services segment to
relevant addresses and ports, filtering in the opposite direction also occurs. If an attack
compromises one of the public servers (by circumventing the IOS Firewall and the HIDS), that
server should not be able to further attack the network. To mitigate this type of attack, specific
filtering prevents any unauthorized requests from being generated by the public servers to any
other location.
As an example, the Web server should be filtered so that it cannot originate requests of its own,
but merely respond to requests from clients. This setup helps prevent a hacker from downloading
additional utilities to the compromised box after the initial attack. It also helps stop unwanted
Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-19

sessions from being triggered by the hacker during the primary attack. An attack that generates
an xterm from the Web server through the firewall to the hackers machine is an example of such
an attack. In addition, private VLANs prevent a compromised public server from attacking other
servers on the same segment. This traffic is not even detected by the IOS Firewall, a fact that
explains why private VLANs are critical.

5-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IOS Firewall

Implementation Commands
The following are necessary mitigation roles and implementation
commands for the IOS Firewall:
Stateful packet filteringPart of CBAC on Cisco IOS Routers
Spoof mitigation and RFC filtering
access-list
access-group
Host DoS mitigation and basic layer 7 filtering
ip inspect
Authenticate remote site, users, and logging
aaa new-model
tacacs-server
aaa authentication login
aaa authorization exec
aaa accounting exec
login authentication

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-20

The following are necessary mitigation roles and implementation commands for the IOS
Firewall:
Stateful packet filteringPart of Context-Based Access Control (CBAC) on Cisco IOS
Routers
Spoof mitigation and RFC filtering

access-listThe access-list command enables you to specify if an IP address is

permitted or denied access to a port or protocol.
access-groupBinds an ACL to an interface.

Host DoS mitigation and basic layer 7 filtering

ip inspectDefines the application protocols to inspect.

Authenticate remote site (and logging)

Copyright

aaa new-modelEnter this command for each protocol that you want to inspect, using
the same inspection-name, to define a set of inspection rules.
tacacs-serverDefines the TACACS server.
aaa authentication loginEnables authentication, authorization, and accounting
(AAA) authentication at login.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-21

aaa authorization execRestricts network access to a user.

aaa accounting execRuns accounting for EXEC shell session.

5-22

login authenticationSpecifies the name of a list of AAA authentication methods to

try at login.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IOS Firewall

Implementation Commands (cont.)
IPSec commands provide for IPSec
tunnel termination:
crypto isakmp policy
encryption
authentication
group
crypto isakmp key
crypto ipsec transform-set
crypto map
set peer
set tranform-set
match address
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-21

IPSec commands

crypto isakmp policySpecifies the parameters to be used during an IKE negotiation.

encryptionSets the algorithm to be negotiated.

authenticationSpecifies the authentication method within an IKE policy.

Copyright

groupSpecifies the Diffie-Hellman (DH) group identifier within an Internet Key

Exchange policy.
crypto isakmp keyConfigures pre-shared authentication keys.
crypto ipsec transform-setAn acceptable combination of security protocols,
algorithms and other settings to apply to IP Security protected traffic.
crypto mapConfigures filtering and classifying traffic to be protected and defines the
policy to be applied to that traffic.

set peerSpecifies an IPSec peer for a crypto map.

set transform-setSpecifies which transform sets to include in a crypto map entry.

match addressSpecifies an extended access list for a crypto map entry.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-23

Spoof Mitigation
and RFC FilteringACLs
router(config)#
--- ---
- -
- - -
- -

The access-list command enables you to specify if an IP address
is permitted or denied access to a port or protocol.
---

router(config-if)#
-- --- ---

The access-group command binds an ACL to an interface.
--
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-22

You can use ACLs to control the transmission of packets on an interface, control vty access, and
restrict the contents of routing updates. The Cisco IOS Software stops checking the extended
ACL after a match occurs.
The syntax for the access-list command is as follows:
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range timerange-name]

5-24

access-list-number

Number of an ACL. This is a decimal number from 100 to 199 or

from 2000 to 2699.

dynamic dynamic-name

(Optional.) Identifies this ACL as a dynamic ACL. Refer to lockand-key access documented in the "Configuring Lock-and-Key
Security (Dynamic Access Lists)" chapter in the Cisco IOS
Security Configuration Guide.

timeout minutes

(Optional.) Specifies the absolute length of time, in minutes, that

a temporary ACL entry can remain in a dynamic ACL. The default
is an infinite length of time and allows an entry to remain
permanently. Refer to lock-and-key access documented in the
"Configuring Lock-and-Key Security (Dynamic Access Lists)"
chapter in the Cisco IOS Security Configuration Guide.

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an Internet protocol. It can be one of the

keywords eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim,
tcp, or udp, or an integer in the range from 0 to 255 representing
an IP number. To match any IP (including ICMP, TCP, and UDP),
use the ip keyword. Some protocols allow further qualifiers
described below.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

source

Number of the network or host from which the packet is being

sent. There are three alternative ways to specify the source:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.

source-wildcard

Wildcard bits to be applied to source. Each wildcard bit 0

indicates the corresponding bit position in the source. Each
wildcard bit set to 1 indicates that both a 0 bit and a 1 bit in the
corresponding position of the IP address of the packet will be
considered a match to this ACL entry.
There are three alternative ways to specify the source wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format.
Place1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.
Wildcard bits set to 1 need not be contiguous in the source
wildcard (for example, a source wildcard of 0.255.0.64 would be
valid).

The syntax for the access-group command is as follows:

ip access-group {access-list-number | access-list-name}{in | out}

Copyright

access-list-number

Number of an ACL. This is a decimal number from 1 to 199 or

from 1300 to 2699.

access-list-name

Name of an IP ACL as specified by an ip access-list command.

in

Filters on inbound packets.

out

Filters on outbound packets.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-25

Spoof Mitigation Example

RFC 2827 Filtering
---

---

Ingress packets must be

from customer addresses
Egress from Internet

ISP
network

Customer
network:
192.168.0.0/16

Ingress to Internet

--
--

---
---

---

Egress packets
cannot be from
and to customers
Ensure that
ingress packets
are valid

---
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-23

A resurgence of DoS attacks aimed at various targets in the Internet have produced new
challenges within the ISP and network security communities to find new and innovative methods
to mitigate these types of attacks. While the filtering method in RFC 2827 does absolutely
nothing to protect against flooding attacks, which originate from valid prefixes (IP addresses), it
will prohibit an attacker within the originating network from launching an attack of this nature
using forged source addresses that do not conform to ingress filtering rules.
All providers of Internet connectivity are urged to implement filtering described in RFC 2827 to
prohibit attackers from using forged source addresses, which do not reside within a range of
legitimately advertised prefixes. In other words, if an ISP is aggregating routing announcements
for multiple downstream networks, strict traffic filtering should be used to prohibit traffic that
claims to have originated from outside of these aggregated announcements.
An additional benefit of implementing this type of filtering is that it enables the originator to be
easily traced to its true source, because the attacker would have to use a valid, and legitimately
reachable, source address.

5-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Unauthorized Access
IOS Firewall Intrusion Detection
The following are the IOS Firewall intrusion detection
features:

Acts as an in-line intrusion detection sensor

When a packet or packets match a signature, it can perform any of the
following configurable actions:
AlarmSends an alarm to a Cisco IDS Director or Syslog server
DropDrops the packet
ResetSends TCP resets to terminate the session
Detects, reports, and acts upon many common attacks

TCP
UDP
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-24

Cisco IOS Firewall and intrusion-detection solutions are designed to meet security requirements
within a network, whether the requirement is for multilevel security with a dedicated appliance
(Cisco PIX Firewall or Cisco IDS Sensor) or for integrated security wherever a router is
deployed (Cisco IOS Firewall with intrusion detection). The standalone appliance and integrated
Cisco solutions meet the various network security needs in a network, based on an organizations
security policy, network security risk and vulnerability, level of performance requirements at the
site, and network segmentation, network media or interface, and routing requirements.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-27

Implementation Commands
IOS Firewall Intrusion Detection
router #
- -
-
Creates audit rules for info and attack signature types

router #
-
Specifies the default actions for attack signatures

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-25

Use the ip audit name global configuration command to create audit rules for info and attack
signature types. Use the no form of this command to delete an audit rule.
The syntax for the ip audit name is as follows:
ip audit name audit-name {info | attack} [list standard-acl] [action [alarm] [drop] [reset]]
audit-name

Name for an audit specification.

info

Specifies that the audit rule is for info signatures.

attack

Specifies that the audit rule is for attack signatures.

list

(Optional.) Specifies an ACL to attach to the audit rule.

standard-acl

(Optional.) Integer representing an ACL. Use with the list

keyword.

action

(Optional.) Specifies an action or actions to take in response to a

match.

alarm

(Optional.) Sends an alarm to the console, NetRanger Director, or

to a Syslog server. Use with the action keyword.

drop

(Optional.) Drops the packet. Use with the action keyword.

reset

(Optional.) Resets the TCP session.

Use the ip audit attack global configuration command to specify the default actions for attack
signatures. Use the no form of this command to set the default action for attack signatures.
The syntax for the ip audit attack is as follows:
ip audit attack {action [alarm] [drop] [reset]}

5-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

action

Specifies an action for the attack signature to take in response to

a match.

alarm

(Optional.) Sends an alarm to the console, NetRanger Director, or

to a Syslog server. Used with the action keyword.

drop

(Optional.) Drops the packet. Used with the action keyword.

reset

(Optional.) Resets the TCP session. Used with the action

keyword.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-29

Implementation Commands
IOS Firewall Intrusion Detection (cont.)
router#

Specifies the method of event notification

router#
- Specifies the maximum number of event notifications that are
placed in the router's event queue

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-26

Use the ip audit notify global configuration command to specify the method of event
notification. Use the no form of this command to disable event notifications.
The syntax for the ip audit notify is as follows:
ip audit notify {nr-director | log}
nr-director

Send messages in NetRanger format to the NetRanger Director

or Sensor.

log

Send messages in Syslog format.

Use the ip audit po max-events global configuration command to specify the maximum number
of event notifications that are placed in the router's event queue. Use the no version of this
command to set the number of recipients to the default setting.
The syntax for the ip audit po max-events is as follows:
ip audit notify {nr-director | log}
number-of-events

5-30

Cisco SAFE Implementation 1.1

Integer in the range from 1 to 65535 that designates the

maximum number of events allowable in the event queue. The
default is 100 events.

Copyright

2003, Cisco Systems, Inc.

Stateful Packet Filtering

IOS Firewall CBAC
IOS Firewall CBAC performs the following:

Packets are inspected entering the firewall by CBAC if they are not
specifically denied by an ACL.
CBAC permits or denies specified TCP and UDP traffic through a
firewall.
A state table is maintained with session information.
ACLs are dynamically created or deleted.
CBAC protects against DoS attacks.
Protection against unauthorized access.

TCP
UDP
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-27

CBAC adds inspection intelligence to ACL capabilities by performing stateful packet inspection
for application status information for applications using TCP and UDP packets for transport.
Using this information, CBAC creates a temporary or dynamic, session-specific ACL entry,
permitting return traffic into the trusted network. This dynamic ACL effectively opens a door in
the IOS Firewall. When a session times out or ends, the ACL entry is deleted and the door closes
to additional traffic. To perform this function, a state table is maintained for session information.
Standard and extended ACLs cannot create temporary ACL entries, so, until now, administrators
have been forced to weigh security risks against information access requirements. Advanced
applications that select from multiple channels for return traffic have been difficult to secure
using standard or extended ACLs.
CBAC is more secure than current ACL-only solutions because it accounts for application type
in deciding whether to allow a session through the IOS Firewall and determines whether it
selects from multiple channels for return traffic. Before CBAC, administrators could permit
advanced application traffic only by writing permanent ACLs that essentially left IOS Firewall
doors open; so most administrators opted to deny all such application traffic. With CBAC, they
can now securely permit multimedia and other application traffic by opening the IOS Firewall as
needed, and closing it all other times. For example, if CBAC is configured to allow Microsoft
NetMeeting, when an internal user initiates a connection, the IOS Firewall permits return traffic.
However, if an external NetMeeting source initiates a connection with an internal user, CBAC
denies entry and drops the packets.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-31

DoS MitigationGeneral Rules for

Applying Inspection Rules and ACLs
The following rules should be followed whenever
possible:

On the interface where traffic initiates

Apply an ACL in the inward direction that only permits
wanted traffic.
Apply a rule in the inward direction that inspects
wanted traffic.
On all other interfaces apply an ACL in the inward
direction that denies all traffic, except traffic (such as
ICMP) not inspected by CBAC.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-28

On the IOS Firewall interface where traffic initiates ACLs should be applied on the inward
direction that only permits wanted traffic, and on the inward direction that inspects wanted
traffic. On all other interfaces, the ACL should be applied on the inward direction that denies all
traffic, except traffic (such as ICMP) not inspected by CBAC.

5-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Basic Layer 7 FilteringInspection

Rules for Application Protocols
Router(config)#

- -
--
Defines the application protocols to inspect
Will be applied to an interface
Available protocols: tcp, udp, cuseeme, ftp, http, h323, netshow, rcmd,
realaudio, rpc, smtp, sqlnet, streamworks, tftp, and vdolive
alert, audit-trail, and timeout are configurable per protocol and override
global settings

- -

-

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-29

You can configure TCP and UDP inspection to permit TCP and UDP packets to enter the
internal network through the firewall, even if the application-layer protocol is not configured to
be inspected. However, TCP and UDP inspection do not recognize application-specific
commands, and therefore might not permit all return packets for an application, particularly if
the return packets have a different port number than the previous exiting packet.
Any application-layer protocol that is inspected will take precedence over the TCP or UDP
packet inspection. For example, if inspection is configured for FTP, all control channel
information will be recorded in the state table, and all FTP traffic will be permitted back through
the firewall if the control channel information is valid for the state of the FTP session. The fact
that TCP inspection is configured is irrelevant to the FTP state information.
With TCP and UDP inspection, packets entering the network must exactly match the
corresponding packet that previously exited the network. The entering packets must have the
same source or destination addresses, and source or destination port numbers as the exiting
packet (but reversed); otherwise, the entering packets will be blocked at the interface. Also, all
TCP packets with a sequence number outside of the window are dropped.
With UDP inspection configured, replies will only be permitted back in through the firewall if
they are received within a configurable time after the last request was sent out.
The syntax for the ip inspect name command is as follows:
ip inspect name inspection-name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

Copyright

inspection-name

Names the set of inspection rules. If you want to add a protocol to

an existing set of rules, use the same inspection-name.

protocol

The protocol to inspect. Use of the following keywords: tcp, udp,

cuseeme, ftp, http, h323, netshow, rcmd, realaudio, rpc, smtp,
sqlnet, streamworks, tftp, or vdolive.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-33

5-34

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert

messages can be set to on or off. If no option is selected, alerts
are generated based on the setting of the ip inspect alert-off
command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to

on or off. If no option is selected, audit trail messages are
generated based on the setting of the ip inspect audit trail
command.

timeout seconds

(Optional.) To override the global TCP or UDP idle timeouts for

the specified protocol, specify the number of seconds for a
different idle timeout. This timeout overrides the global TCP and
UPD timeouts, but will not override the global DNS timeout.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Apply an Inspection
Rule to an Interface

Router(config-if)#

- -
Applies the named inspection rule to an interface

-
Applies the inspection rule to interface e0/0 in inward
direction

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-30

After you define an inspection rule, you apply it to an interface.

Usually, you apply only one inspection rule to one interface. The only exception might occur if
you want to enable CBAC in two directions. For CBAC configured in both directions at a single
firewall interface, you should apply two rules, one for each direction as follows:
If you are configuring CBAC on an external interface, apply the rule to outbound traffic.
If you are configuring CBAC on an internal interface, apply the rule to inbound traffic.
The syntax for the ip inspect name command is as follows:
ip inspect inspection-name {in | out}

Copyright

inspection-name

Identifies which set of inspection rules to apply.

in

Applies the inspection rules to inbound traffic.

out

Applies the inspection rules to outbound traffic.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-35

Example Inspection Rule for Java

Router(config)#

- - -

--
Controls java blocking with a standard ACL

- -

---

---

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-31

Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of
external sites that you designate as friendly. If an applet is from a friendly site, the firewall
allows the applet through. If the applet is not from a friendly site, the applet is blocked.
(Alternately, you could permit applets from all external sites except for those you specifically
designate as hostile.)
Note

CBAC does not detect or block encapsulated Java applets. Therefore, Java applets that are
wrapped or encapsulated, such as applets in .zip or .jar format, are not blocked at the firewall.
CBAC also does not detect or block applets loaded from FTP, gopher, HTTP on a
nonstandard port, and so forth.

The syntax for the ip inspect name command is as follows:

ip inspect name inspection-name http [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout
seconds]

5-36

inspection-name

Names the set of inspection rules. If you want to add a protocol to

an existing set of rules, use the same inspection-name.

http

(Optional.) Specifies the HTTP protocol for Java applet blocking.

java-list access-list

(Optional.) Specifies the numbered standard ACL to use to

determine "friendly" sites. This keyword is available only for the
HTTP protocol, for Java applet blocking. Java blocking only works
with numbered standard ACLs.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert

messages can be set to on or off. If no option is selected, alerts
are generated based on the setting of the ip inspect alert-off
command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to

on or off. If no option is selected, audit trail messages are
generated based on the setting of the ip inspect audit trail
command.

timeout seconds

(Optional.) To override the global TCP or UDP idle timeouts for

the specified protocol, specify the number of seconds for a
different idle timeout. This timeout overrides the global TCP and
UPD timeouts, but will not override the global DNS timeout.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-37

Example Inspection
Rule for RPC Applications
Router(config)#

- -
-

--
Allows given RPC program numberswait-time keeps the
connection open for a specified number of minutes

-


2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-32

Remote Procedure Call (RPC) inspection enables the specification of various program numbers.
You can define multiple program numbers by creating multiple entries for RPC inspection, each
with a different program number. If a program number is specified, all traffic for that program
number is permitted. If a program number is not specified, all traffic for that program number is
blocked. For example, if you created an RPC entry with the NFS program number, all NFS
traffic is allowed through the firewall.
The syntax for the ip inspect name command is as follows:
ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail
{on | off}] [timeout seconds]

5-38

inspection-name

Names the set of inspection rules. If you want to add a protocol to

an existing set of rules, use the same inspection-name as the
existing set of rules.

rpc program-number number

Specifies the program number to permit. This keyword is

available only for the remote-procedure call protocol.

wait-time minutes

(Optional.) Specifies the number of minutes to keep a small hole

in the firewall to allow subsequent connections from the same
source address and to the same destination address and port.
The default wait-time is zero minutes. This keyword is available
only for the RPC protocol.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert

messages can be set to on or off. If no option is selected, alerts
are generated based on the setting of the ip inspect alert-off
command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to

on or off. If no option is selected, audit trail messages are
generated based on the setting of the ip inspect audit trail
command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

timeout seconds

Copyright

2003, Cisco Systems, Inc.

(Optional.) To override the global TCP or UDP idle timeouts for

the specified protocol, specify the number of seconds for a
different idle timeout. This timeout overrides the global TCP and
UPD timeouts, but will not override the global DNS timeout.

SAFE Small Network Design

5-39

Example Inspection Rule

for SMTP Applications
Router(config)#

- - -

--
Only allows the following legal commands in SMTP
applications: DATA, EXPN, HELO, HELP, MAIL, NOOP,
QUIT, RCPT, RSET, SAML, SEND, SOML, and VRFY
If disabled, all SMTP commands are allowed through the
firewall, and potential mail server vulnerabilities are
exposed

- -

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-33

SMTP inspection causes SMTP commands to be inspected for illegal commands. Any packets
with illegal commands are dropped, and the SMTP session hangs and eventually times out.
The syntax for the ip inspect name command is as follows:

5-40

inspection-name

Names the set of inspection rules. If you want to add a protocol to

an existing set of rules, use the same inspection-name as the
existing set of rules.

protocol

A protocol keyword.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert

messages can be set to on or off. If no option is selected, alerts
are generated based on the setting of the ip inspect alert-off
command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to

on or off. If no option is selected, audit trail messages are
generated based on the setting of the ip inspect audit trail
command.

timeout seconds

(Optional.) To override the global TCP or UDP idle timeouts for

the specified protocol, specify the number of seconds for a
different idle timeout. This timeout overrides the global TCP and
UPD timeouts, but will not override the global DNS timeout.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Example Inspection Rule

for IP Packet Fragmentation
Router(config)#

- -
- Protects hosts from certain DoS attacks involving fragmented
IP packets
max = number of unassembled fragmented IP packets
timeout = seconds when the unassembled fragmented IP
packets begin to be discarded

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-34

CBAC inspection rules can help protect hosts against certain DoS attacks involving fragmented
IP packets. Even though the firewall keeps an attacker from making actual connections to a
given host, the attacker may still be able to disrupt services provided by that host. This is done
by sending many non-initial IP fragments or by sending complete fragmented packets through a
router with an ACL that filters the first fragment of a fragmented packet. These fragments can tie
up resources on the target host as it tries to reassemble the incomplete packets.
Using fragmentation inspection, the firewall maintains an interfragment state (structure) for IP
traffic. Non-initial fragments are discarded unless the corresponding initial fragment was
permitted to pass through the firewall. Non-initial fragments received before the corresponding
initial fragments are discarded.
Note

Fragmentation inspection can have undesirable effects in certain cases, because it can result
in the firewall discarding any packet whose fragments arrive out of order. There are many
circumstances that can cause out-of-order delivery of legitimate fragments. Apply
fragmentation inspection in situations where legitimate fragments, which are likely to arrive out
of order, might have a severe performance impact.

Because routers running Cisco IOS Software are used in a very large variety of networks, and
because the CBAC feature is often used to isolate parts of internal networks from one another,
the fragmentation inspection feature is not enabled by default. Fragmentation detection must be
explicitly enabled for an inspection rule using the ip inspect name command. Unfragmented
traffic is never discarded because it lacks a fragment state. Even when the system is under heavy
attack with fragmented packets, legitimate fragmented traffic, if any, still gets some fraction of
the firewalls fragment state resources, and legitimate, unfragmented traffic can flow through the
firewall unimpeded.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-41

The syntax for the ip inspect name command is as follows:

ip inspect name inspection-name fragment [max number timeout seconds]
inspection-name

Names the set of inspection rules. If you want to add a protocol to

an existing set of rules, use the same inspection-name as the
existing set of rules.

fragment

Specifies fragment inspection for the named rule.

max number

(Optional.) Specifies the maximum number of unassembled

packets for which state information (structures) is allocated by
Cisco IOS software. Unassembled packets are packets that arrive
at the router interface before the initial packet for a session. The
acceptable range is 50 through 10000. The default is 256 state
entries.
Memory is allocated for the state structures, and setting this value
to a larger number may cause memory resources to be
exhausted.

timeout seconds

5-42

Cisco SAFE Implementation 1.1

(Optional.) To override the global TCP or UDP idle timeouts for

the specified protocol, specify the number of seconds for a
different idle timeout. This timeout overrides the global TCP and
UPD timeouts, but will not override the global DNS timeout.

Copyright

2003, Cisco Systems, Inc.

AuthenticationIOS Firewall
Authentication Proxy
The Cisco IOS Firewall authentication proxy provides the
following:
HTTP-based authentication
Dynamic, per-user authentication and authorization via
TACACS+ and RADIUS protocols

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-35

The authentication proxy capability in the Cisco IOS Firewall feature set provides dynamic, peruser authentication and authorization for network users. Previously, user identity and related
authorized access were determined by a users IP address, or the security policy had to be
applied to a user group or subnet. Now, per-user policy can be downloaded dynamically to the
router from the TACACS+ or RADIUS authentication server using Cisco IOS Software
authentication, authorization, and accounting (AAA) services.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-43

Implementation Commands
Authenticate Remote Site
router(config)#

Enables the AAA access control model

router(config)#

-- - -
-
Specifies a TACACS+ host

-- -
- --
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-36

You must configure AAA network security services using the aaa new-model, aaa
authentication, aaa authorization, and aaa accounting global configuration commands.
You also need to configure your network access server to communicate with the applicable
security server, either an extended TACACS or RADIUS daemon.
The syntax for the aaa new-model command is as follows:
aaa new-model
This command has no arguments or keywords.
The syntax for the tacacs-server host command is as follows:
tacacs-server host hostname [port integer] [timeout integer] [key string]

5-44

hostname

Name or IP address of the host.

port

(Optional.) Specifies a server port number. This option overrides

the default, which is port 49.

integer

(Optional.) Port number of the server. Valid port numbers range

from 1 to 65535.

timeout

(Optional.) Specifies a timeout value. This overrides the global

timeout value set with the tacacs-server timeout command for
this server only.

integer

(Optional.) Integer value, in seconds, of the timeout interval.

key

(Optional.) Specifies an authentication and encryption key. This

must match the key used by the TACACS+ daemon. Specifying
this key overrides the key set by the global command tacacsserver key for this server only.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

string

Copyright

2003, Cisco Systems, Inc.

(Optional.) Character string specifying authentication and

encryption key.

SAFE Small Network Design

5-45

Implementation Commands
Authenticate Remote Site (cont.)
router(config)#

-

---
-
-
These commands enable AAA authentication at login, restrict
network access to a user, and define the authentication method
used.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-37

Complete the following tasks to configure AAA authentication:

Step 1

Enable AAA by using the aaa new-model global configuration command.

Step 2

Configure security protocol parameters, such as RADIUS, TACACS+, or Kerberos if you are
using a security server.
Define the method lists for authentication by using an AAA authentication command. A method
list is a named list describing the authorization methods to be used (such as RADIUS or
TACACS+), in sequence. Method lists enable you to designate one or more security protocols to
be used for authorization, thus ensuring a backup system in case the initial method fails.

Step 3

5-46

Apply the method lists to a particular interface or line, if required.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands
Authenticate Remote Site (cont.)

-


-
-
- -
Examples of the AAA commands

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-38

Create a method list by entering the aaa authentication login list-name method command for a
particular protocol, where list-name is any character string used to name this method list (for
example, MIS-access). The method argument identifies the list of methods that the
authentication algorithm tries in the given sequence.
Use the login authentication command with the default argument followed by the methods you
want to use in default situations to create a default method list that is used if no method list is
assigned to a line.
The additional methods of authentication are used only if the previous method returns an error,
not if it fails. To ensure that the authentication succeeds even if all methods return an error,
specify none as the final method in the command line.
If authentication is not specifically set for a line, the default is to deny access and no
authentication is performed. Use the more system:running-config command to display
currently configured lists of authentication methods.
Use the aaa authorization command to enable authorization and to create named method lists,
defining authorization methods that can be used when a user accesses the specified function.
Method lists for authorization define the ways authorization is performed and the sequence in
which these methods are performed.
Cisco IOS Software uses the first method listed in your method list to authorize users for specific
network services; if that method fails to respond, the Cisco IOS Software selects the next method
listed in the method list. This process continues until there is successful communication with a
listed authorization method, or all methods defined are exhausted.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-47

The command login authentication is a per-line command used with AAA that specifies the
name of a list of AAA authentication methods to try at login. If no list is specified, the default
list is used (whether or not it is specified in the command line).
The syntax for the aaa authentication login command is as follows:
aaa authentication login {default | list-name} method1 [method2...]
Default

Uses the listed authentication methods that follow this argument

as the default list of methods when a user logs in.

list-name

Character string used to name the list of authentication methods

activated when a user logs in.

method1 [method2...]

At least one keyword.

The syntax for the aaa authorization command is as follows:

aaa authorization {network | exec | commands level | reverse-access | configuration} {default | list-name}
method1 [method2...]
network

Runs authorization for all network-related service requests,

including SLIP, PPP, PPP NCPs, and ARA.

exec

Runs authorization to determine if the user is allowed to run an

EXEC shell. This facility might return user profile information such
as autocommand information.

commands

Runs authorization for all commands at the specified privilege

level.

level

Specific command level that should be authorized. Valid entries

are 0 through 15.

reverse-access

Runs authorization for reverse access connections, such as

reverse Telnet.

configuration

Downloads the configuration from the AAA server.

default

Uses the listed authorization methods that follow this argument as

the default list of methods for authorization.

list-name

Character string used to name the list of authorization methods.

method1 [method2...]

At least one keyword.

The syntax for the aaa accounting command is as follows:

aaa accounting {auth-proxy | system | network | exec | connection | commands level} {default | list-name} {startstop | stop-only | wait-start | none} [broadcast] group groupname

5-48

auth-proxy

Provides information about all authenticated-proxy user events.

system

Performs accounting for all system-level events not associated

with users, such as reloads.

network

Runs accounting for all network-related service requests,

including SLIP, PPP, PPP NCPs, and ARAP.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

exec

Runs accounting for EXEC shell session. This keyword might

return user profile information such as what is generated by the
autocommand command.

connection

Provides information about all outbound connections made from

the network access server, such as Telnet, LAT, TN3270, PAD,
and rlogin.

commands level

Runs accounting for all commands at the specified privilege level.

Valid privilege level entries are integers from 0 through 15.

default

Uses the listed accounting methods that follow this argument as

the default list of methods for accounting services.

list-name

Character string used to name the list of at least one of the

accounting methods.

start-stop

Sends a "start" accounting notice at the beginning of a process

and a "stop" accounting notice at the end of a process. The "start"
accounting record is sent in the background. The requested user
process begins regardless of whether the "start" accounting
notice was received by the accounting server.

stop-only

Sends a "stop" accounting notice at the end of the requested user

process.

wait-start

Sends a "start" accounting notice at the beginning of a process

and a "stop" accounting notice at the end of a process. The "start"
accounting record is sent in the background. The requested user
process does not begin until the "start" accounting notice is
received by the server.

none

Disables accounting services on this line or interface.

broadcast

(Optional.) Enables sending accounting records to multiple AAA

servers. Simultaneously sends accounting records to the first
server in each group. If the first server is unavailable, failover
occurs using the backup servers defined within that group.

group groupname

At least one keyword.

The syntax for the login authentication command is as follows:

login authentication {default | list-name}

Copyright

default

Uses the default list created with the aaa authentication login
command.

list-name

Uses the indicated list created with the aaa authentication login
command.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-49

ImplementationPIX Firewall
This section describes the detailed configuration and implementation of the Cisco PIX Firewall.

Cisco PIX Firewall

Implementation Commands
The following are the
necessary mitigation roles
and implementation
commands for the PIX
Firewall:

Stateful packet filteringthe

default for the PIX Firewall
Host DoS mitigation
commands
ip verify reverse-path
interface
icmp
attack guard commands
are on by default
except for frag guard
Static
Spoof mitigation and RFC
filtering commands
access-list
access-group

Stateful packet filtering, basic Layer

7 filtering, host DoS mitigation,
spoof mitigation, authenticate
remote site, authenticate remote
users, and terminate IPSec

Public
services

ISP

To campus

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-40

The following mitigation roles and commands are used to implement the policy on the PIX
Firewall:
Stateful packet filteringThe default for the PIX firewall.
Host DoS mitigation commands

ip verify reverse-path interfaceImplements Unicast Reverse Path Forwarding (RPF)

IP spoofing protection

icmpEnables or disables pinging to an interface

attack guard commandsAre enabled by default

Static commandUsed to set maximum connections and maximum embryonic

connections

Spoof mitigation and RFC filtering commands

5-50

access-listCreates an ACL

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

access-groupBinds the ACL to an interface

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-51

Cisco PIX FirewallImplementation

Commands (cont.)
The following are the necessary
commands:
Authenticate remote site (and
logging) commands
aaa-server
aaa authentication
logging on
Terminate IPSec commands
sysopt connection permit-ipsec
isakmp enable
isakmp key
isakmp policy
crypto ipsec transform-set
crypto map

Public
services
ISP

To campus

Stateful packet filtering, basic Layer

7 filtering, host DoS mitigation,
authenticate remote sites, and
terminate IPSec

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-41

Authenticate remote site and logging

aaa-serverSpecifies a AAA server

aaa authenticationEnables, disables, or views LOCAL, TACACS+, or RADIUS user
authentication
logging onEnables or disables Syslog and SNMP logging

Terminate IPSec

5-52

sysopt connection permit-ipsecImplicitly permits any packet that came from an

IPSec tunnel
isakmp enableEnables Internet Security Association Key Management Protocol
(ISAKMP) negotiation on the interface on which the IPSec peer communicates with the
PIX Firewall
isakmp keySpecifies the authentication pre-shared key
isakmp policyUniquely identifies the Internet Key Exchange (IKE) policy and
assigns a priority to the policy
crypto ipsec transform-setCreates, views, or deletes IPSec Security Associations
(SAs), SA global lifetime values, and global transform sets

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

crypto mapCreates, modifies, views, or deletes a crypto map entry

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-53

Access Through the PIX Firewall

nat and global

Internet

e0 outside
security level 0

e1 inside
security level 100

PIX Firewall

static and access list

(static and conduit)
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-42

By default, the PIX Firewall denies access to an internal or perimeter (more secure) network
from an external (less secure) network. You specifically allow inbound connections by using
ACLs. ACLs permit access on a first-match basis. For inbound access, you must deny access
first and then permit access.
Note

Beginning with the PIX Firewall version 5.3, ACLs are the preferred method for managing
network access. The conduit command was used in earlier versions. ACLs provide improved
flexibility and greater ease of use for those familiar with Cisco IOS access control. However,
the conduit command is still supported to maintain backward compatibility of configurations
written for previous PIX Firewall versions.

Static NAT creates a permanent, one-to-one mapping between an address on an internal network
(a higher security level interface) and a perimeter or external network (lower security level
interface). For example, to share a web server on a perimeter interface with users on the public
Internet, use static address translation to map the servers actual address to a registered IP
address. Static address translation hides the actual address of the server from users on the less
secure interface, making casual access by unauthorized users less likely. Unlike NAT or PAT, it
requires a dedicated address on the outside network for each host, so it does not save registered
IP addresses.

5-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands
Host DoS Mitigation
pixfirewall(config)#

-
Protects an individual interface against IP spoofing by
enabling both ingress and egress filtering to verify
addressing and route integrity

-
-

pixfirewall(config)#

- - --

Permits or denies the ability to ping a PIX Firewall interface

-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-43

The ip verify reverse-path command implements the following:

Performs a route lookup based on the source address. Usually, the route lookup is based on
the destination address. This is why it is called reverse path forwarding. With this command
enabled, packets are dropped if there is no route found for the packet or the route found does
not match the interface on which the packet arrived.
Specifies which interfaces to protect from an IP spoofing attack using network ingress and
egress filtering, which is described in RFC 2267. This command is disabled by default and
provides Unicast Reverse Path Forwarding (Unicast RPF) functionality for the PIX Firewall.
Provides ingress filtering. Ingress filtering checks inbound packets for IP source address
integrity, and is limited to addresses for networks in the enforcing entitys local routing
table. If the incoming packet does not have a source address represented by a route, then it is
impossible to know whether the packet has arrived on the best possible path back to its
origin. This is often the case when routing entities cannot maintain routes for every network.
Provides egress filtering. Egress filtering verifies that packets destined for hosts outside the
managed domain have IP source addresses verifiable by routes in the enforcing entitys local
routing table. If an exiting packet does not arrive on the best return path back to the
originator, then the packet is dropped and the activity is logged. Egress filtering prevents
internal users from launching attacks using IP source addresses outside of the local domain
because most attacks use IP spoofing to hide the identity of the attacking host. Egress
filtering makes the task of tracing the origin of an attack much easier. When employed,
egress filtering enforces what IP source addresses are obtained from a valid pool of network
addresses. Addresses are kept local to the enforcing entity and are therefore easily traceable.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-55

The clear ip verify command removes ip verify commands from the configuration. Unicast RPF
is a unidirectional input function that screens inbound packets arriving on an interface. Outbound
packets are not screened.
Because of the danger of IP spoofing in the IP protocol, measures need to be taken to reduce this
risk when possible. Unicast RPF, or reverse route lookup, prevents such manipulation under
certain circumstances.
Unicast RPF is implemented as follows:
ICMP packets have no session, so each packet is checked.
UDP and TCP have sessions, so the initial packet requires a reverse route lookup.
Subsequent packets arriving during the session are checked using an existing state
maintained as part of the session. Non-initial packets are checked to ensure they arrived on
the same interface used by the initial packet.
Note

Before using the ip verify command, add static route command statements for every
network that can be accessed on the interfaces you wish to protect. Only enable ip verify if
routing is fully specified. Otherwise, the PIX Firewall will stop traffic on the interface you
specify if routing is not in place.

Use the show interface command to view the number of dropped packets, which appears in the
unicast rpf drops counter.
The icmp command implements the following:
The icmp command controls ICMP traffic that terminates on the PIX Firewall. If no ICMP
control list is configured, then the PIX Firewall accepts all ICMP traffic that terminates at
the interface.
The icmp deny command disables pinging to an interface, and the icmp permit command
enables pinging to an interface. With pinging disabled, the PIX Firewall cannot be detected
on the network. This is also referred to as configurable proxy pinging.
For traffic that is routed through the PIX Firewall only, you can use the access-list or accessgroup commands to control the ICMP traffic routed through the PIX Firewall.
It is recommended that you grant permission for ICMP unreachable message type (type 3).
Denying ICMP unreachable messages disables ICMP Path maximum transmission unit (MTU)
discovery, which can halt IPSec and Point-to-Point Tunneling Protocol (PPTP) traffic. See RFC
1195 and RFC 1435 for details about Path MTU Discovery.
If an ICMP control list is configured, then the PIX Firewall uses a first match to the ICMP traffic
followed by an implicit deny all. That is, if the first matched entry is a permit entry, the ICMP
packet continues to be processed. If the first matched entry is a deny entry or an entry is not
matched, the PIX Firewall discards the ICMP packet and generates the %PIX-3-313001 Syslog
5-56

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

message. An exception is when an ICMP control list is not configured; in that case, a permit is
assumed.
The syntax for the ip verify reverse-path interface command is as follows:
ip verify reverse-path interface int_name
int_name

Name of an interface you want to protect from a DoS attack.

ip verify reverse-path interface

Protects an individual interface against IP spoofing by enabling

both ingress and egress filtering to verify addressing and route
integrity. This command depends upon a default route previously
defined in the configuration. See RFC 2267 for more information.

The syntax for the icmp permit command is as follows:

icmp permit | deny [host] src_addr [src_mask] [type] int_name

Copyright

deny

Disables the ability to ping a PIX Firewall interface.

int_name

The interface name.

permit

Enables the ability to ping a PIX Firewall interface.

src_addr

Address that is either permitted or denied ability to ping an

interface. Use host src_addr to specify a single host.

src_mask

(Optional.) Specifies to use a network mask with the network

address entered.

type

ICMP message type.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-57

Implementation Commands
Host DoS Mitigation (cont.)

pixfirewall(config)#

-- -
Enables the IP Frag Guard feature
The sysopt commands enables you to tune various PIX
Firewall security and configuration features

-- -

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-44

The sysopt security fragguard command enables the IP Frag Guard feature. This feature is
disabled by default. This feature enforces two additional security checks, in addition to the
security checks recommended by RFC 1858, against the many IP fragment style attacks:
teardrop, land, and so on. Each non-initial IP fragments is required to be associated with an
already seen valid initial IP fragment. IP fragments are rated to 100 full IP fragmented packets
per second to each internal host. Note the following:
The IP Frag Guard feature operates on all interfaces in the PIX Firewall and cannot be
selectively enabled or disabled by interface.
The PIX Firewall uses the security fragguard command to enforce the security policy
determined by an access-list permit or access-list deny command to permit or deny packets
through the PIX Firewall.
Note

Use of the sysopt security fragguard command breaks normal IP fragmentation

conventions. However, not using this command exposes the PIX Firewall to the possibility of
IP fragmentation attacks. It is recommended that packet fragmentation not be permitted on
the network if at all possible.

Disable the security fragguard command feature if the PIX Firewall is used as a tunnel for
FDDI packets between routers.
Note

5-58

Because Linux sends IP fragments in reverse order, fragmented Linux packets will not pass
through the PIX Firewall with the sysopt security fragguard command enabled.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the sysopt security fragguard command is as follows:

sysopt security fragguard
security fragguard

Copyright

2003, Cisco Systems, Inc.

Enables the IP Frag Guard feature.

SAFE Small Network Design

5-59

Implementation Commands
Host DoS Mitigation (cont.)
pixfirewall(config)#

- -
-- -- -
- - -

The static command creates a persistent, one-to-one address

translation rule (called a static translation slot or "xlate"). This
translation can be between a local IP address and a global IP
address (static NAT) or between ports (static PAT). The
embryonic connection limit [em_limit] prevents attack by a flood
of embryonic connections. An embryonic connection is one that
has started but not yet completed. The default is 0, which means
unlimited connections.

- ---
-

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-45

The static command creates a persistent, one-to-one address translation rule (called a static
translation slot or xlate). This translation can be between a local IP address and a global IP
address (static Network Address Translation [NAT]) or between ports (static Port Address
Translation [PAT]).
For an external host to initiate traffic to an inside host, a static translation rule needs to exist for
the inside host; this can also be done using a nat 0 access-list address translation rule. Without
the persistent translation rule, the translation cannot occur.
You can use the static and access-list commands when you are accessing the interface of a higher
security level from an interface of a lower security level (for example, when accessing the inside
from a perimeter or the outside interface).
Prior to version 5.3, the PIX Firewall offered no mechanism to protect systems reachable via a
static and TCP conduit from TCP SYN attacks. Previously, if an embryonic connection limit was
configured in a static command statement, the PIX Firewall dropped new connection attempts
after the embryonic threshold was reached. Given this, a modest attack could stop an
institutions Web traffic. For static command statements without an embryonic connection limit,
the PIX Firewall passes all traffic. If the affected system does not have TCP SYN attack
protection, and most operating systems do not offer sufficient protection, then the affected
systems embryonic connection table overloads and all traffic stops.
With the new TCP intercept feature, after the optional embryonic connection limit is reached,
and until the embryonic connection count falls below this threshold, every SYN bound for the
affected server is intercepted. For each SYN, the PIX Firewall responds on behalf of the server
with an empty SYN/ACK segment. The PIX Firewall retains pertinent state information, drops
the packet, and waits for the clients acknowledgement. If the ACK is received, then a copy of
the clients SYN segment is sent to the server and the TCP three-way handshake is performed
5-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

between the PIX Firewall and the server. If this three-way handshake completes, the connection
resumes as normal. If the client does not respond during any part of the connection phase, the
PIX Firewall retransmits the necessary segment using exponential back-offs.
This feature requires no change to the PIX Firewall command set, only that the embryonic
connection limit on the static command now has a new behavior.
The syntax for the static command is as follows:
static [(prenat_interface, postnat_interface)] {mapped_address| interface} real_address [dns] [netmask mask]
[norandomseq] [connection_limit [em_limit]]

Copyright

dns

Specifies that DNS replies that match the xlate are translated.

em_limit

The embryonic connection limit. An embryonic connection is one

that has started but has not yet completed. Set this limit to
prevent attack by a flood of embryonic connections. The default is
0, which means unlimited connections.

global_ip

A global IP address. This address cannot be a Port Address

Translation (PAT) IP address. The IP address on the lower
security level interface you are accessing.

interface

Specifies to overload the global address from interface.

mapped_address

The address into which real_address is translated.

netmask

Reserve word required before specifying the network mask.

norandomseq

Do not randomize the TCP/IP packet's sequence number. Only

use this option if another inline firewall is also randomizing
sequence numbers and the result is scrambling the data. Use of
this option opens a security hole in the PIX Firewall.

postnat_interface

The outside interface when prenat_interface is the inside

interface. However, if the outside interface is used for
prenat_interface, then the translation is applied to the outside
address and the postnat_interface is the inside interface.

prenat_interface

Usually the inside interface, in which case the translation is

applied to the inside address.

real_address

The address to be mapped.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-61

Spoof Mitigation and

RFC FilteringACL
The following are ACL features:
An ACL enables you to determine what traffic will be
allowed or denied through the PIX Firewall.
ACLs are applied per interface (traffic is analyzed
inbound relative to an interface).
The access-list and access-group commands are used to
create an ACL.
The access-list and access-group commands are an
alternative for the conduit and outbound commands.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-46

The access-list command allows any outside host access to the static via a specified port. You
use the access-list and access-group commands to permit access based on source or destination
IP address, or by the protocol port number. Use the access-list command to create a single ACL
entry, and use the access-group command to bind one or more ACL entries to a specific
interface. Only specify one access-group command for each interface.

5-62

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands
Spoof Mitigation and RFC Filtering
pixfirewall(config)#

---
- --
- -
-- -

The access-list command enables you to specify if an IP address
is permitted or denied access to a port or protocol.

---

pixfirewall(config)#

--
The access-group command binds an ACL to an interface.

--
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-47

The access-list command enables you to specify if an IP address is permitted or denied access to
a port or protocol. One or more access-list command statements with the same name are referred
to as an ACL. ACLs associated with IPSec are known as crypto ACLs.
By default, all access-list commands have an implicit deny unless you explicitly specify permit.
In other words, by default, all access in an ACL is denied unless you explicitly grant access
using a permit statement.
The access-group command binds an ACL to an interface. The ACL is applied to traffic
inbound to an interface. If you enter the permit option in an access-list command statement, the
PIX Firewall continues to process the packet. If you enter the deny option in an access-list
command statement, the PIX Firewall discards the packet.
The syntax for the access-list command is as follows:
access-list acl_ID {deny | permit} protocol {source_addr | local_addr} {source_mask | local_mask}[operator port
[port] {destination_addr | remote_addr} {destination_mask | remote_mask} [operator port [port]
acl_ID

Name of an ACL. You can use either a name or number.

deny

When used with the access-group command, the deny option

does not allow a packet to traverse the PIX Firewall. By default,
the PIX Firewall denies all inbound or outbound packets unless
you specifically permit access.
When used with a crypto map command statement, deny does
not select a packet for IPSec protection. The deny option
prevents traffic from being protected by IPSec in the context of
that particular crypto map entry. In other words, it does not allow
the policy as specified in the crypto map command statements to
be applied to this traffic.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-63

destination_addr

IP address of the network or host to which the packet is being

sent. Specify a destination_addr when the access-list command
statement is used in conjunction with an access-group command
statement, or with the aaa match access-list command and the
aaa authorization command. For inbound connections,
destination_addr is the address after NAT has been performed.
For outbound connections, destination_addr is the address before
NAT has been performed.

destination_mask

Netmask bits (mask) to be applied to destination_addr, if the

destination address is a network mask.

local_addr

Address of the network or host local to the PIX Firewall. Specify a

local_addr when the access-list command statement is used in
conjunction with a crypto access-list command statement, a nat
0 access-list command statement, or a vpngroup split-tunnel
command statement. The local_addr is the address after NAT
has been performed.

local_mask

Netmask bits (mask) to be applied to local_addr, if the local

address is a network mask.

The syntax for the access-group command is as follows:

access-group acl_ID in interface interface_name

5-64

acl_ID

The name associated with a given ACL.

in interface

Filter inbound packets at the given interface.

Interface_name

The name of the network interface.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Spoof MitigationRFC 1918 Filtering

--

---

---
---

---

ISP
network

Customer
network

Ingress to Internet
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-48

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the
IP address space for private Internets:
10.0.010.255.255.255 (10/8 prefix)
172.16.0.0172.31.255.255 (172.16/12 prefix)
192.168.0.0192.168.255.255 (192.168/16 prefix)
SAFE SMR Small Network Design recommends that these networks be filtered as RFC 1918
designates them private and they are not to be routed on the Internet. It is recommended that this
filtering be completed on the ISP router as well as the PIX Firewall.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-65

Implementation Commands
Authenticate Remote Site
pixfirewall(config)#

-
- - -
- These commands specify a AAA server
The PIX Firewall enables you to define separate groups of
TACACS+ or RADIUS servers for specifying different types
of traffic

- -
- - - --

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-49

The aaa-server command enables you to specify AAA server groups. The PIX Firewall enables
you to define separate groups of TACACS+ or RADIUS servers for specifying different types of
traffic (for example, a TACACS+ server for inbound traffic and another for outbound traffic).
Another use is where all outbound HTTP traffic is authenticated by a TACACS+ server, and all
inbound traffic uses RADIUS.
AAA server groups are defined by a tag name that directs different types of traffic to each
authentication server. If the first authentication server in the list fails, the AAA subsystem fails
over to the next server in the tag group. You can have up to 14 tag groups and each group can
have up to 14 AAA servers for a total of up to 196 AAA servers.
If your RADIUS server uses ports 1812 for authentication and 1813 for accounting, you are
required to reconfigure the PIX Firewall to use ports 1812 and 1813.
If accounting is in effect, the accounting information goes only to the active server.
If you are upgrading from a previous version of the PIX Firewall and have aaa command
statements in your configuration, using the default server groups enables you to maintain
backward compatibility with the aaa command statements in your configuration.

5-66

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the aaa-server command is as follows:

aaa-server group_tag protocol auth_protocol
aaa-server

Specifies a AAA server or up to 14 groups of servers with a

maximum of 14 servers each. Certain types of AAA services can
be directed to different servers. Services can also be set up for
failover to multiple servers.

group_tag

An alphanumeric string that is the name of the server group. Use

the group_tag in the aaa command to associate aaa
authentication and aaa accounting command statements to a
AAA server. Up to 14 server groups are permitted. However,
LOCAL cannot be used with the aaa-server command because
LOCAL is predefined by the PIX Firewall.

protocol auth_protocol

The type of AAA server: either TACACS+ or RADIUS.

The syntax for the aaa-server command is as follows:

aaa-server group_tag (if_name) host server_ip key timeout seconds
aaa-server

Specifies a AAA server or up to 14 groups of servers with a

maximum of 14 servers each. Certain types of AAA services can
be directed to different servers. Services can also be set up for
failover to multiple servers.

group_tag

An alphanumeric string that is the name of the server group. Use

the group_tag in the aaa command to associate aaa
authentication and aaa accounting command statements to a
AAA server. Up to 14 server groups are permitted. However,
LOCAL cannot be used with the aaa-server command because
LOCAL is predefined by the PIX Firewall.

if_name

The interface name on which the server resides.

host server_ip

The IP address of the TACACS+ or RADIUS server.

key

A case-sensitive, alphanumeric keyword of up to 127 characters

that is the same value as the key on the TACACS+ server. Any
characters entered past 127 are ignored. The key is used
between the client and server for encrypting data between them.
The key must be the same on both the client and server systems.
Spaces are not permitted in the key, but other special characters
are.

timeout seconds

A retransmit timer that specifies the duration that the PIX Firewall
retries access four times to the AAA server before choosing the
next AAA server. The default is 5 seconds. The maximum time is
30 seconds.
For example, if the timeout value is 10 seconds, the PIX Firewall
retransmits for 10 seconds and if no acknowledgment is received,
tries three times more for a total of 40 seconds to retransmit data
before the next AAA server is selected.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-67

Implementation Commands
Authenticate Remote Site (cont.)
pixfirewall(config)#

-
-- -
Defines the AAA authentication method used.

pixfirewall(config)#

- -
Specifies a syslog server that will receive the messages sent
from the PIX Firewall.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-50

To use the aaa authentication command, you must first designate an authentication server with
the aaa-server command. Also, for each IP address, one aaa authentication command is
permitted for inbound connections and one for outbound connections.
The aaa authentication command is not intended to mandate your security policy. The
authentication servers determine whether a user can or cannot access the system, what services
can be accessed, and what IP addresses the user can access. The PIX Firewall interacts with FTP,
HTTP (Web access), and Telnet to display the credentials prompts for logging in to the network
or logging in to exit the network. You can specify that only a single service be authenticated, but
this must agree with the authentication server to ensure that both the firewall and server agree.
The syntax for the aaa-authentication command is as follows:
aaa authentication [serial | enable | telnet | ssh | http] console group_tag
authentication

Enable or disable user authentication, prompt user for username

and password, and verify information with authentication server.
When used with the console option, it enables or disables
authentication service for access to the PIX Firewall console over
Telnet or from the Console connector on the PIX Firewall.
Use of the aaa authentication command requires that you
previously used the aaa-server command to designate an
authentication server.
The aaa authentication command supports HTTP
authentication. The PIX Firewall requires authentication
verification of the HTTP server through the aaa authentication
http console command before PDM can access the PIX Firewall.

5-68

serial

Access verification for the PIX Firewall's serial console.

enable

Access verification for the PIX Firewalls privilege mode.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

telnet

Access verification for the Telnet access to the PIX Firewall

console.

ssh

Access verification for the SSH access to the PIX Firewall

console.

http

Access verification for the HTTP access to the PIX Firewall (via
PDM). The maximum username prompt for HTTP authentication
is 30 characters. The maximum password length is 15 characters.

console

Specifies that access to the PIX Firewall console requires

authentication and, optionally, logs configuration changes to a
Syslog server. The maximum password length for accessing the
console is 16 characters.

group_tag

The AAA server group tag defined by the aaa-server command.

To use the local PIX Firewall user authentication database, enter
LOCAL for this parameter.

The syntax for the logging host command is as follows:

logging host [in_if_name] ip_address [protocol/port]

Copyright

host

Specifies a Syslog server that will receive the messages sent

from the PIX Firewall. You can use multiple logging host
commands to specify additional servers that would all receive the
Syslog messages. However, a server can only be specified to
receive either UDP or TCP, not both. The PIX Firewall only sends
TCP Syslog messages to the PIX Firewall Syslog Server (PFSS).

in_if_name

Interface on which the Syslog server resides.

ip_address

Syslog server's IP address.

protocol

The protocol over which the syslog message is sent; either tcp or
udp. The PIX Firewall only sends TCP Syslog messages to the
PFSS. You can only view the port and protocol values you
previously entered by using the write terminal command and
finding the command in the listingthe TCP protocol is listed as 6
and the UDP protocol is listed as 17.

port

The port from which the PIX Firewall sends either UDP or TCP
Syslog messages. This must be same port at which the Syslog
server listens. For the UDP port, the default is 514 and the
allowable range for changing the value is 1025 through 65535.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-69

Basic Layer 7 Filtering

Java Applet Filtering

Java applet filtering enables an administrator to

prevent the downloading of Java applets by an
inside system.
Java programs can provide a vehicle through
which an inside system can be invaded.
Java applets are executable programs that are
banned within some security policies.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-51

Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of
external sites that you designate as friendly. If an applet is from a friendly site, the firewall
allows the applet through. If the applet is not from a friendly site, the applet is blocked.
(Alternately, you could permit applets from all external sites except for those you specifically
designate as hostile.)

5-70

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

filter java Command

pixfirewall(config)#

-
-
The filter java command filters out Java applets that
return to the PIX Firewall from an outbound
connection.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-52

The filter java command filters out Java applets that return to the PIX Firewall 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. Use 0 for the local_ip or foreign_ip IP
addresses to mean all hosts.
Note

If Java applets are known to be in <object> tags, use the filter activex command to remove
them.

The syntax for the filter java command is as follows:

filter java port[-port] local_ip mask foreign_ip mask

Copyright

java

Specifies to filter out Java applets returning from an outbound

connection.

port

The port that receives Internet traffic on the PIX Firewall.

Typically, this is port 80, but other values are accepted. The
HTTP or URL can be used for port 80.

local_ip

The IP address of the highest security level interface from which

access is sought. You can set this address to 0.0.0.0 (or in
shortened form, 0) to specify all hosts.

mask

Any mask.

foreign_ip

The IP address of the lowest security level interface to which

access is sought. You can use 0.0.0.0 (or in shortened form, 0) to
specify all hosts.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-71

Java Applet Filtering Example

Egress from Internet
ISP
network

Customer
network

Ingress to Internet

Filtering Java Applets on port 80 for internal

subnets on all outbound connections
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-53

RFC 2827 describes a straightforward method for using ingress traffic filtering to prohibit DoS
attacks that use forged IP addresses to be propagated from behind an ISPs aggregation point.

5-72

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ActiveX Blocking
pixfirewall(config)#

-
-
Filters out ActiveX usage from outbound
packets.
ActiveX controls are applets that can be
inserted in web pages or other applications.
ActiveX controls can provide a way for
someone to attack servers.
The PIX Firewall can be used to block ActiveX
controls.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-54

The filter activex command filters out ActiveX, Java applets, and other HTML <object> usages
from outbound packets. ActiveX controls, formerly known as Object Linking and Embedding
(OLE) or Object Linking and Embedding Control (OCX) controls, are components you can
insert in a web page or other application. These controls include custom forms, calendars, or any
of the extensive third-party forms for gathering or displaying information.
The syntax for the filter activex command is as follows:
filter activex port local_ip mask foreign_ip mask

Copyright

activex

Block outbound ActiveX, Java applets, and other HTML <object>

tags from outbound packets.

port

The port that receives Internet traffic on the PIX Firewall.

Typically, this is port 80, but other values are accepted. The http
or url literal can be used for port 80.

local_ip

The IP address of the highest security level interface from which

access is sought. You can set this address to 0.0.0.0 (or in
shortened form, 0) to specify all hosts.

mask

Any mask.

foreign_ip

The IP address of the lowest security level interface to which

access is sought. You can use 0.0.0.0 (or in shortened form, 0) to
specify all hosts.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-73

filter activex Example

Internet

Specifies that the ActiveX blocking
applies to web traffic on port 80 from
any local host and for connections to
any foreign host
Engineering
11.0.0.0

Marketing
12.0.0.0

DMZ

Executive
14.0.0.0

TACACS+
server
RADIUS
server

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-55

As a technology, ActiveX creates many potential problems for the network clients including
causing workstations to fail, introducing network security problems, or being used to attack
servers. This feature blocks the HTML <object> tag and comments it out within the HTML web
page.
Note

5-74

The <object> tag is also used for Java applets, image files, and multimedia objects, which is
also blocked by the filter activex command. If the <object> or </object> HTML tags split
across network packets or if the code in the tags is longer than the number of bytes in the
MTU, the PIX Firewall cannot block the tag.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Summary
Summary
The SAFE small network design has two modules:
Corporate Internet module
Campus module
The corporate Internet module can use either a PIX
Firewall or an IOS Firewall.
The small network campus module contains all users and
intranet servers.
The mitigation roles identified for each threat in SAFE
SMR are integral to a successful implementation.
The IOS Firewall can be implemented to perform as a
firewall, an IDS, and an authentication proxy.
The PIX Firewall can be used to secure the internal
network as well as allowing for the addition of a DMZ.
2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.15-57

SAFE Small Network Design

5-75

5-76

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Lab ExerciseSAFE Small Network Design

Implementation
Complete the following lab exercise to practice what you learned in this chapter.
The lab exercise has the following sub-sections:
PIX Firewall Configuration
IOS Router Configuration

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-1

Visual Objectives
The following figure displays the configuration you will complete in this lab exercise.

Lab Visual Objective

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24
.150

.10P e0/1

Branch

brP
.1 e0/0

10.2.P.0/24

RBB
.1

10.2.P.11

Branch

.2

.150

172.16.P.0/24

Super
Server
WWW
FTP

PSS
WWW
FTP
.10

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP
.2 e0

priv

.1 e4

.1 e2

.5

.1 e1

.50
.4

DMZ
.5

pP

10.0.P.0 /24

pub
172.18.P.0/24

cP
.100

RTS

sensorP

Student

10.0.P.11

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.15-1

PIX Firewall Configuration

Complete the following lab exercise to practice what you learned in this chapter.

Objectives
In this lab exercise, you will configure the PIX Firewall to secure the corporate network by
completing the following tasks:
Initial configuration of the PIX Firewall.
Configure global addresses, NAT, and routing.
Deny outbound traffic from the public services segment network.
Allow outbound traffic from internal networks.
Allow necessary Internet services to the public services segment server.
Implement spoofing protection.
Enable logging to the management server on the internal corporate network.
Lab 5-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Assign Telnet and enable passwords.

Test and verify the configuration.

Network Security Policy

You will implement the following security policies in this lab exercise:
Control incoming traffic:

Allow Internet users access to public services segment server and services.

Allow corporate users access to public services segment server and services.

Deny Internet users access to the corporate office internal network.

Deny inbound traffic from the 127.0.0.0, 192.168.0.0, and 10.0.P.0 networks
(where P = pod number).
Permit Internet Control Message Protocol (ICMP) echo replies to internal networks.
Permit ICMP echo request to all PIX interfaces. The outside interface should not
respond to requests from untrusted networks.

Control outgoing traffic:

Deny traffic initiated from the PSS server.

Allow corporate users access to the Internet.

Apply PIX Firewall hardening and management:

Enable logging.

Assign Telnet and enable passwords.

Setup
Before starting this lab exercise, make sure the PIX Firewall is turned on and that your PC is
connected to the PIX Firewall.
Note

Copyright

The instructor will provide you with the procedures for access to the PIX Firewall console port,
as this will vary according to your lab connectivity. After you access the PIX Firewall console
port, the PIX Firewall prompt appears.

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-3

Task 1Initial Configuration of the PIX Firewall

Complete the following steps to perform the basic initial configuration of the PIX Firewall:
Step 1

Complete a write erase on the PIX Firewall to use a default configuration:

-

Step 2

(where P = pod number)

Check your current configuration to familiarize yourself with the current setup:

Step 3

(where P = pod number)

Assign the PIX Firewall a name, and assign the interfaces the names and security levels defined
in the following table:
Interface

Interface Name

Security Level

ethernet0

outside

ethernet1

inside

100

ethernet2

pss

50

-
- -
- -
-
-

(where P = pod number)

Q1)

What are the default interface names and security levels? Why is it important to assign
the appropriate security levels?
A)

Step 4

Assign IP addresses to the inside, outside, and PSS network interfaces defined in the following
table:
Interface Name

IP Address

Netmask

outside

192.168.P.2

255.255.255.0

inside

10.0.P.1

255.255.255.0

pss

172.16.P.1

255.255.255.0

(where P = pod number)

-- -
-- -
-- --

(where P = pod number)

Lab 5-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 5

Enable the interfaces and set the interface speeds defined in the following table:
Interface Name

Speed

ethernet0

100full

ethernet1

10full

ethernet2

100full

Step 6

(where P = pod number)

Ensure that the IP addresses are correctly configured and are associated with the proper network
interface:
- --

Step 7

(where P = pod number)

Write the configuration to the Flash memory:

(where P = pod number)

Task 2Configure Global Addresses, NAT, and Routing

Complete the following steps to configure a global address pool, NAT, and routing:
Step 1

Assign pools of IP addresses for use by outbound connections defined in the following table:
Interface Name

Global Pool ID

IP Address Range

Netmask

outside

192.168.P.33-222

255.255.255.0

outside

192.168.P.225-254

255.255.255.224

(where P = pod number)

- -

- -

# -

(where P = pod number)

Step 2

Configure the PIX Firewall to allow all inside hosts to use NAT for outbound access. Assign the
hosts to use global pool identity 1.
-

(where P = pod number)

Q2)

Why is the internal network address specified instead of the wildcard network address
(0.0.0.0)?
A)

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-5

Step 3

Assign the perimeter routers inside interface as the PIX Firewalls default route:
# -

(where P = pod number)

Q3)

Is using a default route preferred over obtaining routes via a routing protocol? Why or
why not?
A)

Step 4

Write the current configuration to Flash memory:

#

Step 5

(where P = pod number)

Write the current configuration to the terminal and verify that you have entered the previous
commands correctly:

Step 6

(where P = pod number)

Ping the following devices from the PIX Firewall to ensure they are operational:
PIX Firewall inside interface10.0.P.1
(where P = pod number)
Student PC10.0.P.11
(where P = pod number)
PIX Firewall outside interface192.168.P.2
(where P = pod number)
Perimeter router192.168.P.150
(where P = pod number)
PIX Firewall public services segment interface172.16.P.1
(where P = pod number)
Public services segment server172.16.P.50
(where P = pod number)

(where P = pod number)

Lab 5-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Create a static network mapping between the inside and public services segment networks to
gain access from the inside networks to the public services segment network:

Step 7

- --- -

(where P = pod number)

Q4)

What are some advantages and disadvantages to statically mapping the inside network in
this case?
A)

Confirm your entries:

Step 8

-
-

(where P = pod number)

Assign a name to the public services segment servers private address using the name command,
and verify that the name was entered properly:

Step 9

IP Address

Name

172.16.P.50

www-private

(where P = pod number)

-

(where P = pod number)

Step 10

Write the current configuration to Flash memory:

(where P = pod number)

Step 11

Test connectivity to the public services segment server from the student PC:
1. Test ICMP access does not work to the public services segment server: 172.16.P.50.
(where P = pod number)
2. Test FTP and web access to public services segment server: 172.16.P.50.
(where P = pod number)

Task 3Deny Outbound Traffic from the Public Services Segment

Network
Complete the following steps to deny outbound traffic from the public services segment
network:
Step 1

Create an access control list (ACL) to permit ICMP echo-replies to the internal networks and
deny outbound traffic from the public services segment network:
---

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-7

Continue creating your ACL:

--- -
---

(where P = pod number)

Step 2

Bind the ACL to the public services segment interface by creating an access group:
-- --

(where P = pod number)

Step 3

Confirm that the public services segment server cannot gain access outside of its local subnet:
1. Test ICMP access to perimeter router: 192.168.P.150.
(where P = pod number)
2. Test FTP and web access to the Student PC: 10.0.P.11.
(where P = pod number)
3.

Q5)

Test ICMP access to the VPN Client PC: 172.26.26.P.

(where P = pod number)
Why is it important to restrict outbound access from the public services segment
network?
A)

Step 4

Confirm that you still have connectivity to the public services segment server from the Student
PC:
1. Test ICMP access to the public services segment server: 172.16.P.50.
(where P = pod number)
2. Test FTP and web access to public services segment server: 172.16.P.50.
(where P = pod number)

Task 4Allow Outbound Traffic from Internal Networks

Complete the following steps to allow outbound traffic from internal networks:
Step 1

Add an access-list command statement to permit IP traffic from internal networks:

---

(where P = pod number)

Q6)

Would you recommend being more restrictive? Why?

A)

Step 2

Bind the ACL to the inside interface by creating an access group:

-- -

Step 3

Lab 5-8

Confirm that you still have connectivity to the public services segment server from the Student
PC:

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

1. Test ICMP access to the public services segment server: 172.16.P.50.

(where P = pod number)
2. Test FTP and web access to public services segment server: 172.16.P.50.
(where P = pod number)
Q7)

Why is it important to restrict outbound access to known internal network addresses

and hosts?
A)

Task 5Allow Necessary Internet Services to the Public Services

Segment Server
Complete the following steps to allow necessary Internet services to the public services segment
server:
Step 1

Create a static translation for your public services segment server, and set the maximum number
of connections to unlimited and set the embryonic limit to 1000:
- --- -

(where P = pod number)

Step 2

Assign a name to the public services segment servers public address using the name command
and verify that the name was entered properly:
IP Address

Name

192.168.P.11

www-public

(where P = pod number)

-

(where P = pod number)

Step 3

Create ACLs to deny RFC 2827 and 1918 traffic.

Note

The course lab topology does not allow for including the complete RFC 1918 private
addresses. The listed addresses are those that do not affect the communication between the
lab equipment. For actual implementation, include all appropriate RFC 1918 private addresses
applicable to your network.

---
---

(where P = pod number)

Q8)

What threat do these ACL entries help mitigate?

A)

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-9

Step 4

Create an ACL to allow inbound web and FTP access to the public address of the public services
segment server:
--- -
--- -

Step 5

(where P = pod number)

Create an ACL to allow ICMP echo replies initiated from the internal network, and deny all
other traffic:
---

---

(where P = pod number)

Step 6

Bind the ACL to the outside interface:

-- -

Step 7

(where P = pod number)

Display the ACL and observe the hit counts:
- ---

Step 8

(where P = pod number)

Deny pings to the outside interface:

-
Step 9

(where P = pod number)

Write the current configuration to Flash memory:

(where P = pod number)

Step 10 Verify the configuration by performing the following test from the VPN Client PC:
1. Test that ICMP access does not work to the outside interface of the PIX Firewall:
192.168.P.2.
(where P = pod number)
2. Test FTP and web access to a public services segment server: 192.168.P.11.
(where P = pod number)

Task 6Implement Spoofing Protection

Complete the following steps to implement Unicast Reverse Path Forwarding (RPF) IP spoofing
protection:
Step 1

Enable Unicast RPF IP spoofing protection for the outside and public services segment
interfaces:
- -
-

Step 2

(where P = pod number)

Write the current configuration to Flash memory:

(where P = pod number)

Lab 5-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 7Enable Logging to the Management Server on the Internal

Corporate Network
Complete the following steps to implement logging:
Step 1

Enable logging and send information log messages to the management PC:

-

(where P = pod number)

Q9)

What are some of the benefits of device logging? What determines the appropriate
logging level?
A)

Step 2

Write the current configuration to Flash memory:

(where P = pod number)

Task 8Assign Telnet and Enable Passwords

Complete the following steps to assign Telnet and enable passwords:
Step 1

Configure and set your enable password:

--
-- -

(where P = pod number)

Step 2

Write the current configuration to Flash memory:

Step 3

(where P = pod number)

Compare your configuration to the following sample configuration from pix1:

-
- -
- -
-
-
-
-
--
--
-

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-11




-
-
-
-
-
-
-
-


---
--- -
---
---
---
--- -
--- -
---
---
-


- -



-
-
-
-
-
-




-- -
-- -
--
--
--
Lab 5-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 --
- -
-





-- -
-- -
--
--
--
--
-

- -
- -
-
- - -
- - -
-- -
-- -
--
-

-
-
-
-
- -
- -
--
--
--
--
--

--

-

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-13

Task 9Test and Verify the Configuration

Complete the following steps to test your configuration:
Step 1

Ensure that you cannot access the public services segment server from the VPN client PC via
ICMP, but can access it via FTP and web access:
1. Test ICMP access to the public services segment server: 192.168.P.11.
(where P = pod number)
2. Test FTP and web access to the public services segment server: 192.168.P.11.
(where P = pod number)

Step 2

Ensure that you cannot access the internal corporate network from the VPN client PC:
1. Test ICMP access to the Student PC: 10.0.P.11.
(where P = pod number)
2. Test FTP and web access to the Student PC: 10.0.P.11.
(where P = pod number)

Step 3

Ensure that you can access the Internet from the Student PC:
1. Test ICMP access to the VPN Client PC: 172.26.26.P.
(where P = pod number)
2. Test FTP and web access to the VPN client PC: 172.26.26.P.
(where P = pod number)

Step 4

Ensure that you cannot initiate a connection to any network from the public services segment
server:
1. Test ICMP access to the Student PC: 10.0.P.11.
(where P = pod number)
2. Test FTP and web access to the Student PC: 10.0.P.11.
(where P = pod number)

Step 5

Continue ensuring that you cannot initiate a connection to any network from the public services
segment server:
1. Test ICMP access to the VPN Client PC: 172.26.26.P.
(where P = pod number)
2. Test FTP and web access to the VPN Client PC: 172.26.26.P.
(where P = pod number)

Lab 5-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS Router Configuration

Complete the following lab exercise to practice what you learned in this chapter.

Objectives
In this lab exercise you will complete the following tasks:
Secure the branch office router network services.
Secure management access to the branch office router.
Configure NAT IOS features.
Implement access control filtering.
Configure CBAC and IDS features.
Test the branch office router configuration.

Network Security Policy

You will implement this network security policy in this lab exercise:
Secure the branch office router network services:

Create a warning banner that is displayed when an interactive session is established.

Enforce password encryption to protect device passwords.

Disable unnecessary network services.

Log branch office router events:

Send branch router Syslog output to the internal Syslog server on the branch office
server.

Log informational events on the branch office router to the Syslog server.

Set accurate time-stamping for log and debug messages.

Control administrator access to the branch office router to prevent unauthorized access:

Copyright

Control access into the router from the console, aux ports, and the vty lines.

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-15

Allow Telnet to the perimeter router only from the student system inside the branch
office network.
Authenticate Telnet sessions with usernames and passwords entered into the perimeter
routers local security database.
Log all administrator attempts to the Syslog server.

Implement Network Address Translation (NAT) and Port Address Translation (PAT)
features to hide the internal network addresses.
Prevent source address spoofing:

Deny outgoing IP traffic with the corporate internal address as the source address.

Deny packets with local host, broadcast or multicast (or both), source addresses.

Deny packets without any source address.

Control incoming and outgoing traffic:

Permit incoming traffic that is part of a session that originated from the branch office
network or the corporate office network.

Permit outgoing traffic only from a valid internal network address.

Permit routing updates from the ISP backbone router.

Log all disallowed connections to the Syslog server.

Configure Context-Based Access Control (CBAC) and IOS intrusion detection system (IDS)
features:

Inspect common application protocols and generic TCP and UDP sessions.

Disable IOS IDS informational signatures.

Enable IOS IDS attack signatures to alarm and drop matching packets.

Setup
You should not have to configure any routing or addressing of interfaces on lab equipment in
this exercise. Before starting this lab exercise, set up your equipment so that you can do the
following from the branch office equipment:
Ping the branch office routers inside and outside interfaces from the branch office PC.
Lab 5-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Ping the backbone router in the cloud network from the branch office router.
Establish connectivity to corporate DMZ network resources.
Ensure the Syslog server is running on the branch office PC.

Task 1Secure the Branch Office Router Network Services

Complete the following steps to secure your branch office router. Example command entries are
included with each step. Substitute network and IP addresses from your network where given in
an example.
Step 1

Create a warning message that is displayed when a user establishes an interactive session:
-
-

Step 2

(where P = pod number)

Enable password encryption and assign a secret enable password to protect the routers
passwords:
- --
- -

Step 3

(where P = pod number)

Disable unnecessary network and router services to limit the exposure to direct attacks against
the router:
-

-
- -- - -- -
-

-

Note

Interface configuration commands must be done on each router Ethernet interface.

-
Step 4

(where P = pod number)

Enable logging to the Syslog server to provide a method to monitor router events including
attacks:
- -- -

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-17

(where P = pod number)

Task 2Secure Management Access to the Branch Office Router

Complete the following steps to secure management access to the branch office router:
Step 1

Create a standard ACL to permit management access from the branch PC:
--- -

Step 2

(where P = pod number)

Assign a password to the VTY lines (04), and allow VTY line access only from management
workstations to the router to prevent access by unauthorized users:

-- -
----

-
-

Step 3

(where P = pod number)

Assign a password to the console line to prevent access by unauthorized users:

-- -

-

Step 4

(where P = pod number)

Create a local user account on the router that is used to log into the router:
- - -- -

Step 5

(where P = pod number)

Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU
time for system processes:
-

(where P = pod number)

Task 3Configure NAT IOS Features

Note

Skip this task if you are in a remote lab environment.

Complete the following steps to enable the NAT features to hide the internal network address.
Example command entries are included with each step.
Step 1

Establish static translation between an inside local address and an inside global address:

Lab 5-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 - - -
Step 2

(where P = pod number)

Specify the inside interface and enter interface configuration mode:

Step 3

(where P = pod number)

Mark the interface as connected to the inside:
-

Step 4

(where P = pod number)

Specify the outside interface and enter interface configuration mode:

Step 5

(where P = pod number)

Mark the interface as connected to the outside:
-

(where P = pod number)

Q10)

The interface name is specified instead of the IP address. Why might this be preferred
instead of specifying the interfaces IP address?
A)

Task 4Implement Access Control Filtering

Complete the following steps to configure access control filtering to prevent IP spoofing attacks.
Example command entries are included with each step.
Step 1

Create an ACL that meets the following criteria:

Allows traffic from the ISP router
Allows traffic from the corporate office including internal addresses
Prevents network traffic with source addresses of the branch office network
--- - -

--- - -

--- -
---

(where P = pod number)

Q11)

Is allowing ICMP traffic to the branch routers outside interface acceptable? Why or
why not?
A)

Step 2

Copyright

Create an ACL that filters RFC 1918 addresses that do not conflict with your network addresses.

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-19

Note

The course lab topology does not allow for including the complete RFC 1918 private
addresses. The listed addresses are those that do not effect the communication between the
lab equipment. For actual implementation, include all appropriate RFC 1918 private addresses
applicable to your network.

---
---
Step 3

(where P = pod number)

Create an ACL that filters eigrp routing updates to the branch office router and network:
--- -
---
---

Step 4

(where P = pod number)

Apply the ACL inbound to the routers public interface to prevent traffic from entering the
branch office network:

--

Step 5

(where P = pod number)

Create an ACL that only allows outbound traffic originating from the internal network.
Warning

To avoid being locked out of your router and ensure outside connectivity, enter the network
address of the branch office.

---
---
Step 6

(where P = pod number)

Apply the ACL inbound to the routers private interface to allow the branch office networks to
initiate outbound connections:

--

(where P = pod number)

Task 5Configure CBAC and IDS Features

Complete the following steps to configure CBAC and IDS features. Example command entries
are included with each step.
Step 1

Enable inbound CBAC inspection on the inside interface for the following protocols:
TCP
UDP
FTP
H323

Lab 5-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

RealAudio
-
-
-
-
-

-

(where P = pod number)

Q12)

What other protocols might you consider adding to the inspection list? Why?
A)

Step 2

Configure an IOS IDS on the inside interface to perform the following:

Disable informational signatures
Alarm and drop attack signatures
Report the attacks to a Syslog server



-

-

(where P = pod number)

Task 6Test the Branch Office Router Configuration

Complete the following steps to confirm that the branch office is configured correctly:
Step 1

Ping the branch office routers inside and outside interface from the branch office PC:

Step 2

(where P = pod number)

Establish a Telnet session to the branch office router from the branch office PC:

(where P = pod number)

If you are unable to telnet to your branch office router, console into your branch office router
and check the ACLs applied to your VTY lines and inside interface.
Step 3

Verify HTTP and FTP connectivity to the corporate Web server: 192.168.P.11.
(where P = pod number)

Step 4

Verify that the address translation is working properly using the show ip nat command:

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-21

 - Step 5

(where P = pod number)

Compare your configuration to the following:



-
- --
- --
- --

-
-
--

- - --
-
-
-

-
-
-
-
-
-


-
-
--
-- -

--

Lab 5-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

--
--

-
-
-

--

--
--

-

-

- - -
--- -

---
--- - -
--- - -
--- -
Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-23

---
---

---

---

---

---

---

---
---

-
-

--

-


----

--

-
-

Lab 5-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Answers
Q1)

What are the default interface names and security levels? Why is it important to assign
the appropriate security levels?
A)

Q2)

Why is the internal network address specified instead of the wildcard network address
(0.0.0.0)?
A)

Q3)

Copyright

The public services segment network is a publicly accessible network that

provides public services that are requested by an end-user. The servers on this
network should never initiate outbound traffic. Restricting outbound access
ensures that if the servers are compromised the server cannot be used to either
propagate a virus to other networks or be used as a launching point for future
attacks.

Would you recommend being more restrictive? Why?

A)

Q7)

Statically mapped address help provide a record of the traffic initiated by the
actual IP address instead of the translated address. A possible disadvantage is
exposing the actual IP address to networks that do not have a need to know.

Why is it important to restrict outbound access from the public services segment
network?
A)

Q6)

A default route is preferred because you can have a higher level of trust over
static routes as opposed to learned routes.

What are some advantages and disadvantages to statically mapping the inside network in
this case?
A)

Q5)

To control the networks that are translated. Specifying the wildcard could
possibly allow rogue networks access to other networks.

Is using a default route preferred over obtaining routes via a routing protocol? Why or
why not?
A)

Q4)

The default interface names are outside and inside. The security levels are
important to define the traffic flows that require access controls to permit or
deny traffic.

It depends on the companys security policy. In general being more restrictive

requires additional management, but does reduce the likelihood of internal users
from access unknown or private networks.

Why is it important to restrict outbound access to known internal network addresses

and hosts?

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-25

A)
Q8)

What threat do these ACL entries help mitigate?

A)

Q9)

This might be preferred in those network environments where the branch office
is dynamically assigned an IP address by the ISP.

Is allowing ICMP traffic to the branch routers outside interface acceptable? Why or
why not?
A)

Q12)

Device logging enables the network security administrator to visibility into what
traffic is being allowed or denied. The companys security policy should
ultimately determine the appropriate logging level. Some logistical issues that
effect logging are as follows: disk space, log file analysis, and log file rotation.

The interface name is specified instead of the IP address. Why might this be preferred
instead of specifying the interfaces IP address?
A)

Q11)

These ACL entries are used to mitigate IP spoofing attacks where the attacker
uses internal addresses.

What are some of the benefits of device logging? What determines the appropriate
logging level?
A)

Q10)

This prevents internal users from creating their own networks and accessing
outside networks without prior approval.

Allowing ICMP traffic is ultimately determined by a companys security policy.

The risk of allowing ICMP should be weight against the operational
requirements. Most companies feel that allowing certain types of ICMP packets
is an acceptable risk.

What other protocols might you consider adding to the inspection list? Why?
A)

Other common protocols that could be added are TFTP, HTTP, and Java. The
protocols are covered to some degree by TCP and UDP but provide more
specific inspection.

Lab 5-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network

Design
Overview
This chapter includes the following topics:
Objectives
Midsize network corporate Internet module
Midsize network corporate Internet module design guidelines
Midsize network campus module
Midsize network campus module design guidelines
Midsize network WAN module
ImplementationISP router and edge router
ImplementationIOS Firewall
ImplementationPIX Firewall
ImplementationNIDS
ImplementationVPN Concentrator

ImplementationLayer 3 switch
Summary
Lab exercise

6-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Objectives
This section lists the chapters objectives.

Objectives

Upon completion of this chapter, you will be able to perform the

following tasks:
Identify the functions of modules and the key devices in a
Midsize network.
Understand specific threats and mitigation roles of Cisco
devices.
Recommend alternative devices for network implementation.
Implement specific configurations to apply the mitigation roles.

2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.16-2

SAFE SMR Midsize Network Design

6-3

Midsize Network Corporate Internet Module

The SAFE: Extending the Security Blueprint to Small, Midsize, and Remote-User Networks
(SAFE SMR) midsize network design consists of three modules: the corporate Internet module,
the campus module, and the WAN module.

SAFE Design for Midsize Network

SP edge

Midsize network
or branch edge

Midsize network
or branch Campus

PSTN module

Corporate Internet module

Campus module
Management
server

PSTN

Corporate
users

ISP edge
module

Internet
Frame or ATM
module

FR/ATM
2003, Cisco Systems, Inc. All rights reserved.

Public
services

WAN module

Corporate
servers

CSI 1.16-4

As in the small network design, the corporate Internet module has the connection to the Internet,
and terminates VPN traffic and public-services traffic (Domain Name System [DNS], HTTP,
File Transfer Protocol [FTP], and Simple Mail Transfer Protocol [SMTP]). Dial-in traffic also
terminates at the corporate Internet module. The campus module contains the Layer 2 and Layer
3 switching infrastructure along with all the corporate users, management servers, and intranet
servers.
From a WAN perspective, there are two options for the remote sites connecting into the midsize
design. The first is a private WAN connection using the WAN module; the second is an IPSec
virtual private network (VPN) into the corporate Internet module. Most of the discussion on this
design is based on the midsize network operating as the head-end for a corporation. Specific
design changes when used as a branch are also included.

6-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Corporate

Internet ModuleKey Devices
The following are
key devices:

Servers
Dial-in
SMTP
DNS
FTP or HTTP
Firewall
Layer 2 switch
NIDS appliance
VPN Concentrator
Edge router

2003, Cisco Systems, Inc. All rights reserved.

PSTN

Internet

Public
services

CSI 1.16-5

The goal of the corporate Internet module for a midsize network is to provide internal users with
connectivity to Internet services and Internet users access to information on the public servers
(DNS, FTP, HTTP, and SMTP). Additionally, this module terminates VPN traffic from remote
users and remote sites as well as traffic from traditional dial-in users.
The following are key devices used in the corporate Internet module for a midsize network:
Dial-in serverAuthenticates individual remote users and terminates their analog
connections
SMTP serverActs as a relay between the Internet and the intranet mail servers and inspects
content
DNS serverServes as authoritative external DNS server for the midsize network and relays
internal requests to the Internet
FTP or HTTP serverProvides public information about the organization
FirewallProvides network-level protection of resources and stateful filtering of traffic,
provides differentiated security for remote access users, and authenticates trusted remote
sites and provides connectivity using IPSec tunnels
Layer 2 switches (with private VLAN support)Provides Layer 2 connectivity for devices
NIDS applianceProvides Layer 4-to-Layer 7 monitoring of key network segments in the
module
Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-5

VPN ConcentratorAuthenticates individual remote users and terminates their IPSec

tunnels
Edge routerProvides basic filtering and Layer 3 connectivity to the Internet

6-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats
and Mitigation Roles

The following threats can be

expected:
Unauthorized access
Application layer attacks
Virus and Trojan horse attacks
Password attacks
DoS

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-6

From a threat perspective, a small or midsized network is like most networks connected to the
Internetthere are internal users who need access out and external users who need access in.
Several common threats can generate the initial compromise that a hacker needs to further
penetrate the network with secondary exploits.
The following threats can be expected in the SAFE SMR Midsize network:
Unauthorized accessMitigated through filtering at the ISP, edge router, and corporate
firewall
Application layer attacksMitigated through IDSs at the host and network levels
Virus and Trojan horse attacksMitigated through e-mail content filtering, HIDSs, and
host-based virus scanning
Password attacksLimited services available to brute force (operating systems and IDSs
can detect the threat)
DoSCAR at the ISP edge and TCP setup controls at the firewall

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-7

Expected Threats and

Mitigation Roles (cont.)

IP spoofing
Packet sniffers
Network reconnaissance
Trust exploitation
Port redirection

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-7

IP spoofingRFC 2827 and 1918 filtering at the ISP edge and midsize network edge router
Packet sniffersA switched infrastructure and an HIDS to limit exposure
Network reconnaissanceAn IDS detects reconnaissance, and filters protocols to limit
effectiveness
Trust exploitationRestrictive trust model and private VLANs to limit
trust-based attacks
Port redirectionRestrictive filtering and an HIDS to limit attacks
The publicly addressable servers are likely points of attack within the SAFE SMR Midsize
corporate Internet module. These systems will likely be attacked with application layer
vulnerabilities and denial of service (DoS) attacks.
The remote access and site-to-site VPN services are also points of attack within this module. The
following are expected threats:
Network topology discoveryAccess control lists (ACLs) on the ingress router limit access
to the Cisco VPN Concentrator and firewall (when used to terminate IPSec tunnels from
remote sites), to Internet Key Exchange (IKE), and to Encapsulating Security Payload (ESP)
from the Internet.
Password attackOne-time passwords (OTP) mitigate brute force password attacks.

6-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Unauthorized accessFirewall services after packet decryption prevent traffic on

unauthorized ports.
Man-in-the-middle attacksThese attacks are mitigated through encrypted remote traffic.
Packet sniffersA switched infrastructure limits the effectiveness of sniffing.
Though statistics vary on the percentage, it is an established fact that most attacks come from the
internal network. Disgruntled employees, corporate spies, visiting guests, and inadvertent
bumbling users are all potential sources of such attacks. When designing security, you must be
aware of the potential for internal threats.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-9

Midsize Network Attack Mitigation Roles

for Corporate Internet ModuleOverview
Authenticate users
and terminate
analog dial

Authenticate users
and terminate IPSec

Private VLANs

PSTN

Focused Layer
47 analysis

Spoof
mitigation
basic filtering
Spoof
mitigation,
and
rate-limiting

Stateful packet filtering,

basic Layer 7 filtering,
host DoS mitigation,
authenticate remote
sites, and terminate
IPSec

SMTP content
inspection

Internet

2003, Cisco Systems, Inc. All rights reserved.

Focused Layer
47 analysis

HIDS for local

attack mitigation
CSI 1.16-8

The overall roles and relative location of each device are detailed in the figure. Each device will
be discussed in detail in the following sections.

6-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Corporate Internet Module

Design Guidelines
This section details the functionality of each of the devices within the corporate Internet module.

Design Guidelines ISP Router

PSTN
Spoof mitigation,
and
rate-limiting
Internet

Public
services

The following are the primary functions of the ISP router:

Provides Internet connectivity
Rate-limits non-essential traffic
Provides RFC 1918 and 2827 filtering
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-10

The primary function of the customer-edge router in the ISP (ISP router) is to provide
connectivity to the Internet or ISP network. The egress of the ISP router rate limits nonessential
traffic that exceeds prespecified thresholds in order to mitigate against distributed denial of
service (DdoS) attacks. Finally, at the egress of the ISP router, RFC 1918 and RFC 2827
filtering is configured to mitigate against source-address spoofing of local networks and private
address ranges.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-11

Design Guidelines for the Edge Router

PSTN

Spoof mitigation
and basic
filtering
Internet

Public
services

The edge router establishes a demarcation point.

Filtering on the edge router should be configured to allow only
expected traffic to expected destinations.
RFC 1918 and 2827 filtering should be enabled on the edge router.
The edge router should be configured to drop most fragmented
packets.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-11

The function of the edge router on the midsize network is to provide the demarcation point
between the ISP network and the midsize network. At the ingress of the edge router on the
midsize network, basic filtering limits access to allow only expected IP traffic. This provides a
coarse filter for the most basic attacks.
RFC 1918 and RFC 2827 filtering is also provided as a verification of the ISPs filtering. In
addition, because of the enormous security threat that they create, the router is configured to
drop most fragmented packets that should not generally be seen for standard traffic types on the
Internet. Any legitimate traffic lost because of this filtering is considered acceptable when
compared to the risk of allowing such traffic.
Any IPSec traffic destined for the VPN Concentrator or the firewall is allowed through. Filtering
on the router is configured to allow only IKE and IPSec traffic to reach the VPN Concentrator or
firewall. Because with remote access VPNs the IP address of the remote system is not generally
known, the filtering can be specified only to the head-end peer (VPN Concentrator) with which
the remote users are communicating. With site-to-site VPNs, the IP address of the remote site is
usually known; therefore, filtering may be specified for VPN traffic to and from both peers.

6-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines for a Firewall

Stateful packet filtering, basic
Layer 7 filtering, host DoS
mitigation, authenticate remote
sites, and terminate IPSec

PSTN

Internet

Public
services

The firewalls primary functions include the following:

Provides connection-state enforcement
Terminates site-to-site IPSec VPNs
Provides DMZs
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-12

The primary function of the PIX Firewall is to provide connection-state enforcement and
detailed filtering for sessions initiated through the firewall. The firewall also acts as a
termination point for site-to-site IPSec VPN tunnels for both remote site production and remote
site management traffic.
There are multiple segments off the firewall. The first is the public services segment
(Demilitarized Zone), which contains all the publicly addressable hosts. The second is for remote
access VPN and dial-in.
DNS should be locked down to respond only to desired commands and eliminate any
unnecessary responses that might assist hackers in network reconnaissance. This includes
preventing zone transfers from anywhere except legitimate secondary DNS servers.
The SMTP server includes mail-content inspection services that mitigate virus attacks and
Trojan horse attacks generated against the internal network, which are usually introduced
through the mail system. The firewall itself filters SMTP messages at Layer 7 to allow only
necessary commands to the mail server.
Publicly addressable servers have some protection against TCP SYN floods through mechanisms
such as the use of half-open connection limits on the firewall. From a filtering standpoint, in
addition to limiting traffic on the public services segment to relevant addresses and ports,
filtering in the opposite direction also occurs. If an attack compromises one of the public servers
(by circumventing the firewall, host-based intrusion detection system [HIDS], and networkbased intrusion detection system [NIDS]), that server should not be able to further attack the
network.
To mitigate this type of attack, specific filtering prevents any unauthorized requests from being
generated by the public servers to any other location. As an example, the web server should be
Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-13

filtered so that it cannot originate requests of its own, but merely respond to requests from
clients. This setup helps prevent a hacker from downloading additional utilities to the
compromised device after the initial attack. It also helps stop unwanted sessions from being
triggered by the hacker during the primary attack. An attack that generates an xterm from the
web server through the firewall to the hackers machine is an example of such an attack.
Private VLANs prevent a compromised public server from attacking other servers on the same
segment. This traffic is not even detected by the firewall, a fact that explains why private
VLANs are critical.

6-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines
for Intrusion Detection
Focused Layer
47 analysis

PSTN

Internet

Focused Layer
47 analysis

Public
services

The following are the primary NIDS functions:

Detects attacks on ports that the firewall permits
Provides final analysis of attacks
Provides TCP shunning or resets
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-13

The public services segment includes an NIDS appliance. The primary function of an NIDS is to
detect attacks on ports that the firewall is configured to permit. These attacks are most often
application-layer attacks against specific services. The NIDS on the public services segment
should be set in a restrictive stance because signatures matched here have successfully passed
through the firewall already.
Each of the servers has and HIDS on it as well. The primary function of an HIDS is to monitor
against any rogue activity that occurs at the operating-system level as well as in common server
applications (FTP, HTTP, SMTP, and so on).
The NIDS appliance between the private interface of the firewall and the internal router provides
a final analysis of attacks. Very few attacks should be detected on this segment because only
responses to initiated requests, a few select ports from the public services segment, and traffic
from the remote access segment are allowed to the inside. Only sophisticated attacks should be
seen on this segment because they could mean that a system on the public services segment has
been compromised and the hacker is attempting to take advantage of this foothold to attack the
internal network.
For example, if the public SMTP server was compromised, a hacker might try to attack the
internal mail server over TCP port 25, which is permitted to allow mail transfer between the two
hosts. If attacks are seen on this segment, the responses to those attacks should be more severe
than those on other segments because they probably indicate that a compromise has already
occurred. The use of TCP resets or shunning to thwart, for example, the SMTP attack mentioned
previously, should be seriously considered.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-15

Design Guidelines for

the Remote Access VPN
PSTN
Authenticate users
and terminate IPSec

Internet

Public
services

The VPN Concentrator provides the following:

Secure connectivity
Authenticate users
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-14

The primary function of the remote access VPN Concentrator is to provide secure connectivity
to the midsize network for remote users.
Following termination of the VPN tunnel, traffic is sent through a firewall to ensure that VPN
users are appropriately filtered. This setup also enables IDS shunning to take place on the
firewall. This scenario is in contrast to many deployments today that place the firewall in front of
the VPN device. When placed in front, no visibility into the specific types of user traffic is
possible because the traffic is still encrypted.
Via IPSec policy sent from the Concentrator to the client, users are prevented from enabling split
tunneling, thereby forcing users to access the Internet via the corporate connection. The IPSec
parameters used are Triple Data Encryption Standard (3DES) for encryption and secure hash
algorithm (SHA) and hash-based message authentication code (HMAC) for data integrity.

6-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines for

Dial-In Access Users
Authenticate users
and terminate
analog dial

PSTN

Internet

Public
services

Traditional dial-in users are terminated on an

access router with built-in modems. CHAP is used
to authenticate the user along with the AAA server.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-15

The traditional dial-in users are terminated on an access router with built-in modems. When the
Layer 2 connection is established between the user and the server, three-way Challenge
Handshake Authentication Protocol (CHAP) is used to authenticate the user. As in the remote
access VPN service, the authentication, authorization, and accounting (AAA) server is used for
authentication. When authenticated, the users are provided with IP addresses from an IP pool.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-17

Design Guidelines
for the Inside Router
PSTN

Internet

Public
services

Demarcation

The primary function of the inside router is to provide Layer 3

separation and routing between the corporate Internet module
and the campus module.
The inside router functions strictly as a router with no ACLs
restricting traffic across either interface.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-16

The primary function of the inside router is to provide Layer 3 separation and routing between
the corporate Internet module and the campus module. This device functions strictly as a router
with no ACLs restricting traffic across either interface.
Because routing information itself can be used in a DoS attack, authentication of routing updates
between devices may be used to mitigate such an attack. The inside router provides a final point
of demarcation between the routed intranet and the outside world. Because most firewalls are
configured without routing protocols, it is important to provide a point of routing within the
corporate Internet module that does not rely on the rest of the network.

6-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Alternatives
NIDS and
URL filtering

PSTN

Stateful
firewall
Eliminate

Internet

Public
services

Design alternatives include the following:

A stateful firewall on an edge router
An NIDS on the outside firewall
Eliminate the inside router
2003, Cisco Systems, Inc. All rights reserved.

A URL-filtering server

CSI 1.16-17

This SAFE SMR corporate Internet module has several alternative designs:
Rather than implementing basic filtering on the edge router to the midsize network, a
network administrator may choose to implement a stateful firewall on this device as well.
Having two stateful firewalls provides more of a defense-in-depth approach to security
within the module.
Depending on the network administrators attitude toward attack awareness, an NIDS
appliance might be required in front of the firewall. With the appropriate basic filters, the
IDS outside the firewall can provide important alarm information that would otherwise be
dropped by the firewall.
Because the amount of alarms generated on this segment is probably large, alarms generated
here should have a lower severity than alarms generated behind a firewall. Also, consider
logging alarms from this segment to a separate management station to ensure that legitimate
alarms from other segments get the appropriate attention. With the visibility that an NIDS
outside the firewall provides, evaluation of the attack types your organization is attracting
can be better seen. In addition, evaluation of the effectiveness of ISP and enterprise edge
filters can be performed.
Another alternative is the elimination of the router between the firewall and the campus
module. Although its functions can be integrated into the campus module Layer 3 switch,
this setup would eliminate the ability of the corporate Internet module to function without
relying on Layer 3 services from another area of the network.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-19

The addition of content inspection beyond the mail-content inspection already specified
could also be used. For example, a URL-filtering server could be placed on the public
services segment to filter the types of web pages that employees can access.

6-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Campus Module

This section covers the midsize network campus module.

Midsize Network Campus

Module Key Devices
The following are key devices:

Layer 3 switch
Layer 2 switch
Corporate servers
To the
SMTP or POP3
corporate
Internet module
File and print
User workstations
NIDS appliance
Management hosts
SNMP
Syslog
TACACS+ or RADIUS
NIDS host

Management
server
Corporate
users

Corporate
servers

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-19

The midsize network campus module contains end-user workstations, corporate intranet servers,
management servers, and the associated Layer 2 and Layer 3 infrastructure required to support
the devices. All the campus modules from SAFE Enterprise have been combined into a single
module. This setup more accurately reflects the smaller size of midsize networks, and reduces
the overall cost of the design. As in the corporate Internet module, the redundancy that would
normally be found in an enterprise design has been removed from the midsize network design.
The following are the midsize network campus module key devices:
Layer 3 switchRoute and switch production and management traffic within the campus
module, provide distribution layer services to the building switches, and support advanced
services such as traffic filtering
Layer 2 switches (with private VLAN support)Provides Layer 2 services to user
workstations
Corporate serversProvides e-mail (SMTP and POP3) services to internal users, as well as
delivering file, print, and DNS services to workstations
User workstationsProvide data services to authorized users on the network

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-21

NIDS applianceProvides Layer 4-to-Layer 7 monitoring of key network segments in the

module
Management hostsHosts designated for device management

NIDS hostProvides alarm aggregation for all NIDS devices in the network

Syslog hostAggregates log information for firewall and NIDS hosts

6-22

Simple Network Management Protocol (SNMP) hostProvides SNMP management for

devices

Terminal Access Controller Access Control System Plus (TACACS+)Provides user

authentication for device management
Remote Access Dial-In User Service (RADIUS)Provides user authentication for dial
in access

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats
and Mitigation Roles
The following threats are expected to the SAFE
SMR Midsize Network Campus Module:

Packet sniffersA switched infrastructure limits the

effectiveness of sniffing
Virus and Trojan horse applicationsHost-based virus
scanning prevents most viruses and many Trojan horses
Unauthorized accessThese types of attacks are
mitigated through the use of host-based intrusion
detection and access control
Password attacksThe access control server allows for
strong, two-factor authentication for key applications

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-20

The following threats are expected:

Packet sniffersA switched infrastructure limits the effectiveness of sniffing
Virus and Trojan horse applicationsHost-based virus scanning prevents most viruses and
many Trojan horses
Unauthorized accessThese types of attacks are mitigated through the use of host-based
intrusion detection and access control
Password attacksThe access control server allows for strong two-factor authentication for
key applications

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-23

Expected Threats
and Mitigation Roles (cont.)

Application layer attacksOperating systems, devices,

and applications are kept up-to-date with the latest
security fixes, and they are protected by an HIDS
IP spoofingRFC 2827 filtering prevents source-address
spoofing
Trust exploitationTrust arrangements are very explicit
(private VLANs prevent hosts on the same subnet from
communicating unless necessary)
Port redirectionAn HIDS prevents the installation of
port redirection agents

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-21

Application layer attacksOperating systems, devices, and applications are kept up-to-date
with the latest security fixes, and they are protected by an HIDS
IP spoofingRFC 2827 filtering prevents source-address spoofing
Trust exploitationTrust arrangements are very explicit (private VLANs prevent hosts on
the same subnet from communicating unless necessary)
Port redirectionAn HIDS prevents the installation of port redirection agents

6-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Attack Mitigation

Roles for the Campus Module
Management
server
To the
corporate
Internet module

Focused Layer
47 analysis

HIDS for local

attack mitigation
Host virus
scanning

Corporate
users

Corporate
servers
Layer 3 and 4 filtering of
management traffic, private
VLANs, and RFC filtering

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-22

The campus module performs the following actions:

The NIDS performs focused Layer 4 through 7 analysis.
The Layer 3 switch provides Layer 3 and 4 filtering of management traffic, private VLANs,
and RFC 2827 filtering.
Hosts provide virus scanning.
The HIDS provides local attack mitigation.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-25

Midsize Network Campus Module Design

Guidelines
This section details the functionality of each of the devices within the campus module.

Design Guidelines for

the Core Switch
Management
server
To the
corporate
Internet module

Corporate
users

Layer 3 and 4 filtering of

management traffic, private
VLANs, and RFC 2827 filtering

Corporate
servers

The following are the primary functions of the core switch:

Provides routing and switching for internal traffic

Provides separate VLANs and private VLANs
Implements internal access control
RFC 2827 filtering

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-24

The primary function of the core switch is to provide routing and switching for production and
management traffic, distribution layer services (routing, quality of service [QoS], and access
control) for the distribution and access switches, connectivity for the corporate and management
servers, and advanced services such as traffic filtering between the subnets.
In the figure, a Layer 3 switch is used instead of a Layer 2 switch in order to provide separate
VLANs for the following:
Corporate server segment
Management server segment
Corporate user segment
Connectivity to the WAN module and to the corporate Internet module
The Layer 3 switch provides a line of defense and prevention against internally originated
attacks. It can mitigate the chance of a department accessing confidential information on another
departments server through the use of access control. For example, a network that contains
marketing and research and development might segment off the R and D server to a specific
6-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VLAN and filter access to it, ensuring that only R and D staffs have access to it. For
performance reasons, it is important that this access control be implemented on a hardware
platform that can deliver filtered traffic at near wire rates. This setup generally dictates the use of
Layer 3 switching, as opposed to more traditional dedicated routing devices. This same access
control can also prevent local source-address spoofing through the use of RFC 2827 filtering.
RFC 2827 filtering should be implemented on the corporate user and corporate intranet server
VLANs.
Within each of the VLANs, private VLANs can be used to mitigate trust-exploitation attacks
between the devices. For instance, within the corporate server segment, the individual servers
may not have any requirement to communicate with each other. They need to communicate only
with devices connected to the corporate user segment.
To provide a further line of defense for the management servers, extensive Layer 3 and Layer 4
filtering is configured outbound on the VLAN interface connecting to the management server
segment. The ACL limits connectivity to and from the management servers only to those devices
(via IP addresses) under their control, and only for those protocols and services (via port
number) that are required. This also includes access control for management traffic destined for
the remote site devices. This traffic is encrypted by the firewall and sent to the remote sites.
Allowing only established connections back through the ACL further controls access to the
managed devices.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-27

Design Guidelines
for Intrusion Detection
Management
server
To the
corporate
Internet module

Corporate
users

Focused Layer
47 analysis

Corporate
servers

Intrusion detection should monitor internal traffic for

suspicious activity. Very few attacks should be detected.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-25

The campus module also includes an NIDS appliance. The switch port that connects to the NIDS
appliance is configured such that traffic from all VLANs that require monitoring is mirrored to
the monitoring port of the appliance.
Very few attacks should be detected here because this NIDS appliance provides analysis against
attacks that may originate from within the campus module itself. For instance, if a user
workstation was compromised because of an unknown modem connection to that host, the NIDS
could detect suspicious activity originating from within the campus. Other internal attacks could
originate from disgruntled employees, workstations left where unauthorized people can gain
access to them, or Trojan horse applications inadvertently loaded on portable PCs.
Each of the corporate intranet and management servers also has an HIDS installed.

6-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Alternatives
The following design
alternatives are
available:

Integrated IDS
module in the
core switch

If the network is
To the
small enough,
corporate
incorporate Layer 2
Internet module
switch functionality
into the core switch.
Separate the router and Layer 2
switch instead of the core
switch.
Replace the NIDS appliance
with the IDS module in the core
switch.

2003, Cisco Systems, Inc. All rights reserved.

Integrate switch
functionality

Management
server

Corporate
users

Corporate
servers
Separate
router and
Layer 2 switch

CSI 1.16-26

If the midsize network is small enough, the functionality of the distribution and access switches
can be rolled into the core switch, and the distribution and access switches can be eliminated. In
this case, the end-user workstations would be connected directly to the core switch. Private
VLAN functionality would be implemented on the core switch in order to mitigate trustexploitation attacks.
If the performance requirements of the internal network are not high, a separate router and Layer
2 switch could be used for the core and distribution instead of the higher-performing Layer 3
switch.
If desired, the separate NIDS appliance can be replaced with an integrated IDS that fits into the
core switch. This setup provides higher traffic throughput into the IDS because it sits on the
backplane of the switch, rather than being connected via a single 10/100-Mbps Ethernet port.
ACLs on the switch can be used to control what traffic is sent to the IDS.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-29

Midsize Network WAN Module

This section explains the Midsize Network WAN Module. The WAN module is included only
when connections to remote locations over a private network are required. This requirement may
occur when stringent QoS requirements cannot be met by an IPSec VPN, or when legacy WAN
connections are in place without a compelling cost justification to migrate to IPSec.

Midsize Network WAN Module Key

Devices and Expected Threats

FR/ATM

To the campus
module

Note the following about the WAN module:

The WAN module is included only when connections
to remote locations over a private network are required
The only key device is the IOS Router
The following are expected threats:
IP spoofing
Unauthorized access

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-28

The IOS router is a key device for the midsize network WAN. It provides routing, access
control, and QoS mechanisms to remote locations.
The following are mitigated threats for the midsize network WAN:
IP spoofingIP spoofing can be mitigated through Layer 3 filtering.
Unauthorized accessSimple access control on the router can limit the types of protocols to
which branches have access.

6-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines and Alternatives

Cisco IOS Router
with a firewall

FR/ATM

IPSec tunnel

To the campus
module

VPN tunnel

Use IPSec for additional privacy

Run a firewall on the WAN router
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-29

The amount of security placed in the WAN module depends on the level of trust for the remote
sites and the ISP to which you are connecting. Security is provided by using IOS security
features. In this design, inbound ACLs applied to the serial interface are used to block all
unwanted traffic from accessing the midsize network. Inbound ACLs applied to the Ethernet
interface can be used to further limit what traffic passes from the midsize network back to the
remote sites.
Alternatives involve organizations that are very concerned about information privacy and
encrypt traffic across their classic WAN links. Similar to site-to-site VPNs, IPSec can be used to
achieve this level of information privacy. Additionally, running a firewall on the WAN router
can provide additional access control options when compared with the basic ACLs used in the
SAFE design.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-31

ImplementationISP Router and Edge Router

This section covers the necessary steps needed to implement the SAFE guidelines on the ISP
router.

ISP RouterImplementation
Commands Summary
PSTN
Spoof mitigation
and (D)DoS
rate-limiting

Internet

Public
services

The following are necessary

commands for the ISP router:
Spoof mitigation and RFC filtering
access-list
access-group
(D)DoS rate-limiting
2003, Cisco Systems, Inc. All rights reserved.

rate-limit

CSI 1.16-31

Starting at the customer edge router in the ISP, the egress of the ISP rate limits nonessential
traffic that exceeds pre-specified thresholds in order to mitigate DDoS attacks. Also at the egress
of the ISP router, RFC 1918 and RFC 2827 filtering mitigate source-address spoofing of local
networks and private address ranges.
At the ingress of the firewall, RFC 1918 and RFC 2827 filtering are first provided as a
verification of the ISPs filtering. In addition, because of the enormous security threat that
fragmented packets create, the firewall is configured to drop most fragmented packets that
should not generally be seen for standard traffic types on the Internet. Any legitimate traffic lost
because of this filtering is considered acceptable when compared to the risk of allowing such
traffic. Traffic destined to the firewall itself from the outside is limited to IPSec traffic and any
necessary protocols for routing.

6-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco Edge Router

Implementation Commands
Midsize network or branch edge
corporate Internet module

The following are

necessary commands
for the Cisco edge router:

PSTN

access-list
access-group
Internet

Public
services

Spoof mitigation and

basic filtering

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-32

The function of the edge router on the midsize network is to provide the demarcation point
between the ISP network and the midsize network. At the ingress of the edge router on the
midsize network, basic filtering limits access to allow only expected IP traffic, providing a
coarse filter for the most basic attacks. RFC 1918 and RFC 2827 filtering are also provided here
as a verification of the ISPs filtering.
In addition, because of the enormous security threat that fragmented packets create, the router is
configured to drop most fragmented packets that should not generally be seen for standard traffic
types on the Internet. Any legitimate traffic lost because of this filtering is considered acceptable
when compared to the risk of allowing such traffic.
Any IPSec traffic destined for the VPN Concentrator or the firewall is allowed through. Filtering
on the router is configured to allow only IKE and IPSec traffic to reach the VPN Concentrator or
firewall. Because with remote access VPNs the IP address of the remote system is not generally
known, the filtering can be specified only to the head-end peer (VPN Concentrator) with which
the remote users are communicating. With site-to-site VPNs, the IP address of the remote site is
usually known; therefore, filtering may be specified for VPN traffic to and from both peers.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-33

Implementation CommandsSpoof
Mitigation and RFC Filtering
router(config)#

--- ---
- -
- - -
- -

The access-list command enables you to specify if an IP address
is permitted or denied access to a port or protocol.

---

router(config-if)#

-- --- ---

The access-group command binds an ACL to an interface.

--
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-33

The threat of IP spoofing can be reduced, but not eliminated, through the following measures:
Access controlThe most common method for preventing IP spoofing is to properly
configure access control. To reduce the effectiveness of IP spoofing, configure access
control to deny any traffic from the external network that has a source address that should
reside on the internal network. Note that this helps prevent spoofing attacks only if the
internal addresses are the only trusted addresses. If some external addresses are trusted, this
method is not effective.
RFC 2827 filteringYou can also prevent users of a network from spoofing other networks
(and be a good Internet citizen at the same time) by preventing any outbound traffic on your
network that does not have a source address in your organizations own IP range. Your ISP
can also implement this type of filtering, which is collectively referred to as RFC 2827
filtering. This filtering denies any traffic that does not have the source address that was
expected on a particular interface.
For example, if an ISP is providing a connection to the IP address 15.1.1.0/24, the ISP could
filter traffic so that only traffic sourced from address 15.1.1.0/24 can enter the ISP router
from that interface. Note that unless all ISPs implement this type of filtering, its
effectiveness is significantly reduced. Also, the further you get from the devices you want to
filter, the more difficult it becomes to do that filtering at a granular level. For example,
performing RFC 2827 filtering at the access router to the Internet requires that you allow
your entire major network number (that is, 10.0.0.0/8) to traverse the access router. If you
perform filtering at the distribution layer, as in this architecture, you can achieve more
specific filtering (that is, 10.1.5.0/24).

6-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the access-list command is as follows:

access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-rangename]
access-list-number

Number of an ACL. This is a decimal number from 100 to 199 or

from 2000 to 2699.

dynamic dynamic-name

(Optional.) Identifies this ACL as a dynamic ACL. Refer to lockand-key access documented in the "Configuring Lock-and-Key
Security (Dynamic Access Lists)" chapter in the Cisco IOS
Security Configuration Guide.

timeout minutes

(Optional.) Specifies the absolute length of time, in minutes, that

a temporary ACL entry can remain in a dynamic ACL. The default
is an infinite length of time and allows an entry to remain
permanently. Refer to lock-and-key access documented in the
"Configuring Lock-and-Key Security (Dynamic Access Lists)"
chapter in the Cisco IOS Security Configuration Guide.

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an Internet protocol. It can be one of the

keywords eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim,
tcp, or udp, or an integer in the range from 0 to 255 representing
an IP number. To match any IP (including ICMP, TCP, and UDP)
use the ip keyword.

source

Number of the network or host from which the packet is being

sent. There are three alternative ways to specify the source:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.

source-wildcard

Wildcard bits to be applied to source. Each wildcard bit 0

indicates the corresponding bit position in the source. Each
wildcard bit set to 1 indicates that both a 0 bit and a 1 bit in the
corresponding position of the IP address of the packet will be
considered a match to this access list entry.
There are three alternative ways to specify the source wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format. Place
1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use the host source as an abbreviation for a source and
source-wildcard of source 0.0.0.0.
Wildcard bits set to 1 need not be contiguous in the source
wildcard. For example, a source wildcard of 0.255.0.64 would be
valid.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-35

destination

Number of the network or host to which the packet is being sent.

There are three alternative ways to specify the destination:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for the destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
Use a host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.

destination-wildcard

Wildcard bits to be applied to the destination. There are three

alternative ways to specify the destination wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format. Place
1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.

precedence precedence

(Optional.) Packets can be filtered by precedence level, as

specified by a number from 0 to 7, or by name.

tos tos

(Optional.) Packets can be filtered by type of service level, as

specified by a number from 0 to 15, or by name.

log

(Optional.) Causes an informational logging message about the

packet that matches the entry to be sent to the console. (The
level of messages logged to the console is controlled by the
logging console command.)
The message includes the ACL number, whether the packet was
permitted or denied; the protocol, whether it was TCP, UDP,
ICMP, or a number; and, if appropriate, the source and
destination addresses and source and destination port numbers.
The message is generated for the first packet that matches, and
then at five-minute intervals, including the number of packets
permitted or denied in the prior five-minute interval.
The logging facility might drop some logging message packets if
there are too many to be handled or if there is more than one
logging message to be handled in one second. This behavior
prevents the router from crashing due to too many logging
packets. Therefore, the logging facility should not be used as a
billing tool or an accurate source of the number of matches to an
ACL.

log-input

(Optional.) Includes the input interface and source MAC address

or VC in the logging output.

time-range time-range-name

(Optional.) Name of the time range that applies to this statement.

The name of the time range and its restrictions are specified by
the time-range command.

The syntax for the access-group command is as follows:

ip access-group {access-list-number | access-list-name}{in | out}

6-36

access-list-number

Number of an ACL. This is a decimal number from 1 to 199 or

from 1300 to 2699.

access-list-name

Name of an IP ACL as specified by an ip access-list command.

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ImplementationIOS Firewall
The following section details the implementation of the IOS Firewall features and configuration.

The IOS Firewall

PSTN

Stateful packet filtering, basic

Layer 7 filtering, host DoS
mitigation, authenticate remote
sites, authenticate remote
users, and terminate IPSec

Internet

2003, Cisco Systems, Inc. All rights reserved.

Public
services

CSI 1.16-35

The primary function of the IOS Firewall is to provide connection-state enforcement and
detailed filtering for sessions initiated through the firewall. The firewall also acts as a
termination point for site-to-site IPSec VPN tunnels for both remote site production and remote
site management traffic.
There are multiple segments off the firewall. The first is the public services segment, which
contains all the publicly addressable hosts. The second is for remote access VPN and dial-in.
Publicly addressable servers have some protection against TCP SYN floods through mechanisms
such as the use of half-open connection limits on the firewall. From a filtering standpoint, in
addition to limiting traffic on the public services segment to relevant addresses and ports,
filtering in the opposite direction also occurs. If an attack compromises one of the public servers
(by circumventing the firewall, HIDS, and NIDS), that server should not be able to further attack
the network.
To mitigate this type of attack, specific filtering prevents any unauthorized requests from being
generated by the public servers to any other location. As an example, the web server should be
filtered so that it cannot originate requests of its own, but merely respond to requests from
clients. This setup helps prevent a hacker from downloading additional utilities to the
compromised device after the initial attack. It also helps stop unwanted sessions from being
triggered by the hacker during the primary attack. An attack that generates an xterm from the
web server through the firewall to the hackers machine is an example of such an attack.
Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-37

Private VLANs prevent a compromised public server from attacking other servers on the same
segment. This traffic is not even detected by the firewall, a fact that explains why private
VLANs are critical.

6-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS FirewallImplementation
Commands Summary
The following are necessary mitigation roles and implementation
commands for the IOS Firewall:
Stateful packet filteringPart of CBAC on IOS Routers
Spoof mitigation and RFC filtering
access-list
access-group
Host DoS mitigation
ip inspect
Authenticate remote site, users, and logging
aaa new-model
tacacs-server
aaa authentication login
aaa authorization exec
aaa accounting exec
login authentication
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-36

The following are necessary mitigation roles and implementation commands for the IOS
Firewall:
Stateful packet filteringPart of Context-Based Access Control (CBAC) on Cisco IOS
Routers
Spoof mitigation and RFC filtering

access-listThe access-list command enables you to specify if an IP address is

permitted or denied access to a port or protocol.
access-groupBinds an ACL to an interface.

Host DoS mitigation

ip inspectDefines the application protocols to inspect.

Authenticate remote site (and logging)

Copyright

aaa new-modelTo define a set of inspection rules, enter this command for each
protocol that you want to inspect, using the same inspection-name.

tacacs-serverDefines the TACACS server.

aaa authentication loginEnables AAA authentication at login.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-39

aaa authorization execRestricts network access to a user.

aaa accounting execRuns accounting for EXEC shell session.

6-40

login authenticationSpecifies the name of a list of AAA authentication methods to

try at login.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS FirewallImplementation
Commands Summary (cont.)
IPSec commandsProvide for IPSec tunnel
termination
crypto isakmp policy
encryption
authentication
group
crypto isakmp key
crypto ipsec transform-set
crypto map
set peer
set tranform-set
match address

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-37

IPSec commandsProvide for IPSec tunnel termination

crypto isakmp policySpecifies the parameters to be used during an IKE negotiation.

EncryptionSets the algorithm to be negotiated.

AuthenticationSpecifies the authentication method within an IKE policy.

groupSpecifies the AAA server group to use for preauthentication.

crypto isakmp keyConfigures pre-shared authentication keys.

Copyright

crypto ipsec transform-setAn acceptable combination of security protocols,

algorithms and other settings to apply to IP Security protected traffic.
crypto mapConfigures filtering and classifying traffic to be protected and defines the
policy to be applied to that traffic.

set peerSpecifies an IPSec peer for a crypto map.

set transform-setSpecifies which transform sets to include in a crypto map entry.

match addressSpecifies an extended access list for a crypto map entry.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-41

ImplementationPIX Firewall
This section describes the detailed configuration and implementation of the Cisco PIX Firewall.

PIX FirewallImplementation
Commands Summary
The following are necessary
mitigation roles and implementation
commands for the PIX Firewall:
Stateful packet filtering (this is the
default for the PIX Firewall)
Host DoS mitigation and basic
layer 7 filtering
ip verify reverse-path interface
PSTN
icmp
attack guard commands
(except for frag guard, these are
on by default)
static
Spoof mitigation and RFC filtering
Internet
access-list
access-group

Stateful packet filtering, basic

Layer 7 filtering, host DoS
mitigation, spoof mitigation,
authenticate remote sites,
authenticate remote users, and
terminate IPSec

2003, Cisco Systems, Inc. All rights reserved.

Public
services

CSI 1.16-39

The following mitigation roles and implementation commands are used to implement the policy
on the PIX Firewall:
Stateful packet filteringThe default for the PIX Firewall
Host DoS mitigation and basic layer 7 filtering

ip verify reverse-path interfaceImplements Unicast RPF IP spoofing protection

icmpEnables or disables pinging to an interface

attack guard commandsThese commands are enabled by default

staticCreates a static network address translation

Spoof mitigation and RFC filtering

6-42

access-listCreates an ACL

access-groupBinds the ACL to an interface

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PIX FirewallImplementation
Commands Summary (cont.)
Authenticate the remote site (and
PSTN
logging)
aaa-server
aaa authentication
logging on
Terminate IPSec
sysopt connection permit-ipsec
isakmp enable
Internet
isakmp key
isakmp policy
crypto ipsec transform-set
Stateful packet filtering, basic
Layer 7 filtering, host DoS
crypto map

Public
services

mitigation, authenticate remote

sites, and terminate IPSec

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-40

Authenticate the remote-site and logging

aaa-serverSpecifies a AAA server

aaa authenticationEnables, disables, or views LOCAL, TACACS+, or RADIUS user
authentication
logging onEnables or disables Syslog and SNMP logging

Terminate IPSec

isakmp enableEnables Internet Security Association Key Management Protocol

(ISAKMP) negotiation on the interface on which the IPSec peer communicates with the
PIX Firewall

isakmp keySpecifies the authentication pre-shared key

isakmp policyUniquely identifies the IKE policy and assigns a priority to the policy

Copyright

sysopt connection permit-ipsecImplicitly permits any packet that came from an

IPSec tunnel

crypto ipsec transform-setCreates, views, or deletes IPSec security associations,

Security Association (SA) global lifetime values, and global transform sets
crypto mapCreates, modifies, views, or deletes a crypto map entry

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-43

ImplementationNIDS
This section explains the Cisco Intrusion Detection System (IDS) Sensor setup configuration
tasks. The configuration tasks are presented using the IDS Device Manager (IDM).

NIDS Implementation
IDM Sensor Setup Tasks
The following are the tasks to setup the
Sensor:

Configure the Sensors network settings.

Define the list of hosts that are authorized to
manage the Sensor.
Configure remote management services.
Configure SSH settings.
Configure the Sensors date and time.
Change the password for the account used to
access the IDM.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-42

A Cisco IDS Sensor is initialized using the sysconfig-sensor Sensor command. Once the Sensor
has been initialized, configuration of the Sensor is done via a platform such as IDM or IDS
Management Center (MC).
You can change the parameters configured during Sensor initialization by completing the
following Sensor setup tasks:
Configure the Sensors network settingsThis task involves assigning values to network
and IDS communication parameters, such as an IP address and host identifier.
Define the list of hosts that are authorized to manage the SensorThis task involves
identifying those hosts and networks that should be allowed to manage the Sensor.
Configure remote management servicesThis task involves deciding which network
services are used to gain interactive access to the Sensor.
Configure secure shell (SSH) settingsThis task involves generating the Sensors SSH keys
and managing the known hosts file.

6-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Configure the Sensors date and timeThis task involves identifying the time zone and date.
This is important for time stamping log files.
Change the password for the account used to access IDMThis task involves changing the
password for either the netrangr or root account.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-45

Network Settings
Choose Device>Sensor Setup>Network.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-43

Complete the following steps to configure the Sensors network parameters:

Step 1

Launch your web browser and specify the Sensor as the location:
-----

6-46

Step 2

Log in to the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Device from the area bar. The Device sub-area bar is displayed.

Step 4

Select Sensor Setup from the sub-area bar. The Sensor Setup table of contents (TOC) is
displayed.

Step 5

Select Network from the TOC. The Sensors network settings are displayed in the work content
area.

Step 6

Enter the values listed in the following table for the Cisco IDS settings:
Cisco IDS Settings

Parameter Value

Description

Host Name

<Host Name>

Alphanumeric identifier for the

IEV host.

Host ID

165535

Numeric identifier for the IEV

host.

Organization Name

<Org Name>

Alphanumeric identifier for a

group of Cisco IDS components.

Organization ID

165535

Numeric identifier for a

collection of Cisco IDS
components.

IP Address

<IP Address>

The IP address of the IEV host.

PostOffice Port

102565535

The UDP port number used for

IDS communication.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 7

Choose the alarm severity level from the Route Up Alarm Level drop-down menu.

Step 8

Choose the alarm severity level from the Route Down Alarm Level drop-down menu.

Step 9

Enter the values listed in the following table for the Cisco IDS settings:
Cisco IDS Settings

Parameter Values

Description

Heartbeat interval multiplier

<Host Name>

The number of times the

heartbeat packet is sent to a
Cisco IDS host before the route
is declared down.

IP address

<IP Address>

The IP address of the Sensor

(for example, 10.10.10.3).

Netmask

<network mask>

The subnet mask for the Sensor

(for example, 255.255.255.0).

Default route

<IP Address>

The Sensors default route for

routing purposes, if needed (for
example, 10.10.10.1).

Step 10

Choose Yes or No from the Enable TLS/SSL drop-down menu to enable or disable the TLS/SSL
feature.

Step 11

Enter the port number to use for the IDM web server in the Web Server Port field.

Step 12

Click OK to save the Sensors network settings.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-47

Network Access Control

Choose Device>Sensor Setup>Allowed Hosts.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-44

The access control list (ACL) feature enables the network security administrator to set any
number of IP addresseseither by host or networkwhich are allowed to establish TCP
connections (Telnet, FTP, SSH, HTTP) to a Sensor. In most cases, access to the Sensor in this
manner should be limited to trusted hoststypically the IDM.
The ACL feature uses the UNIX software package TCP wrappers. The TCP wrappers software
controls access by using entries in the /etc/hosts.allow and /etc/hosts.deny files. These files
should not be modified. For more information about the TCP wrappers application, visit the
following web site: www.standford.edu/group/itss-ccs/security/unix/tcpwrappers_README.txt.
Complete the following steps to configure the Sensors network access control feature:
Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Allowed Hosts from the TOC. The list of allowed networks and hosts is displayed in the
work content area.

Step 4

Select Add from the work content area. The Adding information is displayed in the work content
area.

Step 5

Enter the network address in the Network address field.

Note

Step 6

6-48

Include the trailing period when entering network addresses (for example, to enter the network
10.0.1.0/24, enter 10.0.1. in the network address field).

Click OK to save the Sensors allowed hosts settings.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Access Services

Choose Device>Sensor Setup>Remote Access.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-45

The Remote access configuration option enables the network security administrator to disable
insecure communication protocols such as Telnet and FTP.
Note

SSH is enabled by default and cannot be disabled.

Complete the following steps to enable or disable Telnet or FTP access to the Sensor:
Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Remote Access from the TOC. The Sensors remote access settings are displayed in the
work content area.

Step 4

Select or de-select the FTP check box to enable or disable the FTP service.

Step 5

Select or de-select the Telnet check box to enable or disable the Telnet service.

Step 6

Click OK to save the Sensors remote access settings.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-49

Time
Choose Device>Sensor Setup>Time.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-46

The Time configuration option enables the network security administrator to modify the date,
time, and time zone for the Sensor appliance.
Complete the following steps to set the date and time:

6-50

Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Time from the TOC. The Sensors time settings are displayed in the work content area.

Step 4

Enter the new time in the Time field. The format to enter the time is hh:mm:ss where hh is the
two-digit hour, mm is the two-digit minute number, and ss is the two-digit second number.

Step 5

Choose a system-defined time zone from the System Timezone drop-down menu or choose
Custom Timezone and enter a custom timezone.

Step 6

Click Set Time to save the Sensors time settings.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Account Password
Choose Device>Sensor Setup>Password.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-47

The Password configuration option enables the user to change the password for the account used
to log into IDM. Complete the following steps to change the accounts password:
Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Password from the TOC. The user name whose password is to be changed is displayed in
the work content area.

Step 4

Enter the users password in the Current Password field.

Step 5

Enter the new password to be used in the New Password field.

Step 6

Enter the new password to be used in the Password Again field.

Step 7

Click Change Password Now to immediately change the users password.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-51

Applying Sensor Configuration

Choose Apply Changes and Select Finish.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-48

The Sensor configuration settings are saved by the Director and must be transferred to the
Sensor. Complete the following steps to apply the configuration settings to the Sensor:

6-52

Step 1

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 2

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation
Event Logging
The Sensor by default logs all events locally:
Logs events by severity
Logs events by type
The Sensor can transfer archived copies of log
files offline to an FTP server:
Network access to the FTP server
FTP username and password
Directory with write permissions
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-49

The Cisco IDS logging service, loggerd, is enabled by default, and the Sensor is configured to
log events of all types locally. The events logged may be based on severity and type.
The Sensor is capable of transferring archived copies of log files offline to an FTP server. The
following are the requirements for the network log file transfer feature:
Network access to an FTP server
FTP username and password
Directory where the FTP user has write privileges

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-53

NIDS Implementation
Event Logging (cont.)
The IP logging feature captures packets from an
attacking host:
Logs packets automatically when IP Log is a
signature response
Logs packets if the source address is entered
manually
Requires that event logging is enabled
The IP log file is in tcpdump format
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-50

The Sensor IP logging feature captures IP packets from an attacking host. The Sensor may be
configured to capture packets automatically when the signature action is IP Log. The Sensor may
be configured to capture packets if the network security administrator specifies the source
address.
The IP logging feature requires that the Sensors logging feature be enabled. The Director
displays a warning message if logging has not been enabled.
The IP log file is in tcpdump format and may be viewed by any application that is aware of the
tcpdump format.

6-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Event Logging
Choose Configuration>Logging>Event Logging.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-51

Complete the following steps to configure event logging:

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Logging from the sub-area bar. The Logging TOC is displayed.

Step 3

Select Event Logging from the Logging TOC options. The Event logging settings are displayed
in the work content area.

Step 4

Select or de-select the Enable check box to disable or enable the Sensors event logging service.

Step 5

Choose the alarm severity from the Level drop-down menu.

Step 6

Select the event types to log:

1. Select or de-select the Alarms check box.
2. Select or de-select the Errors check box.
3. Select or de-select the Commands check box.
4. Select or de-select the IP Logs check box.

Step 7

Copyright

Click OK to save the event logging settings.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-55

Log File Transfers

Choose Configuration>Logging>Exporting Event Logs.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-52

Complete the following steps to configure the Sensor to transfer the log files offline to an FTP
server:
Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Logging from the sub-area bar. The Logging TOC is displayed.

Step 3

Select Exporting Event Logs from the Logging TOC options. The Exporting Event Logs
settings are displayed in the work content area.

Step 4

Select or de-select the Export Archived Event Log files to enable or disable the exporting
feature.

Step 5

Enter the following parameters in their respective fields:

Cisco IDS Settings

Parameters

Description

Target FTP Server IP Address

<IP Address>

The IP address of the FTP

server.

Target FTP Directory

<Directory Name>

Directory where the log files will

be transferred.

Username

<username>

The username to use for the

FTP connection.

Password

<Password>

The password to use for the

FTP connection.

Note
Step 6

6-56

The user must have write access to the target FTP directory on the FTP server.

Click OK to save the Exporting Event Logs settings.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation
Sensing Overview
The Sensor has parameters that affect the
sensing function and that are not necessarily
specific to a particular signature or set of
signatures.
The following are the global sensing parameters:
Internal network
Sensing properties
Level of traffic logging

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-53

The Sensor has configuration parameters that affect the sensing function. These parameters are
not necessarily specific to a particular signature or set of signatures. The following are the global
sensing parameters:
Internal network
Sensing properties
Level of traffic logging

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-57

Internal Networks
Choose Configuration>Sensing Engine>Internal Networks.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-54

The internal network configuration parameter defines the list of networks that are considered as
protected by the Sensor. This information is used to define inside (IN) and outside (OUT)
network for alarm events. Inside networks are those defined as internal networks. All other
networks are identified as outside networks. The internal network definition is used for two
purposes:
Alarm eventsAlarm events include source (SRC) and destination (DST) fields. The IN and
OUT keywords are the possible values for either the source or destination field.
Signature filteringThe keywords IN and OUT are used when creating an exclusion of
inclusion signature filter.
Note

The internal network definition does not affect the Sensors intrusion detection capabilities. If
no internal network entries are added, the Sensor logs the source and destination of an attack
as OUT, OUT.

Complete the following steps to add addresses to the list of internal networks:
Step 1

Launch your web browser and specify the Sensor as the location:
-----

6-58

Step 2

Log into the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 5

Select Internal Networks from the TOC. The list of internal network addresses is displayed in
the work content area.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 6

Click Add in the work content area. The network address field is displayed.

Step 7

Enter the network address in the Network Address field.

Note

Internal networks may be represented by a single IP address, 10.1.1.1; a range of IP

addresses, 10.1.1.110.1.1.20; the IP address/bitmask, 10.1.1.1/24; or the IP netmask,
10.1.1.0 255.255.255.0.

Step 8

Click OK to add the network address to the list. The address is displayed in the list of network
addresses.

Step 9

Click the Edit icon next to the network address to edit the network address settings.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-59

Sensing Properties
Choose Configuration>Sensing Engine>Sensing Properties.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-55

Complete the following steps to configure the Sensors sensing properties:

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select Sensing Properties from the TOC. The Sensors sensing properties are displayed in the
work content area.

Step 4

Enter parameter values for the settings listed in the following table:
Cisco IDS Setting
Sensing Interface

Parameter Value
CustomEnables the network
security administrator to enter
a user-defined interface
name.

Description
This is the Sensors monitoring
interface device name.
Automatic is the default value.

AutomaticEnables the
Sensor to detect the correct
monitoring interfaces device
name.
Traffic Flow Severity

High
Medium
Low

The alarm severity level

assigned to the Traffic Flow
signatures. The default security
level is High.

Informational
Traffic Flow Timeout

6-60

Cisco SAFE Implementation 1.1

065000

The number of seconds required

to trigger the Traffic Flow
signature.

Copyright

2003, Cisco Systems, Inc.

Cisco IDS Setting

Link Status Alarm Level

Parameter Value
High
Medium
Low

Description
The alarm severity level
assigned to the Link status
signature. The default security
level is Low.

Informational
Storage Timeout Seconds

Step 5

Copyright

10600

The number of seconds to wait

before deleting stored history
after the host goes silent.

Click OK to save the Sensors sensing properties.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-61

Level of Traffic Logging

Choose Configuration>Sensing Engine>Signature Configuration>
Level of Traffic Logging.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-56

The Level of Traffic Logging configuration option is used for TCP and UDP connection
signatures. This defines the types of TCP connection packets and UDP traffic that is logged:
Complete the following steps to configure the Sensors level of traffic logging:
Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select Level Of Traffic Logging from the TOC. The current Level of Traffic logging value is
displayed in the work content area.

Step 4

Choose the traffic logging level from the Level Of Traffic Logging drop-down menu. The
following are the level options:
None
TCP connection requests & UDP traffic (which is the default)
TCP connection requests, SYN-ACK, FIN, RST & UDP traffic
TCP SYN-ACK packets from the specified port & UDP traffic

Step 5

6-62

Click OK to save the traffic logging level.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation
Signature Overview
The sensing engines and signatures are the core
technologies of the Cisco IDSs.
The signatures are researched and developed by
Cisco security engineers.
The sensing engines use the signature
information to determine if the network traffic is
considered malicious activity.
The sensing engines are designed to perform
pattern matching, stateful pattern matching,
protocol decodes, and heuristic methods.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-57

The sensing engines and signatures are the core technology of the Cisco IDS. The Cisco
Countermeasure Response Team (CRT) researches new vulnerabilities and develops signatures
that detect the new threats. The signatures are used by the sensing engine to perform the actual
intrusion detection analysis. The sensing engines are designed to perform a blend of the intrusion
detection analysis techniques, which include the following:
Pattern matching
Stateful pattern matching
Protocol analysis (decoding)
Heuristic methods

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-63

NIDS Implementation
Signature Overview (cont.)
The Director enables the network security administrator
to view the signatures, which are categorized by the
following:
Signature groups
TCP connection signatures
UDP connection signatures
String signatures
ACL violation signatures
Basic signature configuration includes the following:
Enabling or disabling the signature
Assigning the severity level
Assigning the signature action
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-58

The Director enables the network administrator to view the IDS signature, which are categorized
by the following:
Signature groups
Custom signatures
TCP connection signatures
UDP connection signatures
String signatures
ACL violation signatures
Each signature has the following basic configurable parameters:
Enable statusEnables or disables the signature
Severity levelAssigns the severity level (information, low, medium, or high)
Signature actionAssigns the action to take if the signature is triggered

6-64

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Signature Groups
Choose Configuration>Sensing Engine>Signature Configuration>Signature
Group.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-59

The Cisco CRT has grouped the signatures according to either an application or protocol. The
signature groupings are listed in the following table:
All Signatures
Authorization Failure Signatures
BackOrifice Signatures
Custom Signatures
Cisco IOS Signatures
DNS Signatures
Distributed DOS Signatures
FTP Signatures
Fingers Signatures
ICMP Signatures
IDENT Signatures
IMAP Signatures
Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-65

INN Signatures
IP Fragmentation Signatures
IP Header Signatures
LPR Signatures
Loki Signatures
POP Signatures
PostOffice Comm Status Signatures
RPC-based Application Signatures
Rlogin Signatures
SATAN Signatures
SMTP/Sendmail Signatures
SNMP Signatures
SQL Signatures
SSH Signatures
Security Violation Signatures
String Match Signatures
TCP Header Signatures
TCP Hijack Signatures
Telnet Signatures
UDP Application Signatures
UDP Header Signatures
WWW Signatures
Windows/NetBIOS Signatures
6-66

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Note

Copyright

The signature groups may change in subsequent releases.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-67

Custom Signatures
Choose Configuration>Sensing Engine>Signature Configuration>Custom
Signatures.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-60

The custom signatures are those signatures that the network security administrator has tuned or
created. These signatures are associated with a signature micro-engine.
The following are the signature micro-engines available:
Atomic.ICMPUsed to examine ICMP packets for a single condition, such as an ICMP
type.
Atomic.IPOptionsUsed to examine IP packets with a specified IP option.
Atomic.L3.IPUsed to examine layer 3 IP packets for a single condition, such as detecting
Enhanced Interior Gateway Routing Protocol (EIGRP) packets.
Atomic.TCPUsed to examine TCP packets for a single condition, such as a specific TCP
port.
Atomic.UDPUsed to examine UDP packets for a single condition, such as a specific UDP
port.
Flood.Host.ICMPUsed to examine an excessive number of ICMP packets sent to a target
host.
Flood.Host.UDPUsed to examine an excessive number of UDP packets sent to a target
host.
Flood.NetUsed to examine an excessive number of packets sent to a network segment.
6-68

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Flood.TCPSYNUsed to examine an excessive number of half-opened connections.

Service.DNS.TCPUsed to examine TCP DNS packets.
Service.DNS.UDPUsed to examine UDP DNS packets.
Service.PortMapUsed to examine requests made to the RPC port mapper application.
Service.RPCUsed to examine packets sent to RPC programs and applications.
State.HTTPUsed to perform protocol analysis on an HTTP stream.
String.HTTPUsed to search an HTTP stream for a string pattern.
String.ICMPUsed to search ICMP packets for a string pattern.
String.TCPUsed to search TCP packets for a string pattern.
String.UDPUsed to search UDP packets for a string pattern.
Sweep.Host.ICMPUsed to detect a single address scanning multiple network addresses
using ICMP packets.
Sweep.Host.TCPUsed to detect a single address scanning multiple network addresses
using TCP packets.
Sweep.Port.TCPUsed to detect TCP connections to multiple destination ports between
two network addresses.
Sweep.Port.UDPUsed to detect UDP connections to multiple destination ports between
two network addresses.
Sweep.RPCUsed to detect connections to multiple destination ports with RPC request
messages between two network addresses.
Click the Edit icon next to the signature identifier (SIGID) to tune the signature.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-69

String Signatures
Choose Configuration>Sensing Engine>Signature Configuration>String
Signatures.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-61

String pattern matching signatures are based on searching to content (data) of a particular TCP
session. The string pattern is in regular expression similar to regular expression used in
programming languages such as Perl or Python.
Note

It is recommended that you add new string-matching signatures by using the STRING
signature micro-engines.

Complete the following steps to add a string signature:

6-70

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select String Signatures from the TOC. A list of string signatures is displayed in the work
content area.

Step 4

Click Add. The Adding fields are displayed in the work content area.

Step 5

Enter the TCP port number in the Port field.

Step 6

Choose the direction from the Direction drop-down menu.

Step 7

Enter the number of occurrences the string must occur to trigger the signature in the Occurrences
field.

Step 8

Enter the string pattern in the Regular Expression field.

Step 9

Enter user comments to associate with the signature.

Step 10

Choose the signature severity level from the Severity drop-down menu.

Step 11

Select the signature action by selecting the Block, IP Log, or Reset check boxes.

Step 12

Click OK to save the string signature. The signature is displayed in the list of string signatures.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 13

Copyright

Click the Edit icon next to the signatures Enabled circle to tune the signature.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-71

NIDS ImplementationIEV
Complete the following tasks to start
using IEV:
Add the IEV host as a remote event destination.
Download the IEV software from the Sensor.
Install the IEV software on the host.
Reboot the IEV host to start IDS services.
Add IDS devices that the IEV will monitor.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-62

The IDS Event Viewer (IEV) software is included with the Sensor software. You must complete
the following tasks to begin using IEV to monitor events from an IDS device:

6-72

Step 1

Add the IEV host as a remote event destinationThis includes launching a web browser,
specifying the Sensor as the location, and then adding the IEV host as a remote event destination
and enable packet capturing.

Step 2

Download the IEV software from the SensorThis includes launching a web browser,
specifying the Sensor as the location, and then downloading IEV from the Sensor.

Step 3

Install the IEV software on the hostThis includes starting the IEV setup program and
continuing with the installation wizard.

Step 4

Reboot the IEV host to start the IDS servicesThis includes rebooting the IEV host in order to
initialize the IDS services needed by IEV.

Step 5

Add IDS devices that the IEV is to monitorThis includes specifying the IDS devices from
which the IEV application accepts events.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Sensor Remote Host

Choose Configuration>Communication>Remote Hosts and Select Add.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-63

Complete the following steps to add the IEV host as a remote event destination:
Step 1

Launch your web browser and specify the Sensor as the location:
-----

Step 2

Log into the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Communications from the sub-area bar. The Communications TOC is displayed.

Step 5

Select Remote Hosts from the TOC. The remote host options are displayed in the work content
area.

Step 6

Click Add. The Adding window opens in the work content area.

Step 7

Enter the values listed in the following table and accept the default values for the other
parameters.

Copyright

Cisco IDS Settings

Parameters

Description

Host Name

<Host Name>

Alphanumeric identifier for the

IEV host.

Host ID

165535

Numeric identifier for the IEV

host.

Organization Name

<Org Name>

Alphanumeric identifier for a

group of Cisco IDS components.

Organization ID

165535

Numeric identifier for a

collection of Cisco IDS
Components.

IP Address

<IP Address>

The IP address of the IEV host.

PostOffice Port

102565535

The UDP port number used for

IDS communication.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-73

Step 8

6-74

Cisco IDS Settings

Parameters

Description

Heartbeat

165535

Time interval that the Cisco IDS

Communication Infrastructure
uses when transmitting route
verification messages.

Click OK to accept the host values. The IEV host is displayed in the list of remote hosts.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Sensor Remote Event Destination

Choose Configuration>Communication>Remote Hosts>Event
Destinations and Select Add.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-64

Complete the following steps to add the event destination:

Step 1

Select Event Destinations from the Remote Hosts TOC options. The list of event destinations is
displayed in the work content area.

Step 2

Accept the default event destination identification number.

Step 3

Click Add. The Add Destination window opens.

Step 4

Choose the IEV host from the host drop-down menu.

Step 5

Choose the alarm severity from the Level drop-down menu to send medium events to the IEV
host.

Step 6

Choose the Cisco IDS service from the Service drop-down menu.

Step 7

Select the types of events to send to the IEV host.

Step 8

Click OK to accept the event destination values. The IEV host is displayed in the list of event
destinations.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-75

Applying Sensor Configuration

Choose Apply Changes and Select Finish.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-65

Complete the following steps to apply the Sensor configuration:

6-76

Step 1

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 2

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed. The Sensor is configured to capture traffic and ready to send events to the
IEV.

Step 3

Select Logout from the IDM toolbar.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Download
Choose Monitoring>IDS Event Viewer.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-66

Complete the following steps to download the IEV software from the Sensor:
Step 1

Launch your web browser and specify the Sensor as the location by entering the following:
-----

Step 2

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 3

Select Monitoring from the area bar. The Monitoring sub-area bar is displayed.

Step 4

Select IDS Event Viewer from the sub-area bar. The IDS Event Viewer data is displayed in the
Content Area. Notice that Monitoring>IDS Event Viewer is displayed in the path bar.

Step 5

Select Download the Windows NT/2000 IDS Event Viewer from the Downloads section.

Step 6

Save the IEV installation application (iev-win.exe) to your hard disk. Note the destination
location. This information is needed in the next task.
Notice the IEV readme file is available for download. It is recommended to download this file
and review the information prior to installing the IEV.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-77

IEV Installation

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-67

The IEV installation application is a wizard-based installation program. Complete the following
steps to install the IEV application:

6-78

Step 1

Launch the IEV installation application from the location where it was saved. The Cisco IDS
Event Viewer Welcome window opens.

Step 2

Click Next to continue the installation wizard process. The Select Destination Location window
opens.

Step 3

Specify the destination folder if the default location is not acceptable.

Step 4

Click Next to continue with the wizard installation process. The Select Program Manager
window opens.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Installation (cont.)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-68

Step 5

Enter the Program Manager group if the default location is not acceptable.

Step 6

Click Next to continue with the installation wizard process. The Start installation window opens.

Step 7

Click Back if any mistakes were made.

Step 8

Click Next to continue with the installation wizard process. The Installing window displays the
IEV installation progress.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-79

IEV Installation (cont.)

2003, Cisco Systems, Inc. All rights reserved.

Step 9

The IEV application files are copied to the destination location. The IEV file copy process takes
approximately fiveseven minutes depending on system performance. After the files are copied,
the Configure Local Host PostOffice Settings window opens.

Step 10

Enter the local host PostOffice settings in the fields and click Next to continue with the
installation wizard process. The following table contains the communication parameters and a
description of each:
Cisco IDS Settings

Parameters

Description

Port Number

102565535

The UDP port number used for

IDS communication.

Organization Name

<Org Name>

Alphanumeric identifier for a

group of Cisco IDS components
(for example, securitynoc).

Organization ID

165535

Numeric identifier for a

collection of Cisco IDS
components.

Host Name

<Hostname>

Alphanumeric identifier for the

Cisco Director (for example,
director1).

Host ID

165535

Numeric identifier for the Cisco

IDS Director.

Note

6-80

CSI 1.16-69

This step does not add an IDS device to monitor. Adding a device to the IEV is described in
the next step.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Installation (cont.)

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-70

Step 11

Click Finish to complete the IEV installation wizard process. The Install dialog window opens.

Step 12

Click OK to restart the system and complete the installation process.

Review the log.txt file under Cisco IDS Event Viewer\IEV\bin directory. It should only contain
this message: Cisco IDS Event Viewer service successfully started.
Note

Do not remove the c:\my.cnf file. The MySQL server used by the IEV requires this file.

The IEV application requires supporting Cisco IDS services and applications. These services and
applications are initialized after the system is rebooted. The Cisco IDS services and applications
are as follows:
CSIDS Data Feed serviceResponsible for receiving the alarms from remote devices
Cisco IDS Event Viewer serviceStores the alarms in MySQL database, archives the
database files, and checks available disk space
MySQL serviceResponsible for consistently storing the data and serving data when
queried
Note

Copyright

The Cisco IDS Event Viewer service depends on the CSIDS Data Feed and MySQL services.
If you want to stop receiving alarms, you can stop the CSIDS Data Feed service, which will
stop the Cisco IDS Event Viewer service. Later you can restart the Cisco IDS Event Viewer
service, which will cause the CSIDS Data Feed service to resume receiving and storing
alarms.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-81

Add IDS Devices

Choose File>New>Devices.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-71

The IEV installation process does not prompt you to add an IDS device to monitor. Complete the
following steps to add an IDS device to the IEV:

6-82

Step 1

Choose Start>Programs>Cisco Systems>Cisco IDS Event Viewer>Cisco IDS Event Viewer

to launch the IEV. The Cisco IDS Event Viewer application opens.

Step 2

Choose File>New Devices from the main menu. The Device Properties window opens.

Step 3

Enter the new Sensor information in the fields and click OK to save the information. The IDS
device appears in the Devices folder. The following table contains the Sensor communication
parameters and a description of each:
CIDS Settings

Parameters

Description

IP Address

<IP Address>

The IP address of the Sensor.

Organization Name

<Org Name>

Alphanumeric identifier for a

group of Cisco IDS components
(for example, securitynoc).

Organization ID

165535

Numeric identifier for a

collection of Cisco IDS
components.

Host Name

<Host Name>

Alphanumeric identifier for the

Sensor (for example, sensor1).

Host ID

165535

Numeric identifier for the

Sensor.

PostOffice Port

102565535

The UDP port number used for

IDS communication.

Heartbeat

165535

Time interval that the Cisco IDS

communication infrastructure
uses when transmitting route
verification messages.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ImplementationVPN Concentrator
VPN Concentrator Implementation

The following are some of the

items that must be configured
for the VPN Concentrator:
IKE proposals used
Group configuration
Identity

PSTN

Authenticate
users and
terminate IPSec

General
IPSec

2003, Cisco Systems, Inc. All rights reserved.

Internet

Public
services

CSI 1.16-73

Implementation on the Concentrator includes but is not limited to setting up the following:
The IKE proposals that are used
Group configuration

Copyright

Identity

General

IPSec

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-83

Activate IKE Proposal

3002/Unity Client
2.5 Client
Certicom Client

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-74

The Concentrator can handle three types of remote clients: Cisco client, Altiga client, and
Certicom client. Before the Concentrator can interface with these clients, you must make sure
that the appropriate IKE proposal is configured, activated, and prioritized.In remote access
connections, the client sends IKE proposals to the Concentrator. The Concentrator functions
only as a responder. As the responder, the Concentrator checks the active IKE proposal list, in
priority order, to see if it can find a proposal that matches with parameters in the clients
proposed SA. If a match is found, the tunnel establishment continues. If no match is found, the
tunnel is torn down.
The IKE proposals are as follows:
For the Unity Client, use any of the proposals that start with Cisco VPN Client. The
default is Cisco VPN Client-3DES-MD5. The Unity Client proposal must be listed first
under the Active Proposals list, or your Client will not connect.
For the Altiga Client, use any of the IKE proposals, except the IKE proposals that end in
DH7.
For the Certicom Client, use a proposal that ends in DH7. The Certicom client requires a
proposal that supports Diffie-Hellman group 7 (DH7).
Each IKE proposal in the figure is a template. The parameters assigned to the template are
applied to individual remote connection.

6-84

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Within the User Management>Groups>Modify training window, you can view or modify
individual group parameters. There are four tabs located under User Management>Groups:
Identity tabConfigure the group name, password, and group authentication server type.
General tabConfigure access rights and privileges, and access protocols.
IPSec tabConfigure IPSec tunneling parameters.
PPTP/L2TP tabConfigure Point-to-Point Tunneling Protocol (PPTP) and Layer 2
Tunneling Protocol (L2TP) tunneling parameters.
In the Identity tab you can set the following Identity parameters:
Group Name fieldEnter a unique name for this specific group. The maximum is 32
characters.
Password fieldEnter a unique password for this specific group. The minimum is 4 and
maximum is 32 characters. The field displays only asterisks.
Verify fieldRe-enter the group password to verify it. The field displays only asterisks.
Type drop-down menuClick the drop-down menu button and choose the type of group:

Copyright

InternalUse the internal Cisco VPN 3000 Concentrator authentication server to

authenticate groups for IPSec tunneling. The internal server is the default selection.
ExternalUse an external authentication server to verify this group, such as a RADIUS
server.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-85

Error! Not a valid link.

The General tab can be broken down into three sections:

The top section defines access rights and privileges.
The center section is used for WINS and DNS information used by the client.
The bottom section defines which tunneling protocols this group supports.
Within the General tab, you can configure the following parameters:
Access Hours drop-down menuClick the drop-down menu button and select the named
hours when group users can access the Cisco VPN 3000 Concentrator.

No RestrictionsNo restrictions on access hours.

NeverNo access at any time.

Business hoursAccess 9 a.m. to 5 p.m., Monday through Friday.

Simultaneous Logins fieldEnter the number of simultaneous logins that group users are
permitted. The minimum is 1 and the default is 3. While there is no maximum limit,
allowing several could compromise security and affect performance.
Minimum Password Length fieldEnter the minimum number of characters for group user
passwords. The minimum is 1, the default is 8, and the maximum is 32.
Allow Alphabetic-Only Passwords check boxSelect the check box to allow base group
user passwords with alphabetic characters only, which is the default. To protect security, it is
strongly recommended that you not allow such passwords.
Idle Timeout fieldEnter the base group idle timeout period in minutes. If there is no
communication activity on the connection in this period, the system terminates the
connection.
Maximum Connect Time fieldEnter the group maximum connection time in minutes. At
the end of this time, the system terminates the connection.
Filter drop-down menuSelect the type of filter you wish to apply to this group.
Primary DNS fieldEnter the primary IP address of the DNS server for this groups users.
Secondary DNS fieldEnter the IP address of the secondary DNS server for this groups
users.
6-86

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Primary WINS fieldEnter the primary IP address of the WINS server for this groups
users.
Secondary WINS fieldEnter the secondary IP address of the WINS server for this groups
users.
SEP Card Assignment check boxesIt is recommended that you leave all four check boxes
selected.
Tunneling Protocols check boxesSelect the tunneling protocols the user VPN Clients can
use. (Although the Concentrator can support all four protocols simultaneously, in this
chapters lab exercise, de-select PPTP and L2TP. Select IPSec only.)
Strip Realm check boxSelect this check box only for PPTP, L2TP, or both.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-87

Error! Not a valid link.

The IPSec tab enables you to configure IPSec parameters that apply to this group. The window
can be divided into two sections: IPSec and remote access parameters. IPSec parameters can be
set as follows:
IPSec SA drop-down menuClick the drop-down menu button and choose the IPSec SA
assigned to this groups IPSec clients. During tunnel establishment, the IPSec client and
server negotiate a SA that governs authentication, encryption, encapsulation, key
management, and so on. View or modify IPSec SAs on the Configuration>Policy
Management>Traffic Management>Security Associations window.
IKE Peer Identity Validation drop-down menuThis option applies only to tunnel
negotiations based on digital certificates.
IKE Keepalives check boxSelect this check box to enable the feature. (IKE Keepalives is
enabled by default.) This feature enables the Concentrator to monitor the continued presence
of a remote peer, and to report its own presence to that peer. If the peer becomes
unresponsive, the Concentrator initiates removal of the connection. Enabling IKE keepalives
prevent hung connections when rebooting either the host or the peer. For this feature to
work, both the Concentrator and its remote peer must support IKE keepalives. The following
peers support IKE keepalives:

Cisco VPN Client (Release 3.0)

Cisco VPN 3000 Client (Release 2.x)

Cisco VPN 3002 Hardware Client

Cisco VPN 3000 Series Concentrators (with IKE support)

Cisco IOS software

Cisco PIX Firewall

Reauthentication on Rekey check boxBy selecting the Reauthentication on Rekey check

box, the Concentrator prompts the user for an identification and password whenever a re-key
occurs. The default is disabled.
Tunnel Type drop-down menuClick the drop-down menu and choose the remote access
tunnel type. Choose Remote access for IPSec client to LAN applications.

6-88

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ImplementationLayer 3 Switch
This section describes the implementation of the Layer 3 switch in the SAFE SMR medium
network campus module.
Error! Not a valid link.

The following commands and features are used to implement SAFE SMR on a Layer 3 switch:
Layer 3 and 4 filtering (and RFC filtering)

access-list command

access-group command

Trust Exploitation

set vlan command (Configures private VLANs, if practical)

CAM Table Overflow and ARP Spoofing Attacks

Copyright

set port security command

show port command

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-89

Error! Not a valid link.

As with most devices using Cisco IOS or Cisco IOS-like commands, ACLs can be used to
implement Layer 3 and 4 filtering.
The syntax for the access-list command is as follows:
access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range timerange-name]
access-list-number

Number of an ACL. This is a decimal number from 100 to 199 or

from 2000 to 2699.

dynamic dynamic-name

(Optional.) Identifies this ACLs as a dynamic ACL. Refer to lockand-key access documented in the "Configuring Lock-and-Key
Security (Dynamic Access Lists)" chapter in the Cisco IOS
Security Configuration Guide.

timeout minutes

(Optional.) Specifies the absolute length of time, in minutes, that

a temporary ACL entry can remain in a dynamic ACL. The default
is an infinite length of time and allows an entry to remain
permanently. Refer to lock-and-key access documented in the
"Configuring Lock-and-Key Security (Dynamic Access Lists)"
chapter in the Cisco IOS Security Configuration Guide.

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an IP. It can be one of the keywords eigrp,

gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim, tcp, or udp, or an
integer in the range from 0 to 255 representing an IP number. To
match any IP (including ICMP, TCP, and UDP) use the ip
keyword.

source

Number of the network or host from which the packet is being

sent. There are three alternative ways to specify the source:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.

source-wildcard

Wildcard bits to be applied to source. Each wildcard bit 0

indicates the corresponding bit position in the source. Each
wildcard bit set to 1 indicates that both a 0 bit and a 1 bit in the
corresponding position of the IP address of the packet will be
considered a match to this ACL entry.
There are three alternative ways to specify the source wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format. Place
1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a source and
source-wildcard of 0.0.0.0 255.255.255.255.
Use host source as an abbreviation for a source and sourcewildcard of source 0.0.0.0.
Wildcard bits set to 1 need not be contiguous in the source
wildcard (for example, a source wildcard of 0.255.0.64 would be
valid).

6-90

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

destination

Number of the network or host to which the packet is being sent.

There are three alternative ways to specify the destination:
Use a 32-bit quantity in four-part, dotted-decimal format.
Use the any keyword as an abbreviation for the destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.

destination-wildcard

Wildcard bits to be applied to the destination. There are three

alternative ways to specify the destination wildcard:
Use a 32-bit quantity in four-part, dotted-decimal format. Place
1s in the bit positions you want to ignore.
Use the any keyword as an abbreviation for a destination and
destination-wildcard of 0.0.0.0 255.255.255.255.
Use host destination as an abbreviation for a destination and
destination-wildcard of destination 0.0.0.0.

precedence precedence

(Optional.) Packets can be filtered by precedence level, as

specified by a number from 0 to 7, or by name.

tos tos

(Optional.) Packets can be filtered by type of service level, as

specified by a number from 0 to 15, or by name.

log

(Optional.) Causes an informational logging message about the

packet that matches the entry to be sent to the console. (The
level of messages logged to the console is controlled by the
logging console command.)
The message includes the access list number, whether the
packet was permitted or denied; the protocol, whether it was TCP,
UDP, ICMP, or a number; and, if appropriate, the source and
destination addresses and source and destination port numbers.
The message is generated for the first packet that matches, and
then at 5-minute intervals, including the number of packets
permitted or denied in the prior 5-minute interval.
The logging facility might drop some logging message packets if
there are too many to be handled or if there is more than one
logging message to be handled in 1 second. This behavior
prevents the router from crashing due to too many logging
packets. Therefore, the logging facility should not be used as a
billing tool or an accurate source of the number of matches to an
ACL.

log-input

(Optional.) Includes the input interface and source MAC address

or VC in the logging output.

time-range time-range-name

(Optional.) Name of the time range that applies to this statement.

The name of the time range and its restrictions are specified by
the time-range command.

The syntax for the access-group command is as follows:

ip access-group {access-list-number | access-list-name}{in | out}

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-91

6-92

access-list-number

Number of an ACL. This is a decimal number from 1 to 199 or

from 1300 to 2699.

access-list-name

Name of an IP ACL as specified by an ip access-list command.

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Private VLANs (PVLANs) are available on the Catalyst 6000 running Cat operating system 5.4
or later, and are available on the Catalyst 4000, 2980G, 2980G-A, 2948G, and 4912G running
Cat operating system 6.2 or later.
PVLANs are a tool that enables the segregating of traffic at Layer 2 and turning a broadcast
segment into a non-broadcast multi-access-like segment. Traffic that comes to a switch from a
promiscuous port (that is, a port that is capable of forwarding both primary and secondary
VLANs) is able to go out on all the ports that belong to the same primary VLAN. Traffic that
comes to a switch from a port mapped to a secondary VLAN (it can be either an isolated, a
community, or a two-way community VLAN) can be forwarded to a promiscuous port or a port
belonging to the same community VLAN. Multiple ports mapped to the same isolated VLAN
cannot exchange any traffic.
Note

You must configure a private VLAN on the supervisor engine.

Valid values for pvlan-type are as follows:

primarySpecifies the VLAN as the primary VLAN in a PVLAN
isolatedSpecifies the VLAN as the isolated VLAN in a PVLAN
communitySpecifies the VLAN as the community VLAN in a PVLAN
twoway-communitySpecifies the VLAN as a bidirectional community VLAN that carries
the traffic among community ports, and to and from community ports to and from the Multilayer Switch Feature Card (MSFC)
noneSpecifies that the VLAN is a normal Ethernet VLAN, not a PVLAN
Note

VLANs 1001, 1002, 1003, 1004, and 1005 cannot be used in PVLANs.

The syntax for the set vlan command is as follows:

set vlan {vlans} [pvlan-type pvlan_type]

Copyright

vlans

Number identifying the VLAN; valid values are from 1 to 1000,

and from 1025 to 4094.

pvlan-type

(Optional.) Keyword and options to specify the PVLAN type.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-93

Error! Not a valid link.

Configuring port security on the switch can mitigate these attacks. This option provides for
either the specification of the MAC addresses on a particular switch port or the specification of
the number of MAC addresses that can be learned by a switch port. When an invalid MAC is
detected on the port the switch can either block the offending MAC address or shutdown the
port.
The syntax for the set port security command is as follows:
set port security mod/port... [enable | disable] [mac_addr] [age {age_time}]
[maximum {num_ of_mac}] [shutdown {shutdown_time}] [violation
{shutdown | restrict}]
mod/port...

Number of the module and the port on the module.

enable

(Optional.) Enables port security.

disable

(Optional.) Disables port security.

mac_addr

(Optional.) Secure MAC address of the enabled port.

age age_time

(Optional.) Specifies the duration for which addresses on the port

will be secured; valid values are 0 (to disable) and from 1 to 1440
(minutes).

maximum num_of_mac

(Optional.) Specifies the maximum number of MAC addresses to

secure on the port; valid values are from 1 to 1025.

shutdown shutdown_time

(Optional.) Specifies the duration for which a port will remain

disabled in case of a security violation; valid values are 0 (to
disable) and from 1 to 1440 (minutes).

violation

(Optional.) Specifies the action to be taken in the event of a

security violation.

shutdown

Shuts down the port in the event of a security violation.

restrict

Restricts packets from unsecure hosts.

The syntax for the show port command is as follows:

show port security [mod[/port]]
show port security statistics {mod[/port]}
show port security statistics system

6-94

mod

(Optional.) Number of the module.

port

(Optional.) Number of the port on the module.

statistics

Displays security statistics.

system

Displays system-wide configuration information.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Summary
Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-95

Error! Not a valid link.

6-96

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-97

Lab ExerciseMedium Network Design

Implementation
Complete the following lab exercise to practice what you learned in this chapter.

Objectives
In this exercise you will complete the following tasks:
Assign the Sensors IP network settings.
Define the lists of hosts that are allowed to access the Sensor.
Assign the Sensors communications infrastructure settings.
Enable the IDS Device Manager web server.
Save the Sensors initial configuration.
Verify the Sensors network configuration.
Cisco IDS Event Viewer.
Download the IEV software from the Sensor.
Install the IEV software on the PC.
Add the IDS devices to the list of devices monitored by the IEV.
Disable the Sensors insecure remote management services.
Configure the Sensor and PIX Firewall to perform IP Blocking.
Exchange SSH keys between the Sensor and the PIX Firewall.
Assign the blocking action to an IDS signature.
Configure the Sensors blocking properties.
Add a PIX Firewall as a blocking device.
Test the blocking configuration.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-1

Network Security Policy

You will implement this network security policy in this lab:
Monitor traffic on the internal network for attacks.
Centrally manage network-based IDS appliances.
Block attacks at the PIX Firewall if detected by the Sensor.

Visual Objectives
The following figure displays the configuration you will complete in this lab exercise.

Lab Visual Objective

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24
.150

.10P e0/1

Branch

brP
.1 e0/0

10.2.P.0/24

RBB
.1

10.2.P.11

Branch

.2

.150

172.16.P.0/24

Super
Server
WWW
FTP

PSS
WWW
FTP
.10

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP
.2 e0

.5

.1 e1

.50
.4

pub

priv

.1 e4

.1 e2

DMZ
.5

pP

10.0.P.0 /24

172.18.P.0/24

cP
.100

RTS

sensorP

Student

10.0.P.11

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.16-1

Setup
You should not have to configure any routing or addressing of interfaces on lab equipment in
this exercise. You may find that your sensors setting may already be configured. In this case,
verify the settings are correct using the steps below before proceeding.

Task 1Assign the Sensors IP Network Settings

In this task you will assign an IP address to the Sensors command and control interface, a UNIX
hostname, and a default route. Complete the following steps to assign the Sensors IP network
settings:
Step 1

Lab 6-2

Access the terminal server as directed by your instructor:

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

(where P = pod number)

Step 2

Access the Sensor via its console port as directed by your instructor:
- -

(where P = pod number)

Step 3

Log into the Sensor as the root user with the default password attack:

--

Step 4

Execute the sysconfig-sensor utility on the Sensor. The Cisco IDS Sensor Initial Configuration
Utility menu appears.
----

Step 5

Enter y if prompted to write the values to disk. Select the options from the main menu listed in
the following table and assign the lab settings:
Cisco IDS Options/Parameters

Lab Settings

IP Address

10.0.P.4

IP Netmask

255.255.255.0

IP Host Name

sensorP

Default Route

Local: 10.0.P.1

(where P = pod number)

Q1)

In what situations would you not need a default route assigned to the Sensor?
A)

Task 2Define the Lists of Hosts that Are Allowed to Access the
Sensor
Complete the following steps to add the list of hosts and networks that are allowed to access the
Sensor via the network using either Telnet, FTP, SSH, or HTTP:
Step 1

Select the Access Control List option from the main menu. The Access Control List screen is
displayed.

Step 2

Enter the addresses listed in the following table:

Cisco IDS Parameters

Lab Settings

Student PC

Local: 10.0.P.11

Student Network

Local: 10.0.P.

(where P = pod number)

Q2)

Would you recommend being more restrictive? What other network addresses might be
included, if any?
A)

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-3

Step 3

When finished entering addresses, press Enter to exit.

Step 4

Enter y when prompted to write the network access configuration to disk.

Task 3Assign the Sensors Communications Infrastructure Settings

This task involves configuring the Sensors IDS communication infrastructure parameter settings
necessary for communication between the Sensor and Director. Complete the following steps to
assign the Sensors communication infrastructure settings:
Step 1

Select the Communication Infrastructure option from the main menu. The Communication
Infrastructure window opens.

Step 2

Enter y to continue, and enter the Cisco IDS Communications Infrastructure parameters listed in
the following table:
Cisco IDS Parameters

Lab Settings

Sensor Host ID

Sensor Organization ID

Sensor Host Name

sensorP

Sensor Organization Name

podP

Sensor IP Address

10.0.P.4

(where P = pod number)

Step 3

Enter y when prompted if IDM will be used to manage the Sensor. The Communication
Infrastructure settings are displayed.

Step 4

Verify that the settings are correct and enter y when prompted to create the configuration files.
Enter n if any mistakes are made. Then enter y when prompted to enter the values again and
repeat steps 23.

Step 5

The configuration files are created and backup copies of any existing configuration files are
saved.

Step 6

Press Enter to continue. A message stating the configuration files were written successfully is
displayed.

Step 7

Press Enter to continue. The Cisco IDS Sensor Initial Configuration Utility menu is displayed.

Task 4Enable the IDS Device Manager Web Server

This task involves selecting the IDS Device Manager option and enabling the IDM web server.
Complete the following steps to enable the IDM web server:
Step 1

Choose the IDS Device Manager option from the main menu. The IDS Device Manager menu
and current mode is displayed.

Step 2

Select Enable from the IDS Device Manager menu.

Step 3

Select the Exit option to return to the previous menu.

Lab 6-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 5Save the Sensors Initial Configuration

This task involves exiting the Cisco IDS Sensor Initial Configuration utility and rebooting the
Sensor. Complete the following steps to save the Sensors initial configuration:
Step 1

Select the Exit option to exit the Cisco IDS Sensor Initial Configuration utility. A message
stating that the sysconfig-sensor configuration has been completed successfully is displayed.

Step 2

Press Enter to continue. A message stating you have entered values that require a reboot is
displayed.

Step 3

Enter y to reboot. A reboot warning message is displayed. Wait approximately one to two
minutes for the Sensor to reboot.

Task 6Verify the Sensors Network Configuration

This task involves verifying the Sensors IP configuration and IDS communication parameters.
Complete the following steps to verify the Sensors network configuration:
Step 1

Launch your web browser and specify the Sensor as the location:
-

Step 2

(where P = pod number)

Click Yes when prompted to accept the Sensors certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Device from the area bar. The Device sub-area bar is displayed.

Step 5

Select Sensor Setup from the sub-area bar. The Sensor Setup table of contents (TOC) is
displayed.

Step 6

Select Network from the TOC. The Sensors network settings are displayed in the work content
area.

Step 7

Verify the values listed in the following table for the Cisco IDS parameters. Modify the
following values if necessary:

Copyright

Cisco IDS Parameters

Lab Values

Description

Host Name

sensorP

The Sensors alphanumeric

identifier.

Host ID

The Sensors numeric identifier.

Organization Name

podP

Alphanumeric identifier for a

group of Cisco IDS components.

Organization ID

Numeric identifier for a

collection of Cisco IDS
Components.

PostOffice Port

45000

The UDP port number used for

IDS communication.

Heartbeat Interval Multiplier

The number of times the

heartbeat packet is sent to a
Cisco IDS host before the route
is declared down.

IP address

10.0.P.4

The IP address of the Sensor

(for example, 10.10.10.3).

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-5

Cisco IDS Parameters

Lab Values

Description

Netmask

255.255.255.0

The subnet mask for the Sensor

(for example, 255.255.255.0).

Default route

Local: 10.0.P.1

The Sensors default route for

routing purposes, if needed (for
example, 10.10.10.1).

Step 8

Continue with the next task if changes were not made to the Sensors network settings.

Step 9

Click OK to save the Sensors network settings.

Step 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.

Task 7Cisco IDS Event Viewer

Complete the following steps to install the Cisco IDS Event Viewer (IEV):
Step 1

Launch your web browser and specify the Sensor as the location. To do this, enter the following
in the URL field of your web browser:
-

(where P = pod number)

Step 2

Click Yes when prompted to accept the Sensors certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 5

Select Communications from the sub-area bar. The Communications TOC is displayed.

Step 6

Select Remote Hosts from the TOC. The remote host options are displayed in the work content
area.

Step 7

Click Add. The Adding window is displayed in the content area.

Step 8

Enter the values listed in the following table and accept the default values for all other
parameters:

Lab 6-6

Cisco IDS Parameters

Lab Values

Description

Host Name

ievP

Alphanumeric identifier for the

IEV host.

Host ID

12

Numeric identifier for the IEV

host.

Organization Name

podP

Alphanumeric identifier for a

group of Cisco IDS
Components.

Organization ID

Numeric identifier for a

collection of Cisco IDS
Components.

IP Address

Local: 10.0.P.11

The IP address of the IEV host.

PostOffice Port

45000

The UDP port number used for

IDS communication.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IDS Parameters

Lab Values

Description

Heartbeat

Time interval that the Cisco IDS

Communication Infrastructure
uses when transmitting route
verification messages.

(where P = pod number)

Step 9

Click OK to accept the host values. The IEV host is displayed in the list of remote hosts.

Step 10

Select Event Destinations from the Remote Hosts TOC options. The list of event destinations is
displayed in the work content area.

Step 11

Click Add. The Add Destination window opens.

Step 12

Choose the IEV host, ievP.podP, from the host drop-down menu.

Step 13

Choose the alarm severity level, Low, from the Level drop-down menu to send low events to the
IEV host.

Step 14

Choose the Cisco IDS Service, smid, from the Service drop-down menu.

Step 15

Select Cisco IDS event types to send to the IEV host: Alarms, Errors, and Commands.

Step 16

Click OK to accept the event destination values. The IEV host is displayed in the list of event
destinations.

Step 17

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 18

Click Finish to apply your changes to the Sensor. When the changes are successfully applied, a
message is displayed. The Sensor is now configured to capture traffic and ready to send events to
the IEV.

Task 8Download the IEV Software from the Sensor

This task involves accessing the IDM and selecting the IEV software to download. Complete the
following steps to download the IEV software from the Sensor:
Caution

If the lab is set up in a remote fashion, do not attempt to download the IEV Software from the
Sensor. Install the software according to the instructor.

Step 1

Select Monitoring from the area bar. The Monitoring sub-area bar is displayed.

Step 2

Select IDS Event Viewer from the sub-area bar. The IEV data is displayed in the content area.
Notice Monitoring>IDS Event Viewer is displayed in the Path bar.

Step 3

Select Download the Windows NT/2000 IDS Event Viewer from the Downloads section. The
File Download window opens.

Step 4

Select Save this file to disk and click OK. The Save As window opens.

Step 5

Choose Desktop as the download location and click Save to save the IEV installation
application (iev-win.exe) to your desktop. The IEV software is installed in the next task. The
IEV installation application download process takes approximately 1015 minutes depending on
system performance.

Step 6

Log out of the IDM interface and close the web browser.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-7

Task 9Install the IEV Software on the PC

This task involves launching the IEV installation application and entering the Cisco IDS
communication parameters. Complete the following steps to install the IEV software on the PC:
Step 1

Launch the IEV installation application from the PCs desktop. The Cisco IDS Event Viewer
Welcome window opens.

Step 2

Click Next to continue the installation wizard process. The Select Destination Location window
opens.

Step 3

Accept the default installation location and click Next to continue with the wizard installation
process. The Select Program Manager window opens.

Step 4

Accept the default Program Manager group and click Next to continue with the installation
wizard process. The Start installation window opens.

Step 5

Click Back if any mistakes were made. Click Next to continue with the installation wizard
process. The Installing window displays the IEV installation progress.

Step 6

The IEV application files are copied to the destination location. The IEV file copy process takes
approximately five to seven minutes depending on system performance. Once the files are
copied, the Configure Local Host PostOffice Settings window opens.

Step 7

Enter the IEV host PostOffice settings and click Next to continue with the installation wizard
process. The following table contains the communication parameters and a description of each:
Cisco IDS Parameters

Lab Values

Description

Port Number

45000

The UDP port number used for

IDS communication

Organization Name

podP

Alphanumeric identifier for a

group of Cisco IDS components

Organization ID

Numeric identifier for a

collection of Cisco IDS
components

Host Name

ievP

Alphanumeric identifier for the

IEV host

Host ID

12

Numeric identifier for the IEV

host

(where P = pod number)

Step 8

Click Finish to complete the IEV installation wizard process. The Install dialog window opens.

Step 9

Click OK to restart the system and complete the installation process.

Task 10Add the IDS Devices to the List of Devices Monitored by the
IEV
This task involves launching the IEV application and adding the Sensor to the list of devices the
IEV will monitor. Complete the following steps to add the IDS devices to the list of devices
monitored by the IEV:
Step 1

Choose Start>Programs>Cisco Systems>Cisco IDS Event Viewer>Cisco IDS Event Viewer

to launch the IEV. The Cisco IDS Event Viewer application opens.

Step 2

Choose File>New Device from the main menu. The Device Properties window opens.

Lab 6-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Enter the new Sensor information and click OK to save the information. The IDS device appears
in the Device Folders. The following table contains the Sensor communication parameters and a
description of each:

Step 3

Cisco IDS Parameters

Lab Values

Description

IP Address

10.0.P.4

The IP address of the Sensor

Organization Name

podP

Alphanumeric identifier for a

group of Cisco IDS components

Organization ID

Numeric identifier for a

collection of Cisco IDS
Components

Host Name

sensorP

Alphanumeric identifier for the

Sensor

Host ID

Numeric identifier for the Sensor

PostOffice Port

45000

UDP port number used for IDS

communication

Heartbeat

Time interval that the Cisco IDS

Communication Infrastructure
uses when transmitting route
verification messages

(where P = pod number)

Task 11Disable the Sensors Insecure Remote Management Services

This task involves disabling the Sensors Telnet and FTP services to enforce secure
communication between the Sensor and management hosts. Complete the following steps to
disable the Sensors insecure remote management services:
Launch your web browser and specify the Sensor as the location. To do this, enter the following
in the URL field of your web browser:

Step 1

(where P = pod number)

Step 2

Click Yes when prompted to accept the Sensors certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Device from the area bar. The Device sub-area bar is displayed.

Step 5

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 6

Select Remote Access from the TOC. The Sensors remote access settings are displayed in the
work content area.

Step 7

De-select the FTP check box to disable the FTP service.

Step 8

De-select the Telnet check box to disable the Telnet service.

Step 9

Click OK to save the Sensors remote access settings.

Step 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-9

Step 12

Attempt to establish a Telnet session to your Sensor. Access should be denied because your
Sensors Telnet service is disabled.

Step 13

Attempt to establish an FTP session to your Sensor. Access should be denied because your
Sensors FTP service is disabled.

Step 14

Establish a secure shell (SSH) session to the Sensor as netrangr with the password attack.
Access should be allowed because SSH is enabled by default and is a secure method of
communication.

Task 12Configure the Sensor and PIX Firewall to Perform IP Blocking

Complete the following steps to configure the PIX Firewall to perform IP blocking:
Step 1

Configure SSH on the PIX Firewall to allow connections from the Sensor and the IDM host:

-
Note

You may be asked to zeroize the rsa keys if previously generated keys exist. Enter the ca
zeroize command and repeat the ca gen command.

-
-- -

(where P = pod number)

Step 2

Create a static mapping to the student PC on the outside network:

Note

This step is needed to demonstrate the IDS functionality and is not required in a production
environment.

- -- -

(where P = pod number)

Note

The order of the existing ACL must be modified to permit the following entry.

--- -

(where P = pod number)

Task 13Exchange SSH Keys Between the Sensor and the PIX
Firewall
Complete the following steps to exchange SSH keys between the Sensor and the PIX Firewall:
Step 1

Establish a Telnet or SSH session to the Sensor and log on as user netrangr, password attack.

Lab 6-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Q3)

In what situations might Telnet be chosen instead of SSH?

A)

Establish an SSH session as user pix to the PIX Firewall:

Step 2

--- --

(where P = pod number)

Accept the PIX Firewalls SSH key by entering yes when prompted.

Step 3

Note

If you are not prompted to accept the PIX Firewalls SSH key, the key was previously
accepted. Proceed with the next step. If you are given a warning, delete the Sensors
known_hosts file from the Sensor using the rm command.

Step 4

Enter the PIX Firewall Telnet password when prompted: cisco.

Step 5

Exit the SSH session between the Sensor and the PIX Firewall.

Step 6

Exit the Telnet or SSH session to the Sensor.

Task 14Assign the Blocking Action to an IDS Signature

Complete the following steps to configure a signatures action to blocking:
Launch your web browser and specify the Sensor as the location:

Step 1

(where P = pod number)

Step 2

Log into the Cisco IDM as user netrangr. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Sensing Engine from the sub-area bar. The Sensing Engine TOC is displayed.

Step 5

Select Signature Groups from the Sensing Engine TOC. A list of signature groups is displayed
in the work content area.

Step 6

Select All Signatures from the list of Signature Groups. The list of All Signatures is displayed.

Step 7

Select Page 18 Sigid [5070-5085] from the drop-down menu at the bottom of the page.

Step 8

Click the Go to Page button. The list of Signatures is displayed.

Step 9

Select the Edit icon for the WWWinNt cmd.exe access 5081. The Editing window opens.

Step 10

Choose High from the Severity drop-down menu.

Step 11

Select the Block check box from the list of Actions.

Step 12

Change the MinHits value to 1 to enable the signature to trigger after one failed login attempt.

Step 13

Click OK to save the signature settings. The list of Signatures is displayed. Notice that the
WWWinNt cmd.exe Access Signature severity is High and that the action is set to block.

Step 14

Select Page 20 Sigid [5103-5117] from the drop-down menu at the bottom of the page.

Step 15

Click the Go to Page button. The list of Signature is displayed.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-11

Q4)

Are these signatures good candidates to perform IP blocking if detected? Why or why
not?
A)

Step 16

Select the Edit icon for WWWIIS Unicode Attack Signature 5114. The Editing window opens.

Step 17

Choose Log from the Severity drop-down menu.

Step 18

Change the MinHits value to 1 to enable the signature to trigger after one failed login attempt.

Step 19

Click OK to save the signature settings. The list of Signatures is displayed. Notice that the
WWWIIS Unicode Attack Signature severity is High and that the action is set to block.

Step 20

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 21

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.

Task 15Configure the Sensors Blocking Properties

Complete the following steps to configure the Sensors blocking properties:
Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Blocking from the sub-area bar. The Blocking TOC is displayed.

Step 3

Select Blocking Properties from the Blocking TOC. The Sensors blocking properties are
displayed.

Step 4

Select the Enable Blocking check box to enable blocking.

Step 5

Enter values for the Cisco IDS settings listed in the following table:
Cisco IDS Settings

Parameters

Description

Minutes of Block

10

The duration the block is

enforced

Maximum Block Entries

100

The maximum number of

access control entries the
Sensor can add to an ACL

Step 6

Select the Enable Policy Violations Logging check box to enable logging of policy violations.

Step 7

Deselect the Allow the Sensor IP to be Blocked check box to disable the ability to block the
Sensors IP address. This is the default setting.

Step 8

Click OK to save the Sensors blocking properties.

Step 9

If prompted, select Apply Changes from the IDM toolbar. The Finished option is displayed in
the work content area.

Step 10

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.

Task 16Add a PIX Firewall as a Blocking Device

Complete the following steps to add a PIX Firewall as a blocking device:
Lab 6-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Blocking from the sub-area bar. The Blocking TOC is displayed.

Step 3

Select Blocking Devices from the Blocking TOC. A list of the Sensors blocking devices is
displayed.

Step 4

Select Add from the content area. The Adding information is displayed in the content area.

Step 5

Enter values for the Cisco IDS settings listed in the following table:
Cisco IDS Settings

Parameters

Description

IP Address

10.0.P.1

The IP address of the blocking

device

NAT Address

Leave blank

The translated Sensor IP

address

Username

pix

The username used to access

the managed device

Password

cisco

The usernames password

Enable Password

enable

The blocking devices enable or

secret password

(where P = pod number)

Step 6

Choose PIX from the Device Type drop-down menu.

Step 7

Select the Enable SSH check box.

Step 8

Click OK to save the Blocking devices properties. The blocking device is displayed in the
content area.

Step 9

Click OK when the pop-up window with the message A Blocking Device Interface must be
specified for configuration of the new Blocking Device to be complete. opens.

Step 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work
content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully
message is displayed.
Q5)

List some guidelines to follow when deciding how to implement IP blocking.

A)

Task 17Test the Blocking Configuration

This task involves launching an attack against the target network that causes the signature to
initiate the Sensors block function. Complete the following steps to test the blocking
configuration:
Step 1

Launch your web browser from the VPN Client PC.

Step 2

Enter the IP address of your student PC in your browser.

(where student_ip_address = student PC public address)

Step 3

Enter the URLs listed in the following table in your browser.

(where student_ip_address = student PC public address)

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-13

URL

Signature Name

http://192.168.P.10/msadc/samples/selector/showcode.asp

WWW IIS Showcode.asp Access

http://192.168.P.10/scripts/..%c0%af../winnt/system32

WWW IIS Unicode Attack

http://192.168.P.10/ scripts/..%35c../winnt/system32/cmd.exe?/c+dir

WWW WinNT cmd.exe

(where P = pod number)

Note
Step 4

No spaces should be entered in the URL.

View the alarms generated in the IEV. Select a signature that was configured to perform a Block
if detected.
Q6)

Were all the attacks detected by the Sensor and reported to the IEV? Why or why not?
A)

Note

You can view the blocked hosts directly from the PIX Firewall by issuing the show shun
command.

Step 5

Select Administration from the area bar. The Administration sub-area bar is displayed.

Step 6

Select Manual Blocking from the sub-area bar. A list of blocking devices and the list of blocked
hosts and networks is displayed in the content area. Complete the following sub-steps:
1. Notice the status of the Net Device. The status should be Active.
2. Notice the list of blocked devices. The list includes addresses from other pods because you
are monitoring the same network.
Note

Step 7

You can view the blocked hosts directly from the PIX Firewall by issuing the show shun
command.

Select Unblock All to remove all of the addresses from the list of blocked devices.

Lab 6-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Answers
Q1)

In what situations would you not need a default route assigned to the Sensor?
A)

Q2)

Would you recommend being more restrictive? What other network addresses might be
included, if any?
A)

Q3)

Q6)

Copyright

Allowing insecure communication is ultimately determined by a companys

security policy. Telnet might be chosen when the device does not support SSH
or when the management network is an out-of-band management network and
secure communications is not a requirement.

Are these signatures good candidates to perform IP blocking if detected? Why or why
not?
A)

Q5)

In general allowing entire network segments is not desirable unless all of the
management workstations reside on that particular network. It is recommended
to be as restrictive as possible when defining what hosts can manage the Sensor.

In what situations might Telnet be chosen instead of SSH?

A)

Q4)

A default route assigned to the Sensor is not needed when the Sensor does not
need to communicate with devices on another network. The typical scenario
occurs when the IDS Director is on the same network and the Sensor is not
performing blocking.

A companys security policy should define which signatures meet the

requirements for enabling blocking. In general, signatures such as these are
considered an immediate threat and are good candidates for enabling IP
blocking. However, you do risk the possibility of creating a large ACL when
under a massive attack.

List some guidelines to follow when deciding how to implement IP blocking.

A)

Identify all network entry and exit points.

B)

Identify critical hosts and networks that should never be blocked.

C)

Implement ingress and egress filtering.

D)

Identify those signatures that are deemed an immediate threat to your networks
security.

E)

Assign the appropriate block duration.

Were all the attacks detected by the Sensor and reported to the IEV? Why or why not?

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-15

A)

No. The Sensor did not detect all of the signatures once a block signature was
detected. After the block occurred, the PIX Firewall denied the traffic from the
source.

Lab 6-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote User Network

Implementation
Overview
This chapter introduces the Cisco Remote User Network implementation strategy and
components. It includes the following topics:
Design overview
Key devices and threat mitigation
Software access option
Remote site firewall option
VPN Hardware Client option
Remote site router option
Summary

Objectives
This section lists the objectives of this chapter.

Objectives
Upon completion of this chapter, you will be able to perform
the following tasks:
Describe the key devices in a remote user network.
List the threats mitigated.
Discuss the four different options for providing remote user
connectivity.
Understand the mitigation roles of each of the following:
VPN Software Client
PIX Firewall
VPN Hardware Client
IOS Firewall
Implement specific configurations to apply the mitigation roles.

2003, Cisco Systems, Inc. All rights reserved.

7-2

Cisco SAFE Implementation 1.1

CSI 1.17-2

Copyright

2003, Cisco Systems, Inc.

Design Overview
This section gives a brief overview of the SAFE: Extending the Security Blueprint to Small,
Midsize, and Remote-User Networks (SAFE SMR) Remote-User network implementation.

Remote User Connectivity

There are four
options for
remote-user
connectivity:

Covers both
mobile and
home-office
workers
Contains
hardware,
software, and
combined designs

2003, Cisco Systems, Inc. All rights reserved.

ISP edge module

ISP

VPN
Software
Client with
personal
firewall

Software
access option

Broadban
d access
device
Home
office
firewall
with VPN

Broadband
access
device
Hardware
VPN
Client

Remote site Hardware VPN

firewall option Client option

Broadband
access
device
(optional)
Router
with
firewall
and VPN

Remote site
router option

CSI 1.17-4

Remote connectivity applies to both mobile workers and home-office workers. The primary
focus of these designs is providing connectivity from the remote site to the corporate
headquarters and through some means, the Internet. The following four options include
software-only, software-with-hardware, and hardware-only solutions:
Software accessRemote user with a virtual private network (VPN) Software client and
personal firewall software on the PC.
Remote-site firewall optionThe remote site is protected with a dedicated firewall that
provides firewalling and IPSec VPN connectivity to corporate headquarters. WAN
connectivity is provided via an ISP-provided broadband access device (for example, a
Digital Subscriber Line [DSL] or cable modem).
VPN Hardware Client optionRemote site using a dedicated VPN Hardware Client that
provides IPSec VPN connectivity to corporate headquarters. WAN connectivity is provided
via an ISP-provided broadband access device.
Remote-site router optionThe remote site using a router that provides both firewall
capabilities and IPSec VPN connectivity to corporate headquarters. This router can either
provide direct broadband access or go through and ISP-provided broadband access device.
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-3

IPSec Remote-User to LANTunneling

VPN private IP
10.0.1.5

Telecommuter
or mobile
worker

ISP
Internet

Application
server
10.0.1.10

VPN public IP
192.168.1.5

Adapter (NIC) IP address

172.31.1.1
Client IP address
10.0.1.20

The result of implementing IPSec remote-user to

LAN tunneling is that the security perimeter of your
organization is extended to include remote sites.
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-5

A VPN is defined as customer connectivity deployed on a shared infrastructure with the same
policies as a private network. The shared infrastructure can leverage a service provider IP, Frame
Relay, ATM backbone, or the Internet. The result is that the security perimeter of the
organization is extended to the remote site.
The Cisco end-to-end hardware and Cisco IOS software networking products enables a complete
access VPN solution by providing the following:
Sophisticated security for sensitive private transmissions over the public infrastructure
Quality of Service (QoS) through traffic differentiation
Reliability for mission-critical applications
Scalability for supporting large bandwidth of data
Comprehensive network management

7-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IPSec Remote-User to LAN Components

Application
server

VPN
head-end device

ISP

ISP

Telecommuter
or mobile
worker

Internet

PPP connectivity
dial access
IPSec tunnel or session

Client software or hardware

PPP protocol (for dial access)
IPSec protocol
VPN head-end device

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-6

IPSec remote-user-to-LAN components consist of the following:

Cisco VPN Software Client

Resides on a PC

Terminates one end of the tunnel

IPSec and Internet Key Exchange (IKE)

Establishes a secure tunnel or session through the Internet to a Cisco VPN Concentrator
For dialup applications, IPSec relies on Point-to-Point Protocol (PPP) to establish the
physical connection to the local ISP and Internet

Concentrator

Copyright

Terminates the tunnels and sessions

Encrypts, authenticates, and encapsulates data

May provide both authentication and data encryption options

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-5

Key Devices and Threat Mitigation

This section provides details of the key devices for remote-user network implementation.

SAFE Remote UserKey Devices

ISP

Broadband
access device

Hub

The following are the key

devices:
Firewall with a VPN
or a router with a
firewall and VPN

Hardware or
Software VPN
Client

Key devices

2003, Cisco Systems, Inc. All rights reserved.

Broadband access device

Firewall with VPN support
Layer 2 hub
Personal firewall software
Router with firewall and VPN
support
VPN Software Client
VPN Hardware Client

CSI 1.17-8

The following are the key devices in the SAFE remote-user configuration:
Broadband access deviceProvides access to the broadband network (for example, DSL,
cable, and so on)
Firewall with VPN supportProvides secure, end-to-end encrypted tunnels between the
remote site and the corporate head-end, and provides network-level protection of remote-site
resources and stateful filtering of traffic
Layer 2 hubProvides connectivity for devices within the remote site, which can be
integrated into the firewall or VPN Hardware Client
Personal firewall softwareProvides device-level protection for individual PCs
Router with firewall and VPN supportProvides secure, end-to-end encrypted tunnels
between the remote site and the corporate head-end, provides network-level protection of
remote-site resources and stateful filtering of traffic, and can provide advanced services such
as voice or QoS
VPN Software ClientProvides secure, end-to-end encrypted tunnels between individual
PCs and the corporate head-end
7-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Hardware ClientProvides secure, end-to-end encrypted tunnels between the remote
site and the corporate head-end

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-7

Mitigated Remote User Threats

The following threats are common
to most remote user networks:
Unauthorized access
Network reconnaissance
Virus and Trojan horse attacks
IP spoofing
Man-in-the-middle attacks

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-9

The following threats are expected in this environment:

Unauthorized accessAny data that traverses a network that is not authorized.
Network reconnaissanceInformation-gathering activities by which hackers collect data
that is used to later compromise networks.
Virus and Trojan horse attacksViruses are computer programs that are written by devious
programmers and are designed to replicate themselves and infect computers when triggered
by a specific event. Trojan horse attacks are software programs that appear to be harmless
(for example, computer games), but are actually vehicles for destructive code.
IP spoofingPosing as an authorized party in the data transmission by using the IP address
of the of the data recipients.
Manin-the-middle attacksRequires that the attacker have access to network packets that
come across the networks. Such attacks are often implemented using network packet sniffers
and routing and transport protocols. The possible uses of such attacks are theft of
information, hijacking of an ongoing session to gain access to your internal network
resources, traffic analysis to derive information about your network and its users, denial of
service, corruption of transmitted data, and introduction of new information into network
sessions.

7-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Mitigation Options Overview

There are four basic options available to

mitigate threats:
Hardware options
Remote-site firewall
VPN Hardware Client
Remote-site router
Software optionSoftware access

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-10

The following are the solutions for remote access network threat mitigation:
Remote site firewallUse of a remote-site firewall can provide a high level of security.
Cisco VPN Hardware ClientUse of a hardware client that is independent of the host
provides a connection with a greater level of security than a software client.
Remote-site routerUse of a remote-site router can provide a medium level of security but
can establish an IPSec tunnel and basic security that is independent of the host.
Software accessUse of software for access provides security at a host level, which uses the
host processor and memory.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-9

Software Access Option

This section provides details of the software access option for remote users.

Software Access Option

Attack Mitigation Roles
ISP Edge Module

ISP

VPN
Software
Client
with a
personal
firewall

Authenticate remote site,

terminate IPSec, and personal
firewall and virus scanning for
local attack mitigation

Software
access option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-12

The following are the specific attack mitigation roles for the software access option:
Authenticate remote siteProperly identify and verify a user or service
Terminate IPSecSuccessfully establish an IPSec tunnel between the remote site and host
site
Personal firewall and virus scanning for local attack mitigationAllay the risk of virus
infection at the remote site

7-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Software Access Option

Design Guidelines
Geared toward mobile and
home office worker
Remote user needs VPN
software and Internet access
Authentication and
configuration are controlled
from the headquarters
Split tunneling is disabled when
the VPN tunnel is operational
Personal firewall software is
recommended to protect the
remote user when split
tunneling is not enabled or the
VPN is not connected
Virus scanning software is
recommended
2003, Cisco Systems, Inc. All rights reserved.

ISP Edge Module

ISP

VPN
Software
Client
with a
personal
firewall

Software
access option

CSI 1.17-13

The software access option is geared toward the mobile worker as well as the home-office
worker. All the remote user requires is a PC with Cisco VPN Client software and connectivity to
the Internet or ISP network via a dial-in or Ethernet connection.
The primary function of the VPN Software Client is to establish a secure, encrypted tunnel from
the client device to a VPN head-end device. Access and authorization to the network are
controlled from the headquarters location when filtering takes place on the firewall, and on the
client itself if access rights are pushed down via policy. The remote user is first authenticated,
and then receives IP parameters such as a virtual IP address, which is used for all VPN traffic,
and the location of name servers (Domain Name System [DNS] and Windows Internet Name
Service [WINS]).
Split tunneling can also be enabled or disabled via the central site. For the SAFE design, split
tunneling was disabled, making it necessary for all remote users to access the Internet via the
corporate connection when they have a VPN tunnel established. Because the remote user may
not always want the VPN tunnel established when connected to the Internet or ISP network,
personal firewall software is recommended to mitigate unauthorized access to the PC. Virusscanning software is also recommended to mitigate viruses and Trojan horse programs infecting
the PC.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-11

Software Access Option

Implementation
ISP Edge Module

The Cisco VPN Client

version 3.5 or higher is the
recommended product for
implementation of the
software access option:
Provides integrated VPN and
firewall functionality

ISP

VPN
Software
Client
with a
personal
firewall

Simple install process

Configured via the head-end
VPN termination device

Software
access option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-14

It is recommended that you use the latest level of the VPN Software Client unless technical
specifications or compatibility issues require an earlier version.
The Cisco VPN Client version 3.5 or higher is the recommended product for implementation of
the software access option:
Provides integrated VPN and firewall functionality
Simple install process
Configured via the head-end VPN termination device

7-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Windows Client

192.168.1.5

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-15

The VPN Windows Client is a software program that runs on Windows 95, 98, ME, 2000, XP,
and NT 4.0. The VPN Client on a remote PC, communicating with a Concentrator at an
enterprise or service provider, creates a secure connection over the Internet that enables you to
access a private network as if you were an on-site user.
The figure displays the VPN Client window. From this window, you can launch the new
connection wizard, change or set optional parameters, and launch the VPN Client. The
Connection Entry field enables you to provide a unique name for this VPN connection. The
address of the Concentrators public interface is configured in the field Host name or IP address
of the remote server.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-13

Cisco VPN Client Options

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-16

The Options drop-down menu enables you to configure or change optional parameters. By
clicking the Options button, the following options become available:
Clone EntryEnables you to copy a connection entry with all its properties.
Delete EntryEnables you to delete a connection entry.
Rename EntryEnables you to rename a connection entry (it is not case sensitive).
Import EntryProvides a pre-configured .pcf file that loads the VPN Client parameters.
Erase User PasswordEliminates a saved password. Erase User Password is available only
when you have enabled Allow Password Storage under the Mode Configuration parameters
for this group.
Create ShortcutEnables you to create a shortcut for your desktop.
PropertiesEnables you to configure or change the properties of the connection.
Stateful Firewall (Always On)Blocks all inbound traffic (to the VPN Client) that is not
related to an outbound session. After the remote user enables the stateful firewall, it is
always on.
Application LauncherEnables you to launch an application before establishing a
connection. This is used in conjunction with Windows Login Properties.

7-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Windows Logon PropertiesWindows Login Properties Enables the VPN Client to make
the connection to the Concentrator before the user logs in.
If the system administrator needs to know what VPN Client version you have installed on your
PC, click the Title Bar Lock icon, or right-click the system tray icon.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-15

Properties Tabs

General
Authentication
Connections

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-17

From the Options drop-down menu on the Cisco Systems VPN Client main screen, choose
Properties. Within Properties there are three tabs:
GeneralEnables IPSec through Network Address Translation (NAT), displays the status of
the local LAN access feature, and selects Microsoft network logon options.
AuthenticationConfigures the VPN Clients group or digital certificate information.
ConnectionsEnables backup connections and links the VPN connection to Dialup
Networking phonebook entries.

7-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PropertiesGeneral Tab
Win 95/98/ME

2003, Cisco Systems, Inc. All rights reserved.

Win-NT 4/2000/XP

CSI 1.17-18

There are two versions of the General tab, depending on the operating system you are using:
The Windows 95,98, and ME versionProvides options for transparent tunneling, local
LAN access, and Microsoft login options
Windows NT 4.0,2000, and XP versionProvides transparent tunneling and local LAN
access only
The functions of the General tab are as follows:
Enable Transparent Tunneling check boxWorks with Windows 95, 98, NT 4.0, 2000, and
XP. The following are found within the Enable Transparent Tunneling group box:

Allow IPSec over UDP (NAT/PAT) radio buttonEnables you to use the VPN Client to
connect to the Concentrator via UDP through a firewall or router that is running NAT.
Both the VPN Client and Concentrator must be enabled for this feature to work.
Use IPSec over TCP (NAT/PAT/Firewall) radio buttonEnables you to use the VPN
Client to connect to the Concentrator via TCP through a firewall or router that is running
NAT. Both the VPN Client and Concentrator must be enabled for this feature to work.
Allow local LAN access check boxFor security purposes, the user has the ability to
disable local LAN access when using an insecure local LAN (for example, in a hotel).

Peer response timeout fieldThe number of seconds to wait before the VPN Client decides
that the peer is no longer active. The VPN Client continues to send DPD requests until it
reaches the peer response timeout value.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-17

Logon to Microsoft Network check boxWorks with Windows 95, 98, and ME only. The
following are found within the Logon to Microsoft Network group box:

7-18

Use default system logon credentials radio buttonUse the logon username and
password resident on your PC to log onto the Microsoft network (for example, student4).
Prompt for network logon credentials radio buttonIf your logon username and
password differ from the private network, the private network prompts you for the
username and password.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PropertiesAuthentication Tab

The end-user never

sees the password
after initial
configuration.

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-19

The Concentrator and VPN Client connection can be authenticated with either the group name
and password, or digital certificates. The Authentication tab enables you to set your
authentication information. You need to choose one method, group or certificate, via the radio
buttons. Within the Group Access Information group box, enter the group name and password in
the appropriate fields. The group name and password must match what is configured for this
group within the Configuration>User Management>Groups>Identity window. Entries are case
sensitive.
For certificates to be exchanged, the Certificate radio button must be selected. In the Name dropdown menu, any personal certificates loaded on your PC are listed. Choose the certificate to be
exchanged with the Concentrator during connection establishment. If no personal certificates are
loaded in your PC, the drop-down menu is blank. Use the Validate Certificate button to check
the validity of the VPN Clients certificate.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-19

PropertiesConnections Tab

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-20

The last tab is the Connections tab. It defines backup networks and connection to the Internet via
dialup networking. A private network may include one or more backup Concentrators to use if
the primary Concentrator is not available.
Your system administrator tells you whether to enable a backup Concentrator and gives you its
address. If the VPN Client cannot reach the primary Concentrator, the VPN Client tries a backup
Concentrator. Select the Enable backup server(s) check box to enable this feature. Once
selected, click Add to enter the IP address of the backup Concentrator. Your VPN Client then
attempts to connect to your primary Concentrator first. If that Concentrator cannot be reached,
the VPN Client accesses the backup list for the addresses of available backup Concentrators.
Connecting to a private network using a dialup connection is typically a two-step process:
Step 1

Use a dialup connection to your ISP.

Step 2

Use the VPN Client to connect to the private network.

Connecting to the Internet via dialup networking automatically launches the DUN connection
before making the VPN connection. It makes connecting to the ISP and Concentrator a one-step
process. To enable the option, select the Connect to the Internet via dialup check box.

7-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Site Firewall Option

This section provides details of the remote site firewall access option for remote users.

Remote Site Firewall

Attack Mitigation Roles

ISP
Broadband
access
device

Stateful packet filtering,

basic Layer 7 filtering, Host
DoS mitigation, authenticate
remote site, and terminate
IPSec

Home
office
firewall
with a VPN

Virus scanning for local

attack mitigation

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-22

This figure provides attack mitigation roles for the remote site firewall option:
Stateful packet filteringOffers strong security by thoroughly inspecting data packets and
maintaining critical addresses and port numbers in a lookup table
Basic Layer 7 filteringOffers basic filtering at the application layer of the OSI model
Host DoS mitigationPrevents host-based denial of service (DoS) attacks
Authenticate remote siteProperly identifies and verifies a user or service
Terminate IPSecSuccessfully establishes an IPSec tunnel between the remote site and host
site
Virus scanning for local attack mitigationAllays the risk of virus infection at the remote
site

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-21

Remote Site Firewall

Design Guidelines
Geared toward a home-office worker or a very
small branch office
Firewall provides connection-state
enforcement
Termination point for site-to-site IPSec
For remote management and production
Client does not need individual software
(firewall or VPN)
NAT is not used in IPSec tunnel
Device authentication is used at head-end
Allows split tunneling
Authentication is controlled from the
headquarters
Virus checking software is still recommended
Personal firewall software can be used to
protect the remote user when split tunneling
is not enabled
You can use an IDS on a PIX Firewall
2003, Cisco Systems, Inc. All rights reserved.

ISP
Broadband
access
device
Home
office
firewall
with a VPN

Remote site
firewall option

CSI 1.17-23

The remote-site firewall option is geared toward the home-office worker, or potentially a very
small branch office. With this option, it is expected that the remote site have some form of
broadband access available from a service provider. The firewall is installed behind the DSL or
cable modem.
The primary function of the firewall is to establish the secure, encrypted tunnel between itself
and a VPN head-end device, as well as providing connection-state enforcement and detailed
filtering for sessions initiated through it. Individual PCs on the remote-site network do not need
VPN client software to access corporate resources. Additionally, because the stateful firewall
protects access to the Internet, personal firewall software is not necessarily required on the
individual PCs. However, if the network administrator wants an additional level of security,
personal firewall software can also be implemented on remote-site PCs. This setup may be useful
if the home worker also travels and connects to the Internet directly over some public network.
Because the corporate headquarters has a stateful firewall protecting the hosts, the remote site
can have direct access to the Internet, rather than passing all traffic back through the corporate
headquarters. Unless NAT is used when communicating with the headquarters, the IP addresses
of the remote-site devices should be assigned in such a manner as to not overlap addressing
space in the headquarters location or another remote site. Remote-site devices that require direct
access to the Internet will require address translation to a registered address. This address
translation can be achieved by translating all Internet-bound sessions to the public IP address of
the firewall itself.
Access and authorization to the corporate network and the Internet are controlled by the
configuration of both the remote-site firewall and the VPN head-end device. Configuration and
security management of the remote-site firewall can be achieved via an IPSec tunnel from the
public side of the firewall back to the corporate headquarters. This setup ensures that the remotesite user is not required to perform any configuration changes on the home-office firewall.
Authentication should be set up on the firewall to prevent a local user from inadvertently
7-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

modifying their firewall configuration and thereby compromise the security policy of that
device. Individual users at the remote site who access the corporate network are not
authenticated with this option. Instead, the remote-site firewall and VPN head-end use device
authentication.
Virus-scanning software is still recommended to mitigate against viruses and Trojan horse
programs infecting individual PCs at the remote sitejust like all the PCs in the entire
corporation.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-23

PIX FirewallImplementation
Commands Summary
The following are the necessary
implementation mitigation roles and
commands for the PIX Firewall:
Stateful packet filtering (this is the
default for the PIX Firewall)
Host DoS mitigation
ip verify reverse-path interface
icmp
attack guard commands (except for
frag guard, these are on by default)
static/nat
Spoof mitigation and RFC filtering
access-list
access-group

ISP
Broadband
access
device
Home
office
firewall
with a VPN

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-24

The following mitigation roles and commands are used to implement the policy on the Cisco
PIX Firewall:
Stateful packet filtering (this is the default for the PIX Firewall)
Host DoS mitigation

ip verify reverse-path interfaceImplements Unicast RPF IP spoofing protection

icmpEnable or disable pinging to an interface

attack guard commandsEnabled by default

static/natImplements static or dynamic nat

Spoof mitigation and RFC filtering

7-24

access-listCreates an ACL

access-groupBinds the ACL to an interface

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PIX FirewallImplementation
Commands Summary (cont.)
Authenticate remote
Site (and logging)
aaa-server
aaa authentication
logging on
Terminate IPSec
sysopt connection
permit-ipsec
isakmp enable
isakmp key
isakmp policy
crypto ipsec
transform-set
crypto map

ISP
Broadband
access
device
Home
office
firewall
with a VPN

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-25

aaa-serverSpecifies an authentication, authorization, and accounting (AAA) server

aaa authenticationEnables, disables, or views LOCAL, Terminal Access Controller
Access Control System (TACACS+), or Remote Access Dial-In User Service (RADIUS)
user authentication
logging onEnables or disables Syslog and Simple Network Management Protocol
(SNMP) logging
sysopt connection permit-ipsecImplicitly permits any packet that came from an IPSec
tunnel
isakmp enableEnables Internet Security Association Key Management Protocol
(ISAKMP) negotiation on the interface on which the IPSec peer communicates with the PIX
Firewall
isakmp keySpecifies the authentication pre-shared key
isakmp policyUniquely identifies the IKE policy and assigns a priority to the policy
crypto ipsec transform-setCreates, views, or deletes IPSec security associations (SAs),
SA global lifetime values, and global transform sets
crypto mapCreates, modifies, views, or deletes a crypto map entry

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-25

Terminate IPSecSysopt connection

permit-ipsec and isakmp enable
pixfirewall(config)#

-- -
Implicitly permit any packet that came from an IPSec tunnel and
bypass the checking of an associated access-list, conduit, or
access-group command statement for IPSec connections.

-- -

pixfirewall(config)#

-
Used to enable ISAKMP negotiation on the interface on which the
IPSec peer will communicate with the PIX Firewall. This is
enabled by default.

- -
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-26

The sysopt connection permit-ipsec command implicitly permits any packet that came from an
IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group
command statement for IPSec connections.
The isakmp enable command is used to enable ISAKMP negotiation on the interface on which
the IPSec peer will communicate with the PIX Firewall. Use the no isakmp enable command to
disable IKE.
The syntax for the sysopt connection command is as follows:
sysopt connection permit-ipsec
connection permit-ipsec

Implicitly permit any packet that came from an IPSec tunnel and
bypass the checking of an associated access-list, conduit, or
access-group command statement for IPSec connections.

The syntax for the isakmp enable command is as follows:

isakmp enable interface-name
interface-name

7-26

Cisco SAFE Implementation 1.1

The name of the interface on which to enable ISAKMP

negotiation.

Copyright

2003, Cisco Systems, Inc.

Terminate IPSecisakmp key

pixfirewall(config)#

- - -- -- -
Specifies the authentication pre-shared key.
You can use any combination of alphanumeric characters
up to 128 bytes. The pre-shared key must be identical at
both peers.

- -
-- -

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-27

To configure a pre-shared authentication key and associate the key with an IPSec peer address or
hostname, use the isakmp key address command. Use the no isakmp key address command to
delete a pre-shared authentication key and its associated IPSec peer address.
You would configure the pre-shared key at both peers whenever you specify pre-shared key in
an IKE policy. Otherwise, the policy cannot be used because it will not be submitted for
matching by the IKE process.
A netmask of 0.0.0.0. can be entered as a wildcard indicating that any IPSec peer with a given
valid pre-shared key is a valid peer.
Note

The PIX Firewall or any IPSec peer can use the same authentication key with multiple peers,
but this is not as secure as using a unique authentication key between each pair of peers.

The no-xauth or no-config-mode command options are to be used only if the following criteria
are met:
You are using the pre-shared key authentication method within your IKE policy.
The security gateway and VPN Client peers terminate on the same interface.
The Xauth or IKE Mode Configuration feature is enabled for VPN Client peers.
Both the Xauth and IKE Mode Configuration features are specifically designed for remote VPN
Clients. The Xauth feature enables the PIX Firewall to challenge the peer for a username and
password during IKE negotiation. The IKE Mode Configuration enables the PIX Firewall to

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-27

download an IP address to the peer for dynamic IP address assignment. Most security gateways
do not support the Xauth and IKE Mode Configuration features.
If you have the no-xauth command option configured, the PIX Firewall does not challenge the
peer for a username and password. Similarly, if you have the no-config-mode command option
configured, the PIX Firewall does not attempt to download an IP address to the peer for dynamic
IP address assignment.
The syntax for the isakmp key command is as follows:
isakmp key keystring address peer-address [netmask mask] [no-xauth] [no-config-mode]

7-28

key keystring

Specifies the authentication pre-shared key. Use any combination

of alphanumeric characters up to 128 bytes. This pre-shared key
must be identical at both peers.

address peer-address

Specifies the IPSec peer's IP address for the pre-shared key.

netmask mask

(Optional.) The netmask of 0.0.0.0. can be entered as a wildcard

indicating that the key could be used for any peer that does not
have a key associated with its specific IP address.

no-xauth

Only use this if you enabled the Xauth feature, and you have an
IPSec peer that is a gateway. This option associates a given preshared key with a gateway and allows an exception to the Xauth
feature enabled by the crypto map client authentication
command.

no-config-mode

Only use this if you enabled the IKE Mode Configuration feature,
and you have an IPSec peer that is a gateway. This option
associates a given pre-shared key with a gateway and allows an
exception to the IKE Mode Configuration feature enabled by the
crypto map client configuration address command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSecisakmp policy

pixfirewall(config)#

- - - - -
- - --
-
- - Sets the various parameters of the IKE policy that will be used

- - - -
-
-
-
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-28

The isakmp policy command enables you to negotiate IPSec SAs and enable IPSec secure
communications. Several parameters can be configured with this command as illustrated in the
figure.
The syntax for the isakmp policy command is as follows:
isakmp policy priority encryption des | 3des
policy priority

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 65,534, with 1 being the highest
priority and 65,534 the lowest.

encryption 3des

Specifies that the 3DES encryption algorithm is to be used in the

IKE policy.

encryption des

Specifies 56-bit DES-CBC as the encryption algorithm to be used

in the IKE policy.

The syntax for the isakmp policy command is as follows:

isakmp policy priority hash md5 | sha

Copyright

policy priority

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 65,534, with 1 being the highest
priority and 65,534 the lowest.

hash md5

Specifies MD5 (HMAC variant) as the hash algorithm to be used

in the IKE policy.

hash sha

Specifies SHA-1 (HMAC variant) as the hash algorithm to be

used in the IKE policy. This is the default hash algorithm.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-29

The syntax for the isakmp policy command is as follows:

isakmp policy priority authentication pre-share | rsa-sig
policy priority

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 65,534, with 1 being the highest
priority and 65,534 the lowest.

authentication pre-share

Specifies pre-shared keys as the authentication method.

Authentication rsa-sig

Specifies RSA signatures as the authentication method.

RSA signatures provide non-repudiation for the IKE negotiation.
This basically means you can prove to a third party whether you
had an IKE negotiation with the peer.

The syntax for the isakmp policy command is as follows:

isakmp policy priority group1 | 2
policy priority

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 65,534, with 1 being the highest
priority and 65,534 the lowest.

group 1

Specifies that the 768-bit Diffie-Hellman group is to be used in the

IKE policy. This is the default value.

group 2

Specifies that the 1024-bit DH group 2 be used in the IKE policy.

The syntax for the isakmp policy command is as follows:

isakmp policy priority lifetime seconds

7-30

policy priority

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 65,534, with 1 being the highest
priority and 65,534 the lowest.

lifetime seconds

Specifies how many seconds each security association should

exist before expiring. Use an integer from 120 to 86,400 seconds
(one day).

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSeccrypto ipsec

transform-set
pixfirewall(config)#

- -- --
- - -
Create, view, or delete IPSec SAs, SA global lifetime values, and
global transform sets.
You can specify up to three transforms. Transforms define the
IPSec security protocols and algorithms. Each transform
represents an IPSec security protocol (ESP, AH, or both) plus the
algorithm you want to use.

- --
- --

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-29

The crypto ipsec transform-set command defines a transform set. To delete a transform set, use
the no crypto ipsec transform-set command. To view the configured transform sets, use the
show crypto ipsec transform-set command.
A transform set specifies one or two IPSec security protocols (either Encapsulating Security
Payload [ESP] or Authentication Header [AH], or both) and specifies which algorithms to use
with the selected security protocol. During the IPSec SA negotiation, the peers agree to use a
particular transform set when protecting a particular data flow.
You can configure multiple transform sets, and then specify one or more of these transform sets
in a crypto map entry. The transform set defined in the crypto map entry is used in the IPSec SA
negotiation to protect the data flows specified by that crypto map entrys ACL. During the
negotiation, the peers search for a transform set that is the same at both peers. When such a
transform set is found, it is selected and is applied to the protected traffic as part of both peers
IPSec SAs.
When SAs are established manually, a single transform set must be used. The transform set is
not negotiated.
Before a transform set can be included in a crypto map entry, it must be defined using the crypto
ipsec transform-set command.
To define a transform set, you specify one to three transformseach transform represents an
IPSec security protocol (ESP or AH) plus the algorithm you want to use. When the particular
transform set is used during negotiations for IPSec SAs, the entire transform set (the
combination of protocols, algorithms, and other settings) must match a transform set at the
remote peer.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-31

In a transform set you can specify the AH protocol, the ESP protocol, or both. If you specify an
ESP protocol in a transform set, you can specify just an ESP encryption transform or both an
ESP encryption transform and an ESP authentication transform.
Examples of acceptable transform combinations are as follows:
ah-md5-hmac
esp-des
esp-des and esp-md5-hmac
ah-sha-hmac and esp-des and esp-sha-hmac
If one or more transforms are specified in the crypto ipsec transform-set command for an
existing transform set, the specified transforms will replace the existing transforms for that
transform set.
If you change a transform set definition, the change is only applied to crypto map entries that
reference the transform set. The change will not be applied to existing SAs, but will be used in
subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner,
you can clear all or part of the security association database by using the clear [crypto] ipsec sa
command.
The syntax for the crypto ipsec transform-set command is as follows:
crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

7-32

transform-set-name

Specifies the name of the transform set to create or modify.

transform1
transform2
transform3

Specifies up to three transforms. Transforms define the IPSec

security protocols and algorithms. Each transform represents an
IPSec security protocol (ESP, AH, or both) plus the algorithm you
want to use.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands
Terminate IPSec (cont.)
pixfirewall(config)#

- -- -

- --
- - - - - - -- --
--

Sets the various parameters of the IKE policy that will be used.

--
--
-
- -- -
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-30

To create or modify a crypto map entry, use the crypto map ipsec-manual | ipsec-isakmp
command. To create or modify an ipsec-manual crypto map entry, use the ipsec-manual option
of the command. To create or modify an ipsec-isakmp crypto map entry, use the ipsec-isakmp
option of the command. Use the no crypto map command to delete a crypto map entry or set.
Crypto maps provide two functions: filtering and classifying traffic to be protected, and defining
the policy to be applied to that traffic. The first use affects the flow of traffic on an interface; the
second affects the negotiation performed (via IKE) on behalf of that traffic.
IPSec crypto maps link together definitions of the following:
What traffic should be protected
Which IPSec peers to which the protected traffic can be forwardedthese are the peers with
which an SA can be established
Which transform sets are acceptable for use with the protected traffic
How keys and SAs should be used and managed (or what the keys are, if IKE is not used)
A crypto map set is a collection of crypto map entries each with a different seq-num but the same
map-name. Therefore, for a given interface, you could have certain traffic forwarded to one peer
with specified security applied to that traffic, and other traffic forwarded to the same or a
different peer with different IPSec security applied. To accomplish this you would create two
crypto map entries, each with the same map-name, but each with a different seq-num.
The number you assign to the seq-num argument should not be arbitrary. This number is used to
rank multiple crypto map entries within a crypto map set. Within a crypto map set, a crypto map
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-33

entry with a lower seq-num is evaluated before a map entry with a higher seq-num; that is, the
map entry with the lower number has a higher priority.
The syntax for the crypto map map-name command is as follows:
crypto map map-name seq-num ipsec-isakmp | ipsec-manual [dynamicdynamic-map-name]
map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

ipsec-isakmp

Indicates that IKE will be used to establish the IPSec SAs for
protecting the traffic specified by this crypto map entry.

ipsec-manual

Indicates that IKE will not be used to establish the IPSec SAs for
protecting the traffic specified by this crypto map entry.

dynamic

(Optional.) Specifies that this crypto map entry is to reference a

pre-existing dynamic crypto map.

dynamic-map-name

(Optional.) Specifies the name of the dynamic crypto map set to

be used as the policy template.

The syntax for the crypto map map-name command is as follows:

crypto map map-name seq-num match address acl_name
map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

match address

Specifies an ACL for a crypto map entry.

acl_name

Identifies the named encryption ACL. This name should match

the name argument of the named encryption ACL being matched.

The syntax for the crypto map map-name command is as follows:

crypto map map-name seq-num set peer hostname | ip-address
map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

set peer

Specifies an IPSec peer in a crypto map entry.

hostname

Specifies a peer by its hostname. This is the peer's hostname

concatenated with its domain name (for example,
myhost.example.com).

ip-address

Specifies a peer by its IP address.

The syntax for the crypto map map-name command is as follows:

crypto map map-name seq-num set transform-set transform-set-name1 [transform-set-name6]

7-34

map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

set transform-set

Specifies which transform sets can be used with the crypto map
entry.

transform-set-name

The name of the transform set.

For an ipsec-manual crypto map entry, you can specify only one
transform set. For an ipsec-isakmp or dynamic crypto map entry,
you can specify up to six transform sets.

The syntax for the crypto map map-name command is as follows:

crypto map map-name interface interface-name
map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

set transform-set

Specifies which transform sets can be used with the crypto map
entry.

transform-set-name

The name of the transform set.

For an ipsec-manual crypto map entry, you can specify only one
transform set. For an ipsec-isakmp or dynamic crypto map entry,
you can specify up to six transform sets.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-35

VPN Hardware Client Option

This section covers the use of the Cisco VPN Hardware Client for remote access.

Hardware VPN Client

Attack Mitigation Roles
ISP
Broadband
access
device
Hardware
VPN
Client

Authenticate remote site and

terminate IPSec
Personal firewall and virus
scanning for local attack
mitigation

Hardware VPN
Client option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-32

The following are the mitigation roles for the VPN Hardware Client:
Authenticate remote siteProperly identifies and verifies a user or service
Terminate IPSecSuccessfully establishes an IPSec tunnel between the remote site and host
site
Personal firewall and virus scanning for local attack mitigationProvides firewall
inspection and allays the risk of virus infection at the remote site

7-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Hardware VPN Client

Design Guidelines
Same guidelines as Remote Site
Firewall option except that the
Hardware VPN Client does not
have resident stateful firewall
Use a personal firewall on
individual hosts (if split tunneling
will be used)
If no personal firewall is in use,
security behind the VPN device
is dependent upon NAT (with split
tunneling enabled)
Access and authentication are
controlled from the headquarters
Configuration and security
management is done from the
headquarters
VPN Client software is not needed

ISP
Broadband
access
device
Hardware
VPN
Client

Hardware VPN
Client option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-33

The VPN Hardware Client option is identical to the remote-site firewall option except that the
VPN Hardware Client does not have a resident stateful firewall. This setup requires use of a
personal firewall on the individual hosts, particularly when split tunneling is enabled. Without
the personal firewall, the security of the individual hosts behind the VPN device is dependant
upon the attacker being unable to circumvent NAT. This is because when split tunneling is
enabled, connections to the Internet pass through a many-to-one NAT translation and do not
undergo any filtering at Layer 4 and above. With split tunneling disabled, all access to the
Internet must be through the corporate headquarters. This setup partially mitigates the
requirement for personal firewalls on the end systems.
Using a VPN Hardware Client offers two primary advantages:
As with the VPN Software Client, access and authorization to the corporate network and the
Internet are controlled centrally from the headquarters location. Configuration and security
management of the VPN Hardware Client device itself is done via a Secure Sockets Layer
(SSL) connection from the central site. This setup ensures that the remote-site user is not
required to perform any configuration changes on the VPN Hardware Client.
Individual PCs on the remote-site network do not need VPN Client software to access
corporate resources. However, individual users at the remote site who access the corporate
network are not authenticated with this option. Instead, the VPN Hardware Client and VPN
head-end Concentrator authenticate each other.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-37

Hardware VPN ClientImplementation

Welcome to
Cisco Systems
VPN 3000 Concentrator Series
Command Line Interface
Copyright (C) 1998-2000 Cisco Systems, Inc.
1) Configuration
2) Administration
3) Monitoring
4) Save changes to Config file
5) Help Information
6) Exit

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-34

Once connected, the administrator must gain access to the VPN 3002 Hardware Client Manager.
To gain access, complete the following steps:
Step 1

The VPN 3002 comes from the factory with a private interface IP address of 192.168.10.1. Hook
up a PC to the private port and configure the PCs TCP/IP address.

Step 2

Point the browser to the IP address of the private interface (for example, http//192.168.10.1).

Step 3

Log in using the login name and password of admin. No command line interface (CLI)
intervention is required.
However, if you would rather configure the VPN 3002 via CLI or if you need to change the
default address on the private LAN interface, you can use the CLI. The default CLI setting is
9600 8N1.

7-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

GUI

Toolbar
Table of
contents
Manager
screen

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-35

The main window of the VPN 3002 Manager after logging into the device is made up of the
following:
The top frame (VPN 3002 Manager toolbar) provides quick access to Manager functions,
configuration, administration, and monitoring.
The left frame (table of contents [TOC]) provides the TOC to the Managers windows.
The main frame (Managers) displays the current VPN 3002 Manager window. From here
you can navigate the Manager using either the TOC in the left frame or the Cisco toolbar at
the top of the frame. Select a title on the left frame of the window and the VPN 3002 will
bring up the Manager window for the selected title.
Under the location bar, the Save Needed icons may appear. When finished with a configuration
window, click Apply. Apply enables the configuration to take effect immediately. To save the
changes to memory, click the Save Needed icon. If you reboot without saving, your
configuration changes are lost.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-39

Quick Configuration

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-36

There are two ways to configure the VPN 3002: Quick Configuration and the main menu. The
goal of Quick Configuration is to provide the minimal parameters needed for operation. You can
access Quick Configuration from the Configuration>Quick window. The VPN 3002 Quick
Configuration can be run multiple times.

7-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Quick Configuration Example Screens

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-37

Quick Configuration guides you through the windows necessary to get a single tunnel up and
running. Use the main menu to tune an application or configure features individually. The
windows in the figure illustrate some of the IPSec remote access configuration screens using
Quick Configuration.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-41

Launching the Client

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-38

The VPN 3002 is configured, and now the tunnel needs to be established. In Client Mode, by
default, there is no tunnel established. There are two ways to initiate a tunnel:
By clicking Connect Now, under the Monitoring>System Status window
By sending traffic to the VPN Hardware Client destined for the remote end
You can verify the configuration by trying to ping an interface on the remote Concentrator. The
VPN 3002 recognizes the remote-bound traffic and attempts to establish a tunnel. If a tunnel is
established, it is viewable on this screen. If the tunnel does not come up, check the event log of
the VPN 3002 and the Concentrator.

7-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Site Router Option

This section summarizes the remote-site router option and provides configuration details.

Remote Site Router

Attack Mitigation Roles
ISP
Broadband
access
device
Router
with a
firewall
and a VPN

Host DoS mitigation,

stateful packet filtering,
basic Layer 7 filtering,
authenticate the remote
site, and terminate IPSec
Virus scanning for local
attack mitigation

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-40

The following are the attack mitigation roles for the remote-site router option:
Host DoS mitigationPrevents host-based DoS attacks
Stateful packet filteringOffers strong security by thoroughly inspecting data packets and
maintaining critical addresses and port numbers in a lookup table
Basic Layer 7 filteringOffers basic filtering at the application layer of the OSI model
Authenticate remote siteProperly identifies and verifies a user or service
Terminate IPSecSuccessfully establishes an IPSec tunnel between the remote site and host
site
Virus scanning for local attack mitigationAllays the risk of virus infection at the remote
site

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-43

Remote Site Router

Design Guidelines
Same guidelines as the remote
site firewall option
The router can support QoS,
routing, and more
encapsulation options
Broadband capability can be
integrated into the router:
This removes the need for a
separate broadband access
device
This is typically managed by
a service provider
An IDS on a router can be used
(this is not available on Cisco
800 series routers)

2003, Cisco Systems, Inc. All rights reserved.

ISP
Broadband
access
device
Router
with a
firewall
and a VPN

Remote site
firewall option

CSI 1.17-41

The remote-site router option is nearly identical to the remote-site firewall option with a few
exceptions. When deployed behind a standalone broadband access device, the only difference is
the router can support advanced applications such as QoS, routing, and more encapsulation
options. Additionally, if the broadband capability is integrated into the router, a standalone
broadband access device is not needed. This option requires that your ISP allow you to manage
the broadband router itself, which is an uncommon scenario.

7-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IOSImplementation
Commands Summary
The following are necessary mitigation
roles and implementation commands for
Cisco IOS:
Stateful packet filtering (part of CBAC on
Cisco IOS routers)
Spoof mitigation and RFC filtering
access-list
access-group
Host DoS mitigation and basic layer 7
filtering
ip inspect
Authenticate remote site (and logging)
aaa new-model
tacacs-server
aaa authentication login
aaa authorization exec
aaa accounting exec
login authentication

ISP
Broadband
access
device
Router
with a
firewall
and a VPN

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-42

The following are necessary mitigation roles and implementation commands for the IOS
Firewall:
Stateful packet filteringPart of Context-Based Access Control (CBAC) on Cisco IOS
Routers
Spoof mitigation and RFC filtering

access-listThe access-list command enables you to specify if an IP address is

permitted or denied access to a port or protocol.
access-groupBinds an ACL to an interface.

Host DoS mitigation and basic layer 7 filtering

ip inspectDefines the application protocols to inspect.

Authenticate remote site (and logging)

Copyright

aaa new-modelTo define a set of inspection rules, enter this command for each
protocol that you want to inspect, using the same inspection-name.

tacacs-serverDefines the TACACS server.

aaa authentication loginEnables AAA authentication at login.

aaa authorization execRestricts network access to a user.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-45

7-46

aaa accounting execRuns accounting for EXEC shell session.

login authenticationSpecifies the name of a list of AAA authentication methods to
try at login.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IOSImplementation
Commands Summary (cont.)
IPSec commandsProvides for
IPSec tunnel termination
crypto isakmp policy
encryption
authentication
group
crypto isakmp key
crypto ipsec transform-set
crypto map
set peer
set tranform-set
match address

ISP
Broadband
access
device
Router
with a
firewall
and a VPN

Remote site
firewall option

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-43

IPSec commandsProvide for IPSec tunnel termination

crypto isakmp policySpecifies the parameters to be used during an IKE negotiation.

encryptionSets the algorithm to be negotiated.

authenticationSpecifies the authentication method within an IKE policy.

groupSpecifies the AAA server group to use for pre-authentication.

crypto isakmp keyConfigures pre-shared authentication keys.

Copyright

crypto ipsec transform-setAn acceptable combination of security protocols,

algorithms and other settings to apply to IP Security protected traffic.
crypto mapConfigures filtering and classifying traffic to be protected and defines the
policy to be applied to that traffic.

set peerSpecifies an IPSec peer for a crypto map.

set transform-setSpecifies which transform sets to include in a crypto map entry.

match addressSpecifies an extended access list for a crypto map entry.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-47

Terminate IPSecEnable IKE

and Define IKE Policy
router(config)#

-
Enable Internet Key Exchange.

-
router(config)#

-
Defines an Internet Key Exchange policy
Invokes the Internet Security Association Key
Management Protocol policy configuration (configisakmp) command mode.

-
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-44

IKE is enabled by default. IKE does not have to be enabled for individual interfaces, but is
enabled globally for all interfaces at the router.
If you do not want IKE to be used in your IPSec implementation, you can disable IKE at all your
IPSec peers. If you disable IKE at one peer, you must disable it at all your IPSec peers.
If you disable IKE, you will have to make the following concessions at the peers:
You must manually specify all the IPSec SAs in the crypto maps at the peers.
The IPSec SAs of the peers never time out for a given IPSec session.
During IPSec sessions between the peers, the encryption keys never change.
Anti-replay services are not available between the peers.
Certification Authority (CA) support cannot be used.
IKE negotiations must be protected, so each IKE negotiation begins by agreement of both peers
on a common (shared) IKE policy. This policy states which security parameters will be used to
protect subsequent IKE negotiations and mandates how the peers are authenticated.
After the two peers agree upon a policy, the security parameters of the policy are identified by an
SA established at each peer, and these SAs apply to all subsequent IKE traffic during the
negotiation.
You can create multiple, prioritized policies at each peer to ensure that at least one policy will
match the policy of a remote peer.

7-48

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the crypto isakmp command is as follows:

crypto isakmp enable

This command has no keywords or arguments.

The syntax for the crypto isakmp policy command is as follows:
crypto isakmp policy priority
priority

Copyright

2003, Cisco Systems, Inc.

Uniquely identifies the IKE policy and assigns a priority to the

policy. Use an integer from 1 to 10,000, with 1 being the highest
priority and 10,000 the lowest.

Remote User Network Implementation

7-49

Terminate IPSecISAKMP Policy

Configuration
Router (config-isakmp) #

- -
- -
-- - -

- While in the ISAKMP policy configuration command mode, the
following commands are available to specify the parameters in
the policy. If you do not specify one of these commands for a
policy, the default value will be used for that parameter.

- - - -
- -
-
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-45

If you are interoperating with a device that supports only one of the values for a parameter, your
choice is limited to the value supported by the other device. Aside from this, there is often a
trade-off between security and performance, and many of these parameter values represent such
a trade-off. You should evaluate the level of security risks for your network and your tolerance
for these risks. After doing that, the following tips might help you select which value to specify
for each parameter:
The encryption algorithm has two options: 56-bit Data Encryption Standard-cipher block
chaining (DES-CBC), and 168-bit DES.
The hash algorithm has two options: Secure Hash Algorithm-1 (SHA-1), and Message
Digest 5 (MD5). MD5 has a smaller digest and is considered to be slightly faster than SHA1. There has been a demonstrated successful (but extremely difficult) attack against MD5;
however, the hashed message authentication code (HMAC) variant used by IKE prevents
this attack.
The authentication method has three options: Rivet, Shamir, and Adelman (RSA) signatures,
RSA encrypted nonces, and pre-shared keys.

7-50

RSA signatures provide nonrepudiation for the IKE negotiation (you can prove to a third
party after the fact that you did indeed have an IKE negotiation with the remote peer).
RSA signatures allow the use of a CA. Using a CA can dramatically improve the
manageability and scalability of your IPSec network. Additionally, RSA signature-based
authentication uses only two public key operations, whereas RAS encryption uses four
public key operations, making it costlier in terms of overall performance.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

RSA encrypted nonces provide repudiation for the IKE negotiation (you cannot prove to
a third party that you had an IKE negotiation with the remote peer). RSA encrypted
nonces require that peers possess each others public keys but do not use a CA. Instead,
there are two ways for peers to get each others public keys:
Pre-shared keys are clumsy to use if your secured network is large, and they do not scale
well with a growing network. However, they do not require use of a CA, as do RSA
signatures, and might be easier to set up in a small network with fewer than ten nodes.
RSA signatures also can be considered more secure when compared with pre-shared key
authentication.

The Diffie-Hellman (DH) group identifier has two options: 768-bit and 1024-bit DH. The
1024-bit DH option is harder to crack, but requires more CPU time to execute.
The lifetime of the SA can be set to any value. As a general rule, the shorter the lifetime (up
to a point), the more secure your IKE negotiations will be. However, with longer lifetimes,
future IPSec SAs can be set up more quickly.
The syntax for the encryption command is as follows:
encryption {des | 3des}
des

Specifies 56-bit DES-CBC as the encryption algorithm.

3des

Specifies 168-bit DES (3DES) as the encryption algorithm.

The syntax for the hash command is as follows:

hash {sha | md5}
sha

Specifies SHA-1 (HMAC variant) as the hash algorithm.

md5

Specifies MD5 (HMAC variant) as the hash algorithm.

The syntax for the authentication command is as follows:

authentication {rsa-sig | rsa-encr | pre-share}
rsa-sig

Specifies RSA signatures as the authentication method.

rsa-encr

Specifies RSA encrypted nonces as the authentication method.

pre-share

Specifies pre-shared keys as the authentication method.

The syntax for the group command is as follows:

group {1 | 2}

Copyright

Specifies the 768-bit DH group.

Specifies the 1024-bit DH group.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-51

The syntax for the lifetime command is as follows:

lifetime seconds
seconds

7-52

Cisco SAFE Implementation 1.1

Number of seconds that each SA should exist before expiring.

Use an integer from 60 to 86,400 seconds.

Copyright

2003, Cisco Systems, Inc.

Terminate IPSecConfigure an Authentication

Key and Define a Transform Set
Router (config) #

- - -- - Configures a pre-shared authentication key.

- -
--
Router (config) #

- -- --
- - -
Defines a transform set. Also invokes the crypto transform
configuration mode.

- -- -
--
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-46

Complete the following steps at each peer that uses pre-shared keys in an IKE policy to
configure pre-shared keys:
Set the ISAKMP identity of each peer. Each peers identity should be set to either its
hostname or by its IP address. By default, a peers identity is set to its IP address.
Specify the shared keys at each peer. Note that a given pre-shared key is shared between two
peers. At a given peer you could specify the same key to share with multiple remote peers;
however, a more secure approach is to specify different keys to share between different pairs
of peers.
A transform set is an acceptable combination of security protocols, algorithms, and other settings
to apply to IPSec-protected traffic. During the IPSec SA negotiation, the peers agree to use a
particular transform set when protecting a particular data flow.
You can configure multiple transform sets, and then specify one or more of these transform sets
in a crypto map entry. The transform set defined in the crypto map entry is used in the IPSec SA
negotiation to protect the data flows specified by that crypto map entrys ACL. During the
negotiation, the peers search for a transform set that is the same at both peers. When such a
transform set is found, it is selected and will be applied to the protected traffic as part of both
peers IPSec SAs.
To define a transform set, you specify one to three transformseach transform represents an
IPSec security protocol (ESP or AH) plus the algorithm you want to use. When the particular
transform set is used during negotiations for IPSec SAs, the entire transform set (the
combination of protocols, algorithms, and other settings) must match a transform set at the
remote peer.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-53

The syntax for the crypto isakmp key command is as follows:

crypto isakmp key keystring address peer-address [mask]
keystring

Specifies the pre-shared key. Use any combination of

alphanumeric characters up to 128 bytes. This pre-shared key
must be identical at both peers.

address

Use this keyword if the remote peer ISAKMP identity was set with
its IP address.

peer-address

Specifies the IP address of the remote peer.

mask

(Optional.) Specifies the subnet address of the remote peer. (The

argument can be used only if the remote peer ISAKMP identity
was set with its IP address.)

The syntax for the crypto ipsec transform-set command is as follows:

crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

7-54

transform-set-name

Specifies the name of the transform set to create (or modify).

transform1
transform2
transform3

Specifies up to three "transforms." These transforms define the

IPSec security protocols and algorithms.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSecSpecify the Mode

and Create a Crypto Map
Router (cfg-crypto-trans) #

-
Specifies the mode for a transform set

-
Router (config) #

- --
-
Creates or modifies a crypto map entry and enters the
crypto map configuration mode

--

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-47

After you define a transform set, you are put into the crypto transform configuration mode.
While in this mode you can change the mode to either tunnel or transport. This change applies
only to the transform set just defined.
If the traffic to be protected has the same IP address as the IPSec peers and transport mode is
specified, during negotiation the router requests transport mode but accepts either transport or
tunnel mode. If tunnel mode is specified, the router requests tunnel mode and accepts only tunnel
mode.
If you do not change the mode when you first define the transform set, but later decide you want
to change the mode for the transform set, you must re-enter the transform set (specifying the
transform name and all its transforms) and then change the mode.
If you use this command to change the mode, the change only affects the negotiation of
subsequent IPSec SAs via crypto map entries, which specify this transform set. (If you want the
new settings to take effect sooner, you can clear all or part of the SA database.)
Crypto map entries created for IPSec pull together the various parts used to set up IPSec SAs
including the following:
Which traffic should be protected by IPSec (per a crypto ACL)
The granularity of the flow to be protected by a set of SAs
Where IPSec-protected traffic should be sent (who the remote IPSec peer is)
The local address to be used for the IPSec traffic

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-55

What IPSec security should be applied to this traffic (selecting from a list of one or more
transform sets)
Whether SAs are manually established or are established via IKE
Other parameters that might be necessary to define an IPSec SA
The syntax for the mode command is as follows:
mode [tunnel | transport]
tunnel | transport

(Optional.) Specifies the mode for a transform set: either tunnel or

transport mode. If neither tunnel nor transport is specified, the
default (tunnel mode) is assigned.

The syntax for the crypto map command is as follows:

crypto map map-name seq-num ipsec-isakmp [dynamic dynamic-map-name] [discover]

7-56

map-name

The name that identifies the crypto map set. This is the name
assigned when the crypto map was created.

seq-num

The number you assign to the crypto map entry.

ipsec-isakmp

Indicates that IKE will be used to establish the IPSec SAs for
protecting the traffic specified by this crypto map entry.

dynamic

(Optional.) Specifies that this crypto map entry is to reference a

preexisting dynamic crypto map. Dynamic crypto maps are policy
templates used in processing negotiation requests from a peer
IPSec device. If you use this keyword, none of the crypto map
configuration commands will be available.

dynamic-map-name

(Optional.) Specifies the name of the dynamic crypto map set that
should be used as the policy template.

discover

(Optional.) Enables peer discovery. By default, peer discovery is

not enabled.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSecIdentify an ACL

and Specify Transform Sets
Router (config-crypto-map) #

-- ---
Identifies the extended ACL

--
Router (config-crypto-map) #

- -- --
----
Specifies which transform sets can be used with the
crypto map entry

- --
-
2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-48

The match address command is required for all static crypto map entries. If you are defining a
dynamic crypto map entry (with the crypto dynamic-map command), this command is not
required but is strongly recommended.
Use this command to assign an extended ACL to a crypto map entry. You also need to define
this ACL using the access-list or ip access-list extended commands.
The extended ACL specified with this command is used by IPSec to determine which traffic
should be protected by crypto and which traffic does not need crypto protection. (Traffic that is
permitted by the ACL is protected. Traffic that is denied by the ACL is not be protected in the
context of the corresponding crypto map entry.)
Note

The crypto ACL is not used to determine whether to permit or deny traffic through the
interface. An ACL applied directly to the interface makes that determination.

The crypto ACL specified by the match address command is used when evaluating both
inbound and outbound traffic. Outbound traffic is evaluated against the crypto ACLs specified
by the interfaces crypto map entries to determine if it should be protected by crypto and if so (if
traffic matches a permit entry), which crypto policy applies. (If necessary, in the case of static
IPSec crypto maps, new SAs are established using the data flow identity as specified in the
permit entry; in the case of dynamic crypto map entries, if no SA exists, the packet is dropped.)
After passing the regular ACLs at the interface, inbound traffic is evaluated against the crypto
ACLs specified by the entries of the interfaces crypto map set to determine if it should be
protected by crypto and, if so, which crypto policy applies. (In the case of IPSec, unprotected
traffic is discarded because it should have been protected by IPSec.)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-57

In the case of IPSec, the ACL is also used to identify the flow for which the IPSec SAs are
established. In the outbound case, the permit entry is used as the data flow identity (in general),
while in the inbound case the data flow identity specified by the peer must be permitted by the
crypto ACL.
The set transform-set command is required for all static and dynamic crypto map entries.
Use this command to specify which transform sets to include in a crypto map entry.
For an ipsec-isakmp crypto map entry, you can list multiple transform sets with the set
transform-set command. List the higher priority transform sets first.
If the local router initiates the negotiation, the transform sets are presented to the peer in the
order specified in the crypto map entry. If the peer initiates the negotiation, the local router
accepts the first transform set that matches one of the transform sets specified in the crypto map
entry.
The first matching transform set that is found at both peers is used for the SA. If no match is
found, IPSec does not establish an SA. The traffic is dropped because there is no SA to protect
the traffic.
For an ipsec-manual crypto map entry, you can specify only one transform set. If the transform
set does not match the transform set at the remote peers crypto map, the two peers will fail to
correctly communicate because the peers are using different rules to process the traffic.
If you want to change the list of transform sets, re-specify the new list of transform sets to
replace the old list. This change is only applied to crypto map entries that reference this
transform set. The change will not be applied to existing SAs, but will be used in subsequent
negotiations to establish new SAs. If you want the new settings to take effect sooner, you can
clear all or part of the SA database by using the clear crypto sa command.
The syntax for the match address command is as follows:
match address [access-list-id | name]
access-list-id

(Optional.) Identifies the extended ACL by its name or number.

This value should match the access-list-number or name
argument of the extended ACL being matched.

name

(Optional.) Identifies the named encryption ACL. This name

should match the name argument of the named encryption ACL
being matched.

The syntax for the set transform-set command is as follows:

set transform-set transform-set-name [transform-set-name2...transform-set-name6]

7-58

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

transform-set-name

Name of the transform set.

For an ipsec-manual crypto map entry, you can specify only one
transform set.
For an ipsec-isakmp or dynamic crypto map entry, you can
specify up to 6 transform sets.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-59

Terminate IPSecSpecify an IPSec Peer

and Apply a Crypto Map to the Interface
Router (config-crypto-map) #

- - Specifies the IPSec peer

Router (config-if) #

Applies a previously defined crypto map set
to an interface

2003, Cisco Systems, Inc. All rights reserved.

CSI 1.17-49

Use the set peer command to specify an IPSec peer for a crypto map.
This command is required for all static crypto maps. If you are defining a dynamic crypto map
(with the crypto dynamic-map command), this command is not required, and in most cases is
not used (because, in general, the peer is unknown).
For ipsec-isakmp crypto map entries, you can specify multiple peers by repeating this command.
The peer that packets are actually sent to is determined by the last peer that the router heard from
(received either traffic or a negotiation request from) for a given data flow. If the attempt fails
with the first peer, IKE tries the next peer on the crypto map list.
For ipsec-manual crypto entries, you can specify only one IPSec peer per crypto map. If you
want to change the peer, you must first delete the old peer and then specify the new peer.
You can specify the remote IPSec peer by its hostname only if the hostname is mapped to the
peers IP address in a Domain Name Server or if you manually map the hostname to the IP
address with the ip host command.
Use the crypto map command to assign a crypto map set to an interface. You must assign a
crypto map set to an interface before that interface can provide IPSec services. Only one crypto
map set can be assigned to an interface. If multiple crypto map entries have the same map-name
but a different seq-num, they are considered to be part of the same set and are all applied to the
interface. The crypto map entry with the lowest seq-num is considered the highest priority and is
evaluated first. A single crypto map set can contain a combination of cisco, ipsec-isakmp, and
ipsec-manual crypto map entries.

7-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the set peer command is as follows:

set peer {hostname | ip-address}
hostname

Specifies the IPSec peer by its hostname. This is the peer's

hostname concatenated with its domain name (for example,
myhost.example.com).

ip-address

Specifies the IPSec peer by its IP address.

The syntax for the crypto map command is as follows:

crypto map map-name
map-name

Name that identifies the crypto map set. This is the name
assigned when the crypto map was created.
When the no form of the command is used, this argument is
optional. Any value supplied for the argument is ignored.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-61

Summary
This section summarized the information you learned in this chapter.

Summary
The following are the key devices in a remote user
network:
Broadband access devices
Firewalls with VPN support
Layer 2 hubs
Personal firewall software
Routers with firewall and VPN support
VPN Software Clients
VPN Hardware Clients

2003, Cisco Systems, Inc. All rights reserved.

7-62

Cisco SAFE Implementation 1.1

CSI 1.17-51

Copyright

2003, Cisco Systems, Inc.

Summary (cont.)
The following threats can be expected:
Unauthorized access
Network reconnaissance
Virus and Trojan horse attacks
IP spoofing
Man-in-the-middle attacks
Four basic options are available to mitigate threats: one
software-based and three hardware-based options.

2003, Cisco Systems, Inc. All rights reserved.

Copyright

2003, Cisco Systems, Inc.

CSI 1.17-52

Remote User Network Implementation

7-63

Lab ExerciseRemote User Network Design

Implementation
Complete the following lab exercise to practice what you learned in this chapter.
The lab exercise has the following sub-sections:
Section 1Site-to-site VPN configuration
Section 2Client-to-LAN VPN configuration
Section 3Perimeter router configuration
Section 4Network device management (Optional.)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-1

Visual Objectives
The following figure displays the configuration you will complete in this lab exercise.
Error! Not a valid link.

Section 1Site-to-Site VPN Configuration

Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives
In this lab exercise you will configure a site-to-site VPN by completing the following tasks:
Prepare for configuring IPSec pre-shared keys on the PIX Firewall.
Configure IKE parameters on the PIX Firewall.
Configure IPSec parameters on the PIX Firewall.
Configure routing and IKE parameters on the branch office router.
Configure IPSec parameters on the branch office router.
Configure no NAT in the VPN tunnel.
Verify the IPSec configuration.

Network Security Policy

XYZ Company wants to use the branch office Cisco IOS Router and the corporate Cisco PIX
Firewall to create a virtual private network (VPN) over the Internet between the branch office
site, and the internal corporate and Demilitarized Zone DMZ networks. The following are the
objectives to be completed in this section:
IPSec will be configured between the branch office router and the local PIX Firewall to use
pre-shared keys.
Branch office users will have access to the internal corporate and the DMZ network through
the VPN tunnel.
Corporate users will have access to the branch office network through the VPN tunnel.
There will be no Network Address Translation (NAT) used in the VPN tunnel.
Lab 7-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Setup
Before starting this lab exercise, set up your equipment as follows:
Ensure that your PIX Firewall is turned on.
Access the PIX Firewalls console port.
Save your PIX Firewalls configuration from the previous lab exercise to a text file.
Ensure that your branch office router is turned on.
Access the branch office routers console port.

Task 1Prepare for Configuring IPSec Pre-Shared Keys on the PIX

Firewall
Complete the following lab exercise steps to prepare for the IPSec configuration:
Step 1

Determine the Internet Key Exchange (IKE) and IPSec policy.

The IKE policy is to use pre-shared keys and Secure Hash Algorithm (SHA) for
authentication.
The IPSec policy is to use Encapsulating Security Payload (ESP) mode with Triple-Data
Encryption Standard (3DES) encryption.
The IPSec policy is to encrypt IP traffic between internal NT servers in each pod.

Step 2

Enable the PIX Firewall to implicitly permit any packet that came from an IPSec tunnel and
bypass the checking with an associated conduit or access-group command for IPSec
connections:
-- -

(where P = pod number)

Task 2Configure IKE Parameters on the PIX Firewall

Complete the following steps to configure IKE to use pre-shared keys on your PIX Firewall:
Step 1

Ensure that IKE is enabled on the outside interface:

- -

Step 2

(where P = pod number)

Configure the Internet Security Association Key Management Protocol (ISAKMP) pre-shared
key to point to the outside IP address of the branch office router. Use the default ISAKMP
identity mode of address:
- - -- -

(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-3

Step 3

Create an IKE policy by completing the following sub-steps. Use the following parameter values:
Policy priority number10
Encryption algorithm3des
Hash algorithmsha
Authentication methodpre-share
Diffie-Hellman group identifier1
SA lifetime86400
1. Specify the encryption algorithm:
- -

(where P = pod number)

2. Specify the hash algorithm:
- - -

(where P = pod number)

3. Specify the authentication method:
- -

(where P = pod number)

4. Specify the Diffie-Hellman (DH) group identifier:
-

(where P = pod number)

5. Specify the Security Associations (SAs) lifetime:
-

Step 4

(where P = pod number)

View all existing IKE policies:
- -

(where P = pod number)

Task 3Configure IPSec Parameters on the PIX Firewall

Complete the following steps to configure IPSec (IKE Phase 2) parameters:
Step 1

Create an access control list (ACL) to select traffic to protect. The ACL should protect IP traffic
between the internal networks, using the following parameters, and allow branch office users
access to the untranslated public services segment and internal corporate server networks:
Traffic encryptedTraffic between corporate internal networks and branch office networks

Lab 7-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Peer network addressIP address of branch office network

Access list nameNONAT_INSIDE
Access list nameNONAT_PSS
ProtocolAny Internet protocol
---

---

Step 2

(where P = pod number)

Configure NAT so that the addresses in the VPN tunnel are not translated for the internal
corporate network:
- ---

Step 3

(where P = pod number)

Configure NAT so that the addresses in the VPN tunnel are not translated for the public services
segment server:
---

Step 4

(where P = pod number)

Configure an IPSec transform set (IKE phase two parameters). Use the following parameter
values:
Transform namemyset
ESP protocols3des
Modetunnel
- -- - --

Step 5

(where P = pod number)

Create a crypto map by completing the following sub-steps. Use the following parameter values:
Crypto map namebranch
Map number10
Key exchange typeisakmp
Peer172.26.26.10P
(where P = pod number)
Transform setmyset
Match addressNONAT_INSIDE

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-5

Map number20
Match addressNONAT_PSS
1. Create a crypto map entry:
--

(where P = pod number)

2. Assign the ACL to the crypto map:
--

(where P = pod number)

3. Define the peer. The peer IP address should be set to the peers outside interface IP address:
-

(where P = pod number)

4. Specify the transform set used to reach the peer. Use the transform set name you configured
in Step 3.
- -- -

(where P = pod number)

5. Assign the ACL to the crypto map:
--

(where P = pod number)

6. Define the peer. The peer IP address should be set to the peers outside interface IP address.
-

(where P = pod number)

7. Specify the transform set used to reach the peer. Use the transform set name you configured.
- -- -

Step 6

(where P = pod number)

Apply the crypto map set to the outside interface:
-

Step 7

(where P = pod number)

Verify your crypto map configuration:
-

Step 8

(where P = pod number)

Save your configuration:

Step 9

(where P = pod number)

Verify your PIX Firewall configuration is similar to the following configuration for pix1:

Lab 7-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

-
- -
- -
-
-
-
-
--
--
-




-
-
-
-
-
-
-
-


---
--- -
---
---
---
--- -
--- -
--- -
---
---
---
---

-


- -

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-7




-
-
-
-
-
-




-- -
-- -
--
--
--
--
- -
-





-- -
-- -
--
--
--
--
-

- -
- -
- ---
-
---
- - -
- - -
- -- -
-- -
-- -
Lab 7-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

--
-

-
-
-
-
- -
- -
--
--
--
--
-- -
--
- -- - - --
--
-
- -- -
--
--
-
- -- -
-
- -
- -- -
- -
- - - -
-
-

-- -
--

-

Task 4Configure Routing and IKE Parameters on the Branch Office

Router
Complete the following steps to configure IKE on the branch office router:
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-9

Step 1

Add a static route to the corporate internal networks:

Step 2

(where P = pod number)

Add ACL entries to permit traffic between the internal corporate networks and the branch office
network.
Note

The order of the existing ACL must be modified to permit the following entries.

---
--- -

---

Step 3

(where P = pod number)

Enable IKE and ISAKMP on the router:
-

Step 4

(where P = pod number)

Configure the ISAKMP pre-shared key to point to the outside IP address of the PIX Firewall:
- - --

Step 5

(where P = pod number)

Create an IKE policy by completing the following sub-steps. Use the following parameter values:
Policy priority number110
Encryption algorithm3des
Hash algorithmsha
Authentication methodpre-share
Diffie-Hellman group identifier1
SA lifetime86400
1. Set the policy priority and enter config-isakmp mode:
-

(where P = pod number)

2. Set IKE encryption:
- -

(where P = pod number)

3. Set the hash algorithm:

Lab 7-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

- - -

(where P = pod number)

4. Set authentication to use pre-shared keys:
- -

(where P = pod number)

5. Set the DH group:
-

(where P = pod number)

6. Set the IKE SA lifetime:
-

(where P = pod number)

7. Exit the config-isakmp mode:
-

(where P = pod number)

8. Examine the crypto policy suite:
- -

(where P = pod number)

Task 5Configure IPSec Parameters on the Branch Office Router

Complete the steps in the following sections to configure IPSec on your Cisco router:

Configure Transform Sets and SA Parameters

Complete the following steps to configure transform sets and SA parameters:
Step 1

Ensure that you are in configuration mode:

Step 2

(where P = pod number)

Define a transform set. Use the following parameters:
Transform namemyset
ESP protocols3des
Modetunnel
- -- - --
-

Step 3
Copyright

(where P = pod number)

Save your configuration:
2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-11

Step 4

(where P = pod number)

Verify your configuration:
- - -- -

(where P = pod number)

Configure Crypto ACLs

Complete the following steps to configure the crypto ACLs. Create an ACL to select traffic to
protect. The ACL should encrypt traffic between the VPN devices. Use the following
parameters:
Traffic permittedall
Peer addressThe PIX Firewalls outside interface
ACL number103
ProtocolAny Internet protocol
Step 5

Ensure that you are in configuration mode:

Step 6

(where P = pod number)

Create the crypto ACL:
---

---

(where P = pod number)

Configure Crypto Maps

Complete the following steps to configure a crypto map. Use the following parameters:
Crypto map namemymap
Map number10
Key exchange typeisakmp
Peer192.168.P.2
(where P = pod number)
transform setmyself
match address103
Lab 7-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Set the name of the map, the map number, and the type of key exchange to be used:

Step 7

--

(where P = pod number)

Specify the extended ACL to use with this map:

Step 8

--

(where P = pod number)

Specify the transform set you defined earlier:

Step 9

- -- -

Step 10

(where P = pod number)

Assign the VPN peer using the hostname or IP address of the peer:
-

Step 11

(where P = pod number)

Exit the crypto map configuration mode:

(where P = pod number)

Step 12 Check your configuration:
-

(where P = pod number)

Apply the Crypto Map to an Interface

Complete the following steps to assign the crypto map to the appropriate router interface. Use
the following parameters:
Interface to configureethernet 0/1
Crypto map to usemymap
Step 13

Access the interface configuration mode:

(where P = pod number)

Step 14 Assign the crypto map to the interface:

Step 15

(where P = pod number)

Exit interface configuration mode:

(where P = pod number)

Step 16 Save the configuration:

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-13

Task 6Configure No NAT in the VPN Tunnel

This task is not necessary in a remote lab environment as the ranch office router is not
performing NAT. Complete the following steps to configure no NAT in the VPN tunnel:
Step 1

Clear the IP translation table prior to removing NAT configuration statements:

-

Step 2

(where P = pod number)

Remove the previously configured NAT statement:
- - -

Step 3

(where P = pod number)

Create an ACL that defines traffic destined to the corporate network is not translated (no-NAT)
and all other traffic is translated (NAT):
---
---

Step 4

(where P = pod number)

Continue creating an ACL that defines traffic destined to the corporate network is not translated
(no-NAT) and all other traffic is translated (NAT):
---

Step 5

(where P = pod number)

Configure the following route map to set up no NAT in the VPN tunnel:

--
- -

Step 6

(where P = pod number)

Save the configuration to memory:

Step 7

(where P = pod number)

Check your configuration against the following example configuration for branch office router 1:

-
- --
- --
- --

Lab 7-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
- -
--

- - --

-
-
-

-
-
-
-
-
-


-
-

-
-
- - --

- -- - -
--
-
- -- -
--

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-15

--
--

-
-

--

--
--

-

- -
---

-

---
--- - -
--- - -
Lab 7-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

--- -
---
---
--- -
---
---

---

---

---

---

---

---
---

---
---
---

---

---


--

-
-

--

-
-


----

--

-
-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-17

(where P = pod number)

Task 7Verify the IPSec Configuration

Complete the following steps to verify your IPSec configuration:
Step 1

Initiate a web session from your student PC to the branch office PC.

Step 2

Ensure that traffic between peers is being encrypted by completing the following sub-steps on
your PIX Firewall:
1. Examine the IPSec SAs. Note the number of packets encrypted and decrypted.
- - -

(where P = pod number)

2. Generate additional traffic by clicking the Reload button of your web browser.
3. Examine the IPSec SAs again. Note that the packet counters have incremented.
- - -

Step 3

(where P = pod number)

Clear the crypto SAs and complete Steps 1 and 2 on the branch office PC to verify connectivity
from the branch office PC to the student PC, and to the public services segment servers private
address.

Step 4

Confirm your configuration on the branch office router:

- - -

Step 5

(where P = pod number)

Confirm that the branch office network addresses have not been translated:
- -

Step 6

(where P = pod number)

Confirm that the appropriate ACL hit-counters are being incremented:
- ----

(where P = pod number)

Lab 7-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Section 2Client-to-LAN VPN Configuration

Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives
In this lab exercise, complete the following tasks to enable remote access via VPN:
Configure the Cisco VPN Client.
Reset the Concentrator via CLI.
Configure the Concentrator via CLI.
Configure the PIX Firewall.
Configure the VPN Concentrator using Quick Configuration via the web interface.
Configure the VPN Concentrator via the web interface.
Configure the branch office router.
Test and verify the IPSec configuration.

Network Security Policy

In this lab exercise, you will configure the perimeter router, the Cisco VPN Concentrator, and
other managed devices according to the following VPN security policy:
A VPN tunnel will secure communication between the Cisco VPN Client PC and the
Concentrator.
The private interface of the Concentrator is connected to an interface of the PIX Firewall.
Traffic is inspected by the PIX Firewall on the network attached to the Concentrator.
The VPN Client PC must be able to access the corporate internal network.
The VPN Client PC must be able to access the branch office network through the VPN
tunnel between the corporate and branch office networks.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-19

Setup
Before starting this lab exercise, set up your equipment as follows:
Ensure that your Concentrator is turned on.
Access the perimeter routers console port.

Task 1Configure the Cisco VPN Client

Complete the following steps to configure the VPN Client on the VPN Client PC:
Step 1

Choose Start>Programs>Cisco Systems VPN Client>VPN Dialer from the Programs menu.
The VPN Client window opens.

Step 2

Click New. The New Connection Entry Wizard opens.

Step 3

Enter the name studentP for the new connection entry.

(where P = pod number)

Step 4

Click Next.

Step 5

Enter the IP address of the Concentrators Public IP interface: 192.168.P.5.

(where P = pod number)

Step 6

Click Next.

Step 7

Enter the following Group Access Information:

Note

The group name and password information assigned is case-sensitive.

Group NamepodP_group
(where P = pod number)
Group PasswordpodP_group
(where P = pod number)
Confirm PasswordpodP_group
(where P = pod number)
Step 8

Click Next. You have created a new VPN network connection named studentP.
(where P = pod number)

Step 9

Click Finish.

Step 10

In the Cisco VPN Client window, complete the following sub-steps:

1. Choose studentP from the Connection Entry drop-down menu.
(where P = pod number)
2. Verify that the IP address of the remote server Public Interface is correct.

Step 11

Choose Options>Properties.

Lab 7-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 12

Select Properties.

Step 13

Select the General tab, in the Properties window. The properties for studentP window opens.
The following items should be checked on a Windows system:
IPSec through NAT mode should be allowed.
The Peer Response Timeout should be 90.
Allow local LAN access to be checked.
Note

Step 14

Split Tunneling should not be allowed in a production environment.

Select the Authentication tab and verify that the group name spelling is correct. (It is case
sensitive.)
Note

If needed, you can edit the Group Password here in the Authentication tab.

Step 15

Select the Connections tab. Leave the fields blank.

Step 16

Click OK.

Step 17

Close the VPN Client window by clicking the Close button.

Task 2Reset the Concentrator Via CLI

Complete the following steps via the console to set the Concentrator to the factory default using
the CLI in preparation for the next sections.
Note
Step 1

Check with your instructor to see if this needs to be done.

You are prompted for a login. You may have to press Enter to get a login prompt. Enter the
login name and password as follows:
Loginadmin
Passwordadmin
Note

If you are presented with the Quick> prompt, skip to Task 3. The Concentrator is already in
the default factory state.

The following main menu is displayed:

-

-
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-21




Step 2

Reboot the system by entering the following commands:

-
-

The system reboots at this point. Reboot takes several minutes.

Step 3

Proceed to Task 3 when the reboot is complete and you get a login prompt.
Note

Do not close the console window. The reboot will take several minutes to reload the default
configuration to online memory.

Task 3Configure the Concentrator Via CLI

Complete the following steps using the Concentrator CLI to configure the Concentrators private
and public interfaces:

Configure the Private LAN Interface Via CLI Quick Configuration

Complete the following steps to configure the Concentrators private Ethernet interface using the
CLI:
Note
Step 1

You may have to press Enter several times to get a login prompt.

Log into the console by entering the login name and password as follows:
Loginadmin
Passwordadmin

Step 2

If you get the Quick prompt for the system parameters, press Enter to accept the time, date, time
zone, and DST parameters. When finished, proceed with configuring the private interface.
Note

Step 3

A Concentrator received from the factory presents a slightly different order of prompts than
one that was rebooted to factory defaults.

Enter the IP address for Ethernet 1 (Private):

Step 4

(where P = pod number)

Enter the subnet mask for Ethernet 1:

Lab 7-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.


-

Step 5

Complete the rest of the prompts:

- -
-

Warning

Step 6

If you do not exit, the CLI will take you through the Quick Configuration via the GUI instead.

Do not close the console window. Proceed to the next section.

Configure the Public LAN Interface Via CLI

Complete the following steps via the console to configure the public Ethernet interface via the
CLI:
Step 7

Log in if you are not already logged in, by entering the login name and password as follows:
Loginadmin
Passwordadmin

Step 8

Complete the following actions to configure the public interface:

-
-

-- -

(where P = pod number)

- -

Configure the Default Gateway

Complete the following steps via the console to configure the default gateway using the CLI as
the Ethernet interface of the perimeter router:
Step 9

Complete the following actions from the main menu to configure the default gateway:

-
-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-23

(where P = pod number)

-

Configure a Static Route to the Internal Network

Complete the following steps via the CLI to configure a static route to the internal network:
Step 10

Complete the following actions from the main menu to configure a static route:

-
-
-

--
-
- -
--

(where P = pod number)

-

Step 11

Exit the console access and proceed to the next lab steps.

Task 4Configure the PIX Firewall

Complete the following steps to allow Hypertext Transfer Protocol Over Secure Socket Layer
(HTTPS) access to the public interface of the Concentrator:
Step 1

Access the PIX Firewalls console as directed by the instructor.

Step 2

Assign a name and security level to Ethernet interface 4:

-

Step 3

(where P = pod number)

Enable the Ethernet 4 interface for 100 Mbps Ethernet full duplex communication:

Step 4

(where P = pod number)

Assign an IP address to the remote access VPN network interface:
--

Lab 7-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 5

(where P = pod number)

Configure a static translation on the PIX Firewall between the internal network and the remote
access VPN network:
- - -

Step 6

(where P = pod number)

Configure a static translation on the PIX Firewall between the public services segment network
and the remote access VPN network:
- -- -

Step 7

(where P = pod number)

Add an ACL named RAVPN to the PIX Firewall to allow Concentrator traffic to the internal
network at 10.0.P.0:
---

Step 8

(where P = pod number)

Apply the ACL to the ravpn interface of the PIX Firewall:
--

Step 9

(where P = pod number)

Configure a static route on the PIX Firewall to route outbound traffic to the VPN Client:

(where P = pod number)

Step 10 Configure the PIX Firewall to allow the remote VPN users to access the public services segment,
Internet, and branch office networks:
---

--
-
- -- -
---

(where P = pod number)

Step 11 Save your configuration and compare it to the following sample configuration from pix1:

-
- -
- -
-
-
-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-25

 -
--
--
-




-
-
-
-
-
-
-
-


---
--- -
---
---
---
--- -
--- -
--- -
---
---
---
---

---
---

-


- -



-

-
Lab 7-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
-
-




-- -
-- -
--
--
--
--
- -
-





-- -
-- -
--
--
--
--
-

- -
- -
- ---
-
---
---

- - -
- - -
- -- -
- - -
- -
-- -
-- -
--
--
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-27

 -


-
-
-
-
- -
- -
--
--
--
--
-- -
--
- -- - - --
--
-
- -- -
--
--
-
- -- -
--
--
-
- -- -
-
- -
- -- -
- -
- - - -
-
-

-- -
--

-

Lab 7-28 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

(where P = pod number)

Task 5Configure the VPN Concentrator Using Quick Configuration

Via the Web Interface
Complete the following steps using Quick Configuration in the Concentrator management web
interface to configure more Concentrator parameters:
Step 1

Launch your web browser on the Student PC.

Step 2

Enter the IP address of the Concentrators private interface address in the address field. The VPN
3000 Concentrator Series web interface is displayed in your browser.
-

(where P = pod number)

Click Yes if you are prompted by your browser to accept a certificate.
Step 3

Log into the Concentrator by entering the login name and password as follows:
Loginadmin
Passwordadmin

Step 4

Select click here to start Quick Configuration in the Main window. Quick configuration will
lead you through a series of windows. You will be in the Configuration>Quick>IP Interfaces
window.

Step 5

Check the accuracy of Ethernet 1 and 2 IP addresses and subnet masks, which you configured via
CLI.

Step 6

Click Apply only if you made changes to the interface configuration.

Step 7

Click Continue when you are finished verifying interface configuration.

Configuration>Quick>System Info
Complete the following steps to initially configure the VPN Concentrator:
Step 8

Configure the following System Info parameter values:

System NamestudentP VPN
(where P = pod number)
New TimeVerify the current time and date
DST SupportEnable
DNS Server0.0.0.0 (which is the default)
Domain NamepodP.com
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-29

Default Gateway192.168.P.150
(where P = pod number)
Step 9

Click Continue. The Protocol screen is displayed.

Configuration>Quick>Protocols
Complete the following steps to enable the tunneling protocols for this lab exercise:
Step 10

Configure the following Protocol parameter values:

PPTPDisable
L2TPDisable
IPSecEnable

Step 11

Click Continue. The Address Assignment screen is displayed.

Configuration>Quick>Address Assignment
Complete the following steps to configure the Network Address Translation (NAT) address
range for this lab exercise:
Step 12

Configure the following Address Assignment parameter values:

Configured PoolEnabled (select the check box)
Range Start10.0.(P+20).17
(where P = pod number)
Range End10.0.(P+20).30
(where P = pod number)

Step 13

Click Continue. The Authentication screen is displayed.

Configuration>Quick>Authentication
Complete the following steps to identify what type of authentication server to use for this lab
exercise:
Step 14

Choose Internal Server from the Select Server type drop-down menu.

Step 15

Click Continue. The User Database screen is displayed.

Configuration>Quick>User Database
Complete the following steps to configure the user parameters for this lab exercise:
Step 16

Enter the following User Database parameter values:

UsernamestudentP
(where P = pod number)

Lab 7-30 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PasswordstudentP
(where P = pod number)
Verify passwordstudentP
(where P = pod number)
Step 17

Click Add to add the user to the database. The username should appear in the Current Users
window.

Step 18

Click Continue. The IPSec Group screen is displayed.

Configuration>Quick>IPSec Group
Complete the following steps to configure the IPSec Group parameters for this lab exercise:
Step 19

Enter the following IPSec Group parameter values:

Note

The group name and password information is case-sensitive and must match the IPSec group
created earlier.

Group NamepodP_group
(where P = pod number)
PasswordpodP_group
(where P = pod number)
VerifypodP_group
(where P = pod number)
Step 20

Click Continue. The Admin Password screen is displayed.

Configuration>Quick>Admin Password
You can configure the admin password in the Admin Password window. For lab consistency,
please leave the password at its default value.
Step 21

Click Continue.
Note

In a production environment, you should change the password to a secure password.

Configuration>Quick>Done
You have completed the quick configuration steps. Complete the following steps to save the
quick configuration:
Step 22

Click the Save Needed icon to save your configuration.

Step 23

Click OK in the Save Successful window.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-31

Task 6Configure the VPN Concentrator Via the Web Interface

Complete the following steps using the Concentrator management web interface to configure
Concentrator parameters.

Configuration>System>Tunneling Protocols>IPSec>IKE Proposals

Complete the following steps to set the correct IKE proposal for the VPN Client:
Step 1

In the far-left frame, choose Configuration>System>Tunneling Protocols>IPSec>IKE

Proposals.

Step 2

Verify that CiscoVPNClient-3DES-MD5 is listed under Active Proposals. If it is not there, select
it from the Inactive Proposals list and click Activate.
Note

Step 3

If Cisco VPN Client-3DES-MD5 is not at the top of the Active Proposals list, click the Move Up
button to place it there. If it is already there, proceed on to Step 3.

Click the Save Needed icon to save the configuration if needed.

Configuration>System>IP Routing>Default Gateways

Complete the following steps to define the Concentrators default gateway parameters for IP
routing:
Step 4

Choose Configuration>System>IP Routing>Default Gateways.

Step 5

Enter the following Default Gateway parameter values:

Default Gateway192.168.P.150
(where P = pod number)
Metric1
Tunnel default gateway172.18.P.1
(where P = pod number)
Override Default GatewayEnabled

Step 6

Click Apply.

Step 7

Click the Save Needed icon to save the configuration.

Administration>Access Rights>Access Control List

Create ACLs to grant the networks and user groups that will have management access to the
Concentrator:
Step 8

Choose Administration>Access Rights>Access Control List.

Step 9

Click Add to add the internal corporate network administrators. The Add a manager screen is
displayed.

Lab 7-32 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 10

Enter the following Manager Address parameter values:

IP Address10.0.P.0
(where P = pod number)
IP Mask255.255.255.0
Access GroupGroup 1 (admin)

Step 11

Click Add. The Manager address is displayed in the Manager Workstations list.

Step 12

Click Add to add Administrators accessing the Concentrator from the VPN network. The Add a
manager screen is displayed.

Step 13

Enter the following Manager Address parameter values so only this IP range can access the
Concentrator with admin rights:
IP Address10.0.(P+20).16
(where P = pod number)
IP Mask255.255.255.240
Access GroupGroup 1 (admin)

Step 14

Click Add. The Manager address is displayed in the Manager Workstations list.

Step 15

Click Add to add student users accessing the concentrator from the VPN network. The Add a
manager screen is displayed.

Step 16

Enter the following Manager Address parameter values so only this IP range can access the
Concentrator with User rights:
IP Address10.0.(P+20).0
(where P = pod number)
IP Mask255.255.255.240
Access GroupGroup 5 (User)

Step 17

Click Add. The Manager address is displayed in the Manager Workstations list.

Step 18

Click the Save Needed icon to save the configuration.

Disable Insecure Management Protocols

Complete the following steps to disable insecure management protocols:
Step 19

Choose Configuration>System>Management Protocols. The list of management protocols is

displayed.

Step 20

Select FTP. The Configure the FTP server screen is displayed.

Step 21

Disable FTP and click Apply.

Step 22

Select TFTP. The Configure the TFTP server screen is displayed.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-33

Step 23

Disable TFTP and click Apply.

Step 24

Select Telnet. The Configure the Telnet server screen is displayed.

Step 25

Disable Telnet by selecting the check box next to Telnet.

Step 26

Enable Telnet/SSL by selecting the check box next to Telnet/SSL.

Step 27

Click Apply.

Step 28

Select SNMP. The Configure the SNMP server screen is displayed.

Step 29

Disable SNMP and click Apply.

Step 30

Select HTTP/HTTPS. The Configure the HTTP server screen is displayed.

Step 31

Disable HTTP by selecting the check box next to HTTP.

Step 32

Enable HTTPS by selecting the check box next to HTTPS.

Step 33

Click Apply. The HTTP server is automatically restarted to disable HTTP access.
Note

Your session is terminated and requires you to log in again.

Configure Split Tunneling

This section is only necessary in a remote lab environment. Complete the following steps to
configure split tunneling to allow Netmeeting access to the Cisco VPN Client throughout the
VPN configuration and testing:
Step 34

Choose Configuration>Policy Management>Traffic Management>Network Lists.

Step 35

Click the Add button.

Step 36

Enter Student PC in the List Name field.

Step 37

Enter 192.168.P.10/0.0.0.0 in the Network List field.

(where P = pod number)

Step 38

Click the Add button.

Step 39

Choose Configuration>User Management>Groups.

Step 40

Select podP_group in the Group Name field.

(where P = pod number)

Step 41

Click the Modify Group button.

Step 42

Select the Mode Config tab.

Step 43

Select the Allow the networks in the list to bypass tunnel check box.

Step 44

Click Apply.

Step 45

Choose Student PC from the drop-down menu next to the Split Tunneling Network List
Attribute.

Step 46

Click Apply.

Step 47

Click the Save Needed icon to save the configuration.

Lab 7-34 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 7Configure the Branch Office Router

Complete the following steps to allow connection from the VPN remote access users to the
branch office network:
Step 1

Add an ACL entry to allow incoming traffic from the Concentrator network.
Note

The order of the existing ACLs must be modified.

---

Step 2

(where P = pod number)

Add an ACL entry to define that traffic from the branch office network to the Concentrator
network is encrypted:
---

Step 3

(where P = pod number)

Add an ACL to define that traffic from the branch office network is not translated (no-NAT)
when going to the Concentrator network:
---

Step 4

(where P = pod number)

Add a static route to the VPN Client pool network:

Step 5

(where P = pod number)

Save your configuration and compare your configuration to the following sample configuration
from br1:

-
- --
- --
- --

-
- -
--

- - --

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-35

-
-
-

-
-
-
-
-
-


-
-

-
-
- - --

- -- - -
--
-
- -- -
--

--
--
Lab 7-36 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.


-
-

--

--
--

-

- -
---


-

---
--- - -
--- - -
--- -
---
---
--- -
---
---
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-37

---

---

---

---

---

---

---
---

---
---
---
---

---

---

---


--

-
-

--

-
-


----

--

-
-

(where P = pod number)

Lab 7-38 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 8Test and Verify the IPSec Configuration

Complete the following steps to launch the Cisco VPN Client, establish an IPSec connection to
the Concentrator, verify the connection, and verify Client network settings:

Launch the VPN Client

Complete the following steps to launch the VPN Client:
Step 1

Complete the following sub-steps to launch the VPN Client on your VPN Client PC:
1. Choose Start>Programs>Cisco Systems VPN Client>VPN Dialer from the Program
menu.
2. Verify that Connection Entry studentP is selected.
(where P = pod number)
3. Verify the IP address of the remote server: 192.168.P.5.
(where P = pod number)

Step 2

Click Connect. The Connection History window opens, and several messages flash by quickly:
1. If you are prompted for a username, enter: studentP (This is case-sensitive.)
(where P = pod number)
2. When you are prompted to enter a password, enter: studentP (This is case-sensitive.)
(where P = pod number)

Step 3

Click OK. The following messages flash by

Negotiating security profiles
Your link is now secure
Logging onto the network
The window closes and a VPN icon appears in the system tray. The following message appears:
You have successfully launched the IPSec client. The client disappears from the screen and the
VPN Client icon appears in the system tray.

Verify the Connection to All Networks

Complete the following steps to verify the connection to all networks:
Step 4

Verify that the branch office PC can access the following web servers:
Corporate public services segment server172.16.P.50
(where P = pod number)
VPN client PC10.0.(P+20).17
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-39

Student PC10.0.P.11
(where P = pod number)
Step 5

Verify that the VPN Client system can access the following web servers:
Corporate public services segment server172.16.P.50
(where P = pod number)
Student PC10.0.P.11
(where P = pod number)
Branch office PC10.2.P.11
(where P = pod number)

Step 6

Verify that the student PC can access the following web servers:
Corporate public services segment server172.16.P.50
(where P = pod number)
VPN client PC10.0.(P+20).17
(where P = pod number)
Branch office PC10.2.P.11
(where P = pod number)

Lab 7-40 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Section 3Perimeter Router Configuration

Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives
In this lab exercise you will complete the following tasks:
Secure the perimeter router network services.
Configure the PIX Firewall to allow management services.
Secure management access to the perimeter router.
Configure the perimeter router to only allow IPSec traffic to the PIX Firewall and
Concentrator.
Test and verify the perimeter router configuration.

Network Security Policy

You will implement this network security policy in this lab exercise:
Secure the perimeter router network services:

Create a warning banner that is displayed when an interactive session is established.

Enforce password encryption to protect device passwords.

Disable unnecessary network services.

Log perimeter router events:

Send perimeter router Syslog output to the Student PC.

Log informational events on the perimeter router to the Syslog server.

Set accurate time-stamping for log and debug messages.

Control administrator access to the perimeter router to prevent unauthorized access:

Copyright

Control access into the router from the console, aux ports, and the vty lines.

Allow Telnet to the perimeter router only from the student PC.

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-41

Authenticate Telnet sessions with usernames and passwords entered into the perimeter
routers local security database.
The administrator attempts to log into the Syslog server.

Setup
You should not have to configure any routing or addressing of interfaces on lab equipment in
this lab exercise. Before starting this lab exercise, set up your equipment so that you can do the
following from the Student PC:
Ping the perimeter routers outside interface.
Ping the backbone router in the cloud network.

Task 1Secure the Perimeter Router Network Services

Complete the following steps to secure your perimeter routers network services:
Step 1

Create a warning message that is displayed when a user establishes an interactive session:
- -
- -

Step 2

(where P = pod number)

Enable password encryption and assign a secret enable password to protect the routers
passwords:
- --
- -

Step 3

(where P = pod number)

Disable unnecessary network and router services to limit the exposure to direct attacks against
the router:
-

-
- -- - -- -
-

-

Note

Interface configuration commands must be done on each router interface.

Lab 7-42 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 4

(where P = pod number)

Enable logging to a Syslog server to provide a method to monitor router events including attacks:
- -- -

(where P = pod number)

Task 2Configure the PIX Firewall to Allow Management Services

Complete the following steps to configure the PIX Firewall to allow management services.
Example command entries are included with each step. Substitute network and IP addresses from
your network where given in an example.
Step 1

Allow Syslog messages and TFTP transfers through the PIX Firewall to the Student PC.
Note

The order of the existing INBOUND ACL must be modified to permit the management
services. Be sure to bind the ACL to the outside interface.

--- - -
--
--- - -

-- -

(where P = pod number)

Task 3Secure Management Access to the Perimeter Router

Complete the following steps to secure management access to the perimeter router:
Step 1

Create a standard ACL to permit management access from the Student PC:
---

Step 2

(where P = pod number)

Assign a password to the Virtual Teletype (VTY) lines (04), and allow VTY line access only
from management workstations to the router to prevent access by unauthorized users:

-- -
----

-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-43

Step 3

(where P = pod number)

Assign a password to the console line to prevent access by unauthorized users:

-- -

-
-

Step 4

(where P = pod number)

Create a local user account on the router that is used to log into the router:
- - -- -

Step 5

(where P = pod number)

Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU
time for system processes:
-

(where P = pod number)

Task 4Configure the Perimeter Router to Only Allow IPSec Traffic to

the PIX Firewall and Concentrator
Complete the following steps to configure the perimeter router to only allow IPSec traffic to the
PIX Firewall and Concentrator:
Step 1

Create an ACL entry to only allow IPSec traffic from the branch office router to the PIX
Firewall:
--- - - -
--- - -
-
--- - -

Step 2

(where P = pod number)

Add ACL entries to only allow IPSec traffic from VPN Clients to the Concentrator:
--- - -
--- - -
--- -
---

Step 3

(where P = pod number)

Apply the ACL to the perimeter routers outside interface:

--

Lab 7-44 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

(where P = pod number)

Task 5Test and Verify the Perimeter Router Configuration

Complete the following steps to verify that the perimeter router is configured correctly:
Step 1

Ping the perimeter routers inside interface from the Student PC. This should be successful.

Step 2

Ping the perimeter routers outside interface from the Student PC. This should be successful.

Step 3

Establish a Telnet session to the perimeter router from the Student PC:

(where P = pod number)

Note

If you are unable to telnet to your perimeter router, console into your perimeter router and
check the ACLs applied to your VTY lines and inside interface.

Step 4

Verify that the devices are sending Syslog messages to the student PC Syslog server.

Step 5

Verify that the perimeter router configuration is correct:

-
- --
- -- -
- --

-
-
--

- - --

-
-
-

-

-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-45


--

--

--
--

--- -

---
--- - - -
--- - - -
---

- -

--- - -
--- - -
---

---

- -
- -

--
Lab 7-46 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.


-
-


----

--

-
-

Step 6

(where P = pod number)

Verify that the PIX Firewall configuration is correct:


-
- -
- -
-
-
-
-
--
--
-




-
-
-
-
-
-
-
-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-47

---
--- -
---
---
---
--- -
--- -
--- -
---
--- - - --
--- - -
---
---
---

---
---

-


- -



-

-
-
-
-




-- -
-- -
--
--
--
--
- -
-


Lab 7-48 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.




-- -
-- -
--
--
--
--
-

- -
- -
- ---
-
---
---

- - -
- - -
- -- -
- -
- - -
-- -
-- -
--
--
-


-
-
-
-
- -
- -
--
--
--
--
-- -
--

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-49

 - -- - - --
--
-
- -- -
--
--
-
- -- -
--
--
-
- -- -
-
- -
- -- -
- -
- - - -
-
-

-- -
--

-

Step 7

(where P = pod number)

Verify that the student PC can access the following via the web browser:
Public services segment server172.16.P.50
(where P = pod number)
VPN Client PC10.0.(P+20).17
(where P = pod number)
Branch office PC10.2.P.11
(where P = pod number)

Step 8

Verify that the branch office PC can access the following via the web browser:
Public services segment server172.16.P.50
(where P = pod number)

Lab 7-50 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Client PC10.0.(P+20).17

(where P = pod number)
Student PC10.0.P.11
(where P = pod number)
Step 9

Verify the VPN Client PC can access the following via the web browser:
Public services segment server172.16.P.50
(where P = pod number)
Student PC10.0.P.11
(where P = pod number)
Branch office PC10.2.P.11
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-51

Section 4Network Device Management (Optional.)

Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives
In this lab exercise, you will complete the following tasks:
Configure AAA on the VPN 3000 Concentrator.
Configure Syslog on the VPN 3000 Concentrator.
Configure the PIX Firewall to secure management access via AAA.
Configure the perimeter router to secure management access via AAA.
Configure the branch router to secure management access via AAA and to centralize
logging.
Test centralized management of all network devices.

Network Security Policy

In this lab exercise, you will configure the perimeter router, the Concentrator, and other managed
devices according to the following VPN security policy:
All devices must use Cisco Secure Access Control Server (ACS) for authentication,
authorization, and accounting (AAA).
Management should be performed in-band and securely.

Setup
You should not have to configure any routing or addressing of interfaces on lab equipment in
this lab exercise. Before starting this lab exercise, set up your equipment so that you can do the
following from the Student PC:
Ensure that your VPN Concentrator is turned on.
Access the devices via the console ports (except the Concentrator).

Task 1Configure AAA on the VPN 3000 Concentrator

Complete the following steps to configure AAA on the Concentrator:
Step 1

Launch your web browser and log into the Concentrator as an administrator user.

Lab 7-52 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 2

Choose Administration>Access Rights>AAA Servers>Authentication from the menu.

Step 3

Click Add and enter the following information:

Authentication Server10.0.P.10
(where P = pod number)
Server Secretciscosafe
All other settingaccept the default settings

Step 4

Click Save Needed to save your changes.

Step 5

Choose Administration>Access Rights>Administrators from the menu.

Step 6

Click the Modify button for Group Number 1.

Step 7

Choose 15 from the AAA Access Level drop-down menu.

Step 8

Click Apply.

Step 9

Click the Modify button for Group Number 5.

Step 10

Choose 1 from the AAA Access Level drop-down menu.

Step 11

Click Apply to save your changes.

Step 12

Add the following ACL entry to the PIX Firewall to allow traffic from the Concentrator to the
AAA server:
--- - -
--- - -

(where P = pod number)

Task 2Configure Syslog on the VPN 3000 Concentrator

Complete the following steps to configure Syslog on the VPN 3000 Concentrator:
Step 1

Choose Configuration>System>Events>General from the menu.

Step 2

Choose severity level 15 from the Severity to Syslog drop-down menu to send events to the
Syslog server.

Step 3

Click Apply to accept the changes.

Step 4

Choose Configuration>System>Events>Syslog Servers from the menu.

Step 5

Click Add and enter the following Syslog server parameters:

Syslog Server IP Address10.0.P.11
(where P = pod number)
Port514
FacilityLocal 7

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-53

Step 6

Click Add. The Syslog server is listed in the Syslog Server group.

Step 7

Click the Save Needed icon to save your changes.

Step 8

Add an ACL entry to the PIX Firewall to allow traffic from the Concentrator to the Syslog
server:
--- - -
--

(where P = pod number)

Task 3Configure the PIX Firewall to Secure Management Access via

AAA
Complete the following steps to secure management access to the PIX Firewall via AAA:
Step 1

Allow Telnet access from the student PC to the PIX Firewall:

-

(where P = pod number)

Step 2

Define the AAA server parameters:

- - -
- - - - --

(where P = pod number)

Step 3

Enable AAA authentication for Telnet access to the PIX Firewall:

- -

(where P = pod number)

Task 4Configure the Perimeter Router to Secure Management

Access Via AAA
Complete the following steps to secure management access to the perimeter router via AAA:
Step 1

Create a static mapping on the PIX Firewall for the internal AAA server:
- -- -

(where P = pod number)

Step 2

Add an ACL entry to the PIX Firewall allowing traffic to the internal AAA server form the
perimeter router.
Note

The order of the existing INBOUND ACL must be modified to permit the management
services. Be sure to bind the ACL to the outside interface.

--- - -
-

(where P = pod number)

Lab 7-54 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 3

Create a new AAA model and define the AAA server on the perimeter router:

-- - - --

(where P = pod number)

Step 4

Enable AAA authentication and create the following authentication lists with the specified
methods:
defaultUse the list of all Terminal Access Controller Access Control System Plus
(TACACS+) servers for authentication as the primary method. Use the local username
database for authentication as the secondary method. Use the enable password for
authentication as the last method.
no_tacacsUse the line password for authentication.
-
-

Step 5

(where P = pod number)

Enable AAA authorization for exec sessions that required TACACS+ authentication:
-

Step 6

(where P = pod number)

Enable AAA accounting for exec sessions authenticated via TACACS+:
-- -

Step 7

(where P = pod number)

Enable AAA authentication for VTY sessions using the default authentication list:

Step 8

(where P = pod number)

Enable AAA authentication for console access using the no_tacacs authentication list:

Task 5Configure the Branch Router to Secure Management Access

Via AAA and to Centralize Logging
Complete the following steps to secure management access to the branch office router via AAA
and centralize logging:
Step 1

Add a crypto ACL entry to allow IPSec traffic between the branch office router and the
corporate office internal network.
--- -

(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-55

Step 2

Add an ACL entry that does not perform NAT on the branch office routers IP address if the
router communicates with devices on the corporate office internal network:
--- -

(where P = pod number)

Step 3

Add ACL entries to the PIX Firewall to define IPSec traffic to the branch office router:
--- -

(where P = pod number)

Step 4

Add an ACL entry that allows the corporate office management server and workstation access to
the router on the branch office router:
--- -

(where P = pod number)

Step 5

Create a new AAA model and define the AAA server:

-- - - --

(where P = pod number)

Step 6

Enable AAA authentication and create the following authentication lists with the specified
methods:
defaultUse the list of all TACACS+ servers for authentication as the primary method. Use
the local username database for authentication as the secondary method. Use the enable
password for authentication as the last method.
no_tacacsUse the line password for authentication.
-
-

(where P = pod number)

Step 7

Enable AAA authorization for exec sessions that required TACACS+ authentication:
-

Step 8

Enable AAA accounting for exec sessions authenticated via TACACS+:

-- -

Step 9

Enable AAA authentication for VTY sessions using the default authentication list:

(where P = pod number)

Step 10 Enable AAA authentication for console access using the no_tacacs authentication list:

-

(where P = pod number)

Lab 7-56 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 11

Add the corporate office Syslog server to the list of logging hosts:

(where P = pod number)

Task 6Test Centralized Management of All Network Devices

Complete the following steps to validate that the network devices are authenticating using the
AAA server. The AAA server has the following accounts:
Account

Password

Description

ACSAdmin

admin

Account with privilege level 15

access

ACSstudent

student

Account with privilege level 1

access

Step 1

Log into the Concentrator as the admin account. Confirm that you have access to manage the
device.

Step 2

Log into the Concentrator as the student account. Confirm that you only have view and not
management access.

Step 3

Telnet into the PIX Firewall as the admin account.

Step 4

Telnet into the PIX Firewall as the student account.

Note

PIX Firewall releases prior to 6.2 do support assigning privilege levels.

Step 5

Telnet into the perimeter router as the admin account. Confirm that you are logged into enable
mode.

Step 6

Telnet into the perimeter router as the student account. Confirm that you are logged into user
mode.

Step 7

Telnet into the branch office router as the admin account. Confirm that you are logged into
enable mode.

Step 8

Telnet into the branch office router as the student account. Confirm that you are logged into user
mode.

Step 9

Transfer the configuration files for the following devices to the TFTP server address listed:
Branch office router10.0.P.11
(where P = pod number)
Perimeter router192.168.P.10
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-57

PIX firewall10.0.P.11
(where P = pod number)
Step 10

Verify the configuration files for the following devices:

Perimeter router configuration

-
- --
- -- -
- --

-

-
-
-
-- -
-
--

- - --

-
-
-

-

-

--

--

Lab 7-58 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

--
--

--- -

---
--- - - -
--- - - -
---

- -

--- - -
--- - -
---

---

-- - - --

- -
- -

--
-
-


----

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-59

--
-
-

PIX Firewall configuration

-
- -
- -
-
-
-
-
--
--
-




-
-
-
-
-
-
-
-


---
--- -
---
---
---
--- -
--- -
--- -
Lab 7-60 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

---
--- - - --
--- - -
--- - - ---
---
---

--- -
---
--- - - --- - -
--- - - --
---
---

-


- -



-

-
-
-
-




-- -
-- -
--
--
--
--
- -
-




Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-61


-- -
-- -
--
--
--
--
-

- -
- -
- ---
-
---
---

- - -
- - -
- -- -
- -
- -- -
- - -
-- -
-- -
--
--
-


-
-
-
-
- -
- -
- - -
- - - - --
- --
--
--
--

Lab 7-62 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

-- -
--
- -- - - --
--
-
- -- -
--
--
-
- -- -
--
--
-
- -- -
-
- -
- -- -
- -
- - - -
-
-
-

-- -
--

-

Branch office router configuration

-
- --
- --
- --

-

-
Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-63

 -
-
-- -
- -
--

- - --

-
-
-

-
-
-
-
-
-


-
-

-
-
- - --

- -- - -
--
-
- -- -
Lab 7-64 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 --

--
--

-
-

--

--
--

-

- -
---


-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-65


---
---
--- - -
--- - -
--- -
---
---
--- -
---
---
---

---

---

---

---

---

---
---

---
---
---
--- -
---

---

---

---

---


--

-- - - --

-
-

--
-
-
Lab 7-66 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.



----

--
-
-

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-67

Lab ExerciseCase Study

Company A has acquired Company B and wishes to incorporate Company Bs network into their
existing network. Company B uses the VPN Concentrator to terminate its remote users and
wishes to have remote users terminate their VPN connection on their network. Company B also
wishes to continue to use its existing equipment, however it does not want to terminate site-tosite IPSec traffic on the VPN Concentrator. Access to Company As internal network and its
public resources will be provided through a VPN tunnel. Company A has decided to replace
Company Bs obsolete perimeter firewall with a Cisco IOS router to provide a secure perimeter,
IDS reporting, termination of site-to-site IPSec traffic, and to allow for greater expansion and
flexibility in the future. Company A uses a PIX Firewall on the perimeter of its network and
terminates site-to-site VPNs on a Cisco IOS router. Given these requirements and the topology
below, your job is to implement SAFE SMR on the networks as specified by the security
policies provided in each section.
Complete the following lab exercise to implement the case study.
The lab exercise has the following sub-sections:
PIX Firewall Initial Configuration
DMZ IOS Router Initial Configuration
Branch IOS Router Initial Configuration
VPN Concentrator Initial Configuration
PIX Firewall Configuration
Branch Office IOS Router Configuration
Site-to-Site VPN Configuration
Client-to-LAN VPN Configuration
Final Configurations

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-1

Visual Objectives
The following figure displays the configuration you will complete in this lab exercise.

Lab Visual Objective

VPN Client

172.26.26.P

Pod P (110)
172.26.26.0/24

.10P e0/1

.150

brP

Branch
10.3.P.0/24

RBB

.1 e0/0

pub 10.3.P.5

cP

priv 10.2.P.1
10.2.P.0/24

.1

Branch

192.168.P.0/24

10.2.P.11

172.16.P.0/24

Super
Server
WWW
FTP

PSS
WWW
FTP

.2 e0
.1 e2
.50

.1 e1

.10

Lab 8-2 Cisco SAFE Implementation 1.1

.1 e4 172.18.P.0/24

.1 e5

.5 e0/1

DMZ
drP

172.19.P.0/24 .5 e0/0
10.0.P.0 /24

.100

RTS

Student
2003, Cisco Systems, Inc. All rights reserved.

pP

10.0.P.11
CSI 1.18-1

Copyright

2003, Cisco Systems, Inc.

PIX Firewall Initial Configuration

Complete the following lab exercise to configure the PIX Firewall.

Objectives
In this lab exercise, you will configure the PIX Firewall to provide basic connectivity by
completing the following tasks:
Initial configuration of the PIX Firewall.
Configure global addresses, NAT, routing and statics.
Allow outbound traffic from internal networks.
Test and verify the configuration.

Setup
Before starting this lab exercise, make sure the PIX Firewall is turned on and that your PC has
console access to the PIX Firewall.

Task 1Initial Configuration of the PIX Firewall

Complete the following steps to perform the basic initial configuration of the PIX Firewall:
Step 1

Complete a write erase on the PIX Firewall to use a default configuration.

Step 2

Check your current configuration to familiarize yourself with the current setup.

Step 3

Assign the PIX Firewall the parameters and names as defined in the following table and enable
the interfaces:
Interface

Interface Name

Security Level

IP Address/Netmask

ethernet0

outside

192.168.P.2/255.255.2
55.0

ethernet1

inside

100

10.0.P.1/255.255.255.0

ethernet2

PSS

50

172.16.P.1/255.255.25
5.0

ethernet4

DMZ1

70

172.18.P.1/255.255.25
5.0

ethernet5

DMZ2

80

172.19.P.1/255.255.25
5.0

hostname

pixP

(where P = pod number)

Task 2Configure Global Addresses, NAT, Routing and Statics

Complete the following steps to configure a global address pool, NAT, and routing:
Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-3

Step 1

Assign pools of IP addresses for use by outbound connections defined in the following table:
Interface Name

Global Pool ID

IP Address Range

Netmask

outside

192.168.P.33-222

255.255.255.0

(where P = pod number)

Step 2

Configure the PIX Firewall to allow all inside hosts to use NAT for outbound access and apply it
to the inside interface. For the inside host, use IP address 10.0.P.0 (where P = pod number).

Step 3

Assign the perimeter routers inside interface as the PIX Firewalls default route.

Step 4

Configure the PIXs inside interface for 10mb full duplex.

Step 5

Create static network mappings to gain access from the inside networks to the PSS and DMZ
networks according to the following table:
Inside Network

Outside Network

Interfaces

10.0.P.0

10.0.P.0

inside/PSS

10.0.P.0

10.0.P.0

inside/DMZ1

10.0.P.0

10.0.P.0

inside/DMZ2

(where P = pod number)

Step 6

Confirm your entries by examining the nat and global configurations.

Step 7

Write the current configuration to Flash memory.

Task 3Allow Outbound Traffic from Internal Networks

Complete the following steps to allow outbound traffic from internal networks:
Step 1

Create an access list named OUTBOUND permitting ip traffic from the internal networks to all
networks and apply it to the inside interface.

Step 2

Create an access list named INBOUND to permit ICMP echo replies initiated from the internal
networks to all outside networks and denying all other access from the outside networks. Apply it
to the outside interface.

Step 3

Create an access list named PSS-OUT to permit ICMP echo replies initiated from the internal
networks to the PSS network and apply it to the PSS interface.

Step 4

Create an access list named DMZ2-OUT to permit ICMP echo replies initiated from the internal
networks to any network and apply it to the DMZ2 (e5) interface.

Step 5

Compare your configuration to the following:

-
- -
- -
-
-
-

Lab 8-4 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
--
--
-



-
-
-
-
-
-
-
-
---
---
---
---

---
-



-


-
-




-- -
-- -
--
--
--
--

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-5


-- -
-- -
--
--
--
--
-

- -
-
- - -
- - -
- - -
-- -
-- -
--
--
-

-
-
-
-
- -
- -
--
--
--
--
--

--

-

Task 4Test and Verify the Configuration

Step 1

Ping the following devices from the PIX Firewall to ensure they are operational:
PIX Firewall inside interface10.0.P.1
(where P = pod number)

Lab 8-6 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Student PC10.0.P.11
(where P = pod number)
PIX Firewall outside interface192.168.P.2
(where P = pod number)
PIX Firewall PSS interface172.16.P.1
(where P = pod number)
PIX Firewall DMZ1 interface172.18.P.1
(where P = pod number)
PIX Firewall DMZ2 interface172.19.P.1
(where P = pod number)
PSS server172.16.P.50
(where P = pod number)
VPN Client172.26.26.P
(where P = pod number)
Step 2

Establish ftp and web access to the PSS server from the Student PC.

Step 3

Establish ftp and web access to the VPN Client from the Student PC.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-7

DMZ IOS Router Initial Configuration

Complete the following lab exercise to configure the DMZ IOS router.

Objectives
In this lab exercise, you will configure the DMZ IOS router to provide basic connectivity by
completing the following tasks:
Initial configuration of the DMZ IOS router.
Test and verify the configuration.

Setup
Before starting this lab exercise, make sure the DMZ IOS router is turned on and that your PC
has console access to the DMZ IOS router.

Task 1Initial Configuration of the DMZ IOS Router

Complete a write erase on the DMZ IOS Router to use a default configuration.
Step 1

Check your current configuration to familiarize yourself with the current setup.

Step 2

Assign the DMZ IOS Router the parameters as defined in the following tables and enable the
interfaces:
Ethernet0/0172.19.P.5/255.255.255.0
(where P = pod number)
Ethernet0/1172.18.P.5/255.255.255.0
(where P = pod number)
HostnamedrP
(where P = pod number)

Step 3

Set the enable password on the IOS Router to enable.

Add routes to the following networks within the topology:
Network

Next Hop

10.0.P.0/255.255.255.0

172.19.P.1

172.26.26.0/255.255.255.0

172.18.P.1

10.2.P.0/255.255.255.0

172.18.P.1

10.3.P.0/255.255.255.0

172.18.P.1

172.16.P.0/255.255.255.0

172.19.P.1

(where P = pod number)

Lab 8-8 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 4

Compare your configuration to the following:

-
- --
- --
- --

- -

-
-

--

--

--

---




-

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-9

Task 2Test and Verify the Configuration

Step 1

Ping the following devices from the Student PC to ensure they are operational:
DMZ IOS router e0/1 interface172.18.P.5
(where P = pod number)
DMZ IOS router e0/0 interface172.19.P.5
(where P = pod number)

Lab 8-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Branch IOS Router Initial Configuration

Complete the following lab exercise to configure the Branch IOS router.

Objectives
In this lab exercise, you will configure the Branch IOS router to provide basic connectivity by
completing the following tasks:
Initial configuration of the Branch IOS router.
Test and verify the configuration.

Setup
Before starting this lab exercise, make sure the Branch IOS router is turned on and that your PC
has console access to the Branch IOS router.

Task 1Initial Configuration of the Branch IOS Router

Step 1

Complete a write erase on the IOS Router to use a default configuration.

Step 2

Check your current configuration to familiarize yourself with the current setup.

Step 3

Assign the IOS Router the parameters as defined in the following tables and enable the
interfaces:
Ethernet0/010.3.P.1/255.255.255.0
(where P = pod number)
Ethernet0/1172.26.26.10P/255.255.255.0
(where P = pod number)
HostnamebrP
(where P = pod number)

Step 4

Configure the IOS Router to use EIGRP according to the following parameters:
Autonomous System Number1
Network10.0.0.0
Network172.26.0.0
Route SummaryNone

Step 5

Configure a static route on the IOS Router to allow access to the private network on the VPN
Concentrator:

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-11

(where P = pod number)

Step 6

Configure the IOS Router to redistribute static routes into EIGRP:

- -

(where P = pod number)

Step 7

Verify your routing table ensuring that the static route you entered is being redistributed into
EIGRP.

Step 8

Compare your configuration to the following:

-
- --
- --
- --

-
-

--

--

--

- -


-

Lab 8-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.


---
-

Task 2Test and Verify the Configuration

Step 1

Ping the following devices from the Student PC to ensure they are operational:
Branch IOS router e0/0 interface10.3.P.1
(where P = pod number)
Branch IOS router e0/1 interface172.26.26.10P
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-13

VPN Concentrator Initial Configuration

Complete the following lab exercise to configure the VPN Concentrator.

Objectives
In this lab exercise, you will configure the VPN Concentrator to provide basic connectivity by
completing the following tasks:
Reset the VPN concentrator via CLI.
Configure the VPN Concentrator via CLI.
Test and verify the configuration.

Setup
Before starting this lab exercise, make sure the VPN Concentrator is turned on and that your PC
has console access to the VPN Concentrator.

Task 1Reset the VPN Concentrator Via CLI

Complete the following steps via the console to set the Concentrator to the factory default using
the CLI in preparation for the next sections.
Step 1

Access the VPN Concentrator console port and reboot the system to the default configuration.

Task 2Configure the Concentrator Via CLI

Complete the following steps using the VPN Concentrator CLI to configure the Concentrators
private and public interfaces and default gateway:
Step 1

Assign the VPN Concentrator the parameters as defined in the following table and assign a
default gateway of 10.3.P.1 (where P = pod number). Be sure to remove the default filters as
shown in the table:
Interface

IP Address/Netmask

Filter

public (e2)

10.3.P.5/255.255.255.0

none

private (e1)

10.2.P.1/255.255.255.0

none

(where P = pod number)

Task 3Test and Verify the Configuration

Step 1

Ping the following devices from the Student PC to ensure they are operational:
VPN Concentrator public interface10.3.P.5
(where P = pod number)

Lab 8-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Concentrator private interface10.2.P.1

(where P = pod number)
Branch PC10.2.P.11
(where P = pod number)
Step 2

Copyright

Establish ftp and web access to the Branch PC from the Student PC.

2003, Cisco Systems, Inc.

Case Study Lab 8-15

PIX Firewall Configuration

Complete the following lab exercise to configure the PIX Firewall.

Objectives
In this lab exercise, you will configure the PIX Firewall to secure the corporate network by
completing the following tasks:
Deny outbound traffic from the Public Services Segment (PSS) network.
Allow necessary Internet services to the PSS server.
Implement spoofing protection.
Enable logging to the management server on the internal corporate network.
Assign Telnet and enable passwords.
Test and verify the configuration.

Network Security Policy

You will implement the following security policies in this lab exercise:
Control incoming traffic:

Allow Internet users access to PSS server and services.

Allow corporate users access to PSS server and services.

Deny Internet users access to the corporate office internal network.

Deny inbound traffic from the 127.0.0.0 and 10.0.P.0 networks.

(where P = pod number)
Permit Internet Control Message Protocol (ICMP) echo replies to internal networks.
Permit ICMP echo request to all PIX interfaces. The outside interface should not
respond to requests from untrusted networks.

Control outgoing traffic:

Deny traffic initiated from the PSS server.

Allow corporate users access to the Internet.

Lab 8-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Apply PIX Firewall hardening and management:

Enable logging.

Assign Telnet and enable passwords.

Setup
Before starting this lab exercise, make sure the PIX Firewall is turned on and that your PC has
console access to the PIX Firewall.

Task 1Deny Outbound Traffic from the PSS Network

Complete the following steps to deny outbound traffic from the PSS network:
Step 1

Modify the PSS-OUT ACL to deny outbound traffic initiated from the PSS server.

Step 2

Confirm that the PSS server cannot gain access outside of its local subnet from the PSS Server:
Test ICMP access to the Branch Router: 172.26.26.10P
(where P = pod number)
Test FTP and web access to the Student PC: 10.0.P.11
(where P = pod number)
Test ICMP access to the VPN Client PC: 172.26.26.P
(where P = pod number)

Step 3

Confirm that you still have connectivity to the PSS server from the Student PC:
Test ICMP access to the PSS Server: 172.16.P.50
(where P = pod number)
Test ftp and web access to PSS server: 172.16.P.50
(where P = pod number)

Task 2Allow Necessary Internet Services to the PSS Server

Complete the following steps to allow necessary Internet services to the PSS server:
Step 1

Create a static translation for your PSS server using the following parameters:
prenat_interfacePSS
postnat_interfaceoutside
mapped_address192.168.P.11
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-17

real_address172.16.P.50
(where P = pod number)
netmask255.255.255.255
connection_limit0
em_limit1000
Step 2

Modify the INBOUND ACL to deny RFC 2827 and 1918 traffic using the following parameters:
address to be denied127.0.0.0/255.0.0.0
address to be denied10.0.P.0/255.255.255.0
(where P = pod number)
Note

The course lab topology does not allow for including the complete RFC 1918 private
addresses. The listed addresses are those that do not affect the communication between the
lab equipment. For actual implementation, include all appropriate RFC 1918 private addresses
applicable to your network.

Step 3

Modify the INBOUND ACL to allow inbound web and FTP access to the public address of the
PSS server and to explicitly deny all other traffic.

Step 4

Deny all ICMP traffic to the outside interface.

Step 5

Write the current configuration to Flash memory.

Step 6

Compare your configuration to the following:

-
- -
- -
-
-
-
-
--
--
-



-
-
-

Lab 8-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
-
-
-
-
---
---
---
--- -
--- -
---
---
---

--- -
---
---
-



-


-
-
-




-- -
-- -
--
--
--
--





-- -
-- -
Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-19

 --
--
--
--
-

- -
-
- - -
- - -
- - -
- - -
-- -
-- -
--
--
-

-
-
-
-
- -
- -
--
--
--
--
--

--

-

Step 7

Verify the configuration by performing the following test from the VPN Client PC:
Test that ICMP access does not work to the outside interface of the PIX Firewall:
192.168.P.2.
(where P = pod number)

Lab 8-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Test FTP and web access to the PSS server: 192.168.P.11.

(where P = pod number)

Task 3Implement Spoofing Protection

Complete the following steps to implement Unicast Reverse Path Forwarding (RPF) IP spoofing
protection:
Step 1

Enable Unicast RPF IP spoofing protection for the outside and PSS interfaces.

Step 2

Write the current configuration to Flash memory.

Task 4Enable Logging to the Management Server on the Internal

Corporate Network
Complete the following steps to implement logging:
Step 1

Enable logging and send information log messages to the management PC using the following
parameters:
Management PC10.0.P.11
(where P = pod number)
Trap levelinformational

Step 2

Write the current configuration to Flash memory.

Task 5Assign Telnet and Enable Passwords

Complete the following steps to assign Telnet and enable passwords:
Step 1

Configure and set your password according to the following parameters:

enable passwordenable
telnet passwordcisco

Step 2

Write the current configuration to Flash memory:

Step 3

Compare your configuration to the following sample configuration from pix1:

-
- -
- -
-
-
-
-

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-21

 --
--
-



-
-
-
-
-
-
-
-
---
---
---
--- -
--- -
---
---
---

--- -
---
---
-


- -



-


-
-
-




-- -
Lab 8-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -- -
--
--
--
--
- -
-





-- -
-- -
--
--
--
--
-

- -
-
- - -
- - -
- - -
- - -
-- -
-- -
--
--
-

-
-
-
-
- -
- -
--
--
--
--
--

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-23


--

-

Task 6Test and Verify the Configuration

Complete the following steps to test your configuration:
Step 1

Ensure that you cannot access the PSS server from the VPN client PC via ICMP, but can access
it via FTP and web access:
Test ICMP access to the PSS server: 192.168.P.11
(where P = pod number)
Test FTP and web access to the PSS server: 192.168.P.11
(where P = pod number)

Step 2

Ensure that you can access the Internet from the Student PC:
Test ICMP access to the VPN Client PC: 172.26.26.P
(where P = pod number)
Test FTP and web access to the VPN Client PC: 172.26.26.P
(where P = pod number)

Step 3

Ensure that you cannot access the internal corporate network from the VPN client PC. Test
ICMP, web, and FTP access to the Student PC at IP address: 10.0.P.11 (where P = pod number).

Step 4

Ensure that you cannot initiate a connection to any network from the PSS server.

Lab 8-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Branch Office IOS Router Configuration

Complete the following lab exercise to practice what you learned in this chapter.

Objectives
In this lab exercise you will complete the following tasks:
Secure the branch office router network services.
Secure management access to the branch office router.
Configure NAT IOS features.
Implement access control filtering.
Configure CBAC and IDS features.
Test the branch office router configuration.

Network Security Policy

You will implement this network security policy in this lab exercise:
Secure the branch office router network services:

Create a warning banner that is displayed when an interactive session is established.

Enforce password encryption to protect device passwords.

Disable unnecessary network services.

Log branch office router events:

Send branch router Syslog output to the internal Syslog server on the branch office
server.

Log informational events on the branch office router to the Syslog server.

Set accurate time-stamping for log and debug messages.

Control administrator access to the branch office router to prevent unauthorized access:

Copyright

Control access into the router from the console and the vty lines.

2003, Cisco Systems, Inc.

Case Study Lab 8-25

Allow Telnet to the perimeter router only from the student system inside the branch
office network.
Authenticate Telnet sessions with usernames and passwords entered into the perimeter
routers local security database.
Log all administrator attempts to the Syslog server.

Implement Network Address Translation (NAT) and Port Address Translation (PAT)
features to hide the internal network addresses.
Prevent source address spoofing.

Deny outgoing IP traffic with the corporate internal address as the source address.

Deny packets with local host, broadcast or multicast (or both), source addresses.

Deny packets without any source address.

Control incoming and outgoing traffic:

Permit incoming traffic that is part of a session that originated from the branch office
network or the corporate office network.

Permit outgoing traffic only from a valid internal network address.

Permit routing updates from the ISP backbone router.

Log all disallowed connections to the Syslog server.

Configure Context-Based Access Control (CBAC) and IOS intrusion detection system (IDS)
features:

Inspect common application protocols and generic TCP and UDP sessions.

Disable IOS IDS informational signatures.

Enable IOS IDS attack signatures to alarm and drop matching packets.

Setup
Before starting this lab exercise, set up your equipment so that you can do the following from the
branch office equipment:
Ping the branch office routers inside and outside interfaces from the branch office PC.

Lab 8-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Ping the backbone router in the cloud network from the branch office router.
Establish connectivity to corporate PSS network resources.
Ensure the Syslog server is running on the branch office PC.

Task 1Secure the Branch Office Router Network Services

Complete the following steps to secure your branch office router. Example command entries are
included with each step. Substitute network and IP addresses from your network where given in
an example.
Step 1

Create a warning message that is displayed when a user establishes an interactive session using
the following parameters:
banner loginWarning. Authorized Company IT Personnel ONLY!
banner execYou are now executing commands on Company Property!

Step 2

Enable password encryption and assign a secret enable password to protect the routers
passwords using the following parameters:
enable password should be encrypted
enable secretsecret

Step 3

Disable unnecessary network and router services to limit the exposure to direct attacks against
the router. The following services should be disabled on each interface:
source-route
cdp run
finger
tcp-small-servers
udp-small-servers
http server
bootp server
domain-lookup
rcmd rsh-enable
rcmd rcp-enable

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-27

proxy-arp
cdp enable
ip redirects
ip directed-broadcast
Step 4

Enable logging to the Syslog server to provide a method to monitor router events including
attacks:
management PC10.2.P.11
(where P = pod number)
trap levelinformational

Task 2Secure Management Access to the Branch Office Router

Complete the following steps to secure management access to the branch office router:
Step 1

Create a standard ACL to permit management access and log those hits from the Branch PC
using the following parameters:
access list number1
Assign a password to the VTY lines (04) and the console line, and allow VTY line access only
from management workstations to the router to prevent access by unauthorized users using the
following parameters:
passwordcisco
access list1
timeout15

Step 2

Create a local user account on the router that is used to log into the router using the following
parameters:
usernamestudent
passwordstudent
Enable the router feature to prevent CPU cycles from being misallocated by guarantying
CPU time for system processes.

Task 3Configure NAT IOS Features

Complete the following steps to enable the NAT features to hide the internal network address.

Lab 8-28 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Caution
Step 1

Do not do Task 3 in a remote lab environment.

Establish static translation between an inside local address and an outside global address and
apply it to both interfaces using the following parameters:
local-ip10.2.P.11
(where P = pod number)
global-ip172.26.26.11P
(where P = pod number)

Task 4Implement Access Control Filtering

Complete the following steps to configure access control filtering to prevent IP spoofing attacks.
Step 1

Create an ACL that meets the following criteria and apply it to the public (E0/1) interface:
access list number101
Allows traffic, routing updates, and logs from the ISP router (RBB) and no other routers
Allows traffic from the corporate office
Prevents inbound network traffic with source addresses of the branch office internal
networks
Implements RFC 1918 filtering for the following networks

Step 2

127.0.0.0

172.18.0.0

Create an ACL that only allows outbound traffic originating from the internal network and
explicitly denies all other traffic using the following parameters:
access list number102
logginglog

Task 5Configure CBAC and IDS Features

Complete the following steps to configure CBAC and IDS features. Example command entries
are included with each step.
Step 1

Enable inbound CBAC inspection on the inside interface for the following protocols:
TCP
UDP

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-29

FTP
H323
RealAudio
Inspection namebranchfw
Step 2

Configure an IOS IDS on the inside interface to perform the following:

Disable informational signatures
Alarm and drop attack signatures
Report the attacks to the branch office Syslog server
audit-namebranchids

Step 3

Save your configuration and compare it to the following:

-
- --
- -- -
- --

-
- -
--

- - --

-
-
-

-
-
-
-

Lab 8-30 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
-


-

--
--

-
-

--

--
--

- -


-

---
-

---
--- - -
--- - -
--- -
---
---
Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-31

---

---

---

---
---
---

-
-

--

-
-


----

--

-
-

Task 6Test the Branch Office Router Configuration

Complete the following steps to confirm that the branch office is configured correctly:
Step 1

Ping the branch office routers inside and outside interface from the branch office PC.

Step 2

Establish a Telnet session to the branch office router from the branch office PC:
If you are unable to telnet to your branch office router, console into your branch office router
and check the ACLs applied to your VTY lines and inside interface.

Step 3

Verify HTTP and FTP connectivity to the corporate Web server at IP address 192.168.P.11
(where P = pod number).

Step 4

Verify that the address translation is working properly for a local lab.

Lab 8-32 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Site-to-Site VPN Configuration

Complete the following exercise to implement the case study.

Objectives
In this lab exercise you will configure a site-to-site VPN by completing the following tasks:
Prepare the PIX Firewall for the DMZ IOS Router to Branch Office IOS Router IPSec tunnel
configuration.
Prepare for configuring IPSec on the Branch Office IOS Router.
Configure IKE parameters on the Branch Office IOS Router.
Configure IPSec parameters on the Branch Office IOS Router.
Prepare for configuring IPSec pre-shared keys on the DMZ IOS Router.
Configure IKE parameters on the DMZ IOS Router.
Configure IPSec parameters on the DMZ IOS Router.
Configure the PIX Firewall to only allow IPSec Traffic to the DMZ IOS Router.
Verify the IPSec configuration.

Network Security Policy

IPSec will be configured between the branch office IOS Router and the DMZ IOS Router to
use pre-shared keys.
Branch office users will have access to the internal corporate and the DMZ network through
the VPN tunnel.
Corporate users will have access to the branch office network through the VPN tunnel.
There will be no Network Address Translation (NAT) used in the VPN tunnel.

Setup
Before starting this lab exercise, make sure you can access the console ports of the devices used.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-33

Task 1Prepare the PIX Firewall for the DMZ IOS Router to Branch
Office IOS Router IPSec Tunnel Configuration
Step 1

Create a static mapping from the DMZ1 interface to the Outside interface of the PIX Firewall to
translate the e0/1 address on the DMZ IOS Router according to the following:
Inside address172.18.P.5
(where P = pod number)
Outside address192.168.P.200
(where P = pod number)
InterfaceDMZ1

Step 2

Create an access-list entry in the DMZ1-OUT access-list to allow the IOS DMZ Router access to
the Branch Routers outside interface.

Step 3

Create an access-list entry in the INBOUND access-list to allow the outside interface of the
Branch Office IOS Router to the DMZ1 interface of the DMZ IOS Router.

Step 4

Create access list entries in the DMZ2-OUT access-list on the DMZ2 interface to allow the
Branch office networks access to the internal networks and the PSS.

Step 5

Create a static mapping from the DMZ2 interface to the PSS interface of the PIX Firewall to
allow access from the Branch Office networks to the PSS according to the parameters on the
following table:
Inside address10.2.P.0
(where P = pod number)
Outside address10.2.P.0
(where P = pod number)
InterfaceDMZ2

Step 6

Create route statements to route traffic destined for the Branch Office networks to the DMZ IOS
Router interface DMZ2.

Step 7

Save your configuration and compare it to the following:

-
- -
- -
-
-
-
-
--
--

Lab 8-34 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

-



-
-
-
-
-
-
-
-
---
---
---
--- - -
--- -
--- -
---
---
---

--- -
---
--- -
---
---
---
---
---
---
-


- -



-


-
-
-
Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-35





-- -
-- -
--
--
--
--
- -
-





-- -
-- -
--
--
--
--
-

- -
-
- - -
- - -
- - -
- - -
- - -
- -
-- -
-- -
--
--
--
-



-
-
-

Lab 8-36 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
- -
- -
--
--
--
--
--

--

-

Task 2Prepare for Configuring IPSec on the Branch Office IOS

Router
Complete the following lab exercise steps to prepare for the IPSec configuration:
Step 1

Input static routes for the following networks using the translated address of the DMZ IOS
Router as the next hop:
Next Hop192.168.P.200
(where P = pod number)
10.0.P.0/255.255.255.0
(where P = pod number)
172.16.P.0/255.255.255.0
(where P = pod number)

Step 2

Determine the Internet Key Exchange (IKE) and IPSec policy.

The IKE policy is to use pre-shared keys and Secure Hash Algorithm (SHA) for
authentication.
The IPSec policy is to use Encapsulating Security Payload (ESP) mode with Triple-Data
Encryption Standard (3DES) encryption.
The IPSec policy is to encrypt IP traffic between internal NT servers in each pod.

Task 3Configure IKE Parameters on the Branch Office IOS Router

Complete the following steps to configure IKE to use pre-shared keys:

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-37

Step 1

Create an IKE policy using the parameter values listed:

Isakmp keycisco1234
Policy priority number10
Encryption algorithm3des
Hash algorithmsha
Authentication methodpre-share
Diffie-Hellman group identifier1
SA lifetime86400

Task 4Configure IPSec Parameters on the Branch Office IOS Router

Complete the following steps to configure IPSec (IKE Phase 2) parameters:
Step 1

Create an access control list (ACL) to select traffic to protect. The ACL should protect IP traffic
between the internal networks, using the following parameters, and allow branch office users
access to the untranslated Public Services Segment (PSS) and internal corporate server networks:
Traffic encryptedTraffic between corporate internal networks and branch office networks
Access list name103
ProtocolAny Internet protocol

Step 2

Create access-list entries to allow decrypted traffic from the corporate office networks to the
branch office networks:
Corporate Office Networks10.0.P.0/255.255.255.0 and 172.16.P.0/255.255.255.0
(where P = pod number)
Branch Office Networks10.2.P.0/255.255.255.0 and 10.3.P.0/255.255.255.0
(where P = pod number)
Access list name101
ProtocolAny Internet protocol

Step 3

Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed:
Transform namemyset
ESP protocols3des

Lab 8-38 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Modetunnel
Step 4

Create a crypto map using the parameter values listed and apply it to the e0/1 interface:
Crypto map nameDMZ
Map number10
Key exchange typeisakmp
Peer192.168.P.200
(where P = pod number)
Transform setmyset
Match address103

Step 5

Save your configuration and compare it to the following:

-
- --
- -- -
- --

-
- -
--

- - --

-
-
-

-
-
-
-
-

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-39

 -


-
-

-
-
- - --

- -- - -
--
-
- -- -
--

--
--

-
-

--

--
--

- -


-
Lab 8-40 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.


---


-

---
--- - -
--- - -
--- -
---
---
---
---

---

---

---

---

---
---
---

---
---
---
---

-
-

--

-
-


----

--

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-41

-
-

Task 5Prepare for Configuring IPSec Pre-Shared Keys on the DMZ

IOS Router
Complete the following lab exercise steps to prepare for the IPSec configuration:
Step 1

Determine the Internet Key Exchange (IKE) and IPSec policy.

The IKE policy is to use pre-shared keys and Secure Hash Algorithm (SHA) for
authentication.
The IPSec policy is to use Encapsulating Security Payload (ESP) mode with Triple-Data
Encryption Standard (3DES) encryption.
The IPSec policy is to encrypt IP traffic between internal NT servers in each pod.

Task 6Configure IKE Parameters on the DMZ IOS Router

Complete the following steps to configure IKE to use pre-shared keys on the DMZ IOS Router:
Step 1

Create an IKE policy using the parameter values listed:

Isakmp keycisco1234
Policy priority number10
Encryption algorithm3des
Hash alogorithmsha
Authentication methodpre-share
Diffie-Hellman group identifier1
SA lifetime86400

Task 7Configure IPSec Parameters on the DMZ IOS Router

Complete the following steps to configure IPSec (IKE Phase 2) parameters:
Step 1

Create an access control list (ACL) to select traffic to protect. The ACL should protect IP traffic
between the internal networks, using the following parameters, and allow branch office users
access to the untranslated Public Services Segment (PSS) and internal corporate server networks:

Lab 8-42 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Traffic encryptedTraffic between corporate internal networks and branch office networks
Peer network addressIP address of branch office network
Access list name103
ProtocolAny Internet protocol
Step 2

Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed in
the table.
Transform namemyset
ESP protocols3des
Modetunnel

Step 3

Create a crypto map using the parameter values listed and apply it to the e0/1 interface:
Crypto map namebranch
Map number10
Key exchange typeisakmp
Peer172.26.26.10P
(where P = pod number)
Transform setmyset
Match address103

Task 8Configure the PIX Firewall to Only Allow IPSec Traffic to the
DMZ IOS Router
Complete the following steps to configure the perimeter router to only allow IPSec traffic to the
PIX Firewall and Concentrator:
Step 1

Create ACL entries to only allow IPSec traffic from the branch office router to the DMZ IOS
Router using the following parameters:
access-list numberINBOUND
ProtocolESP
ProtocolUDPeq ISAKMP

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-43

Task 9Verify the IPSec Configuration

Complete the following steps to verify your IPSec configuration:
Step 1

Initiate a web session from your student PC to the branch office PC.

Step 2

Ensure that traffic between peers is being encrypted by completing the following sub-steps on
your DMZ IOS Router:
1. Examine the IPSec SAs. Note the number of packets encrypted and decrypted.
2. Generate additional traffic by clicking the Reload button of your web browser.
3. Examine the IPSec SAs again.
4. Note that the packet counters have incremented.

Step 3

Confirm your crypto configuration on the branch office router.

Step 4

Confirm that the branch office network addresses have not been translated.

Step 5

Confirm that the appropriate ACL hit-counters are being incremented.

Lab 8-44 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Client-to-LAN VPN Configuration

Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives
In this lab exercise, complete the following tasks to enable remote access via VPN:
Configure the VPN Concentrator using Quick Configuration via the web interface.
Configure the VPN Concentrator via the web interface.
Configure the Cisco VPN Client.
Configure the Branch Office IOS router.
Test and verify the IPSec configuration.

Network Security Policy

In this lab exercise, you will configure the perimeter router, the Cisco VPN Concentrator, and
other managed devices according to the following VPN security policy:
A VPN tunnel will secure communication between the Cisco VPN Client PC and the
Concentrator.
The VPN Client PC must be able to access the branch office internal network.

Setup
Before starting this lab exercise, set up your equipment as follows:
Ensure that your Concentrator is turned on.
Access the branch office routers console port.

Task 1Configure the VPN Concentrator Using Quick Configuration

Via the Web Interface
Step 1

Configure the VPN Concentrator using the System Info parameters below:
System NamestudentP VPN
(where P = pod number)
New TimeVerify the current time and date

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-45

DST SupportEnable
DNS Server0.0.0.0 (which is the default)
Domain NamepodP.com
(where P = pod number)
Default Gateway10.3.P.1
(where P = pod number)
Step 2

Configure the following Protocol parameter values:

PPTPDisable
L2TPDisable
IPSecEnable

Step 3

Configure the Address Assignment parameter values listed below:

Configured PoolEnabled (select the check box)
Range Start10.2.P.17
(where P = pod number)
Range End10.2.P.30
(where P = pod number)

Step 4

Use an Internal Server with the following parameters:

UsernamestudentP
(where P = pod number)
PasswordstudentP
(where P = pod number)
Verify passwordstudentP
(where P = pod number)

Step 5

Enter the following IPSec Group parameter values:

Note

The group name and password information is case-sensitive and must match the IPSec group
created earlier.

Group NamepodP_group
(where P = pod number)

Lab 8-46 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PasswordpodP_group
(where P = pod number)
VerifypodP_group
(where P = pod number)
Note

You can configure the admin password in the Admin Password window. For lab consistency,
please leave the password at its default value.

Task 2Configure the VPN Concentrator Via the Web Interface

Complete the following steps using the Concentrator management web interface to configure
Concentrator parameters:
Step 1

Modify the Public (Default) filter to allow any traffic.

Note

This modification is necessary for the classroom lab only and is not recommended on a live
network.

Step 2

Apply the Public (Default) filter to the Ethernet 2 (Public) interface on the VPN Concentrator.

Step 3

Use CiscoVPNClient-3DES-MD5 Active Proposal.

Step 4

Enter the Default Gateway parameter values listed:

Metric1
Tunnel default gateway10.3.P.1
(where P = pod number)
Override Default GatewayEnabled

Step 5

Disable the following insecure management protocols:

FTP
TFTP
Telnet
SNMP
HTTP

Step 6

Create a static entry on the PIX Firewall to translate the Student PCs host address to
192.168.P.50 from the inside to the outside.
(where P = pod number)

Step 7

Clear the translation table.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-47

Step 8

Enable split tunneling on the VPN Concentrator only allowing access to the translated address of
the Student PC.
Translated address192.168.P.50
(where P = pod number)

Task 3Configure the Cisco VPN Client

Complete the following steps to configure the VPN Client:
Step 1

Configure the VPN client according to the following parameters:

connection entrystudentP
(where P = pod number)
IP address of the Concentrators Public IP interface10.3.P.5.
(where P = pod number)

Step 2

Enter the following Group Access Information:

Note

The group name and password information assigned is case-sensitive.

Group NamepodP_group
(where P = pod number)
Group PasswordpodP_group
(where P = pod number)
Confirm PasswordpodP_group
(where P = pod number)
Step 3

Ensure the following parameters are configured:

IPSec through NAT mode should be allowed.
The Peer Response Timeout should be 90.
Allow local LAN access should be checked.
Note

Split Tunneling should not be allowed in a production environment.

Task 4Configure the Branch Office IOS Router

This section details configuring the branch office router to allow IKE and IPSec traffic to the
VPN Concentrator.

Lab 8-48 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 1

Configure an access-list entry in access-list number 101 to allow IKE and IPSec
traffic access to the public interface of the VPN concentrator.

Task 5Test and Verify the IPSec Configuration

Complete the following steps to verify the configuration:
Step 1

Launch the VPN client and unsure that you can access the Branch PC through the VPN tunnel.
Test FTP and web access to the Branch PC10.2.P.11
(where P = pod number)

Step 2

Ensure that you can access the PSS server from the VPN client PC through the tunnel via FTP,
and web access:
Test FTP and web access to the PSS server172.16.P.50
(where P = pod number)

Step 3

Ensure that you can access the VPN Client PC through the tunnel from the Student PC:
Test FTP and web access to the VPN client PC10.2.P.17
(where P = pod number)

Step 4

Ensure that you can access the following through the tunnel from the Branch PC:
Test FTP and web access to the VPN client PC10.2.P.17
(where P = pod number)
Test FTP and web access to the PSS Server172.16.P.50
(where P = pod number)
Test FTP and web access to the Student PC10.0.P.11
(where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-49

Final Configurations
Compare your final configurations to the ones shown:
PIX Firewall Configuration
-
- -
- -
-
-
-
-
--
--
-



-
-
-
-
-
-
-
-
---
---
---
--- - -
--- - - -
--- - - -
--- - -
--- -
--- -
---
---
---

--- -
---
--- -
---
Lab 8-50 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

---
---
---
---
-


- -



-


-
-
-




-- -
-- -
--
--
--
--
- -
-





-- -
-- -
--
--
--
--
-

- -
-
- - -
Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-51

- - -
- - -
- - -
- - -
- -
-- -
-- -
--
--
--
-



-
-
-
-
- -
- -
--
--
--
--
--

--

-

Branch IOS Router Configuration

-
- --
- -- -
- --

Lab 8-52 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

 -
- -
--

- - --

-
-
-

-
-
-
-
-
-


-
-

-
-
- - --

- -- - -
--
-
- -- -
--

--
--

-
-

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-53


--

--
--

- -


-

---


-

---
--- - -
--- - -
--- -
---
--- - -
--- - -
---
---
---

---

---

---

---

---
---
---

---
Lab 8-54 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

---
---
---

-
-

--

-
-


----

--

-
-

DMZ IOS Router Configuration

-
- --
- --
- --

- -

-
-

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-55

 -
-
- - --

- -- - -
--
-
- -- -
--

--

--

--

---




-

---
---
---
---

Lab 8-56 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-57