CCSP CSI1.1 Knet

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 � CzechRepublic � 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 That�s 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

http://www.cisco.com/go/offices

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.

CreditsLead 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 in-depth, external and internal network assessments. He also was responsible for the

mailto:[email protected]

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

Copyright 2003, Cisco Systems, Inc. Table of Contents v

Table of Contents

COURSE INTRODUCTION 1-1

Overview 1-1Course Objectives 1-2Lab Topology Overview 1-7

SECURITY FUNDAMENTALS 2-1

Overview 2-1Objectives 2-2Need for Network Security 2-3Network Security Policy 2-10The Security Wheel 2-13Network Attack Taxonomy 2-18Management Protocols and Functions 2-58Summary 2-65 Lab Exercise�Vulnerabilities and Threats Lab 2-1

ARCHITECTURAL OVERVIEW 3-1

Overview 3-1Objectives 3-2SAFE Architectural Overview 3-3Design Fundamentals 3-7Safe Axioms 3-13Summary 3-32

THE CISCO SECURITY PORTFOLIO 4-1

Overview 4-1Objectives 4-2Cisco Security Portfolio Overview 4-3Secure Connectivity�Virtual Private Network Solutions 4-7Secure Connectivity�The 3000 Concentrator Series 4-11Secure Connectivity�Cisco VPN-Optimized Routers 4-17Perimeter Security Firewalls�Cisco PIX Firewall and Cisco IOS Firewall 4-23Intrusion Protection�IDS 4-30Identity�Access Control Solutions 4-36Security Management�VMS and CSPM 4-41Cisco AVVID 4-44Summary 4-48

vi Cisco SAFE Implementation 1.1 Copyright 2003, Cisco Systems, Inc.

SAFE SMALL NETWORK DESIGN 5-1

Overview 5-1Objectives 5-2Small Network Design Overview 5-3Small Network Corporate Internet Module 5-4Small Network Campus Module 5-11Implementation�ISP Router 5-14Implementation�IOS Firewall Features and Configuration 5-18Implementation�PIX Firewall 5-48Summary 5-73 Lab Exercise�SAFE Small Network Design Implementation Lab 5-1

SAFE SMR MIDSIZE NETWORK DESIGN 6-1

Overview 6-1Objectives 6-3Midsize Network Corporate Internet Module 6-4Midsize Network Corporate Internet Module Design Guidelines 6-11Midsize Network Campus Module 6-21Midsize Network Campus Module Design Guidelines 6-26Midsize Network WAN Module 6-30Implementation�ISP Router and Edge Router 6-32Implementation�IOS Firewall 6-37Implementation�PIX Firewall 6-42Implementation�NIDS 6-44Implementation�VPN Concentrator 6-83Implementation�Layer 3 Switch 6-91Summary 6-99 Lab Exercise�Medium Network Design Implementation Lab 6-1

REMOTE USER NETWORK IMPLEMENTATION 7-1

Overview 7-1Objectives 7-2Design Overview 7-3Key Devices and Threat Mitigation 7-6Software Access Option 7-10Remote Site Firewall Option 7-21VPN Hardware Client Option 7-36Remote Site Router Option 7-43Summary 7-61 Lab Exercise�Remote User Network Design Implementation Lab 7-1 Lab Exercise�Case Study Lab 8-1

1

Course Introduction

OverviewThis chapter includes the following topics:

Course objectives

Course agenda

Participant responsibilities

General administration

Graphic symbols

Participant introductions

Cisco security career certifications

Lab topology overview

1-2 Cisco SAFE Implementation 1.1 Copyright 2003, Cisco Systems, Inc.

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

© 2003, Cisco Systems, Inc. All rights reserved. CSI 1.1�1-3

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 today�s 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.


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 Networkswhitepaper.

Copyright 2003, Cisco Systems, Inc. Course Introduction 1-3


Course Agenda

Day 1� Chapter 1�Course Introduction� Chapter 2�Security Fundamentals� Lunch� Lab�Vulnerabilities and Threats� Chapter 3�Architectural Overview� Chapter 4�The Cisco Security Portfolio

Day 2� Chapter 5�SAFE Small Network Design� Lunch� Chapter 5�SAFE Small Network Design (cont.)� Lab�SAFE Small Network Design Implementation


Course Agenda (cont.)

Day 3� Chapter 6�SAFE SMR Midsize Network Design� Lab�Medium Network Design Implementation� Lunch� Chapter 7�Remote User Network Implementation� Lab�Remote User Network Design Implementation

Day 4� Lab 8�Case Study



Participant Responsibilities

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


General Administration

Class-related� Sign-in sheet� Length and times� Break and lunch room

locations� Attire

Facilities-related� Participant materials� Site emergency

procedures� Restrooms� Telephones/faxes



Graphic Symbols

IOS Router PIX Firewall VPN 3000 IDS Sensor Catalyst 6500with IDS Module

IOS Firewall

NetworkAccess Server Policy Manager CA

ServerPC Laptop Server

Web, FTP, etc.

Modem Ethernet Link VPN TunnelHub NetworkCloud

Switch


Participant Introductions

� Your name� Your company� Pre-requisites skills� Brief history� Objective



Cisco Security Career Certifications

www.cisco.com/go/ccsp

Recommended Training through Cisco Learning Partners

Required Exam

9E0-111 or642-521 Cisco Secure PIX Firewall Advanced 3.1

9E0-121 or642-511

Cisco Secure Virtual Private Networks 3.1

640-100 or642-501

Securing Cisco IOS Networks 1.0

9E0-100 or642-531

Cisco Secure Intrusion Detection System 3.0Cisco Secure Intrusion Detection System 4.0

9E0-131 or642-541

Cisco SAFE Implementation 1.1

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

Professional

CCIE

CCSP

CCNA

Associate

Network Security


Cisco Security Career Certifications

Enhance Your Cisco Certifications and Validate Your Areas of Expertise

Cisco Firewall, VPN, and IDS Specialists

www.cisco.com/go/training

Cisco Firewall Specialist

Cisco VPN Specialist

Cisco IDS Specialist


Required Exam

640-100 or642-501


9E0-111 or642-521

Cisco Secure PIX Firewall Advanced 3.1

Pre-requisite: Valid CCNA certification


Required Exam


9E0-121 or642-511

Cisco Secure Virtual Private Networks 3.1

Pre-requisite: Valid CCNA certification640-100 or642-501


Required Exam


9E0-100 or642-531

Cisco Secure Intrusion Detection System 3.0Cisco Secure Intrusion Detection System 4.0

Pre-requisite: Valid CCNA certification640-100 or642-501

http://www.cisco.com/go/ccsp

http://www.cisco.com/go/training


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


.100

e0/1

PSSWWWFTP

172.16.P.0/24

Lab Visual Objective

e0/0

10.0.P.0 /24

Pod P (1�10)

192.168.P.0/24

.1 e2

pP

.4

pub

cP

.1

172.30.P.0/24

sensorP

DMZ

.2

.150

SuperServerWWWFTP

.10

.150

.5

priv

.5

.2 e0172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

rP

RTS

RBB

VPN Client

brP

Branch10.2.P.0/24

.10P e0/1

.50

.1 e0/010.2.P.11

172.26.26.P

Branch

10.0.P.11Student

Each pair of students will be assigned a pod.

Note The P in a command indicates your pod number.



Lab Visual Objective�Case Study

Pod P (1�10)

.100

PSSWWWFTP

172.16.P.0/24

10.0.P.0 /24

192.168.P.0/24

.1 e2

pP

pub cP.1

DMZ

SuperServerWWWFTP

.10

.150

10.3.P.5

priv

.5 e0/0

.2 e0 172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

RTS

RBB

VPN Client

brP

Branch

10.2.P.0/24

.10P e0/1

.50

.1 e0/0

10.2.P.11

172.26.26.P

Branch

10.0.P.11Student

10.2.P.1

.5 e0/1

172.19.P.0/24

10.3.P.0/24

drP.1 e5

Each pair of students will be assigned a pod.

Note The P in a command indicates your pod number.

2

Security Fundamentals

OverviewThis 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


ObjectivesThis section lists the chapter�s 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.

Copyright 2003, Cisco Systems, Inc. Security Fundamentals 2-3

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, supply-chain 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 today�s networks.


The Closed Network

Remote site

Closed network

PSTN

PSTN

Frame relay X.25 leased

line

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.



The Network Today

Mobile and

remote users

Partnersite

Remote site

Open network

Internet

Internet-based intranet (VPN)

PSTN

Internet-based extranet (VPN)

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



Threat Capabilities�More Dangerous and Easier to Use

Sophistication of hacker tools

Packet forging/ spoofing

19901980

Password guessing

Self replicating code

Password cracking

Back doors

Hijacking sessions

Sweepers

Sniffers

Stealth diagnostics

Technical knowledge required

High

Low 2000

Exploiting known vulnerabilities

Disabling audits

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.



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 corporate-wide security policy

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-business�The 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�Today�s 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.



Supply chain Customer careE-commerce

E-learningWorkforce optimization

The E-Business Challenge

Expanded access heightened security risks

Internetaccess

Internetaccess

Corporateintranet

Corporateintranet

InternetpresenceInternet

presence

Internetbusinessvalue

Business security requirements

� Defense-in-depth� Multiple components� Integration into e-business

infrastructure� Comprehensive blueprint

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 e-commerce, 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.



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

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) Act�Includes 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 2000�Agencies must undergo annual self-assessments 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 104-191)�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:

� 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


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.


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 organization�s technology and information assets must abide.�

�(RFC 2196, Site Security Handbook)

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 organization�s 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.�



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

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.



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

The following are some of the key policy components:

Statement of authority and scope�This section specifies who sponsors the security policy and what areas the policy covers.

Acceptable use policy�This section specifies what the company will and will not allow regarding its information infrastructure.

Identification and authentication policy�This 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 policy�This section specifies what the company considers ethical and proper use of its Internet access capabilities.

Campus access policy�This section specifies how on-campus users will use the company�s data infrastructure.

Remote access policy�This section specifies how remote users will access the company�s data infrastructure.

Incident handling procedure�This section specifies how the company will create an incident response team and the procedures it will use during and after and incident occurs.


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� Step 2: Monitor� Step 3: Test� Step 4: Improve

Secure

Monitor

Test

Improve Security Policy

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 network�s topology.



Secure

Monitor

Test


Secure the Network

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

The following are solutions identified to secure a network:

Authentication�The 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.

Encryption�A 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).

Firewalls�A 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 patching�The identification and patching of possible security �holes� that could compromise a network.



Secure

Monitor

Test


Monitor Security

� Detects violations to the security policy

� Involves system auditing and real-time intrusion detection

� Validates the security implementation in Step 1

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.



Secure

Monitor

Test


Test Security

Validateseffectiveness of the security policy through system auditing and vulnerability scanning

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 customer�s network. Delivered by highly expert Cisco Network Security Engineers (NSEs), the Cisco SPA includes an operational, granular analysis of large-scale, distributed service provider networks from the perspective of an outside �hacker.�



Secure

Monitor

Test


Improve Security

� Use information from the monitor and test phases to make improvements to the security implementation.

� Adjust the security policy as security vulnerabilities and risks are identified.

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.


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


Internet

Variety of Attacks

Network attacks can be as varied as the systems that they attempt to penetrate.

Externalexploitation

Externalexploitation

Internalexploitation

Internalexploitation

Dial-inexploitation

Dial-inexploitation

Compromised host

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.



Network Security Threats

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

There are four general threats to network security:

Unstructured threats�These 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 threats�These 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 state-sponsored intelligence collection organizations hire such hackers.

External threats�These 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 threats�These 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.



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

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



Specific Attack Types (cont.)

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

CAM table flooding

VLAN hopping

ARP/MAC poisoning

ARP spoofing

Private VLAN attacks

Multicast brute-force failover

DHCP Starvation



Packet Sniffers

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.

Host A Host BRouter A Router B

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.)



Packet Sniffer Example

There are two primary types of packet sniffers:� General purpose sniffers� Sniffers designed for attack purpose

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


� Captures first 300 to 400 bytes

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



Packet Sniffer Mitigation

The following techniques and tools can be used to mitigate sniffers:� Authentication�A first option for defense against packet sniffers is to

use strong authentication, such as one-time passwords. � Switched infrastructure�Deploy a switched infrastructure to counter

the use of packet sniffers in your environment. � Antisniffer tools�Use these tools to employ software and hardware

designed to detect the use of sniffers on a network. � Cryptography�The most effective method for countering packet

sniffers does not prevent or detect packet sniffers, but rather renders them irrelevant.

Host A Host BRouter A Router B

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

Authentication�Using 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 infrastructure�This 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.


Antisniffer tools�Employing 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.

Cryptography�Rendering packet sniffers irrelevant, which is the most effective method for countering packet sniffers�even 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).



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.

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.



IP Spoofing Mitigation

The threat of IP spoofing can be reduced, but not eliminated, through the following measures:� Access control�The most common method for preventing IP

spoofing is to properly configure access control. � RFC 2827 filtering�Prevent any outbound traffic on your

network that does not have a source address in your organization�s own IP range.

� Additional authentication that does not use IP-based authentication�Examples of this include the following:� Cryptographic (recommended)� Strong, two-factor, one-time passwords

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

Access control�The 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 filtering�You 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 Authentication�The 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.



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

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.



Handlersystems

Clientsystem

4. The client issues commands to handlers that control agents in a mass attack.

1. Scan for systems to hack.

Agentsystems

3. Agents are loaded with remote control attack software.

DDoS Example

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

DDoS attacks are the �next generation� of DoS attacks on the Internet. This type of attack is not new�UDP and TCP SYN flooding, Internet Control Message Protocol (ICMP) echo request floods, and ICMP directed broadcasts (also known as smurf attacks) are similar�but 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 attacker�s 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.



DoS Mitigation

The threat of DoS attacks can be reduced through the following three methods:� Antispoof features�Proper configuration of

antispoof features on your routers and firewalls� Anti-DoS features�Proper configuration of

anti-DoS features on routers and firewalls � Traffic rate limiting�Implement traffic rate

limiting with the networks ISP

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 features�Proper 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 features�Proper 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 limiting�An 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.



Password Attacks

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

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.



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

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 network�s 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 cracking�The 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 computation�This method uses a particular character set such as A�Z, or A�Zplus 0�9 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.



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.

The following are password attack mitigation techniques:

Do not allow users to have the same password on multiple systems�Most 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 logins�This helps to prevent continuous password attempts.

Do not use plain text passwords�Use of either an OTP or encrypted password is recommended.

Use �strong� passwords�Many 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.



Man-in-the-Middle Attacks

� 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

Host A Host B

Router A Router B

Data in clear text

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.



Man-in-the-Middle Mitigation

Man-in-the-middle attacks can be effectively mitigated only through the use of cryptography (encryption).

Host A Host B

Router A ISP Router B

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

IPSec tunnel

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.



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

7 Application6 Presentation5 Session4 Transport3 Network2 Deata link1 Physical

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 organization�s 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,


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



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.

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 analyzed�It is important to review all logs and take action accordingly.

Subscribe to mailing lists that publicize vulnerabilities�Most application and operating system vulnerabilities are published on the Web at various sources.

Keep your operating system and applications current with the latest patches�Always 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 attacks�The 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.



Network Reconnaissance

Network reconnaissance refers to the overall act of learning information about a target network by using publicly available information and applications.

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) queries�Reveals such information as who owns a particular domain and what addresses have been assigned to that domain.

Ping sweeps�Presents a picture of the live hosts in a particular environment.

Port scans�Cycles through all well known ports to provide a complete list of all services running on the hosts.



Network Reconnaissance Example

Sample IP address query

Sample domain name query

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.



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.

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.



Trust Exploitation

� A hacker leverages existing trust relationships

� Several trust models exist� Windows

� Domains� Active

directory� Linux and

UNIX� NFS� NIS+

SystemAUser = psmith; Pat Smith

SystemB � Compromised by hackerUser = psmith; Pat Smith

HackerUser = psmith; Pat Smithson

SystemA Trusts SystemB

SystemB Trusts Everyone

SystemA Trusts Everyone

Hackergains

access to SystemA

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.



Trust Exploitation Mitigation

� 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.

SystemAUser = psmith; Pat Smith

SystemB Compromised

by a hackerUser = psmith; Pat

Smith

HackerUser = psmith; Pat Smithson

Hackerblocked

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.



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.

Host B

Attacker

Source: ADestination: BPort: 23

CompromisedHost A

Source: AttackerDestination: APort: 22

Source: AttackerDestination: BPort: 23

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.



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

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 hacker�s 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.



Virus and Trojan Horses

� Viruses refer to malicious software that are attached to another program to execute a particular unwanted function on a user�s 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.

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 user�s 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 user�s workstation. While the user is occupied with the game, the Trojan horse mails a copy of itself to every user in the user�s 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.



MAC D

Port 3

CAM Table Overflow

� 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 traffic�essentially acting like a hub.

MAC A

MAC BA C?

A C?

A C?

Port 2

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

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 switch�s CAM table fills up with the randomly generated MAC addresses, the switch begins to forward all frames it receives to every port.



A C?

MAC D

CAM Table Overflow Attack Mitigation

The CAM table flood attack can be mitigated by configuring port security on the switch.

MAC A

MAC BA C?

Port 2

Port 3Specify the allowed MAC addresses

A C?

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 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.



The frame is forwarded out all ports with the

inner 802.1q tag

The frame is forwarded out all ports with inner

802.1q tag

VLAN Hopping

There are two types of VLAN hopping attacks:� Double Tagging� Switch Spoofing

The first switch strips the first header

2

The frame is encapsulated with

two 802.1q headers

Double encapsulation

example

1

There are three common forms of VLAN hopping attacks:

Switch Spoofing�In 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 Tagging�Another 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.



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

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.



MAC Spoofing Attack

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.

Destination MAC: AC

A

ARP (A)B3

2

1

CA,B

1 2 3Switch Port

Host Destination MAC: A

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 victim�s 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 A�s IP address but host B�s 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 A�s MAC address.



The associate MAC address to a specific port

MAC Spoofing Attack Mitigation

Using the port security commands on the switch mitigates MAC spoofing attacks.

Destination MAC: AC

A

ARP (A)B3

2

1

CBA

1 2 3Switch port

Host Destination MAC: A

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.



ARP Spoofing Attack

� An attacker attaches his MAC address to another station�s IP address

� The hold-down timers can mitigate this attack

A 192.168.0.1MAC A

B2

1

192.168.0.1MAC B

192.168.0.2MAC B

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 station�s 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.



Private VLAN Attacks

� It is possible to attack PVLANs in an attempt to circumvent their traffic isolation capabilities. One example is the following:� Proxy attacks�Uses 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.

SRC: A1 DST: C2

AttackerMAC: A

IP: 1

ARP (A)

SRC: A1 DST: B2

TargetMAC: B

IP: 2

RouterMAC: C

IP: 3

SRC: A1 DST: C2

SRC: A1 DST: B2

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 bi-directional 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 router�s 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.



Other Layer 2 Attacks

� Spanning Tree Protocol Manipulation�By attacking the Spanning-Tree Protocol, the network attacker hopes to spoof his or her system as the root bridge in the topology.

� CDP attacks�The 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 Starvation�A 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.

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 attacker�s 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 attacker�s 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


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 client-originated DHCP packets to a DHCP server. The server can use this information to implement IP address or other parameter-assignment policies.


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.

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.



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.

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.



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.

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 read-write 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.



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.

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.



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.

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.



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.

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.



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.

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.


SummaryThis 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.



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



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


Copyright 2003, Cisco Systems, Inc. Security Fundamentals Lab 2-1

Lab Exercise�Vulnerabilities and Threats Complete the following lab exercise to practice what you learned in this chapter.

ObjectivesIn 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.

Lab 2-2 Cisco SAFE Implementation 1.1 Copyright 2003, Cisco Systems, Inc.

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


.100

e0/1

PSS,WWW,

and FTP172.16.P.0/24


e0/0

10.0.P.0 /24

Pod P (1�10)

192.168.P.0/24

.1 e2

pP

.4

public

cP

.1

172.30.P.0/24

sensorP

DMZ

.2

.150

Super server,WWW, and FTP

.10

.150

.5

private

.5

.2 e0172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

rP

RTS

RBB

VPN Client

brP

Branch

10.2.P.0/24

.10P e0/1

.50

.1 e0/010.2.P.11

172.26.26.P

Branch

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

Student

Task 1�Port 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)

Copyright 2003, Cisco Systems, Inc. Security Fundamentals Lab 2-3

Task 2�Scan 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 3�Analyze 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.


3

Architectural Overview

OverviewThis 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

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.

Copyright 2003, Cisco Systems, Inc. Architectural Overview 3-3

SAFE Architectural Overview SAFE emulates as closely as possible the functional requirements of today�s 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-in-depth approach focusing on the expected threats and their mitigation (failure of one system is not likely to compromise network resources)

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.



Key Components of a SAFE Network

Authentication,digital certificates

ACLs, Firewalls VPN Tunneling,encryption

Intrusion detection,scanning

Policy management,device management

IdentityPerimeter security

Secure connectivity

Security monitoring

Security management

Internet

The key components of a SAFE network are fundamental to the success of an implementation. These key components are broken down as follows:

Identity�Authentication and digital certificates

Perimeter security�Access Control Lists (ACLs) and firewalls

Secure connectivity�VPN tunneling and encryption

Security monitoring�Intrusion detection and scanning

Security management�Policy 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.



SAFE SMR Principles

� SAFE SMR uses the same principles as SAFE Enterprise only scaled for smaller networks.

� SAFE SMR is based on threat mitigation that is independent of specific devices used.

SPedge

Medium network/branch campus

Medium network/branch edge

Corporate Internet module

WAN module

PSTN module

Frame or ATM

module

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

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.



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 edgeMedium network and

branch campusMedium network/branch edge


WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

SAFE SMR makes the following assumptions:

The security policy is already in place�Cisco does not recommend deploying security technologies without an associated policy.

SAFE does not guarantee a secure environment�Following 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 covered�Proper 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.


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.

SAFE SMR uses the following objectives, which are based on the SAFE SMR Blueprint:

Security and attack mitigation is based on policy�A 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 infrastructure�It 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-effective�At 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 secure�Cisco 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


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 authorized�It�s 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 subnets�Deployment of intrusion detection is necessary to mitigate many of the expected threats discussed in this course.



InternetRouter

Wireless threat

Internal IPThreat

Critical resources

Critical resources

First line of defense

Second line of defense

SAFE�A 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-inthreat

IDS Sensors

HIDS on PCs

HIDS

Personal firewall

WAN

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.



SAFE SMR Resiliency

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

SAFE Enterprise with resiliency example

Remote access VPN

PSTN

Traditional dial access servers

Site-to-Site VPN

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.



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

Softwareaccess option

ISP edge module

VPNSoftware

Client with

personal firewall

SAFE SMR integrated functionality example

ISP

Authenticate remote site,

terminate IPSec, and personal

firewall and virus scanning for local attack mitigation

The advantages to integrated functionality are as follows:

Can be implemented on existing equipment�Many devices such as routers and firewalls can provide multiple functions including routing and packet filtering.

Better interoperability�A router running the IOS Firewall function is less likely to introduce problems into the network than two separate devices.

Can reduce overall cost�It 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 functionality�A standalone appliance can provide functionality that is not available in an integrated product.

Increased performance when required�A 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.



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.

Medium network modules


WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

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.


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


A Target-Rich EnvironmentSAFE SMR is based on the following axioms:� Routers are targets�Routers control access from every

network to every network. � Switches are targets�Like routers, switches (both Layer 2 and

Layer 3) have their own set of security considerations. � Hosts are targets�Host are the most likely target during an

attack.� Networks are targets�Network attacks are among the most

difficult attacks to deal with. � Applications are targets�Applications are coded by human

beings (mostly) and, as such, are subject to numerous errors and vulnerabilities.

� IDSs�IDSs act as alarm system in the physical world.� Secure management and reporting�If you are going to log it,

read it.

The following are axioms for when identifying appliances and applications that are primary network targets:

Routers are targets�Router security is a critical element in any security deployment.

Switches are targets�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 risks associated with routers are applicable to switches as well.

Hosts are targets�A 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 targets�The attacks on networks are most difficult because, typically, they take advantage of an intrinsic characteristic in the way your network operates.

Applications are targets�Attacks on applications can be benign or malignant. It is the malignant attacks that require the most attention.


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 reporting�Logging 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.




WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

Routers Are TargetsRouter security is a critical element in any security deployment:� Routers advertise

networks and filter who can use them.

� Routers are potentially a hacker�s best friend.

� Routers provide access and, therefore, you should secure them to reduce the likelihood that they can be directly compromised.

Routers are targets


Routers control access from network to network. They advertise networks and filter that can use them, and they are potentially a hacker�s 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.

http://www.cisco.com/warp/public/707/21.html




WAN module

Publicservices

Routers Are Targets�General Guidelines

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.

The following guidelines should be followed when securing routers:

Lock down Telnet access to a router�Interactive 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 router�SNMP 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; read-write 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


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 services�As 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 levels�It is necessary to log information on the router (for example, access logs, faults, and warnings).

Authenticate routing updates�If 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.




WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

Switches Are Targets

Most of the security concerns detailed in the �Routers Are Targets� section also apply to switches.

Switches are targets


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.




WAN module

Publicservices

Switches Are Targets�General Guidelines

The following are general guidelines:� 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).

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 off�This 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 switch�This 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 switch�This 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 subnets�The capability for human error, combined with the understanding that VLANs and VLAN-tagging 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.




WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

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.

Hosts are targets


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.

http://www.whitehouse.gov




WAN module

Publicservices

Hosts Are Targets�General Guidelines

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.

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 system�These components include hardware and software.

Keep any systems up-to-date with the latest patches, fixes, and so on�Because patches and fixes are being created constantly for software and hardware. It is a good rule to practice according to your organization�s change management policy on affected hosts.

Pay attention to how these patches affect the operation of other system components�Read release notes and updates on all changes prior to implementation.

Evaluate all updates on test systems before you implement them in a production environment�This 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.




WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

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

Networks are targets


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 attacks�Identifies the MAC layer address for further attack.

Sniffers�A 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) attacks�Causes 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.




WAN module

Publicservices

Networks Are Targets�General Guidelines

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.

One approach to limiting a network attack is to follow filtering guidelines for networks outlined in RFC 1918 and RFC 2827:

RFC 1918�This 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 2827�This 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 ISP�s 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.


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.




WAN module

Publicservices

Applications Are Targets�General Guidelines

The following are general guidelines:� Ensure that commercial and

public domain applications are up-to-date with the latest security fixes.

� Complete code review on applications and custom-developed applications to ensure that the applications are not introducing any security risks caused by poor programming.

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 organization�s change management policies, and test in a non-production environment prior to implementation.

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




WAN module

PSTN module

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

PSTN

Internet

FR/ATM

ISP edgemodule

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

NIDS HIDS


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 systems�HIDS on critical hosts and NIDS looking over the whole network�for 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.




WAN module

Publicservices

IDSs�General Guidelines

The following are general guidelines:� 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.

The following guidelines can aid an administrator in preventing attacks and unnecessary work:

Tune the implementation to decrease false positives�False 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 short�Keeping 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 shunning�TCP 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 monitoring�IT staff are often overworked (particularly in smaller organizations).

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



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.

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


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.



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.

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.


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.




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.

4

The Cisco Security Portfolio

OverviewThis chapter introduces and gives an overview of a Cisco security portfolio. It includes the following topics:

Objectives

Cisco security portfolio overview

Secure connectivity�Virtual Private Network solutions

Secure connectivity�The 3000 Concentrator series

Secure connectivity�Cisco VPN-optimized routers

Perimeter security firewalls�Cisco PIX Firewall and Cisco IOS Firewall

Intrusion protection�IDS

Identity�Access control solutions

Security management�VMS and CSPM

Cisco AVVID

Summary




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.

Copyright 2003, Cisco Systems, Inc. The Cisco Security Portfolio 4-3

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.


Identity Secure

connectivityPerimetersecurity

Intrusionprotection

Security management

Cisco Security Solutions

FirewallsVPNCisco VPN Concentrators

Cisco PIX Firewalls

Intrusion detectionscanning Authentication Policy

Cisco IOS VPN

Cisco IOS IDS

Cisco IOS Firewall

Cisco PIX Firewalls

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

Cisco PIX Firewalls

Cisco Access Control Server

CiscoWorks�VPN and security management solution

Cisco Secure Policy Manager

Cisco offers a wide variety of security solutions:

Secure connectivity�Virtual private network (VPN)

� Cisco VPN Concentrators

� Cisco PIX Firewalls

� Cisco IOS VPN

Perimeter security�Firewalls

� PIX Firewalls

� Cisco IOS Firewalls

Intrusion protection�Intrusion detection scanning

� Cisco Network-based Intrusion Detection System (NIDS) Sensor


� Cisco IOS-based intrusion detection

� Cisco Intrusion Detection System Module (IDSM)

� PIX Firewall-based intrusion detection

Identity�Authentication�Cisco Secure Access Control Server (ACS)

Security management�Policy

� CiscoWorks2000 VPN/Security Management Solution (VMS)

� Cisco Secure Policy Manager (CSPM)

Cisco offers a wide variety of value-added benefits:

Breadth of solutions�Cisco offers the widest range of security and VPN products available in the market today. These products span multiple technology categories�including firewalls, intrusion detection systems, Concentrators, and routers�and 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 recognition�The 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 support�Cisco 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, full-time 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 interoperability�Instead 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 integration�Cisco 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.


Management prowess�Cisco provides a reliable, available, and proven foundation for managing your networks efficiently and cost effectively.



SAFE Blueprint and Ecosystem

Solutions

Ecosystem$$

Cisco programs and services

Security Associate solutions

Integration partners

Applications

Directory

Operations Service control

Infrastructure

Appliances or clients

Cisco AVVID system

architecture

Securee-commerce

Secure supply chainmanagement

Secure intranet forworkforce optimization

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.


Secure Connectivity�Virtual 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

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

� Reduces transport costs


� Enables fast broadband telecommuters and remote site connectivity



Overview�VPNs

Main office

VPN

Business partner

Remote office

Home office

Mobile worker

POP

POP

Remote access VPN�Cost saving

Extranet VPN�Extends WANs to business partners, which leads to new

applications and business models

Intranet VPN�Low cost, tunneled

connections with rich VPN services, which lead to cost savings and new

applications

VPN solutions are provided for the following types of implementation:

Intranet VPN�Links 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 VPN�Links 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 VPN�Connects telecommuters and mobile users securely and cost-effectively 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 provider�s network, it must be encrypted to ensure privacy and security.



VPN Solutions�Choices

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

3015, 3005 Concentrator

3600, 2600, 1700 series routers


SOHO market VPN 3000 Client 3002 Hardware Client

SOHO, 800, 900 series routers


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.


Secure Connectivity�The 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 tunneling�corporate and Internet� Implements behind the Internet access router and is

parallel to the PIX Firewall

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 tunneling�corporate 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


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



Models

3005 3015 3030 3060 3080Simultaneous users 100 100 1500 5000 10,000Performance (Mbps) 4 4 50 100 100Encrytpion cards 0 0 1 2 4Memory (Mb) 64 128 128 256 256Upgradable No Yes Yes Yes N/ADual power supply No Optional Optional Optional YesRedundancy No Yes Yes Yes YesSite-to-site tunnels 100 100 500 1,000 1,000

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.



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

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.



Cisco VPN 3002 Hardware VPN Client

� Easy deployment� Centralized policy push � Two 10/100, and 8-port hub version� DHCP client and server� PAT (external and tunnel)� Client and network extension modes

Cisco VPN Client3002

Cable modem

3002

DSL modem

3002

Single user

Home office

Small office

InternetCisco VPN 30xx

ISDN modem

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.



Aironet client

Aironet clientCisco VPN 3000 Client

MobileCerticom

client

Main officeCisco VPN 30xx

Remote Access Wireless VPN

Internet

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.


Secure Connectivity�Cisco 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

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 company�s 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

� 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



Site-to-Site VPN Scalability and Features Summary

� Scalability� Network resiliency� Bandwidth optimization and QoS� Deployment flexibility

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:

Scalability�Up to 140 Mbps of 3DES throughput and 3000 tunnels

Network resiliency

� Dynamic Route Recovery�Using routing protocols through IPSec-secured GRE tunnels

� Dynamic Tunnel Recovery�Using IPSec (IKE) keepalives

Bandwidth optimization and QoS

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

� Ensures quality of latency-sensitive traffic

Deployment flexibility

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


� Use as standalone VPN device or integrated multi-function device



Cisco Site-to-Site VPN Solutions�Scalability for Every Site

Main office

Small office/home office

Remoteoffice

Regionaloffice

Cisco 1700 Series� VPN-optimized

router connecting remote offices at T1/E1 speeds

Cisco SOHO, 800 and 900 Series� VPN-optimized routers for

ISDN, DSL, and cable connectivity

Cisco 2600 and 3600 Series� VPN-optimized routers

connecting branch and regional offices at nxT1/E1 speeds

Cisco 7000 Series� VPN-optimized routers for

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

Internet

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 office�Cisco 1700 Series, which is a VPN-optimized router connecting remote offices at T1/E1 speeds

Regional office�Cisco 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 Office�Cisco 7000 Series, dedicated VPN head-end and hybrid private WAN and VPN connectivity



VAM�For Cisco 7100,7200 and 7400 Series Routers

Hardware acceleration for � IPsec encryption�Up to 145 Mbps of VPN

performance and 5000 tunnels� RSA�Faster tunnel-recovery key generation

and authentication� IPPCP LZS compression

The VPN Acceleration Module (VAM) is a single-width acceleration module. It provides high-performance, 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 deployments�security, QoS, firewall and intrusion detection, service-level validation, and management. The VAM off-loads IPSec processing from the main processor, thus freeing resources on the processor engines for other tasks.


Perimeter Security Firewalls�Cisco PIX Firewall and Cisco IOS Firewall

This section describes the Cisco perimeter security solutions.


Perimeter Security�PIX 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 company�s Intranet

� Determines whether traffic crossing in either direction is authorized

� Little or no impact on network performance

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 partner�s 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


Restricts access to network resources

Implemented at the physical perimeter between customer intranet and the other company�s intranet

Determines whether traffic crossing in either direction is authorized

Little or no impact on network performance



SMB

Pric

e

Functionality

Gigabit Ethernet

PIX Firewall Family

EnterpriseROBO

PIX 515E-UR

PIX 525-UR

PIX 535-UR

SOHO

PIX 501

PIX 506E

SP

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.



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)

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 deployments�encryption, 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 tasks�hashing, key exchange, and storage of security associations�that free the PIX Firewall main processor and memory to perform other perimeter security functions. The following are features of the VAC:

Encryption�DES 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.

Authentication�Rivest, 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.


Tunneling�The 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.



Perimeter Security�IOS 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

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 today�s 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 solutions�such as authentication, encryption, and failover�by delivering state-of-the-art 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.



User

The user Initiates an IP session.

The return traffic for the user�s IP session is permitted.

IOS Firewall using CBAC

The other IP traffic is blocked.

IOS Firewall�CBAC

The following are the CBAC features:� Stateful inspection� A state table maintains

session state information

� ACL entries are dynamically created and deleted

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 firewall�s 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


Real-time alerts and audit trails


Intrusion Protection�IDSThis section provides an overview and product information for the Cisco Intrusion Detection System (IDS).


Overview�Intrusion Detection Deployment Scenarios

NASDMZ

servers

Datacenter

Users

Corporate office

Business partner

Internet

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

Intranet and Internal IDS�Protects data centers and critical assets from internal threats

Remote access IDS�Hardens perimeter control by monitoring remote users

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

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 IDS�IDS deployment to an extended network

Internet IDS�IDS deployment to a public network

Intranet and internal IDS�IDS deployment to an internal network

Remote access IDS�IDS deployment to a remote-access network



Cisco IDS Solutions�Multiple Platform Integration

� Network Sensors�Overlays network protection

� Switch Sensor�Provides integrated switch protection

� Router Sensor�Provides integrated router protection

� Firewall Sensor�Provides integrated firewall protection

� Comprehensive management�Provides robust system management and monitoring

Cisco IDS solutions include the following:

NIDS�The complete line of market-leading Cisco IDS 4200 Series appliances deliver performance-optimized intrusion protection within an integrated, turnkey solution.

IDSM�The 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 IDS�Cisco IOS Routers deliver integrated intrusion protection along with feature-rich networking services.

Firewall IDS�Integration of IDS functionality into the Cisco PIX 500 Series Firewalls provide protection from a variety of common network-based attacks.

Comprehensive management�Cisco offers a broad set of comprehensive, enterprise-class security management and monitoring options for Cisco IDS, which meets any deployment scale and requirements.



Cisco IDSs provide the following:

Real-time security monitoring�Involves packet capture and analysis.

Most effective attack recognition, which is signature-based�When 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 shunning�The 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 device�s ACLs. This type of automated response by the Sensor should only be configured for attack signatures with a low probability of false-positive detection, such as an unambiguous SATAN attack.

Scalability and remotely manageable�The Cisco IDS solutions provide a robust solution that is scalable to even the largest enterprise networks.

High performance�Depending on the needs of a network, the Cisco IDS portfolio is designed provide above-industry standard performance for each platform, whether it be host-based or network-based.

Low cost of operation�Delivering the lowest cost-of-ownership with network-integrated and hardware-based solutions, Cisco reduces the cost of advanced intrusion protection.

Ease of installation and use�Because of the management platforms and menu-based configuration tools, the Cisco IDS is easily configured and maintained.



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 performance-optimized intrusion protection within an integrated, turn-key solution.



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 sensing�real-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 switch�s 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.


Identity�Access Control Solutions This section describes the available Cisco access control solutions.


Cisco Secure ACS�Features

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

11 22 3344 55 6677

009988

369

147

25

08

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


Restrictions such as time of day and day of week

User and device group profiles



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



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+


Security Management�VMS and CSPM This section describes the Cisco security management solutions.


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.



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-by-device basis. CSPM also provides basic system auditing functions, including real-time alarm notification and a Web-based reporting system.



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


Cisco AVVIDThis section discusses Cisco Architecture for Voice, Video, and Integrated Data (AVVID).


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 today�s Internet business solutions. As the industry�s only enterprise-wide, standards-based network architecture, Cisco AVVID provides the roadmap for combining customers� business and technology strategies into one cohesive model.



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



With Cisco AVVID, customers have a comprehensive roadmap for enabling Internet business solutions and creating a competitive advantage. There are four Cisco AVVID benefits:

Integration�By leveraging the Cisco AVVID architecture and applying the network intelligence inherent in IP, companies can develop comprehensive tools to improve productivity.

Intelligence�Traffic prioritization and intelligent networking services maximize network efficiency for optimized application performance.

Innovation�Customers have the ability to adapt quickly in a changing business environment.

Interoperability�Standards-based APIs enable open-integration with third-party developers, providing customers with choice and flexibility.



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.




5

SAFE Small Network Design

OverviewThe following are the sections covered in this chapter.

Objectives

Small network design overview

Small network corporate Internet module

Small network campus module

Implementation�ISP router

Implementation�IOS Firewall features and configuration

Implementation�PIX Firewall

Summary

Lab exercise




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.

Copyright 2003, Cisco Systems, Inc. SAFE Small Network Design 5-3

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

Campus module

Corporateservers

Corporateusers

SP edgeSmall network

or branch campus

ManagementServer

Small network or branch edge

Publicservices


Firewall

Isolated service networkISP

The small network design has two modules:

Corporate Internet Module�Has 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 Module�Contains 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.)


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

Publicservices

To campus

One or the other

ISP

Layer 2 switch

ServersIOS Firewall or PIX Firewall

IOS Firewall or PIX Firewall

ISP router

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 server�Acts as a relay between the Internet and the intranet mail servers.

DNS server�Serves as authoritative external DNS server for the small network. It relays internal requests to the Internet.

FTP or HTTP server�Provides public information about the organization.

Firewall or IOS Firewall router�Provides 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 Provides host-level intrusion detection.



Expected Threats and Mitigation Roles

The following threats can be expected:� Unauthorized access�Mitigated through filtering at the

firewall � Application layer attacks�Mitigated through HIDSs on

the public servers � Virus and Trojan horse attacks�Mitigated through virus

scanning at the host level � Password attacks�Limited services available to brute

force (operating systems and IDSs can detect the threat)� DoS�Use CAR at the ISP edge and the TCP setup

controls at the firewall to limit exposure

There are publicly addressable servers that are the most likely points of attacks. The following are expected threats to those publicly addressable servers:

Unauthorized access�Mitigated through filtering at the firewall

Application layer attacks�Mitigated through Host-based Intrusion Detection Systems (HIDSs) on the public servers

Virus and Trojan horse attacks�Mitigated through virus scanning at the host level

Password attacks�Limited 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.



Expected Threats and Mitigation Roles (cont.)

� IP spoofing�RFC 2827 and 1918 filtering at the ISP edge router and at the firewall in the corporate Internet module

� Packet sniffers�Switched infrastructure and an HIDS to limit exposure

� Network reconnaissance�An HIDS detects recon, and protocols are filtered to limit effectiveness

� Trust exploitation�Restrictive trust model and private VLANs to limit trust-based attacks

� Port redirection�Restrictive filtering and an HIDS to limit attacks

IP spoofing�RFC 2827 and 1918 filtering at the ISP edge and local firewall

Packet sniffers�Switched infrastructure and an HIDS to limit exposure

Network reconnaissance�HIDS detects recon; protocols filtered to limit exposure

Trust exploitation�Restrictive trust model and private VLANs to limit trust-based attacks

Port redirection�Restrictive 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.



Publicservices

To campus

One or the other

ISP

Small Network Attack Mitigation Roles for the Corporate Internet Module

Stateful packet filtering, basic layer 7 filtering, host DoS

mitigation, and spoof mitigation

Stateful packet filtering, basic layer 7 filtering, host DoS

mitigation, and spoof mitigation

Spoof mitigation and rate-limiting

Private VLANs

HIDS local attack mitigation

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

� HIDS local attack


� Mitigation

At the ingress of the firewall, RFC 1918 and RFC 2827 filtering are provided as a verification of the ISP�s 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 hacker�s 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.



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)

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 functionality�This 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 today�s networks.

Use a dedicated firewall instead of the router�This setup places some restrictions on the deployment. First, firewalls are generally Ethernet-only, requiring some conversion to the appropriate WAN protocol. In today�s 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


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


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

To the corporate

Internet module

Layer 2 switch

Corporate servers

Management host

User workstations

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 servers�Provides e-mail (SMTP and POP3) services to internal users, as well as delivering file, print, and DNS services to workstations

User workstations�Provides data services to authorized users on the network

Management host�Provides HIDS, Syslog, Terminal Access Control System Plus (TACACS+) or Remote Access Dial-In User Service (RADIUS), and general configuration management




You can expect the following threats: � Packet sniffers� Virus and Trojan horse

applications � Unauthorized access � Application layer attacks � Trust exploitation � Port redirection

Corporateservers

CorporateusersManagement

server

To corporate Internet module

HIDS local attack

mitigation

Private VLANs

Host virus scanning HIDS local

attack mitigation

The following are expected threats and mitigation of those threats to the SAFE SMR Small Network Campus Module:

Packet sniffers�A switched infrastructure limits the effectiveness of sniffing

Virus and Trojan horse applications�Host-based virus scanning prevents most viruses and many Trojan horses

Unauthorized access�This type of access is mitigated through the use of host-based intrusion detection and application access control

Application layer attacks�Operating systems, devices, and applications are kept up-to-date with the latest security fixes, and they are protected by an HIDS

Trust exploitation�Private VLANs prevent hosts on the same subnet from communicating unless necessary

Port redirection�An 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


Host virus scanning




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.

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.


Implementation�ISP Router The following section details the implementation of the ISP router.


ISP Router�Implementation Commands

The following are necessary mitigation roles and implementation commands:� Spoof mitigation and RFC filtering

� access-list� access-group

� Rate-limiting� rate-limit

CorporateUsers

ManagementServer

PublicServices

Firewall

ISP

Spoof mitigation rate-limiting

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.



Implementation Commands�Spoof Mitigation and RFC Filtering

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

router(config)#

®±«¬»®ø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

router(config-if)#

®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»ó¹®±«° ïðï ·²

¿½½»ó´·¬ ¿½½»ó´·¬ó²«³¾»® Å¼§²¿³·½ ¼§²¿³·½ó²¿³»Å¬·³»±«¬ ³·²«¬»ÃÃ ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ ±«®½» ±«®½»ó©·´¼½¿®¼ ¼»¬·²¿¬·±² ¼»¬·²¿¬·±²ó©·´¼½¿®¼ Å°®»½»¼»²½» °®»½»¼»²½»Ã Å¬± ¬±Ã Å´±¹ ¤ ´±¹ó·²°«¬Ã Å¬·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã

·° ¿½½»ó¹®±«° ¥¿½½»ó´·¬ó²«³¾»® ¤ ¿½½»ó´·¬ó²¿³»£¥·² ¤ ±«¬£

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 routers�routers 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.


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 source-

wildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-

range-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 lock-and-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 source-wildcard 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.



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}


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.


Implementation�IOS Firewall Features and Configuration

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


Public services

To campus

ISP

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

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


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 hacker�s 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.



Cisco IOS Firewall�Implementation Commands

The following are necessary mitigation roles and implementation commands for the IOS Firewall:� Stateful packet filtering�Part of CBAC on Cisco IOS Routers� Spoof mitigation and RFC filtering


� 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

The following are necessary mitigation roles and implementation commands for the IOS Firewall:

Stateful packet filtering�Part of Context-Based Access Control (CBAC) on Cisco IOS Routers

Spoof mitigation and RFC filtering

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

� access-group�Binds an ACL to an interface.

Host DoS mitigation and basic layer 7 filtering

� ip inspect�Defines the application protocols to inspect.

Authenticate remote site (and logging)

� aaa new-model�Enter this command for each protocol that you want to inspect, using the same inspection-name, to define a set of inspection rules.

� tacacs-server�Defines the TACACS server.

� aaa authentication login�Enables authentication, authorization, and accounting (AAA) authentication at login.


� aaa authorization exec�Restricts network access to a user.

� aaa accounting exec�Runs accounting for EXEC shell session.

� login authentication�Specifies the name of a list of AAA authentication methods to try at login.



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

IPSec commands

� crypto isakmp policy�Specifies the parameters to be used during an IKE negotiation.

� encryption�Sets the algorithm to be negotiated.

� authentication�Specifies the authentication method within an IKE policy.

� group�Specifies the Diffie-Hellman (DH) group identifier within an Internet Key Exchange policy.

� crypto isakmp key�Configures pre-shared authentication keys.

� crypto ipsec transform-set�An acceptable combination of security protocols, algorithms and other settings to apply to IP Security protected traffic.

� crypto map�Configures filtering and classifying traffic to be protected and defines the policy to be applied to that traffic.

� set peer�Specifies an IPSec peer for a crypto map.

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

� match address�Specifies an extended access list for a crypto map entry.



Spoof Mitigation and RFC Filtering�ACLs


router(config)#



router(config-if)#

®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»ó¹®±«° ïðï ·²

¿½½»ó´·¬ ¿½½»ó´·¬ó²«³¾»® Å¼§²¿³·½ ¼§²¿³·½ó²¿³»Å¬·³»±«¬ ³·²«¬»ÃÃ ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ ±«®½» ±«®½»ó©·´¼½¿®¼ ¼»¬·²¿¬·±² ¼»¬·²¿¬·±²ó©·´¼½¿®¼ Å°®»½»¼»²½» °®»½»¼»²½»Ã Å¬± ¬±Ã Å´±¹ ¤ ´±¹ó·²°«¬Ã Å¬·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã

·° ¿½½»ó¹®±«° ¥¿½½»ó´·¬ó²«³¾»® ¤ ¿½½»ó´·¬ó²¿³»£¥·² ¤ ±«¬£

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.



wildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-range-name]






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.








Use a 32-bit quantity in four-part, dotted-decimal format. Place1s in the bit positions you want to ignore.












¿½½»ó´·¬ ïðï °»®³·¬ ïçîòïêèòðòð ðòîëëòîëëòîëë ¿²§

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§

ISPnetwork

Customernetwork:

192.168.0.0/16

Spoof Mitigation Example�RFC 2827 Filtering

� Egress packets cannot be from and to customers

� Ensure that ingress packets are valid

� Ingress packets must be from customer addresses

·²¬»®º¿½» Û¬¸»®²»¬ »ðñï

·° ¿½½»ó¹®±«° ïîð ·²

·° ¿½½»ó¹®±«° ïíð ±«¬

ÿ

¿½½»ó´·¬ ïîð ¼»²§ ·° ïçîòïêèòðòð ðòðòîëëòîëë ¿²§

¿½½»ó´·¬ ïîð °»®³·¬ ·° ¿²§ ¿²§

ÿ

¿½½»ó´·¬ ïíð °»®³·¬ ïçîòïêèòðòð ðòðòîëëòîëë ¿²§

¿½½»ó´·¬ ïíð ¼»²§ ·° ¿²§ ¿²§

Egress from Internet

Ingress to Internet

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.



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:� Alarm�Sends an alarm to a Cisco IDS Director or Syslog server� Drop�Drops the packet� Reset�Sends TCP resets to terminate the session

� Detects, reports, and acts upon many common attacks

TCP

UDP

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 organization�s security policy, network security risk and vulnerability, level of performance requirements at the site, and network segmentation, network media or interface, and routing requirements.



Implementation Commands�IOS Firewall Intrusion Detection

router #

®±«¬»®ý ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²¿³» ¿«¼·¬ó²¿³» ¥·²º± ¤ ¿¬¬¿½µ£ Å´·¬ ¬¿²¼¿®¼ó¿½´Ã Å¿½¬·±² Å¿´¿®³Ã Å¼®±°Ã Å®»»¬ÃÃ

� Creates audit rules for info and attack signature types

®±«¬»®ý ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

router # ·° ¿«¼·¬ ¿¬¬¿½µ ¥¿½¬·±² Å¿´¿®³Ã Å¼®±°Ã Å®»»¬Ã

� Specifies the default actions for attack signatures

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]}


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.



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

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 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.



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

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.



DoS Mitigation�General 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.

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.



·° ·²°»½¬ ²¿³» ·²°»½¬·±²ó²¿³» °®±¬±½±´ Å¿´»®¬¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Å¬·³»±«¬ »½±²¼Ã

Basic Layer 7 Filtering�Inspection Rules for Application Protocols

� 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

Router(config)#

Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ ³¬° ¿´»®¬ ±² ¿«¼·¬ó¬®¿·´ ±² ¬·³»±«¬ íðð

Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ º¬° ¿´»®¬ ±² ¿«¼·¬ó¬®¿·´ ±² ¬·³»±«¬ íðð

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]

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.


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.



·° ·²°»½¬ ·²°»½¬·±²ó²¿³» ¥·² ¤ ±«¬£

Apply an Inspection Rule to an Interface

� Applies the named inspection rule to an interface

Router(config-if)#

Î±«¬»®ø½±²º·¹÷ý ·²¬»®º¿½» »ðñðÎ±«¬»®ø½±²º·¹ó·º÷ý ·° ·²°»½¬ ÚÉÎËÔÛ ·²

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

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.


ip inspect inspection-name {in | out}

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.



Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ ¸¬¬° ¶¿ª¿ó´·¬ ïð ¿´»®¬ ±² ¿«¼·¬ó¬®¿·´ ±² ¬·³»±«¬ íðð

Î±«¬»®ø½±²º·¹÷ý ·° ¿½½»ó´·¬ ïð ¼»²§ ïéîòîêòîêòð ðòðòðòîëë

Î±«¬»®ø½±²º·¹÷ý ·° ¿½½»ó´·¬ ïð °»®³·¬ ïéîòîéòîéòð ðòðòðòîëë

Example Inspection Rule for Java

·° ·²°»½¬ ²¿³» ·²°»½¬·±²ó²¿³» ¸¬¬° ¶¿ª¿ó´·¬ ¿½´ó²«³ Å¿´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Å¬·³»±«¬ »½±²¼Ã

Router(config)#

� Controls java blocking with a standard ACL

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.


ip inspect name inspection-name http [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [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.

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.







Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ ®°½ °®±¹®¿³ó²«³¾»® ïðððîî ©¿·¬ó¬·³» ð ¿´»®¬ ±ºº ¿«¼·¬ó¬®¿·´ ±²

Example Inspection Rule for RPC Applications

·° ·²°»½¬ ²¿³» ·²°»½¬·±²ó²¿³» ®°½°®±¹®¿³ó²«³¾»® ²«³¾»® Å©¿·¬ó¬·³» ³·²«¬»ÃÅ¿´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Å¬·³»±«¬ »½±²¼Ã

Router(config)#

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

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.


ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail

{on | off}] [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.

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.







Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ ³¬°

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

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.



protocol A protocol keyword.






Î±«¬»®ø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ÚÉÎËÔÛ º®¿¹³»²¬ ³¿¨ îëì ¬·³»±«¬ ì

Example Inspection Rule for IP Packet Fragmentation

� 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

·° ·²°»½¬ ²¿³» ·²°»½¬·±²ó²¿³» º®¿¹³»²¬ ³¿¨ ²«³¾»® ¬·³»±«¬ »½±²¼

Router(config)#

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 firewall�s fragment state resources, and legitimate, unfragmented traffic can flow through the firewall unimpeded.



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


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.




Authentication�IOS 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

The authentication proxy capability in the Cisco IOS Firewall feature set provides dynamic, per-user authentication and authorization for network users. Previously, user identity and related authorized access were determined by a user�s 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.



Implementation Commands�Authenticate Remote Site

� Enables the AAA access control model

router(config)#

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ²»©ó³±¼»´

� Specifies a TACACS+ host

router(config)#

®±«¬»®ø½±²º·¹÷ý ¬¿½¿½ó»®ª»® ¸±¬ ïçîòïêèòïòïð ·²¹´»ó½±²²»½¬·±² µ»§ ½·½±¿º»

¿¿¿ ²»©ó³±¼»´

¬¿½¿½ó»®ª»® ¸±¬ ¸±¬²¿³» Å°±®¬ ·²¬»¹»®ÃÅ¬·³»±«¬ ·²¬»¹»®Ã Åµ»§ ¬®·²¹Ã

You must configure AAA network security services using the aaa new-model, aaaauthentication, 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]

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 tacacs-server key for this server only.


string (Optional.) Character string specifying authentication and encryption key.



Implementation Commands�Authenticate Remote Site (cont.)

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

router(config)#

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¥¼»º¿«´¬ ¤ ´·¬ó²¿³»£³»¬¸±¼ï Å³»¬¸±¼îòòòÃ

¿¿¿ ¿«¬¸±®·¦¿¬·±² ¥²»¬©±®µ ¤ »¨»½ ¤ ½±³³¿²¼ ´»ª»´ ¤ ®»ª»®»ó¿½½» ¤ ½±²º·¹«®¿¬·±²£ ¥¼»º¿«´¬ ¤ ´·¬ó²¿³»£ ³»¬¸±¼ï Å³»¬¸±¼î�Ã

´±¹·² ¿«¬¸»²¬·½¿¬·±² ¥¼»º¿«´¬ ¤ ´·¬ó²¿³»£

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 Apply the method lists to a particular interface or line, if required.




� Examples of the AAA commands

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ ´±½¿´ »²¿¾´»

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½ ´·²»

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ ¬¿®¬ó¬±° ¹®±«° ¬¿½¿½õ

®±«¬»®ø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½

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.


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} {start-

stop | stop-only | wait-start | none} [broadcast] group groupname

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.


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}

default Uses the default list created with the aaa authentication logincommand.

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


Implementation�PIX 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 filtering�the

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

Publicservices

To campus

ISP

Stateful packet filtering, basic Layer 7 filtering, host DoS mitigation, spoof mitigation, authenticate

remote site, authenticate remote users, and terminate IPSec

The following mitigation roles and commands are used to implement the policy on the PIX Firewall:

Stateful packet filtering�The default for the PIX firewall.

Host DoS mitigation commands

� ip verify reverse-path interface�Implements Unicast Reverse Path Forwarding (RPF) IP spoofing protection

� icmp�Enables or disables pinging to an interface

� attack guard commands�Are enabled by default

� Static command�Used to set maximum connections and maximum embryonic connections

Spoof mitigation and RFC filtering commands

� access-list�Creates an ACL


� access-group�Binds the ACL to an interface



Cisco PIX Firewall�Implementation 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

Publicservices

To campus

ISP

Stateful packet filtering, basic Layer 7 filtering, host DoS mitigation, authenticate remote sites, and

terminate IPSec

Authenticate remote site and logging

� aaa-server�Specifies a AAA server

� aaa authentication�Enables, disables, or views LOCAL, TACACS+, or RADIUS user authentication

� logging on�Enables or disables Syslog and SNMP logging

Terminate IPSec

� sysopt connection permit-ipsec�Implicitly permits any packet that came from an IPSec tunnel

� isakmp enable�Enables Internet Security Association Key Management Protocol (ISAKMP) negotiation on the interface on which the IPSec peer communicates with the PIX Firewall

� isakmp key�Specifies the authentication pre-shared key

� isakmp policy�Uniquely identifies the Internet Key Exchange (IKE) policy and assigns a priority to the policy

� crypto ipsec transform-set�Creates, views, or deletes IPSec Security Associations (SAs), SA global lifetime values, and global transform sets


� crypto map�Creates, modifies, views, or deletes a crypto map entry



Access Through the PIX Firewall

PIX Firewall

e0 outside security level 0

Internet

e1 insidesecurity level 100

nat and global

static and access list

(static and conduit)

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 server�s 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.



Implementation Commands�Host DoS Mitigation

� 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

°·¨º·®»©¿´´ø½±²º·¹÷ý ·½³° ¼»²§ ¿²§ ±«¬·¼»


·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ·²¬Á²¿³»

·½³° °»®³·¬ ¤ ¼»²§ Å¸±¬Ã ®½Á¿¼¼® Å®½Á³¿µÃÅ¬§°»Ã ·²¬Á²¿³»

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 entity�s 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 entity�s 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.


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 access-group 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


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

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.



Implementation Commands�Host DoS Mitigation (cont.)


°·¨º·®»©¿´´ø½±²º·¹÷ý §±°¬ »½«®·¬§ º®¿¹¹«¿®¼

§±°¬ »½«®·¬§ º®¿¹¹«¿®¼

� Enables the IP Frag Guard feature� The sysopt commands enables you to tune various PIX

Firewall security and configuration features

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 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.


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

sysopt security fragguard

security fragguard Enables the IP Frag Guard feature.



Implementation Commands�Host DoS Mitigation (cont.)

� 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 floodof embryonic connections. An embryonic connection is one that has started but not yet completed. The default is 0, which meansunlimited connections.


°·¨º·®»©¿´´ø½±²º·¹÷ý ¬¿¬·½ ø°ô±«¬·¼»÷ ïçîòïêèòÐòïï ©©©ó°®·ª¿¬» ²»¬³¿µ îëëòîëëòîëëòîëë ð ïððð

¬¿¬·½ Åø°®»²¿¬Á·²¬»®º¿½»ô °±¬²¿¬Á·²¬»®º¿½»÷Ã ¥³¿°°»¼Á¿¼¼®»¤ ·²¬»®º¿½»£ ®»¿´Á¿¼¼®» Å¼²Ã Å²»¬³¿µ ³¿µÃ Å²±®¿²¼±³»¯Ã Å½±²²»½¬·±²Á´·³·¬ Å»³Á´·³·¬ÃÃ

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 institution�s 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 system�s 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 client�s acknowledgement. If the ACK is received, then a copy of the client�s SYN segment is sent to the server and the TCP three-way handshake is performed


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]]

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.



Spoof Mitigation and RFC Filtering�ACL

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.

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.






°·¨º·®»©¿´´ø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§



°·¨º·®»©¿´´ø½±²º·¹÷ý ¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó´·¬ ¿½´Á×Ü Å¼»²§ ¤ °»®³·¬Ã °®±¬±½±´ ¥±«®½»Á¿¼¼® ¤ ´±½¿´Á¿¼¼®£ ¥±«®½»Á³¿µ ¤ ´±½¿´Á³¿µ£ ±°»®¿¬±® °±®¬ ¥¼»¬·²¿¬·±²Á¿¼¼® ¤ ®»³±¬»Á¿¼¼®£ ¥¼»¬·²¿¬·±²Á³¿µ ¤ ®»³±¬»Á³¿µ£ ±°»®¿¬±® °±®¬

¿½½»ó¹®±«° ¿½´Á×Ü ·² ·²¬»®º¿½» ·²¬»®º¿½»Á²¿³»

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-listcommand statement, the PIX Firewall discards the packet.


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 optionprevents 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.


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-tunnelcommand 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.


access-group acl_ID in interface interface_name

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.



ISPnetwork

Customernetwork

Ingress to Internet

Spoof Mitigation�RFC 1918 Filtering

·²¬»®º¿½» Í»®·¿´ ²

·° ¿½½»ó¹®±«° ïðï ·²

ÿ

¿½½»ó´·¬ ïðï ¼»²§ ·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§

¿½½»ó´·¬ ïðï ¼»²§ ·° ïçîòïêèòðòð ðòðòîëëòîëë ¿²§

¿½½»ó´·¬ ïðï ¼»²§ ·° ïéîòïêòðòð ðòïëòîëëòîëë ¿²§

¿½½»ó´·¬ ïðï °»®³·¬ ·° ¿²§ ¿²§

The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private Internets:

10.0.0�10.255.255.255 (10/8 prefix)

172.16.0.0�172.31.255.255 (172.16/12 prefix)

192.168.0.0�192.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.



Implementation Commands�Authenticate Remote Site

� 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


°·¨º·®»©¿´´ø½±²º·¹÷ý ¿¿¿ó»®ª»® ³§¬¿½¿½ °®±¬±½±´ ¬¿½¿½õ

°·¨º·®»©¿´´ø½±²º·¹÷ý ¿¿¿ó»®ª»® ³§¬¿½¿½ ø·²·¼»÷ ¸±¬ ïðòðòïòïð ½·½±¿º»

¿¿¿ó»®ª»® ¹®±«°Á¬¿¹ °®±¬±½±´ ¿«¬¸Á°®±¬±½±´

¿¿¿ó»®ª»® ¹®±«°Á¬¿¹ ø·ºÁ²¿³»÷ ¸±¬ »®ª»®Á·° µ»§ ¬·³»±«¬ »½±²¼

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.


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.




� Defines the AAA authentication method used.


°·¨º·®»©¿´´ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ¬»´²»¬ ½±²±´» ³§µ»§

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


°·¨º·®»©¿´´ø½±²º·¹÷ý ´±¹¹·²¹ ïðòðòÐòí

¿¿¿ ¿«¬¸»²¬·½¿¬·±² Å»®·¿´ ¤ »²¿¾´» ¤ ¬»´²»¬ ¤ ¸ ¤ ¸¬¬°Ã ½±²±´» ¹®±«°Á¬¿¹

´±¹¹·²¹ ¸±¬ Å·²Á·ºÁ²¿³»Ã ·°Á¿¼¼®»Å°®±¬±½±´ñ°±®¬Ã

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.

serial Access verification for the PIX Firewall's serial console.

enable Access verification for the PIX Firewall�s privilege mode.


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]

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 listing�the 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.



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.

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.)



filter java Command

º·´¬»® ¶¿ª¿ °±®¬Åó°±®¬Ã ´±½¿´Á·° ³¿µ º±®»·¹²Á·° ³¿µ


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

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

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.



Java Applet Filtering Example

ISPnetwork

Customernetwork

Filtering Java Applets on port 80 for internal subnets on all outbound connections

Egress from Internet

Ingress to Internet

ÿ

º·´¬»® ¶¿ª¿ èð ðòðòðòð ðòðòðòð ðòðòðòð ðòðòðòð

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 ISP�s aggregation point.



ActiveX Blocking


� 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.

º·´¬»® ¿½¬·ª»¨ °±®¬ ´±½¿´Á·° ³¿µ º±®»·¹²Á·° ³¿µ

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

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 httpor 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.



filter activex Example

11.0.0.0 12.0.0.0 14.0.0.0 TACACS+ server

RADIUS server

ExecutiveEngineering Marketing

Internet

DMZ

°·¨º·®»©¿´´ø½±²º·¹÷ý º·´¬»® ¿½¬·ª»¨ èð ðòðòðòð ðòðòðòð ðòðòðòð ðòðòðòð

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

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 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.


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.


Copyright 2003, Cisco Systems, Inc. SAFE Small Network Design Lab 5-1

Lab Exercise�SAFE 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




.100

e0/1

PSSWWWFTP

172.16.P.0/24


e0/0

10.0.P.0 /24

Pod P (1�10)

192.168.P.0/24

.1 e2

pP

.4

pub

cP

.1

172.30.P.0/24

sensorP

DMZ

.2

.150

SuperServerWWWFTP

.10

.150

.5

priv

.5

.2 e0172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

rP

RTS

RBB

VPN Client

brP

Branch10.2.P.0/24

.10P e0/1

.50

.1 e0/010.2.P.11

172.26.26.P

Branch

10.0.P.11Student

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

ObjectivesIn 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.


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.

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

Note 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.


Task 1�Initial 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:

°·¨Ðý ©®·¬» »®¿»

°·¨Ðý ®»´±¿¼

(where P = pod number)Step 2 Check your current configuration to familiarize yourself with the current setup:

°·¨Ðý ©®·¬» ¬»®³·²¿´

(where P = pod number)Step 3 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 0

ethernet1 inside 100

ethernet2 pss 50

°·¨Ðø½±²º·¹÷ý ¸±¬²¿³» °·¨Ð

°·¨Ðø½±²º·¹÷ý ²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

°·¨Ðø½±²º·¹÷ý ²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

°·¨Ðø½±²º·¹÷ý ²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

°·¨Ðø½±²º·¹÷ý ¸±© ²¿³»·º


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


°·¨Ðø½±²º·¹÷ý ·° ¿¼¼®» ±«¬·¼» ïçîòïêèòÐòî îëëòîëëòîëëòð

°·¨Ðø½±²º·¹÷ý ·° ¿¼¼®» ·²·¼» ïðòðòÐòï îëëòîëëòîëëòð

°·¨Ðø½±²º·¹÷ý ·° ¿¼¼®» ° ïéîòïêòÐòï îëëòîëëòîëëòð



Step 5 Enable the interfaces and set the interface speeds defined in the following table:

Interface Name Speed

ethernet0 100full

ethernet1 10full

ethernet2 100full

°·¨Ðø½±²º·¹÷ý ·²¬»®º¿½» »ð ïððº«´´

°·¨Ðø½±²º·¹÷ý ·²¬»®º¿½» »ï ïðº«´´

°·¨Ðø½±²º·¹÷ý ·²¬»®º¿½» »î ïððº«´´

(where P = pod number)Step 6 Ensure that the IP addresses are correctly configured and are associated with the proper network

interface:

°·¨Ðø½±²º·¹÷ý ¸±© ·° ¿¼¼®»

(where P = pod number)Step 7 Write the configuration to the Flash memory:

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§


Task 2�Configure 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 1 192.168.P.33-222 255.255.255.0

outside 2 192.168.P.225-254 255.255.255.224


°·¨Ðø½±²º·¹÷ý ¹´±¾¿´ ø±«¬·¼»÷ ï ïçîòïêèòÐòííóïçîòïêèòÐòîîî ²»¬³¿µ

îëëòîëëòîëëòð

°·¨Ðø½±²º·¹÷ý ¹´±¾¿´ ø±«¬·¼»÷ î ïçîòïêèòÐòîîëóïçîòïêèòÐòîëì ²»¬³¿µ

îëëòîëëòîëëòîîì

°·¨Ðø½±²º·¹÷# ¸±© ¹´±¾¿´


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.

°·¨Ðø½±²º·¹÷ý ²¿¬ ø·²·¼»÷ ï ïðòðòÐòð îëëòîëëòîëëòð ð ð


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

A)


Step 3 Assign the perimeter router�s inside interface as the PIX Firewall�s default route:

°·¨Ðø½±²º·¹÷# ®±«¬» ±«¬·¼» ð ð ïçîòïêèòÐòïëð


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:

°·¨Ðø½±²º·¹÷# ©®·¬» ³»³±®§

(where P = pod number)Step 5 Write the current configuration to the terminal and verify that you have entered the previous

commands correctly:

°·¨Ðø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´

(where P = pod number)Step 6 Ping the following devices from the PIX Firewall to ensure they are operational:

PIX Firewall inside interface�10.0.P.1(where P = pod number)

Student PC�10.0.P.11(where P = pod number)

PIX Firewall outside interface�192.168.P.2(where P = pod number)

Perimeter router�192.168.P.150(where P = pod number)

PIX Firewall public services segment interface�172.16.P.1(where P = pod number)

Public services segment server�172.16.P.50(where P = pod number)

°·¨Ðø½±²º·¹÷ý °·²¹ ïðòðòÐòï

°·¨Ðø½±²º·¹÷ý °·²¹ ·²·¼» ïðòðòÐòïï

°·¨Ðø½±²º·¹÷ý °·²¹ ïçîòïêèòÐòî

°·¨Ðø½±²º·¹÷ý °·²¹ ïçîòïêèòÐòï

°·¨Ðø½±²º·¹÷ý °·²¹ ïéîòïêòÐòï

°·¨Ðø½±²º·¹÷ý °·²¹ ïéîòïêòÐòëð



Step 7 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:

°·¨Ðø½±²º·¹÷ý ¬¿¬·½ ø·²·¼»ô°÷ ïðòðòÐòð ïðòðòÐòð ²»¬³¿µ îëëòîëëòîëëòð


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

A)

Step 8 Confirm your entries:

°·¨Ðø½±²º·¹÷ý ¸±© ²¿¬

°·¨Ðø½±²º·¹÷ý ¸±© ¹´±¾¿´

(where P = pod number)Step 9 Assign a name to the public services segment server�s private address using the name command,

and verify that the name was entered properly:

IP Address Name

172.16.P.50 www-private


°·¨Ðø½±²º·¹÷ý ²¿³»

°·¨Ðø½±²º·¹÷ý ²¿³» ïéîòïêòÐòëð ©©©ó°®·ª¿¬»

°·¨Ðø½±²º·¹÷ý ¸±© ²¿³»



°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§


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 3�Deny 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:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòÐòð îëëòîëëòîëëòð »½¸±ó

®»°´§


Continue creating your ACL:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§


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

°·¨Ðø½±²º·¹÷ý ¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» °


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. Test ICMP access to the VPN Client PC: 172.26.26.P.(where P = pod number)

Q5) 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)


Task 4�Allow 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:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëòð ¿²§


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 Confirm that you still have connectivity to the public services segment server from the Student PC:




Q7) Why is it important to restrict outbound access to �known� internal network addresses and hosts?

A)

Task 5�Allow 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:

°·¨Ðø½±²º·¹÷ý ¬¿¬·½ ø°ô±«¬·¼»÷ ïçîòïêèòÐòïï ©©©ó°®·ª¿¬» ²»¬³¿µ

îëëòîëëòîëëòîëë ð ïððð


Step 2 Assign a name to the public services segment server�s public address using the name command and verify that the name was entered properly:

IP Address Name

192.168.P.11 www-public


°·¨Ðø½±²º·¹÷ý ²¿³» ïçîòïêèòÐòïï ©©©ó°«¾´·½

°·¨Ðø½±²º·¹÷ý ¸±© ²¿³»


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.

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòÐòð îëëòîëëòîëëòð ¿²§


Q8) What threat do these ACL entries help mitigate?

A)


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

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°

(where P = pod number)Step 5 Create an ACL to allow ICMP echo replies initiated from the internal network, and deny all

other traffic:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòÐòð îëëòîëëòîëëòð

»½¸±ó®»°´§

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§


Step 6 Bind the ACL to the outside interface:

°·¨Ðø½±²º·¹÷ý ¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

(where P = pod number) Step 7 Display the ACL and observe the hit counts:

°·¨Ðø½±²º·¹÷ý ¸±© ¿½½»ó´·¬

(where P = pod number)Step 8 Deny pings to the outside interface:

°·¨Ðø½±²º·¹÷ý ·½³° ¼»²§ ¿²§ ±«¬·¼»

(where P = pod number)Step 9 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 6�Implement Spoofing ProtectionComplete 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:

°·¨Ðø½±²º·¹÷ý ·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

°·¨Ðø½±²º·¹÷ý ·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

(where P = pod number)Step 2 Write the current configuration to Flash memory:

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§



Task 7�Enable 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:

°·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ±²

°·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ¸±¬ ïðòðòÐòïï

°·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ¬®¿° ·²º±


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

A)


°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§


Task 8�Assign Telnet and Enable PasswordsComplete the following steps to assign Telnet and enable passwords:

Step 1 Configure and set your enable password:

°·¨Ðø½±²º·¹÷ý »²¿¾´» °¿©±®¼ »²¿¾´»

°·¨Ðø½±²º·¹÷ý °¿©¼ ½·½±



°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)Step 3 Compare your configuration to the following sample configuration from pix1:

°·¨ïø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´

æ Í¿ª»¼

æ

Ð×È Ê»®·±² êòîøï÷

²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ·²¬ºì »½«®·¬§îð

²¿³»·º »¬¸»®²»¬ë ·²¬ºë »½«®·¬§îë

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï


º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð

º·¨«° °®±¬±½±´ ¸íîí ®¿ ïéïèóïéïç

º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»

²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬»

²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½

¿½½»ó´·¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§

¿½½»ó´·¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§

¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§

¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§

°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòïòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ï ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬î ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ¸«¬¼±©²

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð

³¬« ÐÍÍ ïëðð

³¬« ·²¬ºí ïëðð

³¬« ·²¬ºì ïëðð

³¬« ·²¬ºë ïëðð

·° ¿¼¼®» ±«¬·¼» ïçîòïêèòïòî îëëòîëëòîëëòð

·° ¿¼¼®» ·²·¼» ïðòðòïòï îëëòîëëòîëëòð

·° ¿¼¼®» ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð

·° ¿¼¼®» ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë

·° ¿¼¼®» ·²¬ºì ïîéòðòðòï îëëòîëëòîëëòîëë


·° ¿¼¼®» ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ÐÍÍ ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºì ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºë ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð

¹´±¾¿´ ø±«¬·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿µ îëëòîëëòîëëòð

¹´±¾¿´ ø±«¬·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿µ îëëòîëëòîëëòîîì

²¿¬ ø·²·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð

¬¿¬·½ ø·²·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¬¿¬·½ øÐÍÍô±«¬·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿µ îëëòîëëòîëëòîëë ð ïððð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

®±«¬» ±«¬·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòïëð ï

¬·³»±«¬ ¨´¿¬» íæððæðð

¬·³»±«¬ ½±²² ïæððæðð ¸¿´ºó½´±»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð ·

° ðæíðæðð ·°Á³»¼·¿ ðæðîæðð

¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

²± §±°¬ ®±«¬» ¼²¿¬

¬»´²»¬ ¬·³»±«¬ ë

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æ½ê»é¼¿ç¾»é¿é¾é»½ëéë¿»èêë¼¿¾é¼¿ï½

æ »²¼


Task 9�Test and Verify the ConfigurationComplete 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:


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)


Step 3 Ensure that you can access the Internet from the Student PC:


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)


Step 5 Continue ensuring that you cannot initiate a connection to any network from the public services segment server:


2. Test FTP and web access to the VPN Client PC: 172.26.26.P.(where P = pod number)


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


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:

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


� 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 router�s 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.

SetupYou 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 router�s inside and outside interfaces from the branch office PC.


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 1�Secure 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:

¾®Ðø½±²º·¹÷ý ¾¿²²»® ´±¹·² ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý±³°¿²§ ×Ì Ð»®±²²»´ ÑÒÔÇÿ

¾®Ðø½±²º·¹÷ý ¾¿²²»® »¨»½ ÿÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÿ

(where P = pod number)Step 2 Enable password encryption and assign a secret enable password to protect the router�s

passwords:

¾®Ðø½±²º·¹÷ý »®ª·½» °¿©±®¼ó»²½®§°¬·±²

¾®Ðø½±²º·¹÷ý »²¿¾´» »½®»¬ »½®»¬

(where P = pod number)Step 3 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.

¾®Ðø½±²º·¹ó·º÷ý ²± ·° °®±¨§ó¿®°

¾®Ðø½±²º·¹ó·º÷ý ²± ½¼° »²¿¾´»

¾®Ðø½±²º·¹ó·º÷ý ²± ·° ®»¼·®»½¬

¾®Ðø½±²º·¹ó·º÷ý ²± ·° ¼·®»½¬»¼ó¾®±¿¼½¿¬

(where P = pod number)Step 4 Enable logging to the Syslog server to provide a method to monitor router events including

attacks:

¾®Ðø½±²º·¹÷ý »®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ±²


¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ïðòîòÐòïï

¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

¾®Ðý ©®·¬» ³»³±®§


Task 2�Secure 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:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ï °»®³·¬ ¸±¬ ïðòîòÐòïï ´±¹

(where P = pod number) Step 2 Assign a password to the VTY lines (0�4), and allow VTY line access only from management

workstations to the router to prevent access by unauthorized users:

¾®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì

¾®Ðø½±²º·¹ó´·²»÷ý °¿©±®¼ ½·½±

¾®Ðø½±²º·¹ó´·²»÷ý ¿½½»ó½´¿ ï ·²

¾®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ïë

¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ±«¬°«¬ ²±²»

¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

(where P = pod number)Step 3 Assign a password to the console line to prevent access by unauthorized users:

¾®Ðø½±²º·¹ó´·²»÷ý ´·²» ½±² ð

¾®Ðø½±²º·¹ó´·²»÷ý °¿©±®¼ ½·½±

¾®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ïë

¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ±«¬°«¬ ²±²»

¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

(where P = pod number)Step 4 Create a local user account on the router that is used to log into the router:

¾®Ðø½±²º·¹÷ý «»®²¿³» ¬«¼»²¬ °¿©±®¼ ¬«¼»²¬

(where P = pod number)Step 5 Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU

time for system processes:

¾®Ðø½±²º·¹÷ý ½¸»¼«´»® ¿´´±½¿¬»

¾®Ðý ©®·¬» ³»³±®§


Task 3�Configure 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:


¾®Ðø½±²º·¹÷ý ·° ²¿¬ ·²·¼» ±«®½» ¬¿¬·½ ïðòîòÐòïï ïéîòîêòîêòïïÐ

(where P = pod number)Step 2 Specify the inside interface and enter interface configuration mode:

¾®Ðø½±²º·¹÷ý ·²¬»®º¿½» »ðñð

(where P = pod number)Step 3 Mark the interface as connected to the inside:

¾®Ðø½±²º·¹ó·º÷ý ·° ²¿¬ ·²·¼»

(where P = pod number)Step 4 Specify the outside interface and enter interface configuration mode:

¾®Ðø½±²º·¹÷ý ·²¬»®º¿½» »ðñï

(where P = pod number)Step 5 Mark the interface as connected to the outside:

¾®Ðø½±²º·¹ó·º÷ý ·° ²¿¬ ±«¬·¼»


Q10) The interface name is specified instead of the IP address. Why might this be preferred instead of specifying the interface�s IP address?

A)

Task 4�Implement 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

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ »·¹®° ¸±¬ ïéîòîêòîêòïëð ¸±¬ ïéîòîêòîêòïðÐ

´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ »·¹®° ¸±¬ ïéîòîêòîêòïëð ¸±¬ îîìòðòðòïð

´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±¬ ïéîòîêòîêòïðÐ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ïçîòïêèòÐòð ðòðòðòîëë ¿²§ ´±¹


Q11) Is allowing ICMP traffic to the branch router�s outside interface acceptable? Why or why not?

A)

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


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.

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

(where P = pod number)Step 3 Create an ACL that filters eigrp routing updates to the branch office router and network:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¸±¬ ïéîòîêòîêòïðÐ ¿²§ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹

(where P = pod number) Step 4 Apply the ACL inbound to the router�s public interface to prevent traffic from entering the

branch office network:

¾®Ðø½±²º·¹÷ý ·²¬ »ðñï

¾®Ðø½±²º·¹ó·²¬÷ý ·° ¿½½»ó¹®±«° ïðï ·²

(where P = pod number)Step 5 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.

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðî °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ¿²§ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

(where P = pod number) Step 6 Apply the ACL inbound to the router�s private interface to allow the branch office networks to

initiate outbound connections:

¾®Ðø½±²º·¹÷ý ·²¬ »ðñð

¾®Ðø½±²º·¹ó·²¬÷ý ·° ¿½½»ó¹®±«° ïðî ·²

¾®Ðý ©®·¬» ³»³±®§


Task 5�Configure 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


RealAudio

¾®Ðø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

¾®Ðø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

¾®Ðø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

¾®Ðø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

¾®Ðø½±²º·¹÷ý ·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

¾®Ðø½±²º·¹÷ý ·²¬ »ðñð

¾®Ðø½±²º·¹ó·º÷ý ·° ·²°»½¬ ¾®¿²½¸º© ·²


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

¾®Ðø½±²º·¹÷ý ²± ·° ¿«¼·¬ ·²º±

¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ²±¬·º§ ´±¹

¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

¾®Ðø½±²º·¹÷ý ·²¬ »ðñð

¾®Ðø½±²º·¹ó·º÷ý ·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

¾®Ðý ©®·¬» ³»³±®§


Task 6�Test the Branch Office Router Configuration Complete the following steps to confirm that the branch office is configured correctly:

Step 1 Ping the branch office router�s inside and outside interface from the branch office PC:

½æÄâ °·²¹ ïðòîòÐòï

½æÄâ °·²¹ ïéîòîêòîêòïðÐ

(where P = pod number)Step 2 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:


¾®Ðý ¸±© ·° ²¿¬ ¬®¿²

(where P = pod number)Step 5 Compare your configuration to the following:

¾®ïý ©®·¬» ¬»®³·²¿´

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±² æ îëîï ¾§¬»

ÿ

ª»®·±² ïîòî

»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»

»²¿¾´» »½®»¬ ë üïü°¾ØÚü®ßèÏ½´¹ÞÙ«ìÊí½´éðë½¦ºð

»²¿¾´» °¿©±®¼ é ïðìÜðððßðêïè

ÿ

«»®²¿³» ¬«¼»²¬ °¿©±®¼ é ïìðìðêïÛðèðïîìíÚ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

ÿ

ÿ

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¸ ¬·³»ó±«¬ ïîð

·° ¸ ¿«¬¸»²¬·½¿¬·±²ó®»¬®·» í

ÿ

½¿´´ ®ª°ó§²½

ÿ

ÿ

ÿ

ÿ


ÿ

ÿ

ÿ

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïðòîòïòï îëëòîëëòîëëòð

·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ²¿¬ ·²·¼»

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï

·° ¿¼¼®» ïéîòîêòîêòïðï îëëòîëëòîëëòð

·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ²¿¬ ±«¬·¼»

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

ÿ

®±«¬»® »·¹®° ï

²»¬©±®µ ïðòðòðòð

²»¬©±®µ ïéîòîêòðòð

²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ²¿¬ ·²·¼» ±«®½» ¬¿¬·½ ïðòîòïòïï ïéîòîêòîêòïïï

·° ½´¿´»

²± ·° ¸¬¬° »®ª»®

·° °·³ ¾·¼·®ó»²¿¾´»

ÿ

´±¹¹·²¹ ïðòîòïòïï

¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ »·¹®° ¸±¬ ïéîòîêòîêòïëð ¸±¬ ïéîòîêòîêòïðï ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ »·¹®° ¸±¬ ïéîòîêòîêòïëð ¸±¬ îîìòðòðòïð ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±¬ ïéîòîêòîêòïðï ´±¹


¿½½»ó´·¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¸±¬ ïéîòîêòîêòïðï ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

²± ½¼° ®«²

ÿ

¼·¿´ó°»»® ½±® ½«¬±³

ÿ

ÿ

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ

¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý±³°¿²§ ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð

°¿©±®¼ é ïïðßïðïêïìïÜ

´±¹·² ´±½¿´

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð

°¿©±®¼ é ðêðëðêíîìÚìï

´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼


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

the appropriate security levels?

A) 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.

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

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

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

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

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

A) 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.

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

A) 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.

Q6) Would you recommend being more restrictive? Why?

A) It depends on the company�s security policy. In general being more restrictive requires additional management, but does reduce the likelihood of internal users from access unknown or private networks.

Q7) Why is it important to restrict outbound access to �known� internal network addresses and hosts?


A) This prevents internal users from creating their own networks and accessing outside networks without prior approval.

Q8) What threat do these ACL entries help mitigate?

A) These ACL entries are used to mitigate IP spoofing attacks where the attacker uses internal addresses.

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

A) Device logging enables the network security administrator to visibility into what traffic is being allowed or denied. The company�s 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.

Q10) The interface name is specified instead of the IP address. Why might this be preferred instead of specifying the interface�s IP address?

A) This might be preferred in those network environments where the branch office is dynamically assigned an IP address by the ISP.

Q11) Is allowing ICMP traffic to the branch router�s outside interface acceptable? Why or why not?

A) Allowing ICMP traffic is ultimately determined by a company�s 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.

Q12) 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.

6

SAFE SMR Midsize Network Design

OverviewThis 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

Implementation�ISP router and edge router

Implementation�IOS Firewall

Implementation�PIX Firewall

Implementation�NIDS

Implementation�VPN Concentrator


Implementation�Layer 3 switch

Summary

Lab exercise

Copyright 2003, Cisco Systems, Inc. SAFE SMR Midsize Network Design 6-3



Objectives

Upon completion of this chapter, you will be able to perform thefollowing 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.


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.


SP edgeMidsize network

or branch Campus

SAFE Design for Midsize NetworkMidsize network or branch edge


WAN module

PSTN module

ISP edgemodule

Frame or ATMmodule

Campus module

Corporateusers

Managementserver

Corporateservers

Publicservices

FR/ATM

Internet

PSTN

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.



Midsize Network Corporate Internet Module�Key Devices

The following are key devices:� Servers

� Dial-in� SMTP� DNS� FTP or HTTP

� Firewall� Layer 2 switch� NIDS appliance� VPN Concentrator� Edge router

Publicservices

PSTN

Internet

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 server�Authenticates individual remote users and terminates their analog connections

SMTP server�Acts as a relay between the Internet and the intranet mail servers and inspects content

DNS server�Serves as authoritative external DNS server for the midsize network and relays internal requests to the Internet

FTP or HTTP server�Provides public information about the organization

Firewall�Provides 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 appliance�Provides Layer 4-to-Layer 7 monitoring of key network segments in the module


VPN Concentrator�Authenticates individual remote users and terminates their IPSec tunnels

Edge router�Provides basic filtering and Layer 3 connectivity to the Internet




The following threats can be expected:� Unauthorized access� Application layer attacks� Virus and Trojan horse attacks� Password attacks� DoS

From a threat perspective, a small or midsized 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.

The following threats can be expected in the SAFE SMR Midsize network:

Unauthorized access�Mitigated through filtering at the ISP, edge router, and corporate firewall

Application layer attacks�Mitigated through IDSs at the host and network levels

Virus and Trojan horse attacks�Mitigated through e-mail content filtering, HIDSs, and host-based virus scanning

Password attacks�Limited services available to brute force (operating systems and IDSs can detect the threat)

DoS�CAR at the ISP edge and TCP setup controls at the firewall




� IP spoofing � Packet sniffers � Network reconnaissance � Trust exploitation � Port redirection

IP spoofing�RFC 2827 and 1918 filtering at the ISP edge and midsize network edge router

Packet sniffers�A switched infrastructure and an HIDS to limit exposure

Network reconnaissance�An IDS detects reconnaissance, and filters protocols to limit effectiveness

Trust exploitation�Restrictive trust model and private VLANs to limit trust-based attacks

Port redirection�Restrictive 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 discovery�Access 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 attack�One-time passwords (OTP) mitigate brute force password attacks.


Unauthorized access�Firewall services after packet decryption prevent traffic on unauthorized ports.

Man-in-the-middle attacks�These attacks are mitigated through encrypted remote traffic.

Packet sniffers�A 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.



Midsize Network Attack Mitigation Roles for Corporate Internet Module�Overview

PSTN

Internet

SMTP content inspection

HIDS for local attack mitigation

Focused Layer 4�7 analysis

Spoof mitigation,

and rate-limiting

Spoof mitigation

basic filtering

Private VLANs

Authenticate users and terminate

analog dial

Authenticate users and terminate IPSec

Stateful packet filtering, basic Layer 7 filtering, host DoS mitigation, authenticate remote sites, and terminate

IPSec


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.


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

The following are the primary functions of the ISP router:� Provides Internet connectivity� Rate-limits non-essential traffic� Provides RFC 1918 and 2827 filtering

Publicservices

PSTN

Internet

Spoof mitigation, and

rate-limiting

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.



Design Guidelines for the Edge Router

� 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.

Publicservices

PSTN

Internet

Spoof mitigation and basic filtering

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 ISP�s 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.



Design Guidelines for a Firewall

The firewall�s primary functions include the following:� Provides connection-state enforcement� Terminates site-to-site IPSec VPNs� Provides DMZs


mitigation, authenticate remote sites, and terminate IPSec

Publicservices

PSTN

Internet

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 network-based 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


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 hacker�s 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.



Design Guidelines for Intrusion Detection

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



Publicservices

PSTN

Internet

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.



Design Guidelines for the Remote Access VPN

� The VPN Concentrator provides the following:� Secure connectivity� Authenticate users

Authenticate users and terminate IPSec

Publicservices

PSTN

Internet

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.



Design Guidelines for Dial-In Access Users

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.

Publicservices

PSTN

Internet

Authenticate users and terminate

analog dial

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.



Design Guidelines for the Inside Router

� 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.

DemarcationPublic

services

PSTN

Internet

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.



Design Alternatives

Design alternatives include the following:� A stateful firewall on an edge router� An NIDS on the outside firewall� Eliminate the inside router� A URL-filtering server

Publicservices

PSTN

Internet

Eliminate

NIDS and URL filtering

Statefulfirewall

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 administrator�s 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.


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.


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

� SMTP or POP3� File and print

� User workstations� NIDS appliance� Management hosts

� SNMP� Syslog� TACACS+ or RADIUS� NIDS host

Corporateusers

Managementserver

Corporateservers

To the corporate

Internet module

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 switch�Route 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 servers�Provides e-mail (SMTP and POP3) services to internal users, as well as delivering file, print, and DNS services to workstations

User workstations�Provide data services to authorized users on the network


NIDS appliance�Provides Layer 4-to-Layer 7 monitoring of key network segments in the module

Management hosts�Hosts designated for device management

� Simple Network Management Protocol (SNMP) host�Provides SNMP management for devices

� NIDS host�Provides alarm aggregation for all NIDS devices in the network

� Syslog host�Aggregates log information for firewall and NIDS hosts

� 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




The following threats are expected to the SAFE SMR Midsize Network Campus Module:� Packet sniffers�A switched infrastructure limits the

effectiveness of sniffing � Virus and Trojan horse applications�Host-based virus

scanning prevents most viruses and many Trojan horses � Unauthorized access�These types of attacks are

mitigated through the use of host-based intrusion detection and access control

� Password attacks�The access control server allows for strong, two-factor authentication for key applications

The following threats are expected:

Packet sniffers�A switched infrastructure limits the effectiveness of sniffing

Virus and Trojan horse applications�Host-based virus scanning prevents most viruses and many Trojan horses

Unauthorized access�These types of attacks are mitigated through the use of host-based intrusion detection and access control

Password attacks�The access control server allows for strong two-factor authentication for key applications




� Application layer attacks�Operating systems, devices, and applications are kept up-to-date with the latest security fixes, and they are protected by an HIDS

� IP spoofing�RFC 2827 filtering prevents source-address spoofing

� Trust exploitation�Trust arrangements are very explicit (private VLANs prevent hosts on the same subnet from communicating unless necessary)

� Port redirection�An HIDS prevents the installation of port redirection agents

Application layer attacks�Operating systems, devices, and applications are kept up-to-date with the latest security fixes, and they are protected by an HIDS

IP spoofing�RFC 2827 filtering prevents source-address spoofing

Trust exploitation�Trust arrangements are very explicit (private VLANs prevent hosts on the same subnet from communicating unless necessary)

Port redirection�An HIDS prevents the installation of port redirection agents



Midsize Network Attack Mitigation Roles for the Campus Module


Layer 3 and 4 filtering of management traffic, private

VLANs, and RFC filtering

Host virus scanning

HIDS for local attack mitigation

Corporateusers

Managementserver

Corporateservers

To the corporate

Internet module

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.


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

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

Layer 3 and 4 filtering of management traffic, private

VLANs, and RFC 2827 filtering

Corporateusers

Managementserver

Corporateservers

To the corporate

Internet module

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 department�s 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


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.



Design Guidelines for Intrusion Detection

Intrusion detection should monitor internal traffic for suspicious activity. Very few attacks should be detected.


Corporateusers

Managementserver

Corporateservers

To the corporate

Internet module

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.



Design Alternatives

The following design alternatives are available:� If the network is

small enough, incorporate Layer 2 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.

Integrated IDS module in the core switch

Integrate switch functionality

Separate router and

Layer 2 switch

Corporateusers

Managementserver

Corporateservers

To the corporate

Internet module

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 trust-exploitation 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.


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

� 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

To the campus moduleFR/ATM

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 spoofing�IP spoofing can be mitigated through Layer 3 filtering.

Unauthorized access�Simple access control on the router can limit the types of protocols to which branches have access.




� Use IPSec for additional privacy� Run a firewall on the WAN router

To the campus module

IPSec tunnel

FR/ATM

VPN tunnel

Cisco IOS Router with a firewall

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.


Implementation�ISP Router and Edge Router This section covers the necessary steps needed to implement the SAFE guidelines on the ISP router.


ISP Router�Implementation Commands Summary

The following are necessary commands for the ISP router:� Spoof mitigation and RFC filtering


� (D)DoS rate-limiting� rate-limit

Publicservices

PSTN

Internet

Spoof mitigation and (D)DoS rate-limiting

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 ISP�s 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.



Cisco Edge Router�Implementation Commands

The following are necessary commands for the Cisco edge router:� access-list� access-group

Midsize network or branch edgecorporate Internet module

Publicservices

PSTN

Internet

Spoof mitigation and basic filtering

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 ISP�s 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.





router(config)#



router(config-if)#

®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»ó¹®±«° ïðï ·²

·° ¿½½»ó¹®±«° ¥¿½½»ó´·¬ó²«³¾»® ¤ ¿½½»ó´·¬ó

²¿³»£¥·² ¤ ±«¬£

¿½½»ó´·¬ ¿½½»ó´·¬ó²«³¾»® Å¼§²¿³·½ ¼§²¿³·½ó²¿³»Å¬·³»±«¬ ³·²«¬»ÃÃ ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ ±«®½» ±«®½»ó©·´¼½¿®¼ ¼»¬·²¿¬·±² ¼»¬·²¿¬·±²ó©·´¼½¿®¼

Å°®»½»¼»²½» °®»½»¼»²½»Ã Å¬± ¬±Ã Å´±¹ ¤ ´±¹ó·²°«¬Ã Å¬·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã

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

Access control�The 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 filtering�You 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 organization�s 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).




wildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-range-

name]






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-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.


Use a 32-bit quantity in four-part, dotted-decimal format. Place 1s in the bit positions you want to ignore.


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.


destination Number of the network or host to which the packet is being sent. There are three alternative ways to specify the destination:


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 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.








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


The IOS Firewall


mitigation, authenticate remote sites, authenticate remote users, and terminate IPSec

Publicservices

PSTN

Internet

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 hacker�s 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.



IOS Firewall�Implementation Commands Summary

The following are necessary mitigation roles and implementation commands for the IOS Firewall:� Stateful packet filtering�Part of CBAC on IOS Routers� Spoof mitigation and RFC filtering


� 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






Host DoS mitigation



� aaa new-model�To define a set of inspection rules, enter this command for each protocol that you want to inspect, using the same inspection-name.


� aaa authentication login�Enables AAA authentication at login.







IOS Firewall�Implementation Commands Summary (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

IPSec commands�Provide for IPSec tunnel termination


� Encryption�Sets the algorithm to be negotiated.

� Authentication�Specifies the authentication method within an IKE policy.

� group�Specifies the AAA server group to use for preauthentication.








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


PIX Firewall�Implementation 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� icmp � attack guard commands

(except for frag guard, these are on by default)

� static� Spoof mitigation and RFC filtering



mitigation, spoof mitigation, authenticate remote sites,

authenticate remote users, and terminate IPSec

Publicservices

PSTN

Internet

The following mitigation roles and implementation commands are used to implement the policy on the PIX Firewall:

Stateful packet filtering�The default for the PIX Firewall


� ip verify reverse-path interface�Implements Unicast RPF IP spoofing protection

� icmp�Enables or disables pinging to an interface

� attack guard commands�These commands are enabled by default

� static�Creates a static network address translation






PIX Firewall�Implementation Commands Summary (cont.)

� Authenticate the 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

Publicservices

PSTN

Internet


mitigation, authenticate remote sites, and terminate IPSec

Authenticate the remote-site and logging

� aaa-server�Specifies a AAA server

� aaa authentication�Enables, disables, or views LOCAL, TACACS+, or RADIUS user authentication

� logging on�Enables or disables Syslog and SNMP logging

Terminate IPSec

� sysopt connection permit-ipsec�Implicitly permits any packet that came from an IPSec tunnel

� isakmp enable�Enables Internet Security Association Key Management Protocol (ISAKMP) negotiation on the interface on which the IPSec peer communicates with the PIX Firewall

� isakmp key�Specifies the authentication pre-shared key

� isakmp policy�Uniquely identifies the IKE policy and assigns a priority to the policy

� crypto ipsec transform-set�Creates, views, or deletes IPSec security associations, Security Association (SA) global lifetime values, and global transform sets

� crypto map�Creates, modifies, views, or deletes a crypto map entry


Implementation�NIDSThis 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 Sensor�s network settings.� Define the list of hosts that are authorized to

manage the Sensor.� Configure remote management services.� Configure SSH settings.� Configure the Sensor�s date and time.� Change the password for the account used to

access the IDM.

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 Sensor�s network settings�This 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 Sensor�This task involves identifying those hosts and networks that should be allowed to manage the Sensor.

Configure remote management services�This task involves deciding which network services are used to gain interactive access to the Sensor.

Configure secure shell (SSH) settings�This task involves generating the Sensor�s SSH keys and managing the known hosts file.


Configure the Sensor�s date and time�This 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 IDM�This task involves changing the password for either the netrangr or root account.



Network SettingsChoose Device>Sensor Setup>Network.

Complete the following steps to configure the Sensor�s network parameters:

Step 1 Launch your web browser and specify the Sensor as the location:

¸¬¬°æññ»²±®Á·°Á¿¼¼®»

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 Sensor�s 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 1�65535 Numeric identifier for the IEV host.

Organization Name <Org Name> Alphanumeric identifier for a group of Cisco IDS components.

Organization ID 1�65535 Numeric identifier for a collection of Cisco IDS components.

IP Address <IP Address> The IP address of the IEV host.

PostOffice Port 1025�65535 The UDP port number used for IDS communication.


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 Sensor�s 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 Sensor�s network settings.



Network Access ControlChoose Device>Sensor Setup>Allowed Hosts.

The access control list (ACL) feature enables the network security administrator to set any number of IP addresses�either by host or network�which 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 hosts�typically 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 Sensor�s network access control feature:


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 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).

Step 6 Click OK to save the Sensor�s allowed hosts settings.

http://www.standford.edu/group/itss-ccs/security/unix/tcpwrappers_README.txt



Remote Access ServicesChoose Device>Sensor Setup>Remote Access.

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 3 Select Remote Access from the TOC. The Sensor�s 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 Sensor�s remote access settings.



TimeChoose Device>Sensor Setup>Time.

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:



Step 3 Select Time from the TOC. The Sensor�s 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 Sensor�s time settings.



Account PasswordChoose Device>Sensor Setup>Password.

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 account�s password:



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 user�s 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 user�s password.



Applying Sensor ConfigurationChoose Apply Changes and Select Finish.

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:

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.



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

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



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

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 Sensor�s 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.



Event LoggingChoose Configuration>Logging>Event Logging.

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 Sensor�s 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 Click OK to save the event logging settings.



Log File TransfersChoose Configuration>Logging>Exporting Event Logs.

Complete the following steps to configure the Sensor to transfer the log files offline to an FTP server:


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 The user must have write access to the target FTP directory on the FTP server.

Step 6 Click OK to save the Exporting Event Logs settings.



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

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



Internal Networks

Choose Configuration>Sensing Engine>Internal Networks.

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 events�Alarm 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 filtering�The keywords IN and OUT are used when creating an exclusion of inclusion signature filter.

Note The internal network definition does not affect the Sensor�s 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 2 Log into the IDM as the netrangr user. The default netrangr password is attack.


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.


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.1�10.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.



Sensing Properties

Choose Configuration>Sensing Engine>Sensing Properties.

Complete the following steps to configure the Sensor�s sensing properties:



Step 3 Select Sensing Properties from the TOC. The Sensor�s 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 Parameter Value Description

Sensing Interface Custom�Enables the network security administrator to enter a user-defined interface name.

Automatic�Enables the Sensor to detect the correct monitoring interface�s device name.

This is the Sensor�s monitoring interface device name. Automatic is the default value.

Traffic Flow Severity High

Medium

Low

Informational

The alarm severity level assigned to the Traffic Flow signatures. The default security level is High.

Traffic Flow Timeout 0�65000 The number of seconds required to trigger the Traffic Flow signature.


Cisco IDS Setting Parameter Value Description

Link Status Alarm Level High

Medium

Low

Informational

The alarm severity level assigned to the Link status signature. The default security level is Low.

Storage Timeout Seconds 10�600 The number of seconds to wait before deleting stored history after the host goes silent.

Step 5 Click OK to save the Sensor�s sensing properties.



Level of Traffic Logging

Choose Configuration>Sensing Engine>Signature Configuration>Level of Traffic Logging.

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 Sensor�s level of traffic logging:



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 Click OK to save the traffic logging level.



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.

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



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

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 status�Enables or disables the signature

Severity level�Assigns the severity level (information, low, medium, or high)

Signature action�Assigns the action to take if the signature is triggered



Signature Groups

Choose Configuration>Sensing Engine>Signature Configuration>Signature Group.

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


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


Note The signature groups may change in subsequent releases.



Custom SignaturesChoose Configuration>Sensing Engine>Signature Configuration>Custom Signatures.

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.ICMP�Used to examine ICMP packets for a single condition, such as an ICMP type.

Atomic.IPOptions�Used to examine IP packets with a specified IP option.

Atomic.L3.IP�Used to examine layer 3 IP packets for a single condition, such as detecting Enhanced Interior Gateway Routing Protocol (EIGRP) packets.

Atomic.TCP�Used to examine TCP packets for a single condition, such as a specific TCP port.

Atomic.UDP�Used to examine UDP packets for a single condition, such as a specific UDP port.

Flood.Host.ICMP�Used to examine an excessive number of ICMP packets sent to a target host.

Flood.Host.UDP�Used to examine an excessive number of UDP packets sent to a target host.

Flood.Net�Used to examine an excessive number of packets sent to a network segment.


Flood.TCPSYN�Used to examine an excessive number of half-opened connections.

Service.DNS.TCP�Used to examine TCP DNS packets.

Service.DNS.UDP�Used to examine UDP DNS packets.

Service.PortMap�Used to examine requests made to the RPC port mapper application.

Service.RPC�Used to examine packets sent to RPC programs and applications.

State.HTTP�Used to perform protocol analysis on an HTTP stream.

String.HTTP�Used to search an HTTP stream for a string pattern.

String.ICMP�Used to search ICMP packets for a string pattern.

String.TCP�Used to search TCP packets for a string pattern.

String.UDP�Used to search UDP packets for a string pattern.

Sweep.Host.ICMP�Used to detect a single address scanning multiple network addresses using ICMP packets.

Sweep.Host.TCP�Used to detect a single address scanning multiple network addresses using TCP packets.

Sweep.Port.TCP�Used to detect TCP connections to multiple destination ports between two network addresses.

Sweep.Port.UDP�Used to detect UDP connections to multiple destination ports between two network addresses.

Sweep.RPC�Used 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.



String SignaturesChoose Configuration>Sensing Engine>Signature Configuration>String Signatures.

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:



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.


Step 13 Click the Edit icon next to the signature�s Enabled circle to tune the signature.



NIDS Implementation�IEV

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.

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:

Step 1 Add the IEV host as a remote event destination�This 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 Sensor�This 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 host�This includes starting the IEV setup program and continuing with the installation wizard.

Step 4 Reboot the IEV host to start the IDS services�This 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 monitor�This includes specifying the IDS devices from which the IEV application accepts events.



Sensor Remote HostChoose Configuration>Communication>Remote Hosts and Select Add.

Complete the following steps to add the IEV host as a remote event destination:


¸¬¬°æññ»²±®Á·°Á¿¼¼®»

Step 2 Log into the IDM as the netrangr user. The default netrangr password is attack.


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.


Host Name <Host Name> Alphanumeric identifier for the IEV host.

Host ID 1�65535 Numeric identifier for the IEV host.

Organization Name <Org Name> Alphanumeric identifier for a group of Cisco IDS components.

Organization ID 1�65535 Numeric identifier for a collection of Cisco IDS Components.

IP Address <IP Address> The IP address of the IEV host.




Heartbeat 1�65535 Time interval that the Cisco IDS Communication Infrastructure uses when transmitting route verification messages.

Step 8 Click OK to accept the host values. The IEV host is displayed in the list of remote hosts.



Sensor Remote Event DestinationChoose Configuration>Communication>Remote Hosts>Event Destinations and Select Add.

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.



Applying Sensor ConfigurationChoose Apply Changes and Select Finish.

Complete the following steps to apply the Sensor configuration:


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.



IEV DownloadChoose Monitoring>IDS Event Viewer.

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.



IEV Installation

The IEV installation application is a wizard-based installation program. Complete the following steps to install the IEV application:

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.



IEV Installation (cont.)

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.




Step 9 The IEV application files are copied to the destination location. The IEV file copy process takes approximately five�seven 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:


Port Number 1025�65535 The UDP port number used for IDS communication.

Organization Name <Org Name> Alphanumeric identifier for a group of Cisco IDS components (for example, securitynoc).


Host Name <Hostname> Alphanumeric identifier for the Cisco Director (for example, director1).

Host ID 1�65535 Numeric identifier for the Cisco IDS Director.

Note This step does not add an IDS device to monitor. Adding a device to the IEV is described in the next step.




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 service�Responsible for receiving the alarms from remote devices

Cisco IDS Event Viewer service�Stores the alarms in MySQL database, archives the database files, and checks available disk space

MySQL service�Responsible for consistently storing the data and serving data when queried

Note 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.



Add IDS DevicesChoose File>New>Devices.

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:

Step 1 Choose Start>Programs>Cisco Systems>Cisco IDS Event Viewer>Cisco IDS Event Viewerto 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).


Host Name <Host Name> Alphanumeric identifier for the Sensor (for example, sensor1).

Host ID 1�65535 Numeric identifier for the Sensor.


Heartbeat 1�65535 Time interval that the Cisco IDS communication infrastructure uses when transmitting route verification messages.


Implementation�VPN 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� General� IPSec

Authenticate users and

terminate IPSec

Publicservices

PSTN

Internet

Implementation on the Concentrator includes but is not limited to setting up the following:

The IKE proposals that are used

Group configuration

� Identity

� General

� IPSec



Activate IKE Proposal

3002/Unity Client

2.5 Client

Certicom Client

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 client�s 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.



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 tab�Configure the group name, password, and group authentication server type.

General tab�Configure access rights and privileges, and access protocols.

IPSec tab�Configure IPSec tunneling parameters.

PPTP/L2TP tab�Configure 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 field�Enter a unique name for this specific group. The maximum is 32 characters.

Password field�Enter a unique password for this specific group. The minimum is 4 and maximum is 32 characters. The field displays only asterisks.

Verify field�Re-enter the group password to verify it. The field displays only asterisks.

Type drop-down menu�Click the drop-down menu button and choose the type of group:

� Internal�Use the internal Cisco VPN 3000 Concentrator authentication server to authenticate groups for IPSec tunneling. The internal server is the default selection.

� External�Use an external authentication server to verify this group, such as a RADIUS server.



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 menu�Click the drop-down menu button and select the named hours when group users can access the Cisco VPN 3000 Concentrator.

� No Restrictions�No restrictions on access hours.

� Never�No access at any time.

� Business hours�Access 9 a.m. to 5 p.m., Monday through Friday.

Simultaneous Logins field�Enter 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 field�Enter 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 box�Select 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 field�Enter 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 field�Enter the group maximum connection time in minutes. At the end of this time, the system terminates the connection.

Filter drop-down menu�Select the type of filter you wish to apply to this group.

Primary DNS field�Enter the primary IP address of the DNS server for this group�s users.

Secondary DNS field�Enter the IP address of the secondary DNS server for this group�s users.


Primary WINS field�Enter the primary IP address of the WINS server for this group�s users.

Secondary WINS field�Enter the secondary IP address of the WINS server for this group�s users.

SEP Card Assignment check boxes�It is recommended that you leave all four check boxes selected.

Tunneling Protocols check boxes�Select the tunneling protocols the user VPN Clients can use. (Although the Concentrator can support all four protocols simultaneously, in this chapter�s lab exercise, de-select PPTP and L2TP. Select IPSec only.)

Strip Realm check box�Select this check box only for PPTP, L2TP, or both.



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 menu�Click the drop-down menu button and choose the IPSec SA assigned to this group�s 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 menu�This option applies only to tunnel negotiations based on digital certificates.

IKE Keepalives check box�Select 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 box�By selecting the Reauthentication on Rekey checkbox, the Concentrator prompts the user for an identification and password whenever a re-key occurs. The default is disabled.

Tunnel Type drop-down menu�Click the drop-down menu and choose the remote access tunnel type. Choose Remote access for IPSec client to LAN applications.


Implementation�Layer 3 Switch This section describes the implementation of the Layer 3 switch in the SAFE SMR medium network campus module.


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

� set port security command

� show port command



As with most devices using Cisco IOS or Cisco IOS-like commands, ACLs can be used to implement Layer 3 and 4 filtering.



wildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-

range-name]


dynamic dynamic-name (Optional.) Identifies this ACLs as a dynamic ACL. 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.




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.












destination Number of the network or host to which the packet is being sent. There are three alternative ways to specify the destination:


Use the any keyword as an abbreviation for the destination and destination-wildcard of 0.0.0.0 255.255.255.255.


destination-wildcard Wildcard bits to be applied to the destination. There are three alternative ways to specify the destination wildcard:


Use the any keyword as an abbreviation for a destination and destination-wildcard of 0.0.0.0 255.255.255.255.


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.










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:

primary�Specifies the VLAN as the primary VLAN in a PVLAN

isolated�Specifies the VLAN as the isolated VLAN in a PVLAN

community�Specifies the VLAN as the community VLAN in a PVLAN

twoway-community�Specifies the VLAN as a bidirectional community VLAN that carries the traffic among community ports, and to and from community ports to and from the Multi-layer Switch Feature Card (MSFC)

none�Specifies 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]

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.



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

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.


Summary






Copyright 2003, Cisco Systems, Inc. SAFE SMR Midsize Network Design Lab 6-1

Lab Exercise�Medium Network Design Implementation


ObjectivesIn this exercise you will complete the following tasks:

Assign the Sensor�s IP network settings.

Define the lists of hosts that are allowed to access the Sensor.

Assign the Sensor�s communications infrastructure settings.

Enable the IDS Device Manager web server.

Save the Sensor�s initial configuration.

Verify the Sensor�s 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 Sensor�s 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 Sensor�s blocking properties.

Add a PIX Firewall as a blocking device.

Test the blocking configuration.


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.



.100

e0/1

PSSWWWFTP

172.16.P.0/24


e0/0

10.0.P.0 /24

Pod P (1�10)

192.168.P.0/24

.1 e2

pP

.4

pub

cP

.1

172.30.P.0/24

sensorP

DMZ

.2

.150

SuperServerWWWFTP

.10

.150

.5

priv

.5

.2 e0172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

rP

RTS

RBB

VPN Client

brP

Branch10.2.P.0/24

.10P e0/1

.50

.1 e0/010.2.P.11

172.26.26.P

Branch

10.0.P.11Student

SetupYou should not have to configure any routing or addressing of interfaces on lab equipment in this exercise. You may find that your sensor�s setting may already be configured. In this case, verify the settings are correct using the steps below before proceeding.

Task 1�Assign the Sensor�s IP Network Settings In this task you will assign an IP address to the Sensor�s command and control interface, a UNIX hostname, and a default route. Complete the following steps to assign the Sensor�s IP network settings:

Step 1 Access the terminal server as directed by your instructor:


½æÄ ¬»´²»¬ ïðòðòÐòïðð


Step 2 Access the Sensor via its console port as directed by your instructor:

®¬â Ð


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


Q1) In what situations would you not need a default route assigned to the Sensor?

A)

Task 2�Define 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.


Q2) Would you recommend being more restrictive? What other network addresses might be included, if any?

A)


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 3�Assign the Sensor�s Communications Infrastructure Settings This task involves configuring the Sensor�s IDS communication infrastructure parameter settings necessary for communication between the Sensor and Director. Complete the following steps to assign the Sensor�s 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 4

Sensor Organization ID P

Sensor Host Name sensorP

Sensor Organization Name podP

Sensor IP Address 10.0.P.4


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 2�3.

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 4�Enable 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.


Task 5�Save the Sensor�s Initial Configuration This task involves exiting the Cisco IDS Sensor Initial Configuration utility and rebooting the Sensor. Complete the following steps to save the Sensor�s 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 6�Verify the Sensor�s Network Configuration This task involves verifying the Sensor�s IP configuration and IDS communication parameters. Complete the following steps to verify the Sensor�s network configuration:


¸¬¬°æññïðòðòÐòì

(where P = pod number)Step 2 Click Yes when prompted to accept the Sensor�s certificate.



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 Sensor�s 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:

Cisco IDS Parameters Lab Values Description

Host Name sensorP The Sensor�s alphanumeric identifier.

Host ID 4 The Sensor�s numeric identifier.

Organization Name podP Alphanumeric identifier for a group of Cisco IDS components.

Organization ID P Numeric identifier for a collection of Cisco IDS Components.

PostOffice Port 45000 The UDP port number used for IDS communication.

Heartbeat Interval Multiplier 3 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).



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 Sensor�s 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 Sensor�s network settings.

Step 9 Click OK to save the Sensor�s network settings.



Task 7�Cisco 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:



Step 2 Click Yes when prompted to accept the Sensor�s certificate.



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:


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 P 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.



Heartbeat 5 Time interval that the Cisco IDS Communication Infrastructure uses when transmitting route verification messages.


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 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 8�Download 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 10�15 minutes depending on system performance.

Step 6 Log out of the IDM interface and close the web browser.


Task 9�Install 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 PC�s 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:


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 P 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


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 10�Add 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 Viewerto 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.


Step 3 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:


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 P Numeric identifier for a collection of Cisco IDS Components

Host Name sensorP Alphanumeric identifier for the Sensor

Host ID 4 Numeric identifier for the Sensor

PostOffice Port 45000 UDP port number used for IDS communication

Heartbeat 5 Time interval that the Cisco IDS Communication Infrastructure uses when transmitting route verification messages


Task 11�Disable the Sensor�s Insecure Remote Management Services This task involves disabling the Sensor�s Telnet and FTP services to enforce secure communication between the Sensor and management hosts. Complete the following steps to disable the Sensor�s insecure remote management services:

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:



Step 2 Click Yes when prompted to accept the Sensor�s certificate.




Step 6 Select Remote Access from the TOC. The Sensor�s 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 Sensor�s remote access settings.




Step 12 Attempt to establish a Telnet session to your Sensor. Access should be denied because your Sensor�s Telnet service is disabled.

Step 13 Attempt to establish an FTP session to your Sensor. Access should be denied because your Sensor�s 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 12�Configure 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 cazeroize command and repeat the ca gen command.

°·¨ø½±²º·¹÷ý ½¿ ¿ª» ¿´´

°·¨ø½±²º·¹÷ý ¸ ïðòðòÐòì îëëòîëëòîëëòîëë ·²·¼»

°·¨ø½±²º·¹÷ý ©®·¬» ³»³±®§


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.

°·¨ø½±²º·¹÷ý ¬¿¬·½ ø·²·¼»ô±«¬·¼»÷ ïçîòïêèòÐòïð ïðòðòÐòïï ²»¬³¿µ

îëëòîëëòîëëòîëë


Note The order of the existing ACL must be modified to permit the following entry.

°·¨ø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ïçîòïêèòÐòïð »¯ ©©©


Task 13�Exchange 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.


Q3) In what situations might Telnet be chosen instead of SSH?

A)

Step 2 Establish an SSH session as user pix to the PIX Firewall:

²»¬®¿²¹®à»²±®Ðæñ«®ñ²®â ¸ �´ °·¨ ïðòðòÐòï


Step 3 Accept the PIX Firewall�s SSH key by entering yes when prompted.

Note If you are not prompted to accept the PIX Firewall�s SSH key, the key was previously accepted. Proceed with the next step. If you are given a warning, delete the Sensor�s 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 14�Assign the Blocking Action to an IDS Signature Complete the following steps to configure a signature�s action to blocking:




Step 2 Log into the Cisco IDM as user netrangr. The default netrangr password is attack.


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.


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.



Task 15�Configure the Sensor�s Blocking Properties Complete the following steps to configure the Sensor�s blocking properties:


Step 2 Select Blocking from the sub-area bar. The Blocking TOC is displayed.

Step 3 Select Blocking Properties from the Blocking TOC. The Sensor�s 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:


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 Sensor�s IP address. This is the default setting.

Step 8 Click OK to save the Sensor�s blocking properties.

Step 9 If prompted, select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.


Task 16�Add a PIX Firewall as a Blocking Device Complete the following steps to add a PIX Firewall as a blocking device:



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 Sensor�s 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:


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 username�s password

Enable Password enable The blocking device�s enable or secret password


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 device�s 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.



Q5) List some guidelines to follow when deciding how to implement IP blocking.

A)

Task 17�Test the Blocking Configuration This task involves launching an attack against the target network that causes the signature to initiate the Sensor�s 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)


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


Note No spaces should be entered in the URL.

Step 4 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 shuncommand.

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 You can view the blocked hosts directly from the PIX Firewall by issuing the show shuncommand.

Step 7 Select Unblock All to remove all of the addresses from the list of blocked devices.

http://192.168.P.10/msadc/samples/selector/showcode.asp

http://192.168.P.10/scripts/..%c0%af../winnt/system32

http://192.168.P.10/


AnswersQ1) In what situations would you not need a default route assigned to the Sensor?

A) 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.

Q2) Would you recommend being more restrictive? What other network addresses might be included, if any?

A) 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.

Q3) In what situations might Telnet be chosen instead of SSH?

A) Allowing insecure communication is ultimately determined by a company�s 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.

Q4) Are these signatures good candidates to perform IP blocking if detected? Why or why not?

A) A company�s 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.

Q5) 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 network�s security.

E) Assign the appropriate block duration.

Q6) Were all the attacks detected by the Sensor and reported to the IEV? Why or why not?


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.

7

Remote User Network Implementation

OverviewThis 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


ObjectivesThis 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.

Copyright 2003, Cisco Systems, Inc. Remote User Network Implementation 7-3

Design OverviewThis 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


ISP edge moduleISP

Remote sitefirewall option

VPN Software

Client with personal firewall

Broadband access device

Home office

firewall with VPN

Remote siterouter option

Router with

firewall and VPN

Hardware VPNClient option


Hardware VPN

Client


(optional)

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 access�Remote user with a virtual private network (VPN) Software client and personal firewall software on the PC.

Remote-site firewall option�The 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 option�Remote 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 option�The 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.



IPSec Remote-User to LAN�Tunneling

The result of implementing IPSec remote-user to LAN tunneling is that the security perimeter of your organization is extended to include remote sites.

Applicationserver

10.0.1.10

VPN private IP10.0.1.5

VPN public IP192.168.1.5

Adapter (NIC) IP address172.31.1.1

Client IP address10.0.1.20

ISP

Internet

Telecommuter or mobile

worker

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



InternetApplicationserver

ISPISPVPN

head-end device

PPP connectivitydial access

IPSec tunnel or session

Telecommuter or mobile

worker

IPSec Remote-User to LAN Components

� Client software or hardware� PPP protocol (for dial access)� IPSec protocol� VPN head-end device

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

� Terminates the tunnels and sessions

� Encrypts, authenticates, and encapsulates data

� May provide both authentication and data encryption options


Key Devices and Threat Mitigation This section provides details of the key devices for remote-user network implementation.


SAFE Remote User�Key Devices

The following are the key devices:� 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

ISP

Key devices

Broadband access device Firewall with a VPN

or a router with a firewall and VPN

Hub

Hardware or Software VPN

Client

The following are the key devices in the SAFE remote-user configuration:

Broadband access device�Provides access to the broadband network (for example, DSL, cable, and so on)

Firewall with VPN support�Provides 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 hub�Provides connectivity for devices within the remote site, which can be integrated into the firewall or VPN Hardware Client

Personal firewall software�Provides device-level protection for individual PCs

Router with firewall and VPN support�Provides 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 Client�Provides secure, end-to-end encrypted tunnels between individual PCs and the corporate head-end


VPN Hardware Client�Provides secure, end-to-end encrypted tunnels between the remote site and the corporate head-end



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

The following threats are expected in this environment:

Unauthorized access�Any data that traverses a network that is not authorized.

Network reconnaissance�Information-gathering activities by which hackers collect data that is used to later compromise networks.

Virus and Trojan horse attacks�Viruses 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 spoofing�Posing as an authorized party in the data transmission by using the IP address of the of the data recipients.

Man�in-the-middle attacks�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.



Mitigation Options Overview

There are four basic options available to mitigate threats:� Hardware options

�Remote-site firewall�VPN Hardware Client�Remote-site router

� Software option�Software access

The following are the solutions for remote access network threat mitigation:

Remote site firewall�Use of a remote-site firewall can provide a high level of security.

Cisco VPN Hardware Client�Use 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 router�Use 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 access�Use of software for access provides security at a host level, which uses the host processor and memory.


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

The following are the specific attack mitigation roles for the software access option:

Authenticate remote site�Properly identify and verify a user or service

Terminate IPSec�Successfully establish an IPSec tunnel between the remote site and host site

Personal firewall and virus scanning for local attack mitigation�Allay the risk of virus infection at the remote site



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


ISP Edge Module

ISP

VPN Software

Client with a

personal firewall

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. Virus-scanning software is also recommended to mitigate viruses and Trojan horse programs infecting the PC.



Software Access Option�Implementation

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 deviceSoftware

access option

ISP Edge Module

ISP

VPN Software

Client with a

personal firewall

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



VPN Windows Client

192.168.1.5

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 Concentrator�s public interface is configured in the field Host name or IP address of the remote server.



Cisco VPN Client Options

The Options drop-down menu enables you to configure or change optional parameters. By clicking the Options button, the following options become available:

Clone Entry�Enables you to copy a connection entry with all its properties.

Delete Entry�Enables you to delete a connection entry.

Rename Entry�Enables you to rename a connection entry (it is not case sensitive).

Import Entry�Provides a pre-configured .pcf file that loads the VPN Client parameters.

Erase User Password�Eliminates 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 Shortcut�Enables you to create a shortcut for your desktop.

Properties�Enables 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 Launcher�Enables you to launch an application before establishing a connection. This is used in conjunction with Windows Login Properties.


Windows Logon Properties�Windows 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.



Properties Tabs

� General� Authentication� Connections

From the Options drop-down menu on the Cisco Systems VPN Client main screen, choose Properties. Within Properties there are three tabs:

General�Enables IPSec through Network Address Translation (NAT), displays the status of the local LAN access feature, and selects Microsoft network logon options.

Authentication�Configures the VPN Client�s group or digital certificate information.

Connections�Enables backup connections and links the VPN connection to Dialup Networking phonebook entries.



Properties�General Tab

Win 95/98/ME Win-NT 4/2000/XP

There are two versions of the General tab, depending on the operating system you are using:

The Windows 95,98, and ME version�Provides options for transparent tunneling, local LAN access, and Microsoft login options

Windows NT 4.0,2000, and XP version�Provides transparent tunneling and local LAN access only

The functions of the General tab are as follows:

Enable Transparent Tunneling check box�Works 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 button�Enables 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 button�Enables 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 box�For 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 field�The 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.


Logon to Microsoft Network check box�Works with Windows 95, 98, and ME only. The following are found within the Logon to Microsoft Network group box:

� Use default system logon credentials radio button�Use the logon username and password resident on your PC to log onto the Microsoft network (for example, student4).

� Prompt for network logon credentials radio button�If your logon username and password differ from the private network, the private network prompts you for the username and password.



Properties�Authentication Tab

The end-user never sees the password

after initial configuration.

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 drop-down 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.



Properties�Connections Tab

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.


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



Home office

firewall with a VPN

Stateful packet filtering, basic Layer 7 filtering, Host DoS mitigation, authenticate remote site, and terminate

IPSec

Virus scanning for local attack mitigation

This figure provides attack mitigation roles for the remote site firewall option:

Stateful packet filtering�Offers strong security by thoroughly inspecting data packets and maintaining critical addresses and port numbers in a lookup table

Basic Layer 7 filtering�Offers basic filtering at the application layer of the OSI model

Host DoS mitigation�Prevents host-based denial of service (DoS) attacks

Authenticate remote site�Properly identifies and verifies a user or service

Terminate IPSec�Successfully establishes an IPSec tunnel between the remote site and host site

Virus scanning for local attack mitigation�Allays the risk of virus infection at the remote site



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

ISP



Home office

firewall with a VPN

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 remote-site 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


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 site�just like all the PCs in the entire corporation.



PIX Firewall�Implementation 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



Home office

firewall with a VPN

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 interface�Implements Unicast RPF IP spoofing protection

� icmp�Enable or disable pinging to an interface

� attack guard commands�Enabled by default

� static/nat�Implements static or dynamic nat






PIX Firewall�Implementation 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



Home office

firewall with a VPN

aaa-server�Specifies an authentication, authorization, and accounting (AAA) server

aaa authentication�Enables, disables, or views LOCAL, Terminal Access Controller Access Control System (TACACS+), or Remote Access Dial-In User Service (RADIUS) user authentication

logging on�Enables or disables Syslog and Simple Network Management Protocol (SNMP) logging

sysopt connection permit-ipsec�Implicitly permits any packet that came from an IPSec tunnel

isakmp enable�Enables Internet Security Association Key Management Protocol (ISAKMP) negotiation on the interface on which the IPSec peer communicates with the PIX Firewall

isakmp key�Specifies the authentication pre-shared key

isakmp policy�Uniquely identifies the IKE policy and assigns a priority to the policy

crypto ipsec transform-set�Creates, views, or deletes IPSec security associations (SAs), SA global lifetime values, and global transform sets

crypto map�Creates, modifies, views, or deletes a crypto map entry



Terminate IPSec�Sysopt connection permit-ipsec and isakmp enable

� 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.


°·¨º·®»©¿´´ø½±²º·¹÷ý §±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

� Used to enable ISAKMP negotiation on the interface on which the IPSec peer will communicate with the PIX Firewall. This is enabled by default.

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° »²¿¾´» ±«¬·¼»


§±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

·¿µ³° »²¿¾´» ·²¬»®º¿½»ó²¿³»

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-groupcommand 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, oraccess-group command statement for IPSec connections.

The syntax for the isakmp enable command is as follows:

isakmp enable interface-name

interface-name The name of the interface on which to enable ISAKMP negotiation.



Terminate IPSec�isakmp key

� 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.


°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïéîòîêòîêòïðï ²»¬³¿µ îëëòîëëòîëëòð

·¿µ³° µ»§ µ»§¬®·²¹ ¿¼¼®» °»»®ó¿¼¼®»Å²»¬³¿µ ³¿µÃ Å²±ó¨¿«¬¸Ã Å²±ó½±²º·¹ó³±¼»Ã

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


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]

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 pre-shared key with a gateway and allows an exception to the Xauth feature enabled by the crypto map client authenticationcommand.

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.



Terminate IPSec�isakmp policy

� Sets the various parameters of the IKE policy that will be used

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð ¸¿¸ ¸¿

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð ¹®±«° ï

°·¨º·®»©¿´´ø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð


·¿µ³° °±´·½§ °®·±®·¬§ »²½®§°¬·±² ¼» ¤ í¼»

·¿µ³° °±´·½§ °®·±®·¬§ ¸¿¸ ³¼ë ¤ ¸¿

·¿µ³° °±´·½§ °®·±®·¬§ ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®» ¤ ®¿ó·¹

·¿µ³° °±´·½§ °®·±®·¬§ ¹®±«°ï ¤ î

·¿µ³° °±´·½§ °®·±®·¬§ ´·º»¬·³» »½±²¼

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.


isakmp policy priority hash md5 | sha


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.



isakmp policy priority authentication pre-share | rsa-sig


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.


isakmp policy priority group1 | 2


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.


isakmp policy priority lifetime seconds


lifetime seconds Specifies how many seconds each security association should exist before expiring. Use an integer from 120 to 86,400 seconds (one day).



Terminate IPSec�crypto ipsec transform-set

� 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.


°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ¬®¿²º±®³ó»¬ó²¿³» ¬®¿²º±®³ï Å¬®¿²º±®³î Å¬®¿²º±®³íÃÃ

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 theshow 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 entry�s 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 peer�s 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 �transforms��each 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.


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 sacommand.

The syntax for the crypto ipsec transform-set command is as follows:

crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

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.



Implementation Commands�Terminate IPSec (cont.)

� Sets the various parameters of the IKE policy that will be used.

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ îð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÐÍÍ

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ °»»® ïéîòîêòîêòïðï

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ ¬®¿²º±®³ó»¬ ³§»¬

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»


½®§°¬± ³¿° ³¿°ó²¿³» »¯ó²«³ ·°»½ó·¿µ³° ¤ ·°»½ó³¿²«¿´ Å¼§²¿³·½¼§²¿³·½ó³¿°ó²¿³»Ã

½®§°¬± ³¿° ³¿°ó²¿³» »¯ó²«³ ³¿¬½¸ ¿¼¼®» ¿½´Á²¿³»

½®§°¬± ³¿° ³¿°ó²¿³» »¯ó²«³ »¬ °»»® ¸±¬²¿³» ¤ ·°ó¿¼¼®»

½®§°¬± ³¿° ³¿°ó²¿³» »¯ó²«³ »¬ ¬®¿²º±®³ó»¬ ¬®¿²º±®³ó»¬ó²¿³»ïÅ ¬®¿²º±®³ó»¬ó²¿³»êÃ

½®§°¬± ³¿° ³¿°ó²¿³» ·²¬»®º¿½» ·²¬»®º¿½»ó²¿³»

To create or modify a crypto map entry, use the crypto map ipsec-manual | ipsec-isakmpcommand. To create or modify an ipsec-manual crypto map entry, use the ipsec-manual optionof the command. To create or modify an ipsec-isakmp crypto map entry, use the ipsec-isakmpoption 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 forwarded�these 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


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.


crypto map map-name seq-num match address acl_name



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.


crypto map map-name seq-num set peer hostname | ip-address



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.


crypto map map-name seq-num set transform-set transform-set-name1 [transform-set-name6]




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.


crypto map map-name interface interface-name



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.


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



Hardware VPN

ClientPersonal firewall and virus scanning for local attack

mitigation

Authenticate remote site and terminate IPSec

The following are the mitigation roles for the VPN Hardware Client:



Personal firewall and virus scanning for local attack mitigation�Provides firewall inspection and allays the risk of virus infection at the remote site



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



Hardware VPN

Client

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.



Hardware VPN Client�Implementation

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

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 PC�s 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.



GUI

Table of contents

Toolbar

Manager screen

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 Manager�s windows.

The main frame (Manager�s) 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.



Quick Configuration

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.



Quick Configuration Example Screens

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.



Launching the Client

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.


Remote Site Router Option This section summarizes the remote-site router option and provides configuration details.


Remote Site Router�Attack Mitigation Roles

ISP



Router with a firewall

and a VPN

Virus scanning for local attack mitigation

Host DoS mitigation, stateful packet filtering, basic Layer 7 filtering,

authenticate the remote site, and terminate IPSec

The following are the attack mitigation roles for the remote-site router option:

Host DoS mitigation�Prevents host-based DoS attacks

Stateful packet filtering�Offers strong security by thoroughly inspecting data packets and maintaining critical addresses and port numbers in a lookup table

Basic Layer 7 filtering�Offers basic filtering at the application layer of the OSI model



Virus scanning for local attack mitigation�Allays the risk of virus infection at the remote site



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)

ISP




and a VPN

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.



Cisco IOS�Implementation 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


� 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




and a VPN









� aaa new-model�To define a set of inspection rules, enter this command for each protocol that you want to inspect, using the same inspection-name.


� aaa authentication login�Enables AAA authentication at login.







Cisco IOS�Implementation Commands Summary (cont.)

� IPSec commands�Provides 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




and a VPN

IPSec commands�Provide for IPSec tunnel termination


� encryption�Sets the algorithm to be negotiated.

� authentication�Specifies the authentication method within an IKE policy.

� group�Specifies the AAA server group to use for pre-authentication.









Terminate IPSec�Enable IKE and Define IKE Policy

� Enable Internet Key Exchange.

router(config)#

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ·¿µ³° »²¿¾´»

� Defines an Internet Key Exchange policy� Invokes the Internet Security Association Key

Management Protocol policy configuration (config-isakmp) command mode.

router(config)#

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ·¿µ³° °±´·½§ ïïð

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý

½®§°¬± ·¿µ³° »²¿¾´»

½®§°¬± ·¿µ³° °±´·½§ °®·±®·¬§

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.


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 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.



Terminate IPSec�ISAKMP Policy Configuration

� 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.

Router (config-isakmp) #

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý »²½®§°¬·±² í¼»

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý ¸¿¸ ¸¿

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý ¹®±«° ï

®±«¬»®ø½±²º·¹ó·¿µ³°÷ý ´·º»¬·³» èêìðð

»²½®§°¬·±² ¥¼» ¤ í¼»£¸¿¸ ¥¸¿ ¤ ³¼ë£¿«¬¸»²¬·½¿¬·±² ¥®¿ó·¹ ¤ ®¿ó»²½® ¤ °®»ó¸¿®»£¹®±«° ¥ï ¤ î£´·º»¬·³» »½±²¼

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 SHA-1. 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.

� 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.


� 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 other�s public keys but do not use a CA. Instead, there are two ways for peers to get each other�s 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}

1 Specifies the 768-bit DH group.

2 Specifies the 1024-bit DH group.


The syntax for the lifetime command is as follows:

lifetime seconds

seconds Number of seconds that each SA should exist before expiring. Use an integer from 60 to 86,400 seconds.



Terminate IPSec�Configure 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.

½®§°¬± ·¿µ³° µ»§ µ»§¬®·²¹ ¿¼¼®» °»»®ó¿¼¼®»

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ¬®¿²º±®³ó»¬ó²¿³» ¬®¿²º±®³ï Å¬®¿²º±®³î Å¬®¿²º±®³íÃÃ

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 peer�s identity should be set to either its hostname or by its IP address. By default, a peer�s 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 entry�s 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 peer�s IPSec SAs.

To define a transform set, you specify one to three �transforms��each 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.


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]]

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.



Terminate IPSec�Specify 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

³±¼» Å¬«²²»´ ¤ ¬®¿²°±®¬Ã

½®§°¬± ³¿° ³¿°ó²¿³» »¯ó²«³ ·°»½ó·¿µ³°Å¼§²¿³·½ ¼§²¿³·½ó³¿°ó²¿³»Ã Å¼·½±ª»®Ã

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


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]

map-name The name that identifies the crypto map set. This is the name assigned when the crypto map was created.


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.



Terminate IPSec�Identify an ACL and Specify Transform Sets

Router (config-crypto-map) #

®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý ³¿¬½¸ ¿¼¼®» ïðí

� Identifies the extended ACL


®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý »¬ ¬®¿²º±®³ó»¬ ³§»¬

� Specifies which transform sets can be used with the crypto map entry

»¬ ¬®¿²º±®³ó»¬ ¬®¿²º±®³ó»¬ó²¿³»Å¬®¿²º±®³ó»¬ó²¿³»îòòò¬®¿²º±®³ó»¬ó²¿³»êÃ

³¿¬½¸ ¿¼¼®» ¿½½»ó´·¬ó·¼

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 interface�s 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 interface�s 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.)


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 settransform-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 peer�s 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]


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.



Terminate IPSec�Specify an IPSec Peer and Apply a Crypto Map to the Interface


®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý »¬ °»»® ïçîòïêèòïòî

� Specifies the IPSec peer

Router (config-if) #

®±«¬»®ø½±²º·¹ó·º÷ý ½®§°¬± ³¿° ³§³¿°

� Applies a previously defined crypto map set to an interface

½®§°¬± ³¿° ³¿°ó²¿³»

»¬ °»»® ·°ó¿¼¼®»

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 peer�s 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.


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.


SummaryThis 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



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.

Copyright 2003, Cisco Systems, Inc. Remote User Network Implementation Lab 7-1

Lab Exercise�Remote User Network Design Implementation



Section 1�Site-to-site VPN configuration

Section 2�Client-to-LAN VPN configuration

Section 3�Perimeter router configuration

Section 4�Network device management (Optional.)




Section 1�Site-to-Site VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

ObjectivesIn 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.


SetupBefore starting this lab exercise, set up your equipment as follows:

Ensure that your PIX Firewall is turned on.

Access the PIX Firewall�s console port.

Save your PIX Firewall�s configuration from the previous lab exercise to a text file.

Ensure that your branch office router is turned on.

Access the branch office router�s console port.

Task 1�Prepare 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:

°·¨Ðø½±²º·¹÷ý §±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½


Task 2�Configure 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:

°·¨Ðø½±²º·¹÷ý ·¿µ³° »²¿¾´» ±«¬·¼»

(where P = pod number)Step 2 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:

°·¨Ðø½±²º·¹÷ý ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïéîòîêòîêòïðÐ ²»¬³¿µ îëëòîëëòîëëòð



Step 3 Create an IKE policy by completing the following sub-steps. Use the following parameter values:

Policy priority number�10

Encryption algorithm�3des

Hash algorithm�sha

Authentication method�pre-share

Diffie-Hellman group identifier�1

SA lifetime�86400

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 Association�s (SA�s) lifetime:

°·¨Ðø½±²º·¹÷ý ·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

(where P = pod number)Step 4 View all existing IKE policies:

°·¨Ðø½±²º·¹÷ý ¸±© ·¿µ³° °±´·½§


Task 3�Configure 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 encrypted�Traffic between corporate internal networks and branch office networks


Peer network address�IP address of branch office network

Access list name�NONAT_INSIDE

Access list name�NONAT_PSS

Protocol�Any Internet protocol

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòÐòð îëëòîëëòîëëòð ïðòîòÐòð îëëòîëëòîëëòð

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëòð ïðòîòÐòð îëëòîëëòîëëòð

(where P = pod number)Step 2 Configure NAT so that the addresses in the VPN tunnel are not translated for the internal

corporate network:

°·¨Ðø½±²º·¹÷ý ²¿¬ ø·²·¼»÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ

(where P = pod number)Step 3 Configure NAT so that the addresses in the VPN tunnel are not translated for the public services

segment server:

°·¨Ðø½±²º·¹÷ý ²¿¬ øÐÍÍ÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁÐÍÍ

(where P = pod number)Step 4 Configure an IPSec transform set (IKE phase two parameters). Use the following parameter

values:

Transform name�myset

ESP protocols�3des

Mode�tunnel

°·¨Ðø½±²º·¹÷ý ½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

(where P = pod number)Step 5 Create a crypto map by completing the following sub-steps. Use the following parameter values:

Crypto map name�branch

Map number�10

Key exchange type�isakmp

Peer�172.26.26.10P(where P = pod number)

Transform set�myset

Match address�NONAT_INSIDE


Map number�20

Match address�NONAT_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 peer�s 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 peer�s 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.

°·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ îð »¬ ¬®¿²º±®³ó»¬ ³§»¬

(where P = pod number)Step 6 Apply the crypto map set to the outside interface:

°·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»

(where P = pod number)Step 7 Verify your crypto map configuration:

°·¨Ðø½±²º·¹÷ý ¸±© ½®§°¬± ³¿°

(where P = pod number)Step 8 Save your configuration:

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)Step 9 Verify your PIX Firewall configuration is similar to the following configuration for pix1:

°·¨Ðý ©®·¬» ¬»®³·²¿´


æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ·²¬ºì »½«®·¬§îð

²¿³»·º »¬¸»®²»¬ë ·²¬ºë »½«®·¬§îë

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

¼±³¿·²ó²¿³» °±¼ïò½±³

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»




¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§



¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ïçîòïêèòïòïð »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°


¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§

¿½½»ó´·¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð

°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï


·²¬»®º¿½» »¬¸»®²»¬ð ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ¸«¬¼±©²

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð



³¬« ·²¬ºì ïëðð






·° ¿¼¼®» ·²¬ºì ïîéòðòðòï îëëòîëëòîëëòîëë


·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºì ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºë ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð



²¿¬ ø·²·¼»÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ


²¿¬ øÐÍÍ÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁÐÍÍ



¬¿¬·½ ø·²·¼»ô±«¬·¼»÷ ïçîòïêèòïòïð ïðòðòïòïï ²»¬³¿µ îëëòîëëòîëëòîëë ð ð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»


¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

®±«¬» ±«¬·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï

¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

§±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

²± §±°¬ ®±«¬» ¼²¿¬

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ ïð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁ×ÒÍ×ÜÛ

½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ °»»® ïéîòîêòîêòïðï

½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ îð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ îð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÐÍÍ

½®§°¬± ³¿° ¾®¿²½¸ îð »¬ °»»® ïéîòîêòîêòïðï

½®§°¬± ³¿° ¾®¿²½¸ îð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»

·¿µ³° »²¿¾´» ±«¬·¼»

·¿µ³° µ»§ öööööööö ¿¼¼®» ïéîòîêòîêòïðï ²»¬³¿µ îëëòîëëòîëëòð

·¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

·¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»

·¿µ³° °±´·½§ ïð ¸¿¸ ¸¿

·¿µ³° °±´·½§ ïð ¹®±«° ï

·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

¬»´²»¬ ¬·³»±«¬ ë

¸ ïðòðòïòì îëëòîëëòîëëòîëë ·²·¼»

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æêç¼¿ééï¿íïìðë¿ê¼è¼¾ºº¿º¼ç¿éº¾è¿¿

æ »²¼

Task 4�Configure Routing and IKE Parameters on the Branch Office Router

Complete the following steps to configure IKE on the branch office router:


Step 1 Add a static route to the corporate internal networks:

¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïéîòïêòÐòð îëëòîëëòîëëòð ïçîòïêèòÐòî

¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòðòÐòð îëëòîëëòîëëòð ïçîòïêèòÐòî

(where P = pod number)Step 2 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.

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ïéîòïêòÐòð ðòðòðòîëë ¿²§ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòÐòð ðòðòðòîëë ¸±¬ ïéîòîêòîêòïðÐ ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòÐòð ðòðòðòîëë ¿²§ ´±¹

(where P = pod number)Step 3 Enable IKE and ISAKMP on the router:

¾®Ðø½±²º·¹÷ý ½®§°¬± ·¿µ³° »²¿¾´»

(where P = pod number)Step 4 Configure the ISAKMP pre-shared key to point to the outside IP address of the PIX Firewall:

¾®Ðø½±²º·¹÷ý ½®§°¬± ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïçîòïêèòÐòî

(where P = pod number)Step 5 Create an IKE policy by completing the following sub-steps. Use the following parameter values:






SA lifetime�86400

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:


¾®Ðø½±²º·¹ó·¿µ³°÷ý ¸¿¸ ¸¿

(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:

¾®Ðý ¸±© ½®§°¬± ·¿µ³° °±´·½§


Task 5�Configure 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:

¾®Ðý ½±²º·¹ ¬»®³·²¿´

(where P = pod number)Step 2 Define a transform set. Use the following parameters:



Mode�tunnel

¾®Ðø½±²º·¹÷ý ½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

¾®Ðø½º¹ó½®§°¬±ó¬®¿²÷ý ³±¼» ¬«²²»´

¾®Ðø½º¹ó½®§°¬±ó¬®¿²÷ý »²¼

(where P = pod number)Step 3 Save your configuration:


¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)Step 4 Verify your configuration:

¾®Ðý ¸±© ½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬


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 permitted�all

Peer address�The PIX Firewall�s outside interface

ACL number�103


Step 5 Ensure that you are in configuration mode:

¾®Ðø½±²º·¹÷ý ½±²º·¹ ¬»®³·²¿´

(where P = pod number)Step 6 Create the crypto ACL:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïéîòïêòÐòð ðòðòðòîëë ´±¹

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòÐòð ðòðòðòîëë ´±¹


Configure Crypto Maps Complete the following steps to configure a crypto map. Use the following parameters:

Crypto map name�mymap

Map number�10


Peer�192.168.P.2(where P = pod number)

transform set�myself

match address�103


Step 7 Set the name of the map, the map number, and the type of key exchange to be used:

¾®Ðø½±²º·¹÷ý ½®§°¬± ³¿° ³§³¿° ïð ·°»½ó·¿µ³°

(where P = pod number)Step 8 Specify the extended ACL to use with this map:

¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý ³¿¬½¸ ¿¼¼®» ïðí

(where P = pod number)Step 9 Specify the transform set you defined earlier:

¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý »¬ ¬®¿²º±®³ó»¬ ³§»¬

(where P = pod number)Step 10 Assign the VPN peer using the hostname or IP address of the peer:

¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý »¬ °»»® ïçîòïêèòÐòî

(where P = pod number)Step 11 Exit the crypto map configuration mode:

¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý »²¼

(where P = pod number)Step 12 Check your configuration:

¾®Ð ý ¸±© ½®§°¬± ³¿°


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 configure�ethernet 0/1

Crypto map to use�mymap

Step 13 Access the interface configuration mode:

¾®Ðø½±²º·¹÷ý ·²¬»®º¿½» »¬¸»®²»¬ ðñï

(where P = pod number)Step 14 Assign the crypto map to the interface:

¾®Ðø½±²º·¹ó·º÷ý ½®§°¬± ³¿° ³§³¿°

(where P = pod number)Step 15 Exit interface configuration mode:

¾®Ðø½±²º·¹ó·º÷ý »²¼

(where P = pod number)Step 16 Save the configuration:

¾®Ðý ©®·¬» ³»³±®§


Task 6�Configure 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:

¾®Ðý ½´»¿® ·° ²¿¬ ¬®¿² ö

(where P = pod number)Step 2 Remove the previously configured NAT statement:

¾®Ðø½±²º·¹÷ý ²± ·° ²¿¬ ·²·¼» ±«®½» ¬¿¬·½ ïðòîòÐòïï ïéîòîêòîêòïïÐ

(where P = pod number)Step 3 Create an ACL that defines traffic destined to the corporate network is not translated (no-NAT)

and all other traffic is translated (NAT):

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïéîòïêòÐòð ðòðòðòîëë

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòÐòð ðòðòðòîëë

(where P = pod number)Step 4 Continue creating an ACL that defines traffic destined to the corporate network is not translated

(no-NAT) and all other traffic is translated (NAT):

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðì °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ¿²§

(where P = pod number)Step 5 Configure the following route map to set up no NAT in the VPN tunnel:

¾®Ðø½±²º·¹÷ý ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ïð

¾®Ðø½±²º·¹ó®±«¬»ó³¿°÷ý ³¿¬½¸ ·° ¿¼¼®» ïðì

¾®Ðø½±²º·¹÷ý ·° ²¿¬ ·²·¼» ±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» »¬¸»®²»¬ðñï ±ª»®´±¿¼

(where P = pod number)Step 6 Save the configuration to memory:

¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)Step 7 Check your configuration against the following example configuration for branch office router 1:

¾®ïý ©®·¬» ¬»®³·²¿´

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ

ª»®·±² ïîòï

»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ


²± ´±¹¹·²¹ ½±²±´»

»²¿¾´» »½®»¬ ë üïü½»ðüïª³³²¹Ø©¾òÚÞÕÆÑÒÝ½ÉÆëò


ÿ

«»®²¿³» ¬«¼»²¬ °¿©±®¼ é ðîïëïðìÛðÚðíðïíë

ÿ

ÿ

ÿ

ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

½®§°¬± ·¿µ³° °±´·½§ ïïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

½®§°¬± ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïçîòïêèòïòî

ÿ

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ³§³¿° ïð ·°»½ó·¿µ³°

»¬ °»»® ïçîòïêèòïòî

»¬ ¬®¿²º±®³ó»¬ ³§»¬

³¿¬½¸ ¿¼¼®» ïðí

ÿ


ÿ

ÿ

ÿ

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

½®§°¬± ³¿° ³§³¿°

ÿ

®±«¬»® »·¹®° ï



²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ²¿¬ ·²·¼» ±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼

·° ½´¿´»

·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòî

·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòî

²± ·° ¸¬¬° »®ª»®

ÿ


¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹






¿½½»ó´·¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¸±¬ ïéîòîêòîêòïðï ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¿²§ ´±¹





¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹


¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ´±¹

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ´±¹

¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðì °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§

²± ½¼° ®«²

®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ïð

³¿¬½¸ ·° ¿¼¼®» ïðì

ÿ

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ

¾¿²²»® ´±¹·² ÂÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý±³°¿²§ ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð


»²¼


Task 7�Verify 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.

°·¨Ðø½±²º·¹÷ý ¸±© ½®§°¬± ·°»½ ¿

(where P = pod number)Step 3 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 server�s private address.

Step 4 Confirm your configuration on the branch office router:

¾®Ðý ¸±© ½®§°¬± ·°»½ ¿

(where P = pod number)Step 5 Confirm that the branch office network addresses have not been translated:

¾®Ðý ¸±© ·° ²¿¬ ¬®¿²

(where P = pod number)Step 6 Confirm that the appropriate ACL hit-counters are being incremented:

¾®Ðý ¸±© ¿½½»ó´·¬



Section 2�Client-to-LAN VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

ObjectivesIn 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.



Ensure that your Concentrator is turned on.

Access the perimeter router�s console port.

Task 1�Configure 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 Concentrator�s 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 Name�podP_group(where P = pod number)

Group Password�podP_group(where P = pod number)

Confirm Password�podP_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.


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 Split Tunneling should not be allowed in a production environment.

Step 14 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 2�Reset 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 Check with your instructor to see if this needs to be done.

Step 1 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:

Login�admin

Password�admin

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:

ï÷ Ý±²º·¹«®¿¬·±²

î÷ ß¼³·²·¬®¿¬·±²

í÷ Ó±²·¬±®·²¹

ì÷ Í¿ª» Ý¸¿²¹» ¬± Ý±²º·¹ Ú·´»


ë÷ Ø»´° ×²º±®³¿¬·±²

ê÷ Û¨·¬

Ó¿·² óâ

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 3�Configure the Concentrator Via CLI Complete the following steps using the Concentrator CLI to configure the Concentrator�s private and public interfaces:

Configure the Private LAN Interface Via CLI Quick Configuration Complete the following steps to configure the Concentrator�s private Ethernet interface using the CLI:

Note You may have to press Enter several times to get a login prompt.

Step 1 Log into the console by entering the login name and password as follows:

Login�admin

Password�admin

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 A Concentrator received from the factory presents a slightly different order of prompts than one that was rebooted to factory defaults.

Step 3 Enter the IP address for Ethernet 1 (Private):

Ï«·½µ Û¬¸»®²»¬ ïóâ ÅðòðòðòðÃ ïéîòïèòÐòë

(where P = pod number)Step 4 Enter the subnet mask for Ethernet 1:


Ï«·½µ Û¬¸»®²»¬ ïóâ ÅîëëòðòðòðÃ îëëòîëëòîëëòð

Ï«·½µ Û¬¸»®²»¬ ïóâ Å í Ã í øïðñïðð Ó¾° ¿«¬± ¼»¬»½¬÷

Ï«·½µ Û¬¸»®²»¬ ïóâ Å ï Ã ï øØ¿´ºñÚ«´´ñß«¬±÷

Step 5 Complete the rest of the prompts:

Ï«·½µ óâ ¸ ø¸ · ¬¸» ¸±®¬ ½«¬ ½±³³¿²¼ ¬± ¬¸» ¬±° ´»ª»´ ³»²«ò÷

Ó¿·² óâ ì øÍ¿ª» ½¸¿²¹» ¬± ¬¸» ½±²º·¹ º·´»ò÷

Ó¿·² óâ ê ø»¨·¬÷

Warning If you do not exit, the CLI will take you through the Quick Configuration via the GUI instead.

Step 6 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:

Login�admin

Password�admin

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:

Ó¿·²óâ ï øÝ±²º·¹«®¿¬·±²÷

Ý±²º·¹óâ î øÍ§¬»³ Ó¿²¿¹»³»²¬÷

Í§¬»³ óâ ì ø×Ð Î±«¬·²¹÷


Î±«¬·²¹ óâ î øÜ»º¿«´¬ Ù¿¬»©¿§÷

Î±«¬·²¹ óâ ï øÍ»¬ Ü»º¿«´¬ Ù¿¬»©¿§÷

Î±«¬·²¹ óâ ïçîòïêèòÐòïëð

(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 4�Configure 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 Firewall�s console as directed by the instructor.

Step 2 Assign a name and security level to Ethernet interface 4:

°·¨Ðø½±²º·¹÷ý ²¿³»·º »ì ®¿ª°² »½«®·¬§éë

(where P = pod number)Step 3 Enable the Ethernet 4 interface for 100 Mbps Ethernet full duplex communication:

°·¨Ðø½±²º·¹÷ý ·²¬»®º¿½» »ì ïððº«´´

(where P = pod number)Step 4 Assign an IP address to the remote access VPN network interface:

°·¨Ðø½±²º·¹÷ý ·° ¿¼¼®» ®¿ª°² ïéîòïèòÐòï îëëòîëëòîëëòð


(where P = pod number)Step 5 Configure a static translation on the PIX Firewall between the internal network and the remote

access VPN network:

°·¨Ðø½±²º·¹÷ý ¬¿¬·½ ø·²·¼»ô®¿ª°²÷ ïðòðòÐòð ïðòðòÐòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

(where P = pod number)Step 6 Configure a static translation on the PIX Firewall between the public services segment network

and the remote access VPN network:

°·¨Ðø½±²º·¹÷ý ¬¿¬·½ ø®¿ª°²ô °÷ ïðòðòøÐõîð÷òð ïðòðòøÐõîð÷òð ²»¬³¿µ îëëòîëëòîëëòð ð ð

(where P = pod number)Step 7 Add an ACL named �RAVPN� to the PIX Firewall to allow Concentrator traffic to the internal

network at 10.0.P.0:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ¿²§

(where P = pod number)Step 8 Apply the ACL to the ravpn interface of the PIX Firewall:

°·¨Ðø½±²º·¹÷ý ¿½½»ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°²

(where P = pod number)Step 9 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:

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

°·¨ïø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´

æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ®¿ª°² »½«®·¬§éë


²¿³»·º »¬¸»®²»¬ë ·²¬ºë »½«®·¬§îë

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

¼±³¿·²ó²¿³» °±¼ïò½±³

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»




¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§




¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°


¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§



¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ¿²§

¿½½»ó´·¬ ÒÑÒßÌÁÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð

°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ¸«¬¼±©²


·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð



³¬« ®¿ª°² ïëðð






·° ¿¼¼®» ®¿ª°² ïéîòïèòïòï îëëòîëëòîëëòð


·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ®¿ª°² ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºë ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð



²¿¬ ø·²·¼»÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ



²¿¬ ø®¿ª°²÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁÎßÊÐÒ

²¿¬ ø®¿ª°²÷ î ïðòðòîïòð îëëòîëëòîëëòð ð ð




¬¿¬·½ ø·²·¼»ô®¿ª°²÷ ïðòðòïòð ïðòðòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¬¿¬·½ ø®¿ª°²ôÐÍÍ÷ ïðòðòîïòð ïðòðòîïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°²



®±«¬» ®¿ª°² ïðòðòîïòð îëëòîëëòîëëòð ïéîòïèòïòë ï

¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

§±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

²± §±°¬ ®±«¬» ¼²¿¬

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ ïð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁ×ÒÍ×ÜÛ


½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ îð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ îð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÐÍÍ


½®§°¬± ³¿° ¾®¿²½¸ îð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ íð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ íð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÎßÊÐÒ

½®§°¬± ³¿° ¾®¿²½¸ íð »¬ °»»® ïéîòîêòîêòïðï

½®§°¬± ³¿° ¾®¿²½¸ íð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»

·¿µ³° »²¿¾´» ±«¬·¼»


·¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

·¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»

·¿µ³° °±´·½§ ïð ¸¿¸ ¸¿

·¿µ³° °±´·½§ ïð ¹®±«° ï

·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

¬»´²»¬ ¬·³»±«¬ ë


¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æç½è»î¼¿¿»¼èêðï½»éè¿ë½¼èç¿½íííè¾¼

æ »²¼



Task 5�Configure 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 Concentrator�s 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:

Login�admin

Password�admin

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 Name�studentP VPN (where P = pod number)

New Time�Verify the current time and date

DST Support�Enable

DNS Server�0.0.0.0 (which is the default)

Domain Name�podP.com(where P = pod number)


Default Gateway�192.168.P.150(where P = pod number)

Step 9 Click Continue. The Protocol screen is displayed.

Configuration>Quick>ProtocolsComplete the following steps to enable the tunneling protocols for this lab exercise:

Step 10 Configure the following Protocol parameter values:

PPTP�Disable

L2TP�Disable

IPSec�Enable

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 Pool�Enabled (select the check box)

Range Start�10.0.(P+20).17(where P = pod number)

Range End�10.0.(P+20).30(where P = pod number)

Step 13 Click Continue. The Authentication screen is displayed.

Configuration>Quick>AuthenticationComplete 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:

Username�studentP(where P = pod number)


Password�studentP(where P = pod number)

Verify password�studentP(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.


Password�podP_group(where P = pod number)

Verify�podP_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>DoneYou 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.


Task 6�Configure 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 If Cisco VPN Client-3DES-MD5 is not at the top of the Active Proposals list, click the Move Upbutton to place it there. If it is already there, proceed on to Step 3.

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 Concentrator�s default gateway parameters for IP routing:

Step 4 Choose Configuration>System>IP Routing>Default Gateways.

Step 5 Enter the following Default Gateway parameter values:


Metric�1

Tunnel default gateway�172.18.P.1(where P = pod number)

Override Default Gateway�Enabled

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.


Step 10 Enter the following Manager Address parameter values:

IP Address�10.0.P.0(where P = pod number)

IP Mask�255.255.255.0

Access Group�Group 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 Address�10.0.(P+20).16(where P = pod number)

IP Mask�255.255.255.240

Access Group�Group 1 (admin)


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 Address�10.0.(P+20).0(where P = pod number)

IP Mask�255.255.255.240

Access Group�Group 5 (User)



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.


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 45 Choose Student PC from the drop-down menu next to the Split Tunneling Network List Attribute.




Task 7�Configure 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.

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòøÐõîð÷òð ðòðòðòîëë ¿²§

(where P = pod number)Step 2 Add an ACL entry to define that traffic from the branch office network to the Concentrator

network is encrypted:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòøÐõîð÷òð ðòðòðòîëë

(where P = pod number)Step 3 Add an ACL to define that traffic from the branch office network is not translated (no-NAT)

when going to the Concentrator network:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòøÐõîð÷òð ðòðòðòîëë

(where P = pod number)Step 4 Add a static route to the VPN Client pool network:

¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ïçîòïêèòÐòî

(where P = pod number)Step 5 Save your configuration and compare your configuration to the following sample configuration

from br1:

¾®Ðý ©®·¬» ³»³±®§

¾®ïý ©®·¬» ¬»®³·²¿´

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»



ÿ


ÿ

ÿ


ÿ

ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

½®§°¬± ·¿µ³° °±´·½§ ïïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»


ÿ

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ³§³¿° ïð ·°»½ó·¿µ³°


»¬ ¬®¿²º±®³ó»¬ ³§»¬

³¿¬½¸ ¿¼¼®» ïðí

ÿ

ÿ

ÿ

ÿ

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²


²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

½®§°¬± ³¿° ³§³¿°

ÿ

®±«¬»® »·¹®° ï



²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ²¿¬ ·²·¼» ±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼

·° ½´¿´»

·° ®±«¬» ïðòðòîïòð îëëòîëëòîëëòð ïçîòïêèòïòî



²± ·° ¸¬¬° »®ª»®

ÿ


¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹








¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòîïòð ðòðòðòîëë ¿²§






¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹


¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹



¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë



¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë


²± ½¼° ®«²

®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ïð

³¿¬½¸ ·° ¿¼¼®» ïðì

ÿ

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ


ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼



Task 8�Test 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 server�172.16.P.50(where P = pod number)

VPN client PC�10.0.(P+20).17(where P = pod number)



Step 5 Verify that the VPN Client system can access the following web servers:



Branch office PC�10.2.P.11(where P = pod number)

Step 6 Verify that the student PC can access the following web servers:


VPN client PC�10.0.(P+20).17(where P = pod number)



Section 3�Perimeter Router Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.


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.


Secure the perimeter router 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.


Control administrator access to the perimeter router to prevent unauthorized access:

� 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.



� The administrator attempts to log into the Syslog server.

SetupYou 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 router�s outside interface.

Ping the backbone router in the cloud network.

Task 1�Secure the Perimeter Router Network Services Complete the following steps to secure your perimeter router�s network services:

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

®Ðø½±²º·¹÷ý ¾¿²²»® ´±¹·² ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÿ

®Ðø½±²º·¹÷ý ¾¿²²»® »¨»½ ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÿ

(where P = pod number)Step 2 Enable password encryption and assign a secret enable password to protect the router�s

passwords:

®Ðø½±²º·¹÷ý »®ª·½» °¿©±®¼ó»²½®§°¬·±²

®Ðø½±²º·¹÷ý »²¿¾´» »½®»¬ »½®»¬

(where P = pod number)Step 3 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.

®Ðø½±²º·¹ó·º÷ý ²± ·° °®±¨§ó¿®°


®Ðø½±²º·¹ó·º÷ý ²± ½¼° »²¿¾´»

®Ðø½±²º·¹ó·º÷ý ²± ·° ®»¼·®»½¬

®Ðø½±²º·¹ó·º÷ý ²± ·° ¼·®»½¬»¼ó¾®±¿¼½¿¬

(where P = pod number)Step 4 Enable logging to a Syslog server to provide a method to monitor router events including attacks:

®Ðø½±²º·¹÷ý »®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

®Ðø½±²º·¹÷ý ´±¹¹·²¹ ±²

®Ðø½±²º·¹÷ý ´±¹¹·²¹ ïçîòïêèòÐòïð

®Ðø½±²º·¹÷ý ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´


Task 2�Configure 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.

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòÐòïëð ¸±¬ ïçîòïêèòÐòïð »¯ §´±¹

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòÐòïëð ¸±¬ ïçîòïêèòÐòïð »¯ ¬º¬°

°·¨Ðø½±²º·¹÷ý ¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

°·¨Ðø½±²º·¹÷ý ½´»¿® ¨´¿¬»


Task 3�Secure 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:

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ï °»®³·¬ ïçîòïêèòÐòïð ´±¹

(where P = pod number)Step 2 Assign a password to the Virtual Teletype (VTY) lines (0�4), and allow VTY line access only

from management workstations to the router to prevent access by unauthorized users:

®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì

®Ðø½±²º·¹ó´·²»÷ý °¿©±®¼ ½·½±

®Ðø½±²º·¹ó´·²»÷ý ¿½½»ó½´¿ ï ·²

®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ë

®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ·²°«¬ ¬»´²»¬


®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ±«¬°«¬ ²±²»

®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

(where P = pod number)Step 3 Assign a password to the console line to prevent access by unauthorized users:

®Ðø½±²º·¹ó´·²»÷ý ´·²» ½±² ð

®Ðø½±²º·¹ó´·²»÷ý °¿©±®¼ ½·½±

®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ë

®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ·²°«¬ ²±²»

®Ðø½±²º·¹ó´·²»÷ý ¬®¿²°±®¬ ±«¬°«¬ ²±²»

®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

(where P = pod number)Step 4 Create a local user account on the router that is used to log into the router:

®Ðø½±²º·¹÷ý «»®²¿³» ¬«¼»²¬ °¿©±®¼ ¬«¼»²¬

(where P = pod number)Step 5 Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU

time for system processes:

®Ðø½±²º·¹÷ý ½¸»¼«´»® ¿´´±½¿¬»


Task 4�Configure 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:

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ »° ¸±¬ ïéîòîêòîêòïðÐ ¸±¬ ïçîòïêèòÐòî

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¸±¬ ïéîòîêòîêòïðÐ ¸±¬ ïçîòïêèòÐòî »¯ ·¿µ³°

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðÐ ¸±¬ ïçîòïêèòÐòî

(where P = pod number)Step 2 Add ACL entries to only allow IPSec traffic from VPN Clients to the Concentrator:

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ »° ¿²§ ¸±¬ ïçîòïêèòÐòë

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¿²§ ¸±¬ ïçîòïêèòÐòë »¯ ·¿µ³°

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¸±¬ ïçîòïêèòÐòë

®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðï °»®³·¬ ·° ¿²§ ¿²§

(where P = pod number)Step 3 Apply the ACL to the perimeter router�s outside interface:

®Ðø½±²º·¹÷ý ·²¬»®º¿½» »ðñï

®Ðø½±²º·¹ó·º÷ý ·° ¿½½»ó¹®±«° ïðï ·²

®Ðø½±²º·¹ó·º÷ý »²¼


®Ðý ©®·¬» ³»³±®§


Task 5�Test and Verify the Perimeter Router Configuration Complete the following steps to verify that the perimeter router is configured correctly:

Step 1 Ping the perimeter router�s inside interface from the Student PC. This should be successful.

Step 2 Ping the perimeter router�s outside interface from the Student PC. This should be successful.

Step 3 Establish a Telnet session to the perimeter router from the Student PC:

½æÄ¬»´²»¬ ïçîòïêèòÐòïëð


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:

®Ðý ©®·¬» ¬»®³·²¿´

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»

»²¿¾´» »½®»¬ ë üïüÖ«ºªüñÖÆè¯ëñ¹ßÒ¹ßÝÕÝ¾Êë¾ë·ð

»²¿¾´» °¿©±®¼ é ðìëèðîïëðÝîÛ

ÿ


ÿ

³»³±®§ó·¦» ·±³»³ ïë

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° º·²¹»®

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

ÿ


·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïçîòïêèòïòïëð îëëòîëëòîëëòð

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï

·° ¿¼¼®» ïéîòíðòïòî îëëòîëëòîëëòð

·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

ÿ

®±«¬»® »·¹®° ï

²»¬©±®µ ïéîòíðòðòð

²»¬©±®µ ïçîòïêèòïòð

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»

²± ·° ¸¬¬° »®ª»®

ÿ

´±¹¹·²¹ ïçîòïêèòïòïð

¿½½»ó´·¬ ï °»®³·¬ ïçîòïêèòïòïð ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ »° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî

¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî »¯ ·¿µ³°

¿½½»ó´·¬ ïðï ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî

¿½½»ó´·¬ ïðï °»®³·¬ »° ¿²§ ¸±¬ ïçîòïêèòïòë

¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¿²§ ¸±¬ ïçîòïêèòïòë »¯ ·¿µ³°

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¸±¬ ïçîòïêèòïòë

¿½½»ó´·¬ ïðï °»®³·¬ ·° ¿²§ ¿²§

²± ½¼° ®«²

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ë ð

°¿©±®¼ é ïíðêïÛðïðèðí


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ë ð

°¿©±®¼ é ðìëèðîïëðÝîÛ

´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

(where P = pod number)Step 6 Verify that the PIX Firewall configuration is correct:

°·¨Ðý ©®·¬» ¬»®³·²¿´

æ Í¿ª»¼


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ®¿ª°² »½«®·¬§éë

²¿³»·º »¬¸»®²»¬ë ·²¬ºë »½«®·¬§îë

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

¼±³¿·²ó²¿³» °±¼ïò½±³

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»





¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§




¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°


¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòïòïëð ¸±¬ ïçîòïêèòïòïð »¯ §´±¹

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòïòïëð ¸±¬ ïçîòïêèòïòïð »¯ ¬º¬°

¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§





°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ¸«¬¼±©²

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð



³¬« ®¿ª°² ïëðð








·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³


²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ®¿ª°² ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºë ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð



²¿¬ ø·²·¼»÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ










¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°²



¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

§±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

²± §±°¬ ®±«¬» ¼²¿¬


½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ ïð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁ×ÒÍ×ÜÛ


½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ îð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ îð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÐÍÍ


½®§°¬± ³¿° ¾®¿²½¸ îð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ íð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ íð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÎßÊÐÒ


½®§°¬± ³¿° ¾®¿²½¸ íð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»

·¿µ³° »²¿¾´» ±«¬·¼»


·¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

·¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»

·¿µ³° °±´·½§ ïð ¸¿¸ ¸¿

·¿µ³° °±´·½§ ïð ¹®±«° ï

·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

¬»´²»¬ ¬·³»±«¬ ë


¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æïðëðëçíï¿ð½ïî¾¾íºêºí¾»¼¾½èìîî¿ë¼

æ »²¼

(where P = pod number)Step 7 Verify that the student PC can access the following via the web browser:


VPN Client PC�10.0.(P+20).17(where P = pod number)


Step 8 Verify that the branch office PC can access the following via the web browser:



VPN Client PC�10.0.(P+20).17(where P = pod number)


Step 9 Verify the VPN Client PC can access the following via the web browser:





Section 4�Network Device Management (Optional.) Complete the following lab exercise sub-section to practice what you learned in this chapter.

ObjectivesIn 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.

SetupYou 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 1�Configure 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.


Step 2 Choose Administration>Access Rights>AAA Servers>Authentication from the menu.

Step 3 Click Add and enter the following information:

Authentication Server�10.0.P.10(where P = pod number)

Server Secret�ciscosafe

All other setting�accept 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:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ¬½° ¸±¬ ïéîòïèòÐòë ¸±¬ ïðòðòÐòïð »¯ ¬¿½¿½

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ·½³° ¸±¬ ïéîòïèòÐòë ¸±¬ ïðòðòÐòïð »½¸±

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§


Task 2�Configure 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 1�5 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 Address�10.0.P.11(where P = pod number)

Port�514

Facility�Local 7


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:

°·¨Ðø½±²º·¹÷ý ¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ «¼° ¸±¬ ïéîòïèòÐòë ¸±¬ ïðòðòÐòïï »¯ §´±¹

°·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§


Task 3�Configure 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:

°·¨ø½±²º·¹÷ý ¬»´²»¬ ïðòðòÐòïï îëëòîëëòîëëòîëë ·²·¼»


Step 2 Define the AAA server parameters:

°·¨ø½±²º·¹÷ ý ¿¿¿ó»®ª»® ³§¬¿½¿½ °®±¬±½±´ ¬¿½¿½õ

°·¨ø½±²º·¹÷ ý ¿¿¿ó»®ª»® ³§¬¿½¿½ ø·²·¼»÷ ¸±¬ ïðòðòÐòïð ½·½±¿º»


Step 3 Enable AAA authentication for Telnet access to the PIX Firewall:

°·¨ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ¬»´²»¬ ½±²±´» ³§¬¿½¿½


Task 4�Configure 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:

°·¨ø½±²º·¹÷ý ¬¿¬·½ ø·²·¼»ô±«¬·¼»÷ ïçîòïêèòÐòîð ïðòðòÐòïð ²»¬³¿µ îëëòîëëòîëëòîëë ð ð


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.

°·¨ø½±²º·¹÷ý ¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¸±¬ ïçîòïêèòÐòïëð ¸±¬ ïçîòïêèòÐòîð »¯ ¬¿½¿½



Step 3 Create a new AAA model and define the AAA server on the perimeter router:

®Ðø½±²º·¹÷ý ¿¿¿ ²»©ó³±¼»´

®Ðø½±²º·¹÷ý ¬¿½¿½ó»®ª»® ¸±¬ ïçîòïêèòÐòîð ·²¹´»ó½±²²»½¬·±² µ»§ ½·½±¿º»


Step 4 Enable AAA authentication and create the following authentication lists with the specified methods:

default�Use 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_tacacs�Use the line password for authentication.

®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ ´±½¿´ »²¿¾´»

®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½ ´·²»

(where P = pod number)Step 5 Enable AAA authorization for exec sessions that required TACACS+ authentication:

®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ

(where P = pod number)Step 6 Enable AAA accounting for exec sessions authenticated via TACACS+:

®Ðø½±²º·¹÷ý ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ ¬¿®¬ó¬±° ¹®±«° ¬¿½¿½õ

(where P = pod number)Step 7 Enable AAA authentication for VTY sessions using the default authentication list:

®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì

®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ¼»º¿«´¬

(where P = pod number)Step 8 Enable AAA authentication for console access using the no_tacacs authentication list:

®Ðø½±²º·¹÷ý ´·²» ½±² ð

®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½

®Ðø½±²º·¹ó´·²»÷ý »²¼

®Ðý ©®·¬» ³»³±®§

Task 5�Configure 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.

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðí °»®³·¬ ·° ¸±¬ ïéîòîêòîêòïðÐ ïðòðòÐòð ðòðòðòîëë



Step 2 Add an ACL entry that does not perform NAT on the branch office router�s IP address if the router communicates with devices on the corporate office internal network:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ïðì ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðÐ ïðòðòÐòð ðòðòðòîëë


Step 3 Add ACL entries to the PIX Firewall to define IPSec traffic to the branch office router:

°·¨ø½±²º·¹÷ý ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëòð ¸±¬ ïéîòîêòîêòïðÐ


Step 4 Add an ACL entry that allows the corporate office management server and workstation access to the router on the branch office router:

¾®Ðø½±²º·¹÷ý ¿½½»ó´·¬ ï °»®³·¬ ¸±¬ ïðòðòÐòïï


Step 5 Create a new AAA model and define the AAA server:

¾®Ðø½±²º·¹÷ý ¿¿¿ ²»©ó³±¼»´

¾®Ðø½±²º·¹÷ý ¬¿½¿½ó»®ª»® ¸±¬ ïðòðòÐòïð ·²¹´»ó½±²²»½¬·±² µ»§ ½·½±¿º»


Step 6 Enable AAA authentication and create the following authentication lists with the specified methods:

default�Use 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_tacacs�Use the line password for authentication.

¾®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ ´±½¿´ »²¿¾´»

¾®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½ ´·²»


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:

¾®Ðø½±²º·¹÷ý ´·²» ½±² ð

¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½



Step 11 Add the corporate office Syslog server to the list of logging hosts:

¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ïðòðòÐòïï

¾®Ðø½±²º·¹÷ý »²¼

¾®Ðý ©®·¬» ³»³±®§


Task 6�Test 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 router�10.0.P.11(where P = pod number)

Perimeter router�192.168.P.10(where P = pod number)


PIX firewall�10.0.P.11(where P = pod number)

Step 10 Verify the configuration files for the following devices:

Perimeter router configuration

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»

¿¿¿ ²»©ó³±¼»´

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ ´±½¿´ »²¿¾´»

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½ ´·²»

¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ

¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ ¬¿®¬ó¬±° ¹®±«° ¬¿½¿½õ

»²¿¾´» »½®»¬ ë üïüÖ«ºªüñÖÆè¯ëñ¹ßÒ¹ßÝÕÝ¾Êë¾ë·ð

»²¿¾´» °¿©±®¼ é ðìëèðîïëðÝîÛ

ÿ


ÿ

³»³±®§ó·¦» ·±³»³ ïë

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° º·²¹»®

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïçîòïêèòïòïëð îëëòîëëòîëëòð

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»


¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï

·° ¿¼¼®» ïéîòíðòïòî îëëòîëëòîëëòð

·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

ÿ

®±«¬»® »·¹®° ï

²»¬©±®µ ïéîòíðòðòð

²»¬©±®µ ïçîòïêèòïòð

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»

²± ·° ¸¬¬° »®ª»®

ÿ

´±¹¹·²¹ ïçîòïêèòïòïð

¿½½»ó´·¬ ï °»®³·¬ ïçîòïêèòïòïð ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ »° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî

¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî »¯ ·¿µ³°

¿½½»ó´·¬ ïðï ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòî

¿½½»ó´·¬ ïðï °»®³·¬ »° ¿²§ ¸±¬ ïçîòïêèòïòë

¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¿²§ ¸±¬ ïçîòïêèòïòë »¯ ·¿µ³°

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¸±¬ ïçîòïêèòïòë

¿½½»ó´·¬ ïðï °»®³·¬ ·° ¿²§ ¿²§

²± ½¼° ®«²

¬¿½¿½ó»®ª»® ¸±¬ ïçîòïêèòïòîð ·²¹´»ó½±²²»½¬·±² µ»§ ½·½±¿º»

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·½± ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ë ð

°¿©±®¼ é ïíðêïÛðïðèðí

´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ë ð


°¿©±®¼ é ðìëèðîïëðÝîÛ

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

PIX Firewall configuration

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ®¿ª°² »½«®·¬§éë

²¿³»·º »¬¸»®²»¬ë ·²¬ºë »½«®·¬§îë

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

¼±³¿·²ó²¿³» °±¼ïò½±³

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»




¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±¬ ©©©ó°®·ª¿¬» ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§




¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ ©©©

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±¬ ©©©ó°«¾´·½ »¯ º¬°



¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòïòïëð ¸±¬ ïçîòïêèòïòïð »¯ §´±¹

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïçîòïêèòïòïëð ¸±¬ ïçîòïêèòïòïð »¯ ¬º¬°

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¸±¬ ïçîòïêèòïòïëð ¸±¬ ïçîòïêèòïòîð »¯ ¬¿½¿½

¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§



¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¸±¬ ïéîòîêòîêòïðï


¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ¬½° ¸±¬ ïéîòïèòïòë ¸±¬ ïðòðòïòïð »¯ ¬¿½¿½

¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ·½³° ¸±¬ ïéîòïèòïòë ¸±¬ ïðòðòïòïð »½¸±

¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ «¼° ¸±¬ ïéîòïèòïòë ¸±¬ ïðòðòïòïï »¯ §´±¹

¿½½»ó´·¬ ÎßÊÐÒ °»®³·¬ ·° ¿²§ ¿²§


°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ïððº«´´

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ¸«¬¼±©²

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð



³¬« ®¿ª°² ïëðð








·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð


º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ®¿ª°² ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²¬ºë ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð



²¿¬ ø·²·¼»÷ ð ¿½½»ó´·¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ









¬¿¬·½ ø·²·¼»ô±«¬·¼»÷ ïçîòïêèòïòîð ïðòðòïòïð ²»¬³¿µ îëëòîëëòîëëòîëë ð ð


¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°²



¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

¿¿¿ó»®ª»® ³§¬¿½¿½ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ³§¬¿½¿½ ø·²·¼»÷ ¸±¬ ïðòðòïòïð ½·½±¿º» ¬·³»±«¬ ïð

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ¬»´²»¬ ½±²±´» ³§¬¿½¿½

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»


§±°¬ ½±²²»½¬·±² °»®³·¬ó·°»½

²± §±°¬ ®±«¬» ¼²¿¬

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ ïð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁ×ÒÍ×ÜÛ


½®§°¬± ³¿° ¾®¿²½¸ ïð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ îð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ îð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÐÍÍ


½®§°¬± ³¿° ¾®¿²½¸ îð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ íð ·°»½ó·¿µ³°

½®§°¬± ³¿° ¾®¿²½¸ íð ³¿¬½¸ ¿¼¼®» ÒÑÒßÌÁÎßÊÐÒ


½®§°¬± ³¿° ¾®¿²½¸ íð »¬ ¬®¿²º±®³ó»¬ ³§»¬

½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬·¼»

·¿µ³° »²¿¾´» ±«¬·¼»


·¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

·¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»

·¿µ³° °±´·½§ ïð ¸¿¸ ¸¿

·¿µ³° °±´·½§ ïð ¹®±«° ï

·¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

¬»´²»¬ ïðòðòïòïï îëëòîëëòîëëòîëë ·²·¼»

¬»´²»¬ ¬·³»±«¬ ë


¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æéçèïºðêêïç»çðï¼ç¿¼ì»½»êè¼ðï»»ìî¼æ

»²¼

Branch office router configuration

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»

¿¿¿ ²»©ó³±¼»´

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ ´±½¿´ »²¿¾´»


¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½ ´·²»

¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½õ

¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ ¬¿®¬ó¬±° ¹®±«° ¬¿½¿½õ



ÿ


ÿ

ÿ

ÿ

ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

ÿ

½®§°¬± ·¿µ³° °±´·½§ ïïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»


ÿ

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ³§³¿° ïð ·°»½ó·¿µ³°


»¬ ¬®¿²º±®³ó»¬ ³§»¬


³¿¬½¸ ¿¼¼®» ïðí

ÿ

ÿ

ÿ

ÿ

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

¸¿´ºó¼«°´»¨

²± ½¼° »²¿¾´»

½®§°¬± ³¿° ³§³¿°

ÿ

®±«¬»® »·¹®° ï



²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ²¿¬ ·²·¼» ±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼

·° ½´¿´»


·° ®±«¬» ïðòðòîïòð îëëòîëëòîëëòð ïçîòïêèòïòî


²± ·° ¸¬¬° »®ª»®

ÿ



´±¹¹·²¹ ïðòðòïòïï

¿½½»ó´·¬ ï °»®³·¬ ïðòðòïòïï

¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹








¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòîïòð ðòðòðòîëë ¿²§





¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹


¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹



¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ¸±¬ ïéîòîêòîêòïðï ïðòðòïòð ðòðòðòîëë



¿½½»ó´·¬ ïðì ¼»²§ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë

¿½½»ó´·¬ ïðì ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðï ïðòðòïòð ðòðòðòîëë


²± ½¼° ®«²

®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ïð

³¿¬½¸ ·° ¿¼¼®» ïðì

ÿ

¬¿½¿½ó»®ª»® ¸±¬ ïðòðòïòïð ·²¹´»ó½±²²»½¬·±² µ»§ ½·½±¿º»

ÿ

ÿ

¾¿²²»® »¨»½ ÂÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ


ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»


´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð


¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

Copyright 2003, Cisco Systems, Inc. Case Study Lab 8-1

Lab Exercise�Case Study Company A has acquired Company B and wishes to incorporate Company B�s 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 it�s existing equipment, however it does not want to terminate site-to-site IPSec traffic on the VPN Concentrator. Access to Company A�s internal network and it�s public resources will be provided through a VPN tunnel. Company A has decided to replace Company B�s 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.


PIX Firewall Initial Configuration

DMZ IOS Router Initial Configuration

Branch IOS Router Initial Configuration

VPN Concentrator Initial Configuration


Branch Office IOS Router Configuration

Site-to-Site VPN Configuration

Client-to-LAN VPN Configuration

Final Configurations





Pod P (1�10)

.100

PSSWWWFTP

172.16.P.0/24

10.0.P.0 /24

192.168.P.0/24

.1 e2

pP

pub cP.1

DMZ

SuperServerWWWFTP

.10

.150

10.3.P.5

priv

.5 e0/0

.2 e0 172.18.P.0/24.1 e4

.1 e1

172.26.26.0/24

RTS

RBB

VPN Client

brP

Branch

10.2.P.0/24

.10P e0/1

.50

.1 e0/0

10.2.P.11

172.26.26.P

Branch

10.0.P.11Student

10.2.P.1

.5 e0/1

172.19.P.0/24

10.3.P.0/24

drP.1 e5


PIX Firewall Initial Configuration Complete the following lab exercise to configure the PIX Firewall.

ObjectivesIn 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.


SetupBefore starting this lab exercise, make sure the PIX Firewall is turned on and that your PC has console access to the PIX Firewall.

Task 1�Initial 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 0 192.168.P.2/255.255.255.0

ethernet1 inside 100 10.0.P.1/255.255.255.0

ethernet2 PSS 50 172.16.P.1/255.255.255.0

ethernet4 DMZ1 70 172.18.P.1/255.255.255.0

ethernet5 DMZ2 80 172.19.P.1/255.255.255.0

hostname pixP


Task 2�Configure Global Addresses, NAT, Routing and Statics 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 1 192.168.P.33-222 255.255.255.0


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 router�s inside interface as the PIX Firewall�s default route.

Step 4 Configure the PIX�s 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


Step 6 Confirm your entries by examining the nat and global configurations.

Step 7 Write the current configuration to Flash memory.

Task 3�Allow 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:

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ÜÓÆï »½«®·¬§éð


²¿³»·º »¬¸»®²»¬ë ÜÓÆî »½«®·¬§èð

»²¿¾´» °¿©±®¼ èÎ§îÇ¶×§¬éÎÎÈËîì »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»



¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§

¿½½»ó´·¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§

°¿¹»® ´·²» îì

·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬±

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð



³¬« ÜÓÆï ïëðð

³¬« ÜÓÆî ïëðð





·° ¿¼¼®» ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð

·° ¿¼¼®» ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð


º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ÜÓÆï ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ÜÓÆî ðòðòðòð

°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð




¬¿¬·½ ø·²·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¬¿¬·½ ø·²·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî


¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

²± §±°¬ ®±«¬» ¼²¿¬

¬»´²»¬ ¬·³»±«¬ ë

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æë¾ðï¿êîîéëí¿é¼¼çê»ìê»¿¾éìðîç»ðºð

æ »²¼

ÅÑÕÃ

Task 4�Test and Verify the Configuration Step 1 Ping the following devices from the PIX Firewall to ensure they are operational:

PIX Firewall inside interface�10.0.P.1(where P = pod number)



PIX Firewall outside interface�192.168.P.2(where P = pod number)

PIX Firewall PSS interface�172.16.P.1(where P = pod number)

PIX Firewall DMZ1 interface�172.18.P.1(where P = pod number)

PIX Firewall DMZ2 interface�172.19.P.1(where P = pod number)

PSS server�172.16.P.50(where P = pod number)

VPN Client�172.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.


DMZ IOS Router Initial Configuration Complete the following lab exercise to configure the DMZ IOS router.

ObjectivesIn 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.


SetupBefore 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 1�Initial Configuration of the DMZ IOS Router Complete a write erase on the DMZ IOS Router to use a default configuration.


Step 2 Assign the DMZ IOS Router the parameters as defined in the following tables and enable the interfaces:

Ethernet0/0�172.19.P.5/255.255.255.0(where P = pod number)


Hostname�drP(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




Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

²± »®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¼®ï

ÿ

»²¿¾´» »½®»¬ ë üïüÆéÆñüÝÏ¼¦±Ê¬µ·»ºîµº×ÚÜªÚÎï

ÿ

³»³±®§ó·¦» ·±³»³ ïë

·° «¾²»¬ó¦»®±

ÿ

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïéîòïçòïòë îëëòîëëòîëëòð

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï

·° ¿¼¼®» ïéîòïèòïòë îëëòîëëòîëëòð

ÿ

·° ½´¿´»

·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïéîòïçòïòï

·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïéîòïçòïòï

·° ®±«¬» ïéîòîêòîêòð îëëòîëëòîëëòð ïéîòïèòïòï

·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïéîòïèòïòï

·° ®±«¬» ïðòíòïòð îëëòîëëòîëëòð ïéîòïèòïòï

²± ·° ¸¬¬° »®ª»®

ÿ

´·²» ½±² ð

¬®¿²°±®¬ ·²°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

ÿ

²± ½¸»¼«´»® ¿´´±½¿¬»


»²¼

Task 2�Test and Verify the Configuration Step 1 Ping the following devices from the Student PC to ensure they are operational:

DMZ IOS router e0/1 interface�172.18.P.5(where P = pod number)

DMZ IOS router e0/0 interface�172.19.P.5(where P = pod number)


Branch IOS Router Initial Configuration Complete the following lab exercise to configure the Branch IOS router.

ObjectivesIn 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.


SetupBefore 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 1�Initial Configuration of the Branch IOS Router Step 1 Complete a write erase on the IOS Router to use a default configuration.


Step 3 Assign the IOS Router the parameters as defined in the following tables and enable the interfaces:


Ethernet0/1�172.26.26.10P/255.255.255.0(where P = pod number)

Hostname�brP(where P = pod number)

Step 4 Configure the IOS Router to use EIGRP according to the following parameters:

Autonomous System Number�1

Network�10.0.0.0

Network�172.26.0.0

Route Summary�None

Step 5 Configure a static route on the IOS Router to allow access to the private network on the VPN Concentrator:

¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòîòÐòð îëëòîëëòîëëòð ïðòíòÐòë



Step 6 Configure the IOS Router to redistribute static routes into EIGRP:

¾®Ðø½±²º·¹÷ý ®±«¬»® »·¹®° ï

¾®Ðø½±²º·¹ó®±«¬»®÷ý ®»¼·¬®·¾«¬» ¬¿¬·½


Step 7 Verify your routing table ensuring that the static route you entered is being redistributed into EIGRP.


Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

²± »®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

ÿ

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïðòíòïòï îëëòîëëòîëëòð

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


ÿ

®±«¬»® »·¹®° ï

®»¼·¬®·¾«¬» ¬¿¬·½



²± ¿«¬±ó«³³¿®§


²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»

·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïðòíòïòë

²± ·° ¸¬¬° »®ª»®

ÿ

´·²» ½±² ð

¬®¿²°±®¬ ·²°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

ÿ

²± ½¸»¼«´»® ¿´´±½¿¬»

»²¼


Branch IOS router e0/0 interface�10.3.P.1(where P = pod number)

Branch IOS router e0/1 interface�172.26.26.10P(where P = pod number)


VPN Concentrator Initial Configuration Complete the following lab exercise to configure the VPN Concentrator.

ObjectivesIn 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.


SetupBefore starting this lab exercise, make sure the VPN Concentrator is turned on and that your PC has console access to the VPN Concentrator.

Task 1�Reset 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 2�Configure the Concentrator Via CLI Complete the following steps using the VPN Concentrator CLI to configure the Concentrator�s 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



VPN Concentrator public interface�10.3.P.5(where P = pod number)


VPN Concentrator private interface�10.2.P.1(where P = pod number)

Branch PC�10.2.P.11(where P = pod number)

Step 2 Establish ftp and web access to the Branch PC from the Student PC.


PIX Firewall Configuration Complete the following lab exercise to configure the PIX Firewall.

ObjectivesIn 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.


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.


Apply PIX Firewall hardening and management:

� Enable logging.

� Assign Telnet and enable passwords.

SetupBefore starting this lab exercise, make sure the PIX Firewall is turned on and that your PC has console access to the PIX Firewall.

Task 1�Deny 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 2�Allow 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_interface�PSS

postnat_interface�outside

mapped_address�192.168.P.11(where P = pod number)


real_address�172.16.P.50(where P = pod number)

netmask�255.255.255.255

connection_limit�0

em_limit�1000

Step 2 Modify the INBOUND ACL to deny RFC 2827 and 1918 traffic using the following parameters:

address to be denied�127.0.0.0/255.0.0.0

address to be denied�10.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 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)


Test FTP and web access to the PSS server: 192.168.P.11.(where P = pod number)

Task 3�Implement Spoofing ProtectionComplete 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.


Task 4�Enable 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 PC�10.0.P.11(where P = pod number)

Trap level�informational


Task 5�Assign Telnet and Enable PasswordsComplete the following steps to assign Telnet and enable passwords:

Step 1 Configure and set your password according to the following parameters:

enable password�enable

telnet password�cisco


Step 3 Compare your configuration to the following sample configuration from pix1:

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ÜÓÆï »½«®·¬§éð

²¿³»·º »¬¸»®²»¬ë ÜÓÆî »½«®·¬§èð


»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»







¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§


»½¸±ó®»°´§


¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§


°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬±

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð












·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð



°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð







¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî


¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

²± §±°¬ ®±«¬» ¼²¿¬


¬»´²»¬ ¬·³»±«¬ ë

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æìî»èèíð¾¾ëéëë¾íèïï¼êºï»ºîº¿ëì½êð

æ »²¼

ÅÑÕÃ

Task 6�Test and Verify the ConfigurationComplete 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.


Branch Office IOS Router Configuration Complete the following lab exercise to practice what you learned in this chapter.


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.


Secure the branch office router 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.


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

� Control access into the router from the console and the vty lines.


� Allow Telnet to the perimeter router only from the student system inside the branch office network.


� 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.

SetupBefore starting this lab exercise, set up your equipment so that you can do the following from the branch office equipment:

Ping the branch office router�s inside and outside interfaces from the branch office PC.


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 1�Secure 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 login�Warning. Authorized Company IT Personnel ONLY!

banner exec�You are now executing commands on Company Property!

Step 2 Enable password encryption and assign a secret enable password to protect the router�s passwords using the following parameters:

enable password should be encrypted

enable secret�secret

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


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 PC�10.2.P.11(where P = pod number)

trap level�informational

Task 2�Secure 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 number�1

Assign a password to the VTY lines (0�4) 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:

password�cisco

access list�1

timeout�15

Step 2 Create a local user account on the router that is used to log into the router using the following parameters:

username�student

password�student

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

Task 3�Configure NAT IOS Features Complete the following steps to enable the NAT features to hide the internal network address.


Caution Do not do Task 3 in a remote lab environment.

Step 1 Establish static translation between an inside local address and an outside global address and apply it to both interfaces using the following parameters:

local-ip�10.2.P.11(where P = pod number)

global-ip�172.26.26.11P(where P = pod number)

Task 4�Implement 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:


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

� 127.0.0.0

� 172.18.0.0

Step 2 Create an ACL that only allows outbound traffic originating from the internal network and explicitly denies all other traffic using the following parameters:


logging�log

Task 5�Configure 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

RealAudio

Inspection name�branchfw

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-name�branchids

Step 3 Save your configuration and compare it to the following:

Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»

»²¿¾´» »½®»¬ ë üïü¯òÙéüß¯¦»Úß·ñ²²ÍÜ±´ÜØ¶Ú¹Èð

»²¿¾´» °¿©±®¼ é ðéïÝîììÚëÝðÝðÜ

ÿ

«»®²¿³» ¬«¼»²¬ °¿©±®¼ é ðëïèïîïßîëìçìðïÜ

ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° º·²¹»®

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°


·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

ÿ

®±«¬»® »·¹®° ï

®»¼·¬®·¾«¬» ¬¿¬·½



²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»


²± ·° ¸¬¬° »®ª»®

ÿ


¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ »·¹®° ¸±¬ ïéîòîêòîêòïëð ¸±¬ ïéîòîêòîêòïðï







¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹


¿½½»ó´·¬ ïðî °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ¿²§ ´±¹

¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

²± ½¼° ®«²

ÿ

¾¿²²»® »¨»½ ÂÝÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ

¾¿²²»® ´±¹·² ÂÝÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý±³°¿²§ ×Ì Ð»®±²²»´ ÑÒÔÇÂÝ

ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð

°¿©±®¼ é ïîïßðÝðìïïðì

´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

Task 6�Test the Branch Office Router Configuration Complete the following steps to confirm that the branch office is configured correctly:

Step 1 Ping the branch office router�s 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.


Site-to-Site VPN Configuration Complete the following exercise to implement the case study.

ObjectivesIn 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.

SetupBefore starting this lab exercise, make sure you can access the console ports of the devices used.


Task 1�Prepare 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 address�172.18.P.5(where P = pod number)

Outside address�192.168.P.200(where P = pod number)

Interface�DMZ1

Step 2 Create an access-list entry in the DMZ1-OUT access-list to allow the IOS DMZ Router access to the Branch Router�s 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 address�10.2.P.0(where P = pod number)

Outside address�10.2.P.0(where P = pod number)

Interface�DMZ2

Step 6 Create route statements to route traffic destined for the Branch Office networks to the DMZ IOS Router interface DMZ2.


Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

æ Í¿ª»¼

æ


²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ÜÓÆï »½«®·¬§éð

²¿³»·º »¬¸»®²»¬ë ÜÓÆî »½«®·¬§èð

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼


¸±¬²¿³» °·¨ï

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»




¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ·° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòîðð




¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§


»½¸±ó®»°´§


¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§

¿½½»ó´·¬ ÜÓÆïóÑËÌ °»®³·¬ ·° ¿²§ ¸±¬ ïéîòîêòîêòïðï


¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòïòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð

°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬±

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð












·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð



°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð







¬¿¬·½ øÜÓÆïô±«¬·¼»÷ ïçîòïêèòïòîðð ïéîòïèòïòë ²»¬³¿µ îëëòîëëòîëëòîëë ð ð

¬¿¬·½ øÜÓÆîôÐÍÍ÷ ïðòîòïòð ïðòîòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÜÓÆïóÑËÌ ·² ·²¬»®º¿½» ÜÓÆï

¿½½»ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî


®±«¬» ÜÓÆî ïðòîòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï

®±«¬» ÜÓÆî ïðòíòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï

¬·³»±«¬ ¨´¿¬» íæððæðð




¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

²± §±°¬ ®±«¬» ¼²¿¬

¬»´²»¬ ¬·³»±«¬ ë

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æìíçêç»êéð½ïèéç¼ºï½éëîçéè»½½è¿»è¼

æ »²¼

ÅÑÕÃ

Task 2�Prepare for Configuring IPSec on the Branch Office IOS Router


Step 1 Input static routes for the following networks using the translated address of the DMZ IOS Router as the next hop:

Next Hop�192.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)





Task 3�Configure IKE Parameters on the Branch Office IOS Router Complete the following steps to configure IKE to use pre-shared keys:


Step 1 Create an IKE policy using the parameter values listed:

Isakmp key�cisco1234






SA lifetime�86400

Task 4�Configure 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:


Access list name�103


Step 2 Create access-list entries to allow decrypted traffic from the corporate office networks to the branch office networks:

Corporate Office Networks�10.0.P.0/255.255.255.0 and 172.16.P.0/255.255.255.0(where P = pod number)

Branch Office Networks�10.2.P.0/255.255.255.0 and 10.3.P.0/255.255.255.0(where P = pod number)



Step 3 Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed:




Mode�tunnel

Step 4 Create a crypto map using the parameter values listed and apply it to the e0/1 interface:

Crypto map name�DMZ

Map number�10


Peer�192.168.P.200(where P = pod number)


Match address�103


Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ

²± ´±¹¹·²¹ ½±²±´»



ÿ


ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° º·²¹»®

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí


·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

½®§°¬± ·¿µ³° °±´·½§ ïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

½®§°¬± ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïçîòïêèòïòîðð

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ÜÓÆ ïð ·°»½ó·¿µ³°

»¬ °»»® ïçîòïêèòïòîðð

»¬ ¬®¿²º±®³ó»¬ ³§»¬

³¿¬½¸ ¿¼¼®» ïðí

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

²± ½¼° »²¿¾´»

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

½®§°¬± ³¿° ÜÓÆ

ÿ

®±«¬»® »·¹®° ï

®»¼·¬®·¾«¬» ¬¿¬·½



²± ¿«¬±ó«³³¿®§


²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»

·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð


·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð

²± ·° ¸¬¬° »®ª»®

ÿ


¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹





¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹




¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹



¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

²± ½¼° ®«²

ÿ

¾¿²²»® »¨»½ ÂÝÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ


ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´


¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

Task 5�Prepare for Configuring IPSec Pre-Shared Keys on the DMZ IOS Router






Task 6�Configure 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 key�cisco1234



Hash alogorithm�sha



SA lifetime�86400

Task 7�Configure 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:



Peer network address�IP address of branch office network



Step 2 Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed in the table.



Mode�tunnel

Step 3 Create a crypto map using the parameter values listed and apply it to the e0/1 interface:

Crypto map name�branch

Map number�10


Peer�172.26.26.10P(where P = pod number)


Match address�103

Task 8�Configure 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 number�INBOUND

Protocol�ESP

Protocol�UDP�eq ISAKMP


Task 9�Verify 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.


Client-to-LAN VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

ObjectivesIn 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.


Ensure that your Concentrator is turned on.

Access the branch office router�s console port.

Task 1�Configure the VPN Concentrator Using Quick Configuration Via the Web Interface

Step 1 Configure the VPN Concentrator using the System Info parameters below:

System Name�studentP VPN (where P = pod number)

New Time�Verify the current time and date


DST Support�Enable

DNS Server�0.0.0.0 (which is the default)

Domain Name�podP.com(where P = pod number)


Step 2 Configure the following Protocol parameter values:

PPTP�Disable

L2TP�Disable

IPSec�Enable

Step 3 Configure the Address Assignment parameter values listed below:

Configured Pool�Enabled (select the check box)

Range Start�10.2.P.17(where P = pod number)

Range End�10.2.P.30(where P = pod number)

Step 4 Use an Internal Server with the following parameters:

Username�studentP(where P = pod number)

Password�studentP(where P = pod number)

Verify password�studentP(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.



Password�podP_group(where P = pod number)

Verify�podP_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 2�Configure 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:

Metric�1

Tunnel default gateway�10.3.P.1(where P = pod number)

Override Default Gateway�Enabled

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 PC�s host address to 192.168.P.50 from the inside to the outside. (where P = pod number)

Step 7 Clear the translation table.


Step 8 Enable split tunneling on the VPN Concentrator only allowing access to the translated address of the Student PC.

Translated address�192.168.P.50(where P = pod number)

Task 3�Configure 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 entry�studentP(where P = pod number)

IP address of the Concentrator�s Public IP interface�10.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 Password�podP_group(where P = pod number)

Confirm Password�podP_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 4�Configure the Branch Office IOS Router This section details configuring the branch office router to allow IKE and IPSec traffic to the VPN Concentrator.


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 5�Test 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 PC�10.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 server�172.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 PC�10.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 PC�10.2.P.17(where P = pod number)

Test FTP and web access to the PSS Server�172.16.P.50(where P = pod number)

Test FTP and web access to the Student PC�10.0.P.11(where P = pod number)


Final Configurations Compare your final configurations to the one�s shown:



²¿³»·º »¬¸»®²»¬ð ±«¬·¼» »½«®·¬§ð

²¿³»·º »¬¸»®²»¬ï ·²·¼» »½«®·¬§ïðð

²¿³»·º »¬¸»®²»¬î ÐÍÍ »½«®·¬§ëð

²¿³»·º »¬¸»®²»¬í ·²¬ºí »½«®·¬§ïë

²¿³»·º »¬¸»®²»¬ì ÜÓÆï »½«®·¬§éð

²¿³»·º »¬¸»®²»¬ë ÜÓÆî »½«®·¬§èð

»²¿¾´» °¿©±®¼ Ê°Û«ñÜÞ·Ë¯®òÊ¸Ùé »²½®§°¬»¼

°¿©¼ îÕÚÏ²¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

¸±¬²¿³» °·¨ï

º·¨«° °®±¬±½±´ º¬° îï

º·¨«° °®±¬±½±´ ¸¬¬° èð

º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð


º·¨«° °®±¬±½±´ ·´ íèç

º·¨«° °®±¬±½±´ ®¸ ëïì

º·¨«° °®±¬±½±´ ®¬° ëëì

º·¨«° °®±¬±½±´ ³¬° îë

º·¨«° °®±¬±½±´ ¯´²»¬ ïëîï

º·¨«° °®±¬±½±´ ·° ëðêð

º·¨«° °®±¬±½±´ µ·²²§ îððð

²¿³»




¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòîðð

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ »° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòîðð

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòîðð »¯ ·¿µ³°

¿½½»ó´·¬ ×ÒÞÑËÒÜ °»®³·¬ ·° ¸±¬ ïéîòîêòîêòïðï ¸±¬ ïçîòïêèòïòîðð




¿½½»ó´·¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§


»½¸±ó®»°´§


¿½½»ó´·¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§

¿½½»ó´·¬ ÜÓÆïóÑËÌ °»®³·¬ ·° ¿²§ ¸±¬ ïéîòîêòîêòïðï



¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð

¿½½»ó´·¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð

°¿¹»® ´·²» îì

´±¹¹·²¹ ±²

´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

´±¹¹·²¹ ¸±¬ ·²·¼» ïðòðòïòïï

·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ï ïðº«´´

·²¬»®º¿½» »¬¸»®²»¬î ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± ¸«¬¼±©²

·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬±

·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬±

·½³° ¼»²§ ¿²§ ±«¬·¼»

³¬« ±«¬·¼» ïëðð

³¬« ·²·¼» ïëðð











·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ±«¬·¼»

·° ª»®·º§ ®»ª»®»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³

²± º¿·´±ª»®

º¿·´±ª»® ¬·³»±«¬ ðæððæðð

º¿·´±ª»® °±´´ ïë

º¿·´±ª»® ·° ¿¼¼®» ±«¬·¼» ðòðòðòð

º¿·´±ª»® ·° ¿¼¼®» ·²·¼» ðòðòðòð


º¿·´±ª»® ·° ¿¼¼®» ·²¬ºí ðòðòðòð



°¼³ ¸·¬±®§ »²¿¾´»

¿®° ¬·³»±«¬ ïììðð








¬¿¬·½ øÜÓÆïô±«¬·¼»÷ ïçîòïêèòïòîðð ïéîòïèòïòë ²»¬³¿µ îëëòîëëòîëëòîëë ð ð

¬¿¬·½ øÜÓÆîôÐÍÍ÷ ïðòîòïòð ïðòîòïòð ²»¬³¿µ îëëòîëëòîëëòð ð ð

¿½½»ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬·¼»

¿½½»ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²·¼»

¿½½»ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ

¿½½»ó¹®±«° ÜÓÆïóÑËÌ ·² ·²¬»®º¿½» ÜÓÆï

¿½½»ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî


®±«¬» ÜÓÆî ïðòîòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï

®±«¬» ÜÓÆî ïðòíòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï

¬·³»±«¬ ¨´¿¬» íæððæðð



¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾±´«¬»

¿¿¿ó»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½õ

¿¿¿ó»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«

¿¿¿ó»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´

²± ²³°ó»®ª»® ´±½¿¬·±²

²± ²³°ó»®ª»® ½±²¬¿½¬

²³°ó»®ª»® ½±³³«²·¬§ °«¾´·½

²± ²³°ó»®ª»® »²¿¾´» ¬®¿°

º´±±¼¹«¿®¼ »²¿¾´»

²± §±°¬ ®±«¬» ¼²¿¬

¬»´²»¬ ¬·³»±«¬ ë

¸ ¬·³»±«¬ ë

¬»®³·²¿´ ©·¼¬¸ èð

Ý®§°¬±½¸»½µ«³æëðìíèºçë»½ìíºìç¼ïî¿½ð¿ïëí¾»í¿ëðð

æ »²¼

ÅÑÕÃ

Branch IOS Router Configuration

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» ¸±©ó¬·³»¦±²»

»®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¾®ï

ÿ


²± ´±¹¹·²¹ ½±²±´»



ÿ


ÿ

³»³±®§ó·¦» ·±³»³ ïð

·° «¾²»¬ó¦»®±

²± ·° ±«®½»ó®±«¬»

²± ·° º·²¹»®

²± ·° ¼±³¿·²ó´±±µ«°

ÿ

²± ·° ¾±±¬° »®ª»®

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¬½°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© º¬°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© «¼°

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

·° ·²°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·±

·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±°

ÿ

½®§°¬± ·¿µ³° °±´·½§ ïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

½®§°¬± ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïçîòïêèòïòîðð

ÿ

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ÜÓÆ ïð ·°»½ó·¿µ³°

»¬ °»»® ïçîòïêèòïòîðð

»¬ ¬®¿²º±®³ó»¬ ³§»¬

³¿¬½¸ ¿¼¼®» ïðí

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð


·° ¿½½»ó¹®±«° ïðî ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

·° ·²°»½¬ ¾®¿²½¸º© ·²

·° ¿«¼·¬ ¾®¿²½¸·¼ ·²

²± ½¼° »²¿¾´»

ÿ


·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï


·° ¿½½»ó¹®±«° ïðï ·²

²± ·° ®»¼·®»½¬

²± ·° °®±¨§ó¿®°

²± ½¼° »²¿¾´»

½®§°¬± ³¿° ÜÓÆ

ÿ

®±«¬»® »·¹®° ï

®»¼·¬®·¾«¬» ¬¿¬·½



²± ¿«¬±ó«³³¿®§

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»

ÿ

·° ½´¿´»

·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð


·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð

²± ·° ¸¬¬° »®ª»®

ÿ


¿½½»ó´·¬ ï °»®³·¬ ïðòîòïòïï ´±¹





¿½½»ó´·¬ ïðï °»®³·¬ »° ¿²§ ¸±¬ ïðòíòïòë ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ «¼° ¿²§ ¸±¬ ïðòíòïòë ´±¹ »¯ ·¿µ³°

¿½½»ó´·¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹

¿½½»ó´·¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹




¿½½»ó´·¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹



¿½½»ó´·¬ ïðî ¼»²§ ·° ¿²§ ¿²§ ´±¹

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë


¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

²± ½¼° ®«²

ÿ

¾¿²²»® »¨»½ ÂÝÝÝÇ±« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼ ±² Ý±³°¿²§ Ð®±°»®¬§ÂÝ


ÿ

´·²» ½±² ð

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ²±²»

¬®¿²°±®¬ ±«¬°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

¿½½»ó½´¿ ï ·²

»¨»½ó¬·³»±«¬ ïë ð


´±¹·² ´±½¿´

¬®¿²°±®¬ ·²°«¬ ¬»´²»¬

¬®¿²°±®¬ ±«¬°«¬ ²±²»

ÿ

½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

»²¼

DMZ IOS Router Configuration

Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ

ÿ


»®ª·½» ¬·³»¬¿³° ¼»¾«¹ «°¬·³»

»®ª·½» ¬·³»¬¿³° ´±¹ «°¬·³»

²± »®ª·½» °¿©±®¼ó»²½®§°¬·±²

ÿ

¸±¬²¿³» ¼®ï

ÿ

»²¿¾´» »½®»¬ ë üïüÆéÆñüÝÏ¼¦±Ê¬µ·»ºîµº×ÚÜªÚÎï

ÿ

³»³±®§ó·¦» ·±³»³ ïë

·° «¾²»¬ó¦»®±

ÿ

·° ¿«¼·¬ ²±¬·º§ ´±¹

·° ¿«¼·¬ °± ³¿¨ó»ª»²¬ ïðð

ÿ


½®§°¬± ·¿µ³° °±´·½§ ïð

»²½® í¼»

¿«¬¸»²¬·½¿¬·±² °®»ó¸¿®»

½®§°¬± ·¿µ³° µ»§ ½·½±ïîíì ¿¼¼®» ïéîòîêòîêòïðï

ÿ

½®§°¬± ·°»½ ¬®¿²º±®³ó»¬ ³§»¬ »°óí¼»

ÿ

½®§°¬± ³¿° ¾®¿²½¸ ïð ·°»½ó·¿µ³°

»¬ °»»® ïéîòîêòîêòïðï

»¬ ¬®¿²º±®³ó»¬ ³§»¬

³¿¬½¸ ¿¼¼®» ïðí

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñð

·° ¿¼¼®» ïéîòïçòïòë îëëòîëëòîëëòð

ÿ

·²¬»®º¿½» Í»®·¿´ðñð

²± ·° ¿¼¼®»

¸«¬¼±©²

²± º¿·®ó¯«»«»

ÿ

·²¬»®º¿½» Û¬¸»®²»¬ðñï

·° ¿¼¼®» ïéîòïèòïòë îëëòîëëòîëëòð

½®§°¬± ³¿° ¾®¿²½¸

ÿ

·° ½´¿´»

·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïéîòïçòïòï

·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïéîòïèòïòï

·° ®±«¬» ïðòíòïòð îëëòîëëòîëëòð ïéîòïèòïòï

·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïéîòïçòïòï

·° ®±«¬» ïéîòîêòîêòð îëëòîëëòîëëòð ïéîòïèòïòï

²± ·° ¸¬¬° »®ª»®

ÿ

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòíòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë

¿½½»ó´·¬ ïðí °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòíòïòð ðòðòðòîëë

ÿ

´·²» ½±² ð

¬®¿²°±®¬ ·²°«¬ ²±²»

´·²» ¿«¨ ð

´·²» ª¬§ ð ì

ÿ

²± ½¸»¼«´»® ¿´´±½¿¬»

»²¼


Date post:	08-Dec-2016
Category:	Documents
Upload:	trinhtuong
View:	217 times
Download:	1 times

CCSP CSI1.1 Knet

Documents