CCSP CSI1.1 Knet

Citation preview

CSI

Cisco SAFE Implementation Version 1.1

Student Guide

Copyright

2003, Cisco Systems, Inc. All rights reserved.

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

Copyright 2003, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All 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

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

Credits Lead Course Developer

Steve Hanna

Contributing Course Developer

Jamey Brooks, Danny Rodriguez

Editors

Kayce M. Clark, Erin R. Stanley

Manager, Documentation

Ed Rivera

Additional Contributors

Jarrett Cravey, Jeanne Jackson, Randy Rivera, Jagdeep Kang

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

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

Table of Contents

COURSE INTRODUCTION

1-1

Overview Course Objectives Lab Topology Overview

1-1 1-2 1-7

SECURITY FUNDAMENTALS

2-1

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

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

ARCHITECTURAL OVERVIEW

3-1

Overview Objectives SAFE Architectural Overview Design Fundamentals Safe Axioms Summary

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

THE CISCO SECURITY PORTFOLIO

4-1

Overview Objectives Cisco Security Portfolio Overview Secure 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

Copyright

2003, Cisco Systems, Inc.

Table of Contents

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

v

SAFE SMALL NETWORK DESIGN

5-1

Overview 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—SAFE Small Network Design Implementation

SAFE SMR MIDSIZE NETWORK DESIGN

6-1

Overview Objectives Midsize Network Corporate Internet Module Midsize Network Corporate Internet Module Design Guidelines Midsize Network Campus Module Midsize Network Campus Module Design Guidelines Midsize Network WAN Module Implementation—ISP Router and Edge Router Implementation—IOS Firewall Implementation—PIX Firewall Implementation—NIDS Implementation—VPN Concentrator Implementation—Layer 3 Switch Summary Lab Exercise—Medium Network Design Implementation

REMOTE USER NETWORK IMPLEMENTATION

Cisco SAFE Implementation 1.1

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

7-1

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

vi

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

Copyright

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

2003, Cisco Systems, Inc.

1

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

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

Course Objectives Upon completion of this course, you will be able to perform the following tasks: • Describe in detail the four basic types of threats that may be encountered in 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. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—1-3

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

1-2

Cisco SAFE Implementation 1.1

CSI 1.1—1-4

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—1-5

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

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—1-6

Course Introduction

1-3

Participant Responsibilities

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

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

CSI 1.1—1-7

General Administration

Class-related • Sign-in sheet

• Participant materials

• Length and times

• Site emergency procedures

• Break and lunch room locations • Attire

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

1-4

Facilities-related

Cisco SAFE Implementation 1.1

• Restrooms • Telephones/faxes

CSI 1.1—1-8

Copyright

2003, Cisco Systems, Inc.

Graphic Symbols

IOS Router

PIX Firewall

Network Access Server

Policy Manager

Hub

Modem

VPN 3000

CA Server

Ethernet Link

IDS Sensor

Catalyst 6500 with IDS Module

PC

Laptop

Network Cloud

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

VPN Tunnel

IOS Firewall

Server Web, FTP, etc.

Switch

CSI 1.1—1-9

Participant Introductions

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

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—1-10

Course Introduction

1-5

Cisco Security Career Certifications Expand Your Professional Options and Advance Your Career Cisco Certified Security Professional (CCSP) Certification Professional-level recognition in designing and implementing Cisco security solutions Expert CCIE

Professional CCSP

Required Exam

Recommended Training through Cisco Learning Partners

9E0-111 or 642-521

Cisco Secure PIX Firewall Advanced 3.1

9E0-121 or 642-511

Cisco Secure Virtual Private Networks 3.1

640-100 or 642-501 9E0-100 or 642-531

Associate CCNA

9E0-131 or 642-541

Network Security

Securing Cisco IOS Networks 1.0 Cisco Secure Intrusion Detection System 3.0 Cisco Secure Intrusion Detection System 4.0 Cisco SAFE Implementation 1.1

www.cisco.com/go/ccsp © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—1-11

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

Required Exam

Recommended Training through Cisco Learning Partners

Pre-requisite: Valid CCNA certification

640-100 or 642-501

Securing Cisco IOS Networks 1.0

9E0-111 or 642-521

Cisco Secure PIX Firewall Advanced 3.1

Cisco VPN Specialist

Required Exam

Recommended Training through Cisco Learning Partners

Pre-requisite: Valid CCNA certification

Cisco IDS Specialist

640-100 or 642-501

Securing Cisco IOS Networks 1.0

9E0-121 or 642-511

Cisco Secure Virtual Private Networks 3.1 Required Exam

Recommended Training through Cisco Learning Partners

Pre-requisite: Valid CCNA certification

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

1-6

Cisco SAFE Implementation 1.1

640-100 or 642-501

Securing Cisco IOS Networks 1.0

9E0-100 or 642-531

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

www.cisco.com/go/training

CSI 1.1—1-12

Copyright

2003, Cisco Systems, Inc.

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

Lab Visual Objective VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24 .150

.10P e0/1

Branch

brP .1 e0/0

10.2.P.0/24

RBB .1

10.2.P.11 .2

Branch

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP .150

172.16.P.0/24

.2 e0

PSS WWW FTP

priv

.1 e4

.1 e2

DMZ .5

pP .5

.1 e1

pub 172.18.P.0/24

cP

.50

Super Server WWW FTP

.10

.4

10.0.P.0 /24

.100

RTS

sensorP

Student

10.0.P.11

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

CSI 1.1—1-14

Each pair of students will be assigned a pod.

Note

Copyright

The P in a command indicates your pod number.

2003, Cisco Systems, Inc.

Course Introduction

1-7

Lab Visual Objective—Case Study VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24

.10P e0/1

.150

brP

Branch

RBB

.1 e0/0 10.3.P.0/24

.1

pub 10.3.P.5

cP

priv 10.2.P.1

Branch

192.168.P.0/24

10.2.P.11

10.2.P.0/24

.2 e0 172.16.P.0/24

PSS WWW FTP

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

.1 e2 .1 e1

.1 e5

DMZ drP

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

.50 .10

10.0.P.0 /24

Super Server WWW FTP

.100

RTS

Student

10.0.P.11

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

CSI 1.1—1-15

Each pair of students will be assigned a pod.

Note

1-8

The P in a command indicates your pod number.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

2

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

Objectives This section lists the 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. • • • • •

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

2-2

Cisco SAFE Implementation 1.1

CSI 1.1—2-2

Copyright

2003, Cisco Systems, Inc.

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

The Closed Network

Closed network PSTN

Remote site

Frame relay X.25 leased line

PSTN

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

CSI 1.1—2-4

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-3

The Network Today Open network Mobile and remote users

Internet

Internet-based intranet (VPN) Internet-based extranet (VPN)

Remote site PSTN

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

Partner site

CSI 1.1—2-5

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.

2-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Threat Capabilities—More Dangerous and Easier to Use Packet forging/ spoofing

High

Stealth diagnostics Back doors

Sophistication of hacker tools

Sweepers Sniffers

Exploiting known vulnerabilities

Hijacking sessions Disabling audits

Self replicating code

Technical knowledge required

Password cracking

Password guessing

Low

1980

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

1990

2000 CSI 1.1—2-6

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-5

The Role of Security is Changing

The need for security is becoming more important because of the following reasons: • Required for e-business • Required for communicating and doing business safely in potentially unsafe environments • Result has been that networks require development and implementation of a corporatewide security policy

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

CSI 1.1—2-7

Security has moved to the forefront of network management and implementation. It is necessary for the survival of many businesses to allow open access to network resources, and ensure that the data and resources are as secure as possible. The need for security is becoming more important because of the following: Required for e-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.

2-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The E-Business Challenge

E-commerce

Internet business value

Supply chain

Workforce optimization

Customer care

E-learning

Business security requirements

Internet access

Corporate intranet

Internet presence

• • • •

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

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

CSI 1.1—2-8

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-7

Legal and Governmental Policy Issues

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

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

CSI 1.1—2-9

The legal ramifications of breaches in data confidentiality and integrity can also be extremely costly for organizations. The US Government has enacted and is currently developing regulations to control the privacy of electronic information. The existing and pending regulations generally stipulate that organizations in violation could face a range of penalties. The following are some examples: Gramm-Leach Bliley (GLB) 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 selfassessments and independent assessments of their security practices and policies, which are required for submission. The Health Insurance Portability and Accountability Act (HIPPA) of 1996 (Public Law 104191)—Part of a broad Congressional attempt at incremental healthcare reform. The “administrative simplification” aspect of that law requires the United States Department of Health and Human Services (DHHS) to develop standards and requirements for maintenance and transmission of health information that identifies individual patients. These standards are designed to do the following:

2-8

—

Improve the efficiency and effectiveness of the healthcare system by standardizing the interchange of electronic data for specified administrative and financial transactions

—

Protect the security and confidentiality of electronic health information

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-9

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

What Is a Security Policy?

“A security policy is a formal statement of the rules by which people who are given access to an organization’s technology and information assets must abide.” –(RFC 2196, Site Security Handbook)

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

CSI 1.1—2-11

According to the Site Security Handbook (RFC 2196), “A security policy is a formal statement of the rules by which people who are given access to an 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.”

2-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Why Create a Security Policy?

• To create a baseline of your current security posture • To set the framework for security implementation • To define allowed and not allowed behaviors • To help determine necessary tools and procedures • To communicate consensus and define roles • To define how to handle security incidents

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

CSI 1.1—2-12

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-11

What Should the Security Policy Contain?

• Statement of authority and scope • Acceptable use policy • Identification and authentication policy • Internet use policy • Campus access policy • Remote access policy • Incident handling procedure

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

CSI 1.1—2-13

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.

2-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Network Security Is a Continuous Process

Network security is a continuous process built around a security policy:

Secure

Improve

Security Policy

Monitor

• Step 1: Secure • Step 2: Monitor • Step 3: Test

Test

• Step 4: Improve

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

CSI 1.1—2-15

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-13

Secure the Network Implement security solutions to stop or prevent unauthorized access or activities, and to protect information:

Secure

Improve

Security Policy

Monitor

• Authentication • Encryption

Test

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

CSI 1.1—2-16

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.

2-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Monitor Security

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

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

Secure

Improve

Security Policy

Monitor

Test

CSI 1.1—2-17

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-15

Test Security

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

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

Secure

Improve

Security Policy

Monitor

Test

CSI 1.1—2-18

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

2-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Improve Security

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

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

Secure

Security Policy

Monitor

Test

CSI 1.1—2-19

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-17

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

Variety of Attacks

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

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

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

Dial-in exploitation

Internal exploitation

Compromised host

CSI 1.1—2-21

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

2-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—2-22

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-19

Specific Attack Types All of the following can be used to compromise your system: • • • • • • • • • • •

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

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

CSI 1.1—2-23

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

2-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Specific Attack Types (cont.)

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

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

CSI 1.1—2-24

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-21

Packet Sniffers Host A

Router A

Router B

Host B

A packet sniffer is a software application that uses a network adapter card in promiscuous mode to capture all network packets. The following are the packet sniffer features: • Packet sniffers exploit information passed in clear text. Protocols that pass information in the clear include the following: – Telnet – FTP – SNMP – POP – HTTP • Packet sniffers must be on the same collision domain. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—2-25

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

2-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Packet Sniffer Example

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

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

CSI 1.1—2-26

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

Captures all packets

—

Included with some operating systems

—

Freeware and shareware versions available

Designed for attack purpose Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-23

2-24

—

Captures first 300 to 400 bytes

—

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Packet Sniffer Mitigation Host A

Router A

Router B

Host B

The following techniques and tools can be used to mitigate sniffers: • 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. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—2-27

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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-25

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

2-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—2-28

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-27

IP Spoofing Mitigation The threat of IP spoofing can be reduced, but not eliminated, through the following measures: • Access 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

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

CSI 1.1—2-29

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.

2-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

DoS

DoS attacks focus on making a service unavailable for normal use. They have the following characteristics: • Different from most other attacks because they are generally not targeted at gaining access to your network or the information on your network • Require very little effort to execute • Among the most difficult to completely eliminate

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

CSI 1.1—2-30

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-29

DDoS Example 1. Scan for systems to hack.

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

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

Handler systems

3. Agents are loaded with remote control attack software.

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

CSI 1.1—2-31

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.

2-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

DoS Mitigation

The threat of DoS attacks can be reduced through the following three methods: • Antispoof 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

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

CSI 1.1—2-32

When involving specific network server applications, such as a HTTP server or a File Transfer Protocol (FTP) server, these attacks can focus on acquiring and keeping open all the available connections supported by that server, effectively locking out valid users of the server or service. DoS attacks can also be implemented using common Internet protocols, such as TCP and ICMP. While most DoS attacks exploit a weakness in the overall architecture of the system being attacked rather than a software bug or security hole, some attacks compromise the performance of your network by flooding the network with undesired, and often useless, network packets and by providing false information about the status of network resources. The threat of DoS attacks can be reduced through the following three methods: Antispoof 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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-31

Password Attacks

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

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

CSI 1.1—2-33

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

2-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Password Attack Example

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

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

CSI 1.1—2-34

Just as with packet sniffers and IP spoofing attacks, a brute-force password attack can provide access to accounts that can be used to modify critical network files and services. An example that compromises your 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–Z plus 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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-33

Password Attacks Mitigation

The following are mitigation techniques: • Do not allow users to use the same password on multiple systems. • Disable accounts after a certain number of unsuccessful login attempts. • Do not use plain text passwords. An OTP or a cryptographic password is recommended. • Use “strong” passwords. Strong passwords are at least eight characters long and contain uppercase letters, lowercase letters, numbers, and special characters.

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

CSI 1.1—2-35

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.

2-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Man-in-the-Middle Attacks Host A

Host B Data in clear text Router A

Router B

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

CSI 1.1—2-36

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-35

Man-in-the-Middle Mitigation

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

IPSec tunnel Host A

Host B

Router A

ISP

Router B

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

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

CSI 1.1—2-37

Man-in-the-Middle attack mitigation is achieved, as shown in the figure, by encrypting traffic in an IPSec tunnel, which would only allow the hacker to see cipher text.

2-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Application Layer Attacks Application layer attacks have the following characteristics: • Exploit well known weaknesses, such as protocols, that are intrinsic to an application or system (for example, sendmail, HTTP, and FTP) • Often use ports that are allowed through a firewall (for example, TCP port 80 used in an attack against a web server behind a firewall) • Can never be completely eliminated, because new vulnerabilities are always being discovered

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

7 6 5 4 3 2 1

Application Presentation Session Transport Network Deata link Physical

CSI 1.1—2-38

Application-layer attacks can be implemented using several different methods: One of the most common methods is exploiting well known weaknesses in software commonly found on servers, such as sendmail, PostScript, and FTP. By exploiting these weaknesses, attackers can gain access to a computer with the permissions of the account running the application, which is usually a privileged, system-level account. Trojan horse program attacks are implemented using programs that an attacker substitutes for common programs. These programs may provide all the functionality that the normal program provides, but also include other features that are known to the attacker, such as monitoring login attempts to capture user account and password information. These programs can capture sensitive information and distribute it back to the attacker. They can also modify application functionality, such as applying a blind carbon copy to all e-mail messages so that the attacker can read all of your 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,

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-37

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

2-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Application Layer Attacks Mitigation

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

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

CSI 1.1—2-39

The following are some measures you can take to reduce your risks for application layer attacks: Read operating system and network log files or have them 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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-39

Network Reconnaissance

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

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

CSI 1.1—2-40

Network Reconnaissance refers to the overall act of learning information about a target network by using publicly available information and applications. When hackers attempt to penetrate a particular network, they often need to learn as much information as possible about the network before launching attacks. Examples include DNS queries, ping sweeps, and port scans: Domain Name System (DNS) 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.

2-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Network Reconnaissance Example

Sample IP address query

Sample domain name query © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—2-41

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-41

Network Reconnaissance Mitigation

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

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

CSI 1.1—2-42

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

2-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

SystemA Trusts SystemB SystemB Trusts Everyone SystemA Trusts Everyone

SystemA User = psmith; Pat Smith

Hacker gains access to SystemA

SystemB – Compromised by hacker User = psmith; Pat Smith

Hacker User = psmith; Pat Smithson

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

CSI 1.1—2-43

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-43

Trust Exploitation Mitigation

SystemA User = psmith; Pat Smith

Hacker blocked

Hacker User = psmith; Pat Smithson

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

SystemB Compromised by a hacker User = psmith; Pat Smith

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

CSI 1.1—2-44

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

2-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Port Redirection

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

Attacker

Source: Attacker Destination: A Port: 22

Source: Attacker Destination: B Port: 23

Compromised Host A

Source: A Destination: B Port: 23

Host B

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

CSI 1.1—2-45

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-45

Unauthorized Access

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

CSI 1.1—2-46

While not a specific type of attack, unauthorized access attacks refer to the majority of attacks executed in networks today. In order for someone to brute-force a Telnet login, they must first get the Telnet prompt on a system. Upon connection to the Telnet port, the hacker might see the message “authorization required to use this resource.” If the hacker continues to attempt access, the 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.

2-46

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Virus and Trojan Horses

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

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

CSI 1.1—2-47

The primary vulnerabilities for end-user workstations are viruses and Trojan horse attacks. Viruses refer to malicious software that is attached to another program to execute a particular unwanted function on a 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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-47

CAM Table Overflow A C? A C? Port 2

MAC B

Port 3 MAC A

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

A C? MAC D

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

CSI 1.1—2-48

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

2-48

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

CAM Table Overflow Attack Mitigation A

C?

A C? Port 2

MAC B

Port 3 MAC A

Specify the allowed MAC addresses

A

C? MAC D

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

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

CSI 1.1—2-49

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

Note

Copyright

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

2003, Cisco Systems, Inc.

Security Fundamentals

2-49

VLAN Hopping Double encapsulation example

The frame is encapsulated with two 802.1q headers

The first switch strips the first header

1

The frame is forwarded out all ports with inner 802.1q tag

2 The frame is forwarded out all ports with the inner 802.1q tag

There are two types of VLAN hopping attacks: • Double Tagging • Switch Spoofing © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—2-50

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.

2-50

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VLAN Hopping Attack Mitigation

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

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

CSI 1.1—2-51

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-51

MAC Spoofing Attack A Destination MAC: A

1

C ARP (A) B

3 Switch Port 1 2 3 Host

A,B

C

2 Destination MAC: A

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

CSI 1.1—2-52

MAC spoofing attacks involve the use of a known MAC address and IP address of a host on a remote VLAN in order to try and get the target switch to forward frames from the attacker. By sending a single frame with the 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.

2-52

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

MAC Spoofing Attack Mitigation A Destination MAC: A

1

C ARP (A) B

3 Switch port 1 2 3 Host

A

B

C

2

The associate MAC address to a specific port

Destination MAC: A

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

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

CSI 1.1—2-53

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-53

ARP Spoofing Attack

• An attacker attaches his MAC address to another station’s IP address • The hold-down timers can mitigate this attack

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

A

192.168.0.1 MAC A

1

B 192.168.0.2 MAC B

2 192.168.0.1 MAC B

CSI 1.1—2-54

A similar attack to the ARP/MAC poisoning attack is an ARP spoofing attack where an attacker that lies within an ARP domain attaches their MAC address to another 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.

2-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Private VLAN Attacks SRC: A1 DST: C2

Attacker MAC: A IP: 1

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

ARP (A)

Target MAC: B IP: 2

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

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

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

CSI 1.1—2-55

While PVLANs are a common mechanism to restrict communications between systems on the same logical IP subnet it is not a full-proof mechanism. Private VLANs work by limiting which ports within a VLAN can communicate with other ports in the same VLAN. Isolated ports within a VLAN can communicate only with promiscuous ports. Community ports can communicate only with other members of the same community and promiscuous ports. Promiscuous ports can communicate with any port. In a proxy attack against private VLANs frames are forwarded to a host on the network connected to a promiscuous port such as a router. This attack allows for only unidirectional traffic because any attempt by the target to send traffic back will be blocked by the PVLAN configuration. If both hosts are compromised then static ARP entries could be used to allow bidirectional traffic. In the previous figure, the attacker sends a packet with the source IP and MAC address of his machine, a destination IP of the target system, but a destination MAC address of the router. The switch forwards the frame to the 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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-55

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.

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

CSI 1.1—2-56

By attacking the Spanning-Tree Protocol, the network attacker hopes to spoof his or her system as the root bridge in the topology. To do this the network attacker broadcasts out Spanning-Tree Protocol Configuration/Topology Change Bridge Protocol Data Units (BPDUs) in an attempt to force spanning-tree recalculations. The BPDUs sent out by the network 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 2-56

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-57

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

Configuration Management

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

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

CSI 1.1—2-58

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

2-58

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Configuration Management Recommendations

When possible, the following practices are advised: • Use IPSec, SSH, SSL, or any other encrypted and authenticated transport. • ACLs should be configured to allow only management servers to connect to the device. All attempts from other IP addresses should be denied and logged. • RFC 2827 filtering at the perimeter router should be used to mitigate the chance of an outside attacker spoofing the addresses of the management hosts.

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

CSI 1.1—2-59

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-59

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

CSI 1.1—2-60

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

2-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Logging

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

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

CSI 1.1—2-61

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-61

Logging Recommendations

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

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

CSI 1.1—2-62

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

2-62

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—2-63

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals

2-63

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

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

CSI 1.1—2-64

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

2-64

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—2-66

Security Fundamentals

2-65

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

2-66

Cisco SAFE Implementation 1.1

CSI 1.1—2-67

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—2-68

Security Fundamentals

2-67

2-68

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals Lab 2-1

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

Lab Visual Objective VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24

brP .1 e0/0

10.2.P.0/24

.150

.10P e0/1

Branch

RBB .1

10.2.P.11

Branch

.2

e0/1

172.30.P.0/24

.150

e0/0

192.168.P.0/24

rP

.2 e0

PSS, WWW, and FTP

172.16.P.0/24

pP .1 e4

.1 e2

DMZ .5

private .5

.1 e1

public 172.18.P.0/24

cP

.50 .10

Super server, WWW, and FTP

.4

10.0.P.0 /24

.100

RTS

sensorP

Student

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

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

CSI 1.1—2-1

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. ÝæÄØ¿½µïðïIJ½ ó¸

Step 3

Port scan the target host or devices as specified by the instructor: ÝæÄØ¿½µïðïIJ½ óª ó¦ ó² ó© í ïéîòïêòÐòëð îðóììí øËÒÕÒÑÉÒ÷ ÅïéîòïêòÐòëðà èð øá÷ ±°»² øËÒÕÒÑÉÒ÷ ÅïéîòïêòÐòëðà îë øá÷ ±°»² øËÒÕÒÑÉÒ÷ ÅïéîòïêòÐòëðà îï øá÷ ±°»²

(where P = pod number)

Lab 2-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

Security Fundamentals Lab 2-3

Lab 2-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

3

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

Objectives This section lists the chapter’s objectives.

Objectives

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

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

3-2

Cisco SAFE Implementation 1.1

CSI 1.1—3-2

Copyright

2003, Cisco Systems, Inc.

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-indepth approach focusing on the expected threats and their mitigation (failure of one system is not likely to compromise network resources)

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

CSI 1.1—3-4

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-3

Key Components of a SAFE Network

Identity

Authentication, digital certificates

Perimeter security

ACLs, Firewalls

Secure connectivity

Security monitoring

VPN Tunneling, encryption

Intrusion detection, scanning

Security management

Policy management, device management

Internet

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

CSI 1.1—3-5

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.

3-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Principles SP edge PSTN module

Medium network/ branch edge Corporate Internet module

Campus module Management server

PSTN

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

Medium network/ branch campus

Corporate users

ISP edge module

Internet Frame or ATM module

FR/ATM

Public services

WAN module

Corporate servers

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

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

CSI 1.1—3-6

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-5

SAFE SMR Assumptions

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

SP edge

Medium network/branch edge

PSTN module

Corporate Internet module

Medium network and branch campus Campus module Management server

PSTN

Corporate users

ISP edge module Public services

Internet Frame or ATM module

WAN module

Corporate servers

FR/ATM

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

CSI 1.1—3-7

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.

3-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

SAFE SMR Environment SAFE SMR uses the following design objectives: • Security and attack mitigation is based on policy. • Security implementation must be throughout the infrastructure (not just on specialized security devices). • Deployment must be cost-effective. • Management and reporting must be secure. • Users and administrators of critical network resources must be authenticated and authorized. • Intrusion detection must be used for critical resources and subnets.

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

CSI 1.1—3-9

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-7

devices outside the network require management and reporting. In these cases in-band management may be necessary. Users and administrators of critical network resources must be authenticated and 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.

3-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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-in HIDS threat Router

Internal IP Threat

Internet

Personal firewall

HIDS on PCs WAN Critical Critical resources IDS Sensors

Second line of defense

Wireless threat

First line of defense

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

CSI 1.1—3-10

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-9

SAFE SMR Resiliency SAFE Enterprise with resiliency example

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

Remote access VPN

Site-to-Site VPN PSTN Traditional dial access servers

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

CSI 1.1—3-11

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

3-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

SAFE SMR integrated functionality example ISP edge module

ISP

VPN Software Client with personal firewall

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

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

CSI 1.1—3-12

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

2003, Cisco Systems, Inc.

Architectural Overview

3-11

SAFE SMR Module Concept SAFE SMR uses a green field or “from scratch” module approach, which has the following advantages: • The architecture addresses security relationships between the various functional blocks of the network. • Security can be implemented on a module-by-module basis instead of attempting the entire architecture in a single phase. • Modules can and should be combined to achieve desired functionality. © 2003, Cisco Systems, Inc. All rights reserved.

Medium network modules PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM

CSI 1.1—3-13

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

3-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

A Target-Rich Environment SAFE SMR is based on the following axioms: • Routers are 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. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—3-15

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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-13

Intrusion detection systems (IDSs)—When an IDS detects something that it considers an attack; it can either take corrective action itself or notify a management system for actions by the administrator. Secure management and 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.

3-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Routers Are Targets Router security is a critical element in any security deployment: • Routers advertise networks and filter who can use them. • Routers are potentially a hacker’s best friend. • Routers provide access and, therefore, you should secure them to reduce the likelihood that they can be directly compromised.

Medium network modules PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM

Routers are targets

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

CSI 1.1—3-16

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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-15

Routers Are Targets— General Guidelines Corporate Internet module

The following are general guidelines: • Lock down Telnet access to a router. • Lock down SNMP access to a router. • Control access to a router through the use of TACACS+. • Turn off unneeded services. • Log at appropriate levels.

Public services

WAN module

• Authenticate routing updates.

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

CSI 1.1—3-17

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; readwrite strings should be used only for actual write operations. Control access to a router through the use of Terminal Access Controller Access Control System Plus (TACACS+)—TACACS+ is a protocol providing detailed accounting 3-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

information and flexible administrative control over authentication and authorization processes to control unauthorized access. TACACS+ is facilitated through authentication, authorization, and accounting (AAA). Turn off unneeded 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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-17

Switches Are Targets

Medium network modules PSTN module

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

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM

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

CSI 1.1—3-18

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

3-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Switches Are Targets— General Guidelines The following are general guidelines:

Corporate Internet module

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

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

Public services

WAN module

CSI 1.1—3-19

The following guidelines are in addition to router-specific guidelines and apply to both Layer 2 and Layer 3 switches: Ports without any need to trunk should have trunk settings set to 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 VLANtagging protocols were not designed with security in mind, makes their use in sensitive environments inadvisable. Private VLANs provide some added security to specific network applications (not available on most low-end switches)—They work by limiting which ports within a VLAN can communicate with ports in the same VLAN. The figure identifies the location of the switches in the SAFE SMR example.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-19

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

Medium network modules PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM

Hosts are targets CSI 1.1—3-20

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

3-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Hosts Are Targets— General Guidelines Corporate Internet module

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

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

Public services

WAN module

CSI 1.1—3-21

The following are guidelines that can be a major factor in maintaining a secure environment for hosts: Pay careful attention to each of the components within the 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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-21

Networks Are Targets

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

Medium network modules PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM

Networks are targets

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

CSI 1.1—3-22

Network attacks are among the most difficult attacks to deal with because they typically take advantage of an intrinsic characteristic in the way your network operates. These attacks include: Address Resolution Protocol (ARP)—Identifies network component addresses for further attack. Media Access Control (MAC)-based Layer 2 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.

3-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Networks Are Targets— General Guidelines Corporate Internet module

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

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

Public services

WAN module

CSI 1.1—3-23

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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-23

Error! Not a valid link.

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

3-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Applications Are Targets— General Guidelines

The following are general guidelines:

Corporate Internet module

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

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

Public services

WAN module

CSI 1.1—3-25

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-25

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

Medium network modules PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module Public services

Internet Frame or ATM module

Corporate servers

WAN module

FR/ATM

NIDS

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

HIDS

CSI 1.1—3-26

IDSs act like an alarm system in the physical world. When an IDS detects something that it considers an attack, it can either take corrective action itself or notify a management system for actions by the administrator. Some systems are more or less equipped to respond to and prevent such an attack. Host-based intrusion detection can work by intercepting operating system and application calls on an individual host. It can also operate by after-the-fact analysis of local log files. The former approach allows better attack prevention, whereas the latter approach dictates a more passive attack-response role. Because of the specificity of their role, host-based IDSs (HIDSs) are often better at preventing specific attacks than network-based IDSs (NIDSs), which usually issue only an alert upon discovery of an attack. However, that specificity causes a loss of perspective to the overall network. This is where NIDS excels. Ideally, Cisco recommends a combination of the two 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.

3-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IDSs—General Guidelines The following are general guidelines:

Corporate Internet module

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

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

Public services

WAN module

CSI 1.1—3-27

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.

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-27

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

CSI 1.1—3-28

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-29

Secure Management and Reporting Logging and reading information from many devices can be very challenging. The following issues must be considered: Identify which logs are most important. Separate important messages from notifications. Ensure that logs are not tampered with in transit. Ensure that time stamps match each other when multiple devices report the same alarm. • Identify what information is needed if log data is required for a criminal investigation. • Identify how to deal with the volume of messages that can be generated when a system is under attack. • • • •

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

CSI 1.1—3-29

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

Architectural Overview

3-31

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

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

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

3-32

Cisco SAFE Implementation 1.1

CSI 1.1—3-31

Copyright

2003, Cisco Systems, Inc.

4

The Cisco Security Portfolio Overview This chapter introduces and gives an overview of a Cisco security portfolio. It includes the following topics: Objectives Cisco security portfolio overview Secure 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 This section lists the chapter’s objectives.

Objectives

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

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

4-2

Cisco SAFE Implementation 1.1

CSI 1.1—4-2

Copyright

2003, Cisco Systems, Inc.

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

Cisco Security Solutions Secure connectivity

VPN Cisco VPN Concentrators

Perimeter security

Intrusion protection

Identity

Firewalls

Intrusion detection scanning

Authentication

Cisco PIX Firewalls

Cisco PIX Firewalls Cisco IOS VPN

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

Cisco Access Control Server

Cisco PIX Firewalls

Cisco IOS Firewall

Cisco IOS IDS

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

Security management

Policy CiscoWorks— VPN and security management solution Cisco Secure Policy Manager

CSI 1.1—4-4

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 —

Copyright

Cisco Network-based Intrusion Detection System (NIDS) Sensor

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-3

—

Cisco IOS-based intrusion detection

—

Cisco Intrusion Detection System Module (IDSM)

—

PIX Firewall-based intrusion detection

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, fulltime assistance. Cisco support and service also includes the tools, expertise, and resources needed to quickly install, maintain, and enhance Cisco security and VPN products to protect the business network as effectively as possible. Unsurpassed 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.

4-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-5

SAFE Blueprint and Ecosystem Secure e-commerce

Solutions

Secure supply chain management

Secure intranet for workforce optimization

$

Ecosystem

Integration partners Security Associate solutions Cisco programs and services

Directory

Service control Infrastructure Appliances or clients

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

Operations

Applications

Cisco AVVID system architecture CSI 1.1—4-5

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

4-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure 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

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

CSI 1.1—4-7

Secure connectivity provides the following: Data privacy, encryption, and VPN —

Provides security over untrusted public networks

—

Provides enhanced transport security for “private” networks

Extended network reach —

Teleworkers

—

New or small sites

—

Partner connectivity

Cost-effective, high-bandwidth connectivity —

Copyright

Reduces transport costs

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-7

—

4-8

Enables fast broadband telecommuters and remote site connectivity

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Overview—VPNs Home office Intranet VPN—Low cost, tunneled connections with rich VPN services, which lead to cost savings and new applications

Remote office POP

Main office

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

Remote access VPN—Cost saving

Business partner Mobile worker

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

CSI 1.1—4-8

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 costeffectively to corporate network resources from anywhere in the world over any access technology. Because this traffic may run on un-trusted segments outside the service provider’s network, it must be encrypted to ensure privacy and security.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-9

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 SOHO market

3015, 3005 Concentrator

3600, 2600, 1700 series routers

PIX Firewall 515, 506

VPN 3000 Client 3002 Hardware Client

SOHO, 800, 900 series routers

PIX Firewall 506, 501

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

CSI 1.1—4-9

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

4-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure 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

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

CSI 1.1—4-11

The following are the features and uses for the Cisco VPN 3000 Concentrator Series: Primarily used for remote access Includes a standards-based VPN Client and management GUI Allows mobile workers and telecommuters broadband connectivity over cable and DSL Uses Remote Access Dial-In User Service (RADIUS) for authentication Split 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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-11

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

4-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Models

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

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

3005 100 4 0 64 No No No 100

3015 100 4 0 128 Yes Optional Yes 100

3030 1500 50 1 128 Yes Optional Yes 500

3060 5000 100 2 256 Yes Optional Yes 1,000

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

CSI 1.1—4-12

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-13

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

CSI 1.1—4-13

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

4-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco VPN 3002 Hardware VPN Client Cisco VPN Client

Single user 3002

Cable modem Home office Cisco VPN 30xx

3002

Internet DSL modem Small office

• Easy deployment • Centralized policy push

3002

ISDN modem

• Two 10/100, and 8-port hub version • DHCP client and server • PAT (external and tunnel) • Client and network extension modes

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

CSI 1.1—4-14

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-15

Remote Access Wireless VPN Main office Cisco VPN 30xx

Internet

Mobile Certicom client

Aironet client Cisco VPN 3000 Client

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

Aironet client

CSI 1.1—4-15

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

4-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Secure 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 © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—4-17

Site-to-site VPNs are an alternative WAN infrastructure that are used to connect branch offices, home offices, or business partners’ sites to all or portions of a 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

Copyright

—

A leased line

—

Frame relay

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-17

—

ATM

Connects remote, branch office, and central sites Enables customers to avoid exorbitant 800 number costs as well as modem technology Implements at the WAN edge

4-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Site-to-Site VPN Scalability and Features Summary

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

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

CSI 1.1—4-18

Cisco VPN-optimized routers include high-performance, hardware-based IPSec encryption, multiple WAN interfaces, and the entire Cisco IOS Software feature set. Using Cisco IOS Software, Cisco VPN Routers also provide a comprehensive feature set to meet the most diverse networking requirements, including support for routing, multiprotocol, and multicast across the VPN, as well as enhanced features like firewall capabilities and QoS. The following are Site-to-Site VPN scalability and features summary for Cisco VPN optimized routers: 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 —

Copyright

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

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-19

—

4-20

Use as standalone VPN device or integrated multi-function device

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco Site-to-Site VPN Solutions— Scalability for Every Site Cisco 1700 Series • VPN-optimized router connecting remote offices at T1/E1 speeds

Cisco 7000 Series Remote office

• VPN-optimized routers for dedicated VPN head-end and hybrid private WAN and VPN connectivity Main office

Regional office

Internet

Cisco 2600 and 3600 Series • VPN-optimized routers connecting branch and regional offices at nxT1/E1 speeds

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

Cisco SOHO, 800 and 900 Series Small office/ home office

• VPN-optimized routers for ISDN, DSL, and cable connectivity

CSI 1.1—4-19

Site-to-Site VPNs are best constructed using a wide variety of Cisco VPN Routers. VPN Routers provide scalability through optional encryption acceleration. The Cisco VPN Router portfolio provides solution for small office/home office (SOHO) access through central-site VPN aggregation, including platforms for fast-emerging cable and digital subscriber line (DSL) access technologies. The following provides recommendations for scalability for Site-to-Site VPN solutions: Remote 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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-21

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

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

CSI 1.1—4-20

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

4-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Perimeter Security 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 © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—4-22

Globally networked businesses rely on their networks to communicate with employees, customers, partners, and suppliers. While immediate access to information and communication is an advantage, it raises concerns about security-protecting access to critical network resources. Network administrators need to know who is accessing what resources and establish clear perimeters to control that access. An effective security policy balances accessibility with protection. Security policies are enforced at network perimeters. Often people think of a perimeter as the boundary between an internal network and the Internet, but a perimeter can be established anywhere within a private network, or between your network and a 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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-23

Restricts access to network resources Implemented at the physical perimeter between customer intranet and the other company’s intranet Determines whether traffic crossing in either direction is authorized Little or no impact on network performance

4-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PIX Firewall Family

Price

PIX 535-UR

PIX 525-UR PIX 515E-UR

PIX 506E

Gigabit Ethernet

PIX 501

SOHO

ROBO

SMB

Enterprise

SP

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

CSI 1.1—4-23

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-25

VAC

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

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

CSI 1.1—4-24

The VPN Accelerator Card (VAC) for the PIX Firewall series provides high-performance, tunneling and encryption services suitable for site-to-site and remote access applications. This hardware-based VPN accelerator is optimized to handle the repetitive but voluminous mathematical functions required for IPSec. Offloading encryption functions to the card not only improves IPSec encryption processing, but also maintains high-end firewall performance. As an integral component of the Cisco virtual VPN solution, the VAC provides platform scalability and security while working seamlessly with services necessary for successful VPN 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. 4-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-27

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 © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—4-25

As network security becomes increasingly critical to securing business transactions, businesses must integrate security into the network design and infrastructure. Security policy enforcement is most effective when it is an inherent component of the network. Cisco IOS Software runs on more than 80 percent of Internet backbone routers, making it the most fundamental component of 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-theart security features, such as stateful, application-based filtering; dynamic per-user authentication and authorization; defense against network attacks; Java blocking; and real-time alerts. When combined with Cisco IOS IPSec software and other Cisco IOS software-based technologies, such as Layer 2 Tunneling Protocol (L2TP) and QoS, the Cisco IOS Firewall provides a complete, integrated VPN solution.

4-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS Firewall—CBAC

The following are the CBAC features: • Stateful inspection

The user Initiates an IP session.

User

• A state table maintains session state information • ACL entries are dynamically created and deleted

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

The return traffic for the user’s IP session is permitted. The other IP traffic is blocked.

IOS Firewall using CBAC

CSI 1.1—4-26

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-29

Real-time alerts and audit trails

4-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Overview—Intrusion Detection Deployment Scenarios Business partner

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

Users

Corporate office

Data center

NAS

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

Internet

Remote access IDS— Hardens perimeter control by monitoring remote users

DMZ servers

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

CSI 1.1—4-28

The Cisco IDS is an enterprise-class, network-based intrusion detection system. Designed to address the increased requirements for security visibility, denial-of-service (DoS) protection, antihacking detection, and e-commerce business defenses, the Cisco IDS family leads the market in innovative security monitoring solutions. Sensor devices detect unauthorized activity traversing the network, such as attacks by hackers, by analyzing traffic in real time, enabling users to quickly respond to security breaches. When unauthorized activity is detected, Cisco IDS Sensors can send alarms to a management console with details of the activity, and can control other systems, such as routers, to terminate the unauthorized sessions. There are four recommended deployment scenarios: Extranet 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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-31

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

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

CSI 1.1—4-29

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.

4-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Cisco IDSs provide the following: Real-time security 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 falsepositive 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 hostbased 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.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-33

Error! Not a valid link.

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

4-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

The Cisco IDS 4200 Series Sensors are purpose-built, high-performance network security “appliances” that protect against unauthorized, malicious activity traversing the network (for example, attacks by hackers). Cisco IDS Sensors analyze traffic in real time, enabling users to quickly respond to security breaches. The IDSM is a switching module that is easy to install and maintain in the Catalyst 6000 family switch. The IDSM performs network 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.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-35

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

1 2 3 4 5 6 7 8 9 0

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

1 2 3 4 5 6 7 8 9 0

CSI 1.1—4-34

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

4-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Restrictions such as time of day and day of week User and device group profiles

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-37

Error! Not a valid link.

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

4-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-39

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

Error! Not a valid link.

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

4-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

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

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-41

Error! Not a valid link.

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

VPN

—

Firewall

—

NIDS

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

4-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Error! Not a valid link.

The Internet is creating tremendous business opportunities for Cisco and Cisco customers. Internet business solutions such as e-commerce, supply chain management, e-learning, and customer care are dramatically increasing productivity and efficiency. Cisco AVVID is the one enterprise architecture that provides the intelligent network infrastructure for 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.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-43

Error! Not a valid link.

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

4-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

With Cisco AVVID, customers have a comprehensive roadmap for enabling Internet business solutions and creating a competitive advantage. There are four Cisco AVVID benefits: 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.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-45

Error! Not a valid link.

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

4-46

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

The Cisco Security Portfolio

4-47

5

SAFE Small Network Design Overview The following are the sections covered in this chapter. Objectives Small network design overview Small network corporate Internet module Small network campus module Implementation—ISP router Implementation—IOS Firewall features and configuration Implementation—PIX Firewall Summary Lab exercise

Objectives This section lists the chapter’s objectives.

Objectives

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

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

5-2

Cisco SAFE Implementation 1.1

CSI 1.1—5-2

Copyright

2003, Cisco Systems, Inc.

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

SAFE Design for Small Networks

SP edge

Small network or branch edge Corporate Internet module

ISP

Small network or branch campus Campus module Management Server

Isolated service network Public services

Firewall

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

Corporate users Corporate servers

CSI 1.1—5-4

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-3

Small Network Corporate Internet Module This section discusses the Corporate Internet Module.

Small Network Corporate Internet Module Components and Key Devices

The following are key devices: • Servers – SMTP – DNS – FTP or HTTP • Firewall or IOS Firewall router • Layer 2 switch • HIDS

IOS Firewall or PIX Firewall

Servers

Layer 2 switch

Public services

ISP

ISP router

To campus

One or the other IOS Firewall or PIX Firewall

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

CSI 1.1—5-6

The Corporate Internet Module provides internal users with connectivity to Internet services and Internet users access to information on public servers. VPN access is also provided to remote locations and telecommuters. This module is not designed to serve e-commerce type applications. The following are key devices in the Corporate Internet Module: SMTP 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 5-4

Provides host-level intrusion detection.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats and Mitigation Roles The following threats can be expected: • Unauthorized 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

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

CSI 1.1—5-7

There are publicly addressable servers that are the most likely points of attacks. The following are expected threats to those publicly addressable servers: Unauthorized 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.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-5

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

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

CSI 1.1—5-8

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.

5-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Small Network Attack Mitigation Roles for the Corporate Internet Module Stateful packet filtering, basic layer 7 filtering, host DoS mitigation, and spoof mitigation

HIDS local attack mitigation

Private VLANs

ISP

Public services

Spoof mitigation and rate-limiting

One or the other

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

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

CSI 1.1—5-9

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

Spoof mitigation

—

Rate-limiting

Firewall —

Stateful packet filtering

—

Basic Layer 7 filtering

—

Host DoS mitigation

—

Spoof mitigation

Layer 2 switches (with private VLAN support) —

Private VLANs

HIDS —

Copyright

HIDS local attack

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-7

—

Mitigation

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

5-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—5-10

The SAFE SMR Small Network Design alternatives represent the ultimate in scaled-down, security-conscious network design, where all the security and VPN services are compressed into a single device. There are two choices when deciding how to implement this network design: Use a router with firewall and VPN 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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-9

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

5-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Small Network Campus Module The following section discusses the campus module.

Small Network Campus Module Key Devices

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

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

User workstations

Management host Corporate servers

To the corporate Internet module

Layer 2 switch

CSI 1.1—5-12

The Campus Module contains end-user workstations, corporate intranet servers, management servers, and the associated Layer 2 infrastructure required to support the devices. Within the small network design, this Layer 2 functionality has been combined into a single switch. The following are key devices for the SAFE SMR Small Network Campus Module: Layer 2 switch (with private VLAN support)—Provides Layer 2 services to user workstations Corporate 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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-11

Expected Threats and Mitigation Roles

You can expect the following threats: • Packet sniffers • Virus and Trojan horse applications • Unauthorized access • Application layer attacks • Trust exploitation • Port redirection

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

HIDS local attack mitigation Management server

To corporate Internet module

Host virus scanning

HIDS local attack mitigation

Corporate users Corporate servers

Private VLANs

CSI 1.1—5-13

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

5-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Host virus scanning

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-13

Design Guidelines and Alternatives The following guidelines and alternatives are available: • Private VLANs can be enabled in order to mitigate trust-exploitation attacks between the devices. • Because there are no Layer 3 services within the campus module, it is important to note that this design places an increased emphasis on application and host security due to the open nature of the internal network. • Alternatives involve setting a small filtering router or firewall between the management stations and the rest of the network.

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

CSI 1.1—5-14

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

5-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

ISP Router— Implementation Commands Spoof mitigation rate-limiting Management Server

ISP

Public Services

Corporate Users

Firewall

The following are necessary mitigation roles and implementation commands: • Spoof mitigation and RFC filtering – access-list – access-group • Rate-limiting – rate-limit © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-16

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-15

Implementation Commands—Spoof Mitigation and RFC Filtering router(config)#

¿½½»--ó´·-¬ ¿½½»--ó´·-¬ó²«³¾»® ż§²¿³·½ ¼§²¿³·½ó²¿³» Ŭ·³»±«¬ ³·²«¬»-Ãà ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ -±«®½» -±«®½»ó©·´¼½¿®¼ ¼»-¬·²¿¬·±² ¼»-¬·²¿¬·±²ó©·´¼½¿®¼ Å°®»½»¼»²½» °®»½»¼»²½»Ã Ŭ±- ¬±-à Ŵ±¹ ¤ ´±¹ó·²°«¬Ã Ŭ·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã • The access-list command enables you to specify if an IP address is permitted or denied access to a port or protocol.

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

router(config-if)#

·° ¿½½»--ó¹®±«° ¥¿½½»--ó´·-¬ó²«³¾»® ¤ ¿½½»--ó´·-¬ó ²¿³»£¥·² ¤ ±«¬£ • The access-group command binds an ACL to an interface.

®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»--ó¹®±«° ïðï ·² © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-17

Cisco provides basic traffic filtering capabilities with access control lists (ACLs). ACLs can be configured for all routed network protocols (IP, AppleTalk, and so on) to filter the packets of those protocols as the packets pass through a router. You can configure ACLs at your router to control access to a network: ACLs can prevent certain traffic from entering or exiting a network. ACLs should be used in IOS Firewall routers, which are often positioned between your internal network and an external network (for example, the Internet). You can also use ACLs on a router positioned between two parts of your network, to control traffic entering or exiting a specific part of your internal network. To provide the security benefits of ACLs, you should at a minimum configure ACLs on border 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.

5-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

dynamic dynamic-name

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

timeout minutes

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

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

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

source

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-17

source-wildcard

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

The syntax for the access-group command is as follows: ip access-group {access-list-number | access-list-name}{in | out}

5-18

access-list-number

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

access-list-name

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

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

ISP

To campus

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

CSI 1.1—5-19

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

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-19

sessions from being triggered by the hacker during the primary attack. An attack that generates an xterm from the Web server through the firewall to the 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.

5-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

CSI 1.1—5-20

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)

Copyright

—

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.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-21

5-22

—

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 SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

CSI 1.1—5-21

IPSec commands

Copyright

—

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.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-23

Spoof Mitigation and RFC Filtering—ACLs router(config)# ¿½½»--ó´·-¬ ¿½½»--ó´·-¬ó²«³¾»® ż§²¿³·½ ¼§²¿³·½ó²¿³» Ŭ·³»±«¬ ³·²«¬»-Ãà ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ -±«®½» -±«®½»ó©·´¼½¿®¼ ¼»-¬·²¿¬·±² ¼»-¬·²¿¬·±²ó©·´¼½¿®¼ Å°®»½»¼»²½» °®»½»¼»²½»Ã Ŭ±- ¬±-à Ŵ±¹ ¤ ´±¹ó·²°«¬Ã Ŭ·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã • The access-list command enables you to specify if an IP address is permitted or denied access to a port or protocol. ®±«¬»®ø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

router(config-if)# ·° ¿½½»--ó¹®±«° ¥¿½½»--ó´·-¬ó²«³¾»® ¤ ¿½½»--ó´·-¬ó ²¿³»£¥·² ¤ ±«¬£ • The access-group command binds an ACL to an interface. ®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»--ó¹®±«° ïðï ·² © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-22

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

5-24

access-list-number

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

dynamic dynamic-name

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

timeout minutes

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

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

source

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

source-wildcard

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

The syntax for the access-group command is as follows: ip access-group {access-list-number | access-list-name}{in | out}

Copyright

access-list-number

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

access-list-name

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

in

Filters on inbound packets.

out

Filters on outbound packets.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-25

Spoof Mitigation Example— RFC 2827 Filtering ¿½½»--ó´·-¬ ïðï °»®³·¬ ïçîòïêèòðòð ðòîëëòîëëòîëë ¿²§ ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ¿²§ ¿²§

• Ingress packets must be from customer addresses

Egress from Internet Customer network: 192.168.0.0/16

ISP network Ingress to Internet ·²¬»®º¿½» Û¬¸»®²»¬ »ðñï

• Egress packets cannot be from and to customers

·° ¿½½»--ó¹®±«° ïîð ·² ·° ¿½½»--ó¹®±«° ïí𠱫¬ ÿ ¿½½»--ó´·-¬ ïîð ¼»²§ ·° ïçîòïêèòðòð ¿½½»--ó´·-¬ ïîð °»®³·¬ ·° ¿²§ ¿²§ ÿ ¿½½»--ó´·-¬ ïíð °»®³·¬ ïçîòïêèòðòð

ðòðòîëëòîëë ¿²§

ðòðòîëëòîëë ¿²§

• Ensure that ingress packets are valid

¿½½»--ó´·-¬ ïíð ¼»²§ ·° ¿²§ ¿²§ © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-23

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

5-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Unauthorized Access— IOS Firewall Intrusion Detection The following are the IOS Firewall intrusion detection features: • Acts as an in-line intrusion detection sensor • When a packet or packets match a signature, it can perform any of the following configurable actions: – 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 © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-24

Cisco IOS Firewall and intrusion-detection solutions are designed to meet security requirements within a network, whether the requirement is for multilevel security with a dedicated appliance (Cisco PIX Firewall or Cisco IDS Sensor) or for integrated security wherever a router is deployed (Cisco IOS Firewall with intrusion detection). The standalone appliance and integrated Cisco solutions meet the various network security needs in a network, based on an 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.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-27

Implementation Commands— IOS Firewall Intrusion Detection router # ·° ¿«¼·¬ ²¿³» ¿«¼·¬ó²¿³» ¥·²º± ¤ ¿¬¬¿½µ£ Å´·-¬ -¬¿²¼¿®¼ó ¿½´Ã Å¿½¬·±² Å¿´¿®³Ã ż®±°Ã Å®»-»¬Ãà • Creates audit rules for info and attack signature types

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

router # ·° ¿«¼·¬ ¿¬¬¿½µ ¥¿½¬·±² Å¿´¿®³Ã ż®±°Ã Å®»-»¬Ã • Specifies the default actions for attack signatures

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

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

CSI 1.1—5-25

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

Name for an audit specification.

info

Specifies that the audit rule is for info signatures.

attack

Specifies that the audit rule is for attack signatures.

list

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

standard-acl

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

action

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

alarm

(Optional.) Sends an alarm to the console, NetRanger Director, or to a Syslog server. Use with the action keyword.

drop

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

reset

(Optional.) Resets the TCP session.

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

5-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

action

Specifies an action for the attack signature to take in response to a match.

alarm

(Optional.) Sends an alarm to the console, NetRanger Director, or to a Syslog server. Used with the action keyword.

drop

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

reset

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

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-29

Implementation Commands— IOS Firewall Intrusion Detection (cont.) router# ·° ¿«¼·¬ ²±¬·º§ ¥²®ó¼·®»½¬±® ¤ ´±¹£ • Specifies the method of event notification

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

router# ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ²«³¾»®ó±ºó»ª»²¬• Specifies the maximum number of event notifications that are placed in the router's event queue

᫬»®ý ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð

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

CSI 1.1—5-26

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

Send messages in NetRanger format to the NetRanger Director or Sensor.

log

Send messages in Syslog format.

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

5-30

Cisco SAFE Implementation 1.1

Integer in the range from 1 to 65535 that designates the maximum number of events allowable in the event queue. The default is 100 events.

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—5-27

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-31

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

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

CSI 1.1—5-28

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

5-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Basic Layer 7 Filtering—Inspection Rules for Application Protocols Router(config)#

·° ·²-°»½¬ ²¿³» ·²-°»½¬·±²ó²¿³» °®±¬±½±´ Å¿´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Ŭ·³»±«¬ -»½±²¼-à • Defines the application protocols to inspect • Will be applied to an interface – Available protocols: tcp, udp, cuseeme, ftp, http, h323, netshow, rcmd, realaudio, rpc, smtp, sqlnet, streamworks, tftp, and vdolive – alert, audit-trail, and timeout are configurable per protocol and override global settings

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

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

CSI 1.1—5-29

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

Copyright

inspection-name

Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name.

protocol

The protocol to inspect. Use of the following keywords: tcp, udp, cuseeme, ftp, http, h323, netshow, rcmd, realaudio, rpc, smtp, sqlnet, streamworks, tftp, or vdolive.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-33

5-34

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert messages can be set to on or off. If no option is selected, alerts are generated based on the setting of the ip inspect alert-off command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to on or off. If no option is selected, audit trail messages are generated based on the setting of the ip inspect audit trail command.

timeout seconds

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Apply an Inspection Rule to an Interface

Router(config-if)#

·° ·²-°»½¬ ·²-°»½¬·±²ó²¿³» ¥·² ¤ ±«¬£ • Applies the named inspection rule to an interface

᫬»®ø½±²º·¹÷ý ·²¬»®º¿½» »ðñð ᫬»®ø½±²º·¹ó·º÷ý ·° ·²-°»½¬ ÚÉÎËÔÛ ·² • Applies the inspection rule to interface e0/0 in inward direction

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

CSI 1.1—5-30

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

Copyright

inspection-name

Identifies which set of inspection rules to apply.

in

Applies the inspection rules to inbound traffic.

out

Applies the inspection rules to outbound traffic.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-35

Example Inspection Rule for Java Router(config)#

·° ·²-°»½¬ ²¿³» ·²-°»½¬·±²ó²¿³» ¸¬¬° ¶¿ª¿ó´·-¬ ¿½´ó²«³ Å¿´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Ŭ·³»±«¬ -»½±²¼-à • Controls java blocking with a standard ACL

᫬»®ø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ÚÉÎËÔÛ ¸¬¬° ¶¿ª¿ó´·-¬ ïð ¿´»®¬ ±² ¿«¼·¬ó¬®¿·´ ±² ¬·³»±«¬ íðð ᫬»®ø½±²º·¹÷ý ·° ¿½½»--ó´·-¬ ïð ¼»²§ ïéîòîêòîêòð ðòðòðòîëë ᫬»®ø½±²º·¹÷ý ·° ¿½½»--ó´·-¬ ïð °»®³·¬ ïéîòîéòîéòð ðòðòðòîëë

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

CSI 1.1—5-31

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

Note

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

The syntax for the ip inspect name command is as follows: ip inspect name inspection-name http [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]

5-36

inspection-name

Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name.

http

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

java-list access-list

(Optional.) Specifies the numbered standard ACL to use to determine "friendly" sites. This keyword is available only for the HTTP protocol, for Java applet blocking. Java blocking only works with numbered standard ACLs.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert messages can be set to on or off. If no option is selected, alerts are generated based on the setting of the ip inspect alert-off command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to on or off. If no option is selected, audit trail messages are generated based on the setting of the ip inspect audit trail command.

timeout seconds

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

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-37

Example Inspection Rule for RPC Applications Router(config)#

·° ·²-°»½¬ ²¿³» ·²-°»½¬·±²ó²¿³» ®°½ °®±¹®¿³ó²«³¾»® ²«³¾»® Å©¿·¬ó¬·³» ³·²«¬»-à ſ´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Ŭ·³»±«¬ -»½±²¼-à • Allows given RPC program numbers—wait-time keeps the connection open for a specified number of minutes

᫬»®ø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ÚÉÎËÔÛ ®°½ °®±¹®¿³ó²«³¾»® ïðððîî ©¿·¬ó¬·³» ð ¿´»®¬ ±ºº ¿«¼·¬ó¬®¿·´ ±² © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-32

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

5-38

inspection-name

Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name as the existing set of rules.

rpc program-number number

Specifies the program number to permit. This keyword is available only for the remote-procedure call protocol.

wait-time minutes

(Optional.) Specifies the number of minutes to keep a small hole in the firewall to allow subsequent connections from the same source address and to the same destination address and port. The default wait-time is zero minutes. This keyword is available only for the RPC protocol.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert messages can be set to on or off. If no option is selected, alerts are generated based on the setting of the ip inspect alert-off command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to on or off. If no option is selected, audit trail messages are generated based on the setting of the ip inspect audit trail command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

timeout seconds

Copyright

2003, Cisco Systems, Inc.

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

SAFE Small Network Design

5-39

Example Inspection Rule for SMTP Applications Router(config)#

·° ·²-°»½¬ ²¿³» ·²-°»½¬·±²ó²¿³» -³¬° Å¿´»®¬ ¥±²¤±ºº£Ã Å¿«¼·¬ó¬®¿·´ ¥±²¤±ºº£Ã Ŭ·³»±«¬ -»½±²¼-à • Only allows the following legal commands in SMTP applications: DATA, EXPN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML, and VRFY • If disabled, all SMTP commands are allowed through the firewall, and potential mail server vulnerabilities are exposed

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

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

CSI 1.1—5-33

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

5-40

inspection-name

Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name as the existing set of rules.

protocol

A protocol keyword.

alert {on | off}

(Optional.) For each inspected protocol, the generation of alert messages can be set to on or off. If no option is selected, alerts are generated based on the setting of the ip inspect alert-off command.

audit-trail {on | off}

(Optional.) For each inspected protocol, audit-trail can be set to on or off. If no option is selected, audit trail messages are generated based on the setting of the ip inspect audit trail command.

timeout seconds

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Example Inspection Rule for IP Packet Fragmentation Router(config)#

·° ·²-°»½¬ ²¿³» ·²-°»½¬·±²ó²¿³» º®¿¹³»²¬ ³¿¨ ²«³¾»® ¬·³»±«¬ -»½±²¼• Protects hosts from certain DoS attacks involving fragmented IP packets – max = number of unassembled fragmented IP packets – timeout = seconds when the unassembled fragmented IP packets begin to be discarded

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

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

CSI 1.1—5-34

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

Note

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

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-41

The syntax for the ip inspect name command is as follows: ip inspect name inspection-name fragment [max number timeout seconds] inspection-name

Names the set of inspection rules. If you want to add a protocol to an existing set of rules, use the same inspection-name as the existing set of rules.

fragment

Specifies fragment inspection for the named rule.

max number

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

timeout seconds

5-42

Cisco SAFE Implementation 1.1

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

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—5-35

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-43

Implementation Commands— Authenticate Remote Site router(config)#

¿¿¿ ²»©ó³±¼»´ • Enables the AAA access control model

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

router(config)#

¬¿½¿½-ó-»®ª»® ¸±-¬ ¸±-¬²¿³» Å°±®¬ ·²¬»¹»®Ã Ŭ·³»±«¬ ·²¬»¹»®Ã ŵ»§ -¬®·²¹Ã • Specifies a TACACS+ host

®±«¬»®ø½±²º·¹÷ý ¬¿½¿½-ó-»®ª»® ¸±-¬ ïçîòïêèòïòïð -·²¹´»ó½±²²»½¬·±² µ»§ ½·-½±-¿º» © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-36

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

5-44

hostname

Name or IP address of the host.

port

(Optional.) Specifies a server port number. This option overrides the default, which is port 49.

integer

(Optional.) Port number of the server. Valid port numbers range from 1 to 65535.

timeout

(Optional.) Specifies a timeout value. This overrides the global timeout value set with the tacacs-server timeout command for this server only.

integer

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

key

(Optional.) Specifies an authentication and encryption key. This must match the key used by the TACACS+ daemon. Specifying this key overrides the key set by the global command tacacsserver key for this server only.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

string

Copyright

2003, Cisco Systems, Inc.

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

SAFE Small Network Design

5-45

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

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¥¼»º¿«´¬ ¤ ´·-¬ó²¿³»£ ³»¬¸±¼ï ų»¬¸±¼îòòòà ¿¿¿ ¿«¬¸±®·¦¿¬·±² ¥²»¬©±®µ ¤ »¨»½ ¤ ½±³³¿²¼´»ª»´ ¤ ®»ª»®-»ó¿½½»-- ¤ ½±²º·¹«®¿¬·±²£ ¥¼»º¿«´¬ ¤ ´·-¬ó²¿³»£ ³»¬¸±¼ï ų»¬¸±¼î›Ã ´±¹·² ¿«¬¸»²¬·½¿¬·±² ¥¼»º¿«´¬ ¤ ´·-¬ó²¿³»£ • These commands enable AAA authentication at login, restrict network access to a user, and define the authentication method used.

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

CSI 1.1—5-37

Complete the following tasks to configure AAA authentication: Step 1

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

Step 2

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

Step 3

5-46

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands— Authenticate Remote Site (cont.)

®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ´±½¿´ »²¿¾´» ®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½´·²» ®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ®±«¬»®ø½±²º·¹÷ý ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ -¬¿®¬ó -¬±° ¹®±«° ¬¿½¿½-õ ®±«¬»®ø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½• Examples of the AAA commands

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

CSI 1.1—5-38

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-47

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

Uses the listed authentication methods that follow this argument as the default list of methods when a user logs in.

list-name

Character string used to name the list of authentication methods activated when a user logs in.

method1 [method2...]

At least one keyword.

The syntax for the aaa authorization command is as follows: aaa authorization {network | exec | commands level | reverse-access | configuration} {default | list-name} method1 [method2...] network

Runs authorization for all network-related service requests, including SLIP, PPP, PPP NCPs, and ARA.

exec

Runs authorization to determine if the user is allowed to run an EXEC shell. This facility might return user profile information such as autocommand information.

commands

Runs authorization for all commands at the specified privilege level.

level

Specific command level that should be authorized. Valid entries are 0 through 15.

reverse-access

Runs authorization for reverse access connections, such as reverse Telnet.

configuration

Downloads the configuration from the AAA server.

default

Uses the listed authorization methods that follow this argument as the default list of methods for authorization.

list-name

Character string used to name the list of authorization methods.

method1 [method2...]

At least one keyword.

The syntax for the aaa accounting command is as follows: aaa accounting {auth-proxy | system | network | exec | connection | commands level} {default | list-name} {startstop | stop-only | wait-start | none} [broadcast] group groupname

5-48

auth-proxy

Provides information about all authenticated-proxy user events.

system

Performs accounting for all system-level events not associated with users, such as reloads.

network

Runs accounting for all network-related service requests, including SLIP, PPP, PPP NCPs, and ARAP.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

exec

Runs accounting for EXEC shell session. This keyword might return user profile information such as what is generated by the autocommand command.

connection

Provides information about all outbound connections made from the network access server, such as Telnet, LAT, TN3270, PAD, and rlogin.

commands level

Runs accounting for all commands at the specified privilege level. Valid privilege level entries are integers from 0 through 15.

default

Uses the listed accounting methods that follow this argument as the default list of methods for accounting services.

list-name

Character string used to name the list of at least one of the accounting methods.

start-stop

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

stop-only

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

wait-start

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

none

Disables accounting services on this line or interface.

broadcast

(Optional.) Enables sending accounting records to multiple AAA servers. Simultaneously sends accounting records to the first server in each group. If the first server is unavailable, failover occurs using the backup servers defined within that group.

group groupname

At least one keyword.

The syntax for the login authentication command is as follows: login authentication {default | list-name}

Copyright

default

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

list-name

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

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-49

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

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

Public services

ISP

To campus

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

CSI 1.1—5-40

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 —

5-50

access-list—Creates an ACL

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

—

Copyright

access-group—Binds the ACL to an interface

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-51

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

Public services

ISP

To campus

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

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

CSI 1.1—5-41

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

5-52

—

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

—

Copyright

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

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-53

Access Through the PIX Firewall

nat and global

Internet

e0 outside security level 0

e1 inside security level 100

PIX Firewall

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

CSI 1.1—5-42

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

Note

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

Static NAT creates a permanent, one-to-one mapping between an address on an internal network (a higher security level interface) and a perimeter or external network (lower security level interface). For example, to share a web server on a perimeter interface with users on the public Internet, use static address translation to map the 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.

5-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands— Host DoS Mitigation pixfirewall(config)#

·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ·²¬Á²¿³» • Protects an individual interface against IP spoofing by enabling both ingress and egress filtering to verify addressing and route integrity

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

pixfirewall(config)#

·½³° °»®³·¬ ¤ ¼»²§ Ÿ±-¬Ã -®½Á¿¼¼® Å-®½Á³¿-µÃ Ŭ§°»Ã ·²¬Á²¿³» • Permits or denies the ability to ping a PIX Firewall interface

°·¨º·®»©¿´´ø½±²º·¹÷ý ·½³° ¼»²§ ¿²§ ±«¬-·¼» © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-43

The ip verify reverse-path command implements the following: Performs a route lookup based on the source address. Usually, the route lookup is based on the destination address. This is why it is called reverse path forwarding. With this command enabled, packets are dropped if there is no route found for the packet or the route found does not match the interface on which the packet arrived. Specifies which interfaces to protect from an IP spoofing attack using network ingress and egress filtering, which is described in RFC 2267. This command is disabled by default and provides Unicast Reverse Path Forwarding (Unicast RPF) functionality for the PIX Firewall. Provides ingress filtering. Ingress filtering checks inbound packets for IP source address integrity, and is limited to addresses for networks in the enforcing 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.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-55

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

Note

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

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

5-56

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

ip verify reverse-path interface

Protects an individual interface against IP spoofing by enabling both ingress and egress filtering to verify addressing and route integrity. This command depends upon a default route previously defined in the configuration. See RFC 2267 for more information.

The syntax for the icmp permit command is as follows: icmp permit | deny [host] src_addr [src_mask] [type] int_name

Copyright

deny

Disables the ability to ping a PIX Firewall interface.

int_name

The interface name.

permit

Enables the ability to ping a PIX Firewall interface.

src_addr

Address that is either permitted or denied ability to ping an interface. Use host src_addr to specify a single host.

src_mask

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

type

ICMP message type.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-57

Implementation Commands— Host DoS Mitigation (cont.)

pixfirewall(config)#

-§-±°¬ -»½«®·¬§ º®¿¹¹«¿®¼ • Enables the IP Frag Guard feature • The sysopt commands enables you to tune various PIX Firewall security and configuration features

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

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

CSI 1.1—5-44

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

Note

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

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

Note

5-58

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

Enables the IP Frag Guard feature.

SAFE Small Network Design

5-59

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

-¬¿¬·½ Åø°®»²¿¬Á·²¬»®º¿½»ô °±-¬²¿¬Á·²¬»®º¿½»÷à ¥³¿°°»¼Á¿¼¼®»--¤ ·²¬»®º¿½»£ ®»¿´Á¿¼¼®»-- ż²-à Ų»¬³¿-µ ³¿-µÃ Ų±®¿²¼±³-»¯Ã Ž±²²»½¬·±²Á´·³·¬ Å»³Á´·³·¬Ãà • The static command creates a persistent, one-to-one address translation rule (called a static translation slot or "xlate"). This translation can be between a local IP address and a global IP address (static NAT) or between ports (static PAT). The embryonic connection limit [em_limit] prevents attack by a flood of embryonic connections. An embryonic connection is one that has started but not yet completed. The default is 0, which means unlimited connections.

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

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

CSI 1.1—5-45

The static command creates a persistent, one-to-one address translation rule (called a static translation slot or “xlate”). This translation can be between a local IP address and a global IP address (static Network Address Translation [NAT]) or between ports (static Port Address Translation [PAT]). For an external host to initiate traffic to an inside host, a static translation rule needs to exist for the inside host; this can also be done using a nat 0 access-list address translation rule. Without the persistent translation rule, the translation cannot occur. You can use the static and access-list commands when you are accessing the interface of a higher security level from an interface of a lower security level (for example, when accessing the inside from a perimeter or the outside interface). Prior to version 5.3, the PIX Firewall offered no mechanism to protect systems reachable via a static and TCP conduit from TCP SYN attacks. Previously, if an embryonic connection limit was configured in a static command statement, the PIX Firewall dropped new connection attempts after the embryonic threshold was reached. Given this, a modest attack could stop an 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 5-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

dns

Specifies that DNS replies that match the xlate are translated.

em_limit

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

global_ip

A global IP address. This address cannot be a Port Address Translation (PAT) IP address. The IP address on the lower security level interface you are accessing.

interface

Specifies to overload the global address from interface.

mapped_address

The address into which real_address is translated.

netmask

Reserve word required before specifying the network mask.

norandomseq

Do not randomize the TCP/IP packet's sequence number. Only use this option if another inline firewall is also randomizing sequence numbers and the result is scrambling the data. Use of this option opens a security hole in the PIX Firewall.

postnat_interface

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

prenat_interface

Usually the inside interface, in which case the translation is applied to the inside address.

real_address

The address to be mapped.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-61

Spoof Mitigation and RFC 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.

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

CSI 1.1—5-46

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

5-62

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

¿½½»--ó´·-¬ ¿½´Á×Ü Å¼»²§ ¤ °»®³·¬Ã °®±¬±½±´ ¥-±«®½»Á¿¼¼® ¤ ´±½¿´Á¿¼¼®£ ¥-±«®½»Á³¿-µ ¤ ´±½¿´Á³¿-µ£ ±°»®¿¬±® °±®¬ ¥¼»-¬·²¿¬·±²Á¿¼¼® ¤ ®»³±¬»Á¿¼¼®£ ¥¼»-¬·²¿¬·±²Á³¿-µ ¤ ®»³±¬»Á³¿-µ£ ±°»®¿¬±® °±®¬ • The access-list command enables you to specify if an IP address is permitted or denied access to a port or protocol.

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

¿½½»--ó¹®±«° ¿½´Á×Ü ·² ·²¬»®º¿½» ·²¬»®º¿½»Á²¿³» • The access-group command binds an ACL to an interface.

°·¨º·®»©¿´´ø½±²º·¹÷ý ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-47

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

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

deny

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-63

destination_addr

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

destination_mask

Netmask bits (mask) to be applied to destination_addr, if the destination address is a network mask.

local_addr

Address of the network or host local to the PIX Firewall. Specify a local_addr when the access-list command statement is used in conjunction with a crypto access-list command statement, a nat 0 access-list command statement, or a vpngroup split-tunnel command statement. The local_addr is the address after NAT has been performed.

local_mask

Netmask bits (mask) to be applied to local_addr, if the local address is a network mask.

The syntax for the access-group command is as follows: access-group acl_ID in interface interface_name

5-64

acl_ID

The name associated with a given ACL.

in interface

Filter inbound packets at the given interface.

Interface_name

The name of the network interface.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Spoof Mitigation—RFC 1918 Filtering ·²¬»®º¿½» Í»®·¿´ ² ·° ¿½½»--ó¹®±«° ïðï ·² ÿ ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ïðòðòðòð

ðòîëëòîëëòîëë ¿²§

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

ðòïëòîëëòîëë ¿²§

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

ISP network

Customer network

Ingress to Internet

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

CSI 1.1—5-48

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.

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-65

Implementation Commands— Authenticate Remote Site

pixfirewall(config)#

¿¿¿ó-»®ª»® ¹®±«°Á¬¿¹ °®±¬±½±´ ¿«¬¸Á°®±¬±½±´ ¿¿¿ó-»®ª»® ¹®±«°Á¬¿¹ ø·ºÁ²¿³»÷ ¸±-¬ -»®ª»®Á·° µ»§ ¬·³»±«¬ -»½±²¼• These commands specify a AAA server • The PIX Firewall enables you to define separate groups of TACACS+ or RADIUS servers for specifying different types of traffic

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

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

CSI 1.1—5-49

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

5-66

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Specifies a AAA server or up to 14 groups of servers with a maximum of 14 servers each. Certain types of AAA services can be directed to different servers. Services can also be set up for failover to multiple servers.

group_tag

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

protocol auth_protocol

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

The syntax for the aaa-server command is as follows: aaa-server group_tag (if_name) host server_ip key timeout seconds aaa-server

Specifies a AAA server or up to 14 groups of servers with a maximum of 14 servers each. Certain types of AAA services can be directed to different servers. Services can also be set up for failover to multiple servers.

group_tag

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

if_name

The interface name on which the server resides.

host server_ip

The IP address of the TACACS+ or RADIUS server.

key

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

timeout seconds

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-67

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

¿¿¿ ¿«¬¸»²¬·½¿¬·±² Å-»®·¿´ ¤ »²¿¾´» ¤ ¬»´²»¬ ¤ --¸ ¤ ¸¬¬°Ã ½±²-±´» ¹®±«°Á¬¿¹ • Defines the AAA authentication method used.

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

pixfirewall(config)#

´±¹¹·²¹ ¸±-¬ Å·²Á·ºÁ²¿³»Ã ·°Á¿¼¼®»-Å°®±¬±½±´ñ°±®¬Ã • Specifies a syslog server that will receive the messages sent from the PIX Firewall.

°·¨º·®»©¿´´ø½±²º·¹÷ý ´±¹¹·²¹ ïðòðòÐòí © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—5-50

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

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

5-68

serial

Access verification for the PIX Firewall's serial console.

enable

Access verification for the PIX Firewall’s privilege mode.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

telnet

Access verification for the Telnet access to the PIX Firewall console.

ssh

Access verification for the SSH access to the PIX Firewall console.

http

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

console

Specifies that access to the PIX Firewall console requires authentication and, optionally, logs configuration changes to a Syslog server. The maximum password length for accessing the console is 16 characters.

group_tag

The AAA server group tag defined by the aaa-server command. To use the local PIX Firewall user authentication database, enter LOCAL for this parameter.

The syntax for the logging host command is as follows: logging host [in_if_name] ip_address [protocol/port]

Copyright

host

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

in_if_name

Interface on which the Syslog server resides.

ip_address

Syslog server's IP address.

protocol

The protocol over which the syslog message is sent; either tcp or udp. The PIX Firewall only sends TCP Syslog messages to the PFSS. You can only view the port and protocol values you previously entered by using the write terminal command and finding the command in the 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.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-69

Basic Layer 7 Filtering— Java Applet Filtering

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

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

CSI 1.1—5-51

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

5-70

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

filter java Command

pixfirewall(config)#

º·´¬»® ¶¿ª¿ °±®¬Åó°±®¬Ã ´±½¿´Á·° ³¿-µ º±®»·¹²Á·° ³¿-µ • The filter java command filters out Java applets that return to the PIX Firewall from an outbound connection.

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

CSI 1.1—5-52

The filter java command filters out Java applets that return to the PIX Firewall from an outbound connection. The user still receives the HTML page, but the web page source for the applet is commented out so that the applet cannot execute. Use 0 for the local_ip or foreign_ip IP addresses to mean all hosts.

Note

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

The syntax for the filter java command is as follows: filter java port[-port] local_ip mask foreign_ip mask

Copyright

java

Specifies to filter out Java applets returning from an outbound connection.

port

The port that receives Internet traffic on the PIX Firewall. Typically, this is port 80, but other values are accepted. The HTTP or URL can be used for port 80.

local_ip

The IP address of the highest security level interface from which access is sought. You can set this address to 0.0.0.0 (or in shortened form, 0) to specify all hosts.

mask

Any mask.

foreign_ip

The IP address of the lowest security level interface to which access is sought. You can use 0.0.0.0 (or in shortened form, 0) to specify all hosts.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-71

Java Applet Filtering Example ÿ º·´¬»® ¶¿ª¿ èð ðòðòðòð ðòðòðòð ðòðòðòð ðòðòðòð Egress from Internet ISP network

Customer network

Ingress to Internet

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

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

CSI 1.1—5-53

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

5-72

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ActiveX Blocking pixfirewall(config)#

º·´¬»® ¿½¬·ª»¨ °±®¬ ´±½¿´Á·° ³¿-µ º±®»·¹²Á·° ³¿-µ • Filters out ActiveX usage from outbound packets. • ActiveX controls are applets that can be inserted in web pages or other applications. • ActiveX controls can provide a way for someone to attack servers. • The PIX Firewall can be used to block ActiveX controls.

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

CSI 1.1—5-54

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

Copyright

activex

Block outbound ActiveX, Java applets, and other HTML tags from outbound packets.

port

The port that receives Internet traffic on the PIX Firewall. Typically, this is port 80, but other values are accepted. The http or url literal can be used for port 80.

local_ip

The IP address of the highest security level interface from which access is sought. You can set this address to 0.0.0.0 (or in shortened form, 0) to specify all hosts.

mask

Any mask.

foreign_ip

The IP address of the lowest security level interface to which access is sought. You can use 0.0.0.0 (or in shortened form, 0) to specify all hosts.

2003, Cisco Systems, Inc.

SAFE Small Network Design

5-73

filter activex Example Internet

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

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

Engineering 11.0.0.0

Marketing 12.0.0.0

Executive 14.0.0.0

TACACS+ server RADIUS server

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

CSI 1.1—5-55

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

Note

5-74

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—5-57

SAFE Small Network Design

5-75

5-76

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-1

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

Lab Visual Objective VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24 .150

.10P e0/1

Branch

brP .1 e0/0

10.2.P.0/24

RBB .1

10.2.P.11 .2

Branch

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP .150 .2 e0 172.16.P.0/24

PSS WWW FTP

priv

.1 e4

.1 e2

DMZ .5

pP .5

.1 e1

pub 172.18.P.0/24

cP

.50

Super Server WWW FTP

.10

.4

10.0.P.0 /24

.100

RTS

sensorP

Student

10.0.P.11

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

CSI 1.1—5-1

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

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Assign Telnet and enable passwords. Test and verify the configuration.

Network Security Policy You will implement the following security policies in this lab exercise: Control incoming traffic: —

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

—

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

—

Deny Internet users access to the corporate office internal network.

—

Deny inbound traffic from the 127.0.0.0, 192.168.0.0, and 10.0.P.0 networks (where P = pod number).

—

Permit Internet Control Message Protocol (ICMP) echo replies to internal networks.

—

Permit ICMP echo request to all PIX interfaces. The outside interface should not respond to requests from untrusted networks.

Control outgoing traffic: —

Deny traffic initiated from the PSS server.

—

Allow corporate users access to the Internet.

Apply PIX Firewall hardening and management: —

Enable logging.

—

Assign Telnet and enable passwords.

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

Note

Copyright

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

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-3

Task 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

(where P = pod number) Check your current configuration to familiarize yourself with the current setup: °·¨Ðý ©®·¬» ¬»®³·²¿´

Step 3

(where P = pod number) Assign the PIX Firewall a name, and assign the interfaces the names and security levels defined in the following table: Interface

Interface Name

Security Level

ethernet0

outside

0

ethernet1

inside

100

ethernet2

pss

50

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

(where P = pod number) Q1)

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

Step 4

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

IP Address

Netmask

outside

192.168.P.2

255.255.255.0

inside

10.0.P.1

255.255.255.0

pss

172.16.P.1

255.255.255.0

(where P = pod number) °·¨Ðø½±²º·¹÷ý ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòÐòî îëëòîëëòîëëòð °·¨Ðø½±²º·¹÷ý ·° ¿¼¼®»-- ·²-·¼» ïðòðòÐòï îëëòîëëòîëëòð °·¨Ðø½±²º·¹÷ý ·° ¿¼¼®»-- °-- ïéîòïêòÐòï îëëòîëëòîëëòð

(where P = pod number)

Lab 5-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 5

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

Speed

ethernet0

100full

ethernet1

10full

ethernet2

100full

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

(where P = pod number) Ensure that the IP addresses are correctly configured and are associated with the proper network interface: °·¨Ðø½±²º·¹÷ý -¸±© ·° ¿¼¼®»--

Step 7

(where P = pod number) Write the configuration to the Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)

Task 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

(where P = pod number) °·¨Ðø½±²º·¹÷ý ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòÐòííóïçîòïêèòÐòîîî ²»¬³¿-µ îëëòîëëòîëëòð °·¨Ðø½±²º·¹÷ý ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòÐòîîëóïçîòïêèòÐòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì °·¨Ðø½±²º·¹÷# -¸±© ¹´±¾¿´

(where P = pod number) Step 2

Configure the PIX Firewall to allow all inside hosts to use NAT for outbound access. Assign the hosts to use global pool identity 1. °·¨Ðø½±²º·¹÷ý ²¿¬ ø·²-·¼»÷ ï ïðòðòÐòð îëëòîëëòîëëòð ð ð

(where P = pod number) Q2)

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-5

Step 3

Assign the perimeter router’s inside interface as the PIX Firewall’s default route: °·¨Ðø½±²º·¹÷# ®±«¬» ±«¬-·¼» ð ð ïçîòïêèòÐòïëð

(where P = pod number) Q3)

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

Step 4

Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷# ©®·¬» ³»³±®§

Step 5

(where P = pod number) Write the current configuration to the terminal and verify that you have entered the previous commands correctly: °·¨Ðø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´

Step 6

(where P = pod number) Ping the following devices from the PIX Firewall to ensure they are operational: PIX Firewall inside 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) °·¨Ðø½±²º·¹÷ý °·²¹ ïðòðòÐòï °·¨Ðø½±²º·¹÷ý °·²¹ ·²-·¼» ïðòðòÐòïï °·¨Ðø½±²º·¹÷ý °·²¹ ïçîòïêèòÐòî °·¨Ðø½±²º·¹÷ý °·²¹ ïçîòïêèòÐòï °·¨Ðø½±²º·¹÷ý °·²¹ ïéîòïêòÐòï °·¨Ðø½±²º·¹÷ý °·²¹ ïéîòïêòÐòëð

(where P = pod number)

Lab 5-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Step 7

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

(where P = pod number) Q4)

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

Confirm your entries:

Step 8

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

(where P = pod number) Assign a name to the public services segment server’s private address using the name command, and verify that the name was entered properly:

Step 9

IP Address

Name

172.16.P.50

www-private

(where P = pod number) °·¨Ðø½±²º·¹÷ý ²¿³»°·¨Ðø½±²º·¹÷ý ²¿³» ïéîòïêòÐòëð ©©©ó°®·ª¿¬» °·¨Ðø½±²º·¹÷ý -¸±© ²¿³»

(where P = pod number) Step 10

Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number) Step 11

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

Task 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: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòÐòð îëëòîëëòîëëòð »½¸±ó ®»°´§

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-7

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

(where P = pod number) Step 2

Bind the ACL to the public services segment interface by creating an access group: °·¨Ðø½±²º·¹÷ý ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» °--

(where P = pod number) Step 3

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

Q5)

Test ICMP access to the VPN Client PC: 172.26.26.P. (where P = pod number) Why is it important to restrict outbound access from the public services segment network? A)

Step 4

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

Task 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: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëòð ¿²§

(where P = pod number) Q6)

Would you recommend being more restrictive? Why? A)

Step 2

Bind the ACL to the inside interface by creating an access group: °·¨Ðø½±²º·¹÷ý ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼»

Step 3

Lab 5-8

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Why is it important to restrict outbound access to “known” internal network addresses and hosts? A)

Task 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: °·¨Ðø½±²º·¹÷ý -¬¿¬·½ ø°--ô±«¬-·¼»÷ ïçîòïêèòÐòïï ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð

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

(where P = pod number) °·¨Ðø½±²º·¹÷ý ²¿³» ïçîòïêèòÐòïï ©©©ó°«¾´·½ °·¨Ðø½±²º·¹÷ý -¸±© ²¿³»

(where P = pod number) Step 3

Create ACLs to deny RFC 2827 and 1918 traffic. Note

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

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

(where P = pod number) Q8)

What threat do these ACL entries help mitigate? A)

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-9

Step 4

Create an ACL to allow inbound web and FTP access to the public address of the public services segment server: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬°

Step 5

(where P = pod number) Create an ACL to allow ICMP echo replies initiated from the internal network, and deny all other traffic: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòÐòð îëëòîëëòîëëòð »½¸±ó®»°´§ °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§

(where P = pod number) Step 6

Bind the ACL to the outside interface:

Step 7

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

Step 8

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

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

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

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

(where P = pod number) Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

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

Task 6—Implement Spoofing Protection Complete the following steps to implement Unicast Reverse Path Forwarding (RPF) IP spoofing protection: Step 1

Enable Unicast RPF IP spoofing protection for the outside and public services segment interfaces: °·¨Ðø½±²º·¹÷ý ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» °·¨Ðø½±²º·¹÷ý ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ

Step 2

(where P = pod number) Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)

Lab 5-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Task 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: °·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ±² °·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ¸±-¬ ïðòðòÐòïï °·¨Ðø½±²º·¹÷ý ´±¹¹·²¹ ¬®¿° ·²º±

(where P = pod number) Q9)

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

Step 2

Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)

Task 8—Assign Telnet and Enable Passwords Complete the following steps to assign Telnet and enable passwords: Step 1

Configure and set your enable password: °·¨Ðø½±²º·¹÷ý »²¿¾´» °¿--©±®¼ »²¿¾´» °·¨Ðø½±²º·¹÷ý °¿--©¼ ½·-½±

(where P = pod number) Step 2

Write the current configuration to Flash memory: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

Step 3

(where P = pod number) Compare your configuration to the following sample configuration from pix1: °·¨ïø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´ æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ·²¬ºì -»½«®·¬§î𠲿³»·º »¬¸»®²»¬ë ·²¬ºë -»½«®·¬§îë »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-11

º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬» ²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ©©©ó°®·ª¿¬» ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòïòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ï ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± -¸«¬¼±©² ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ·²¬ºì ïëð𠳬« ·²¬ºë ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ·²¬ºì ïîéòðòðòï îëëòîëëòîëëòîëë Lab 5-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

·° ¿¼¼®»-- ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºì ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºë ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëòð ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì ²¿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòïëð ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬ ¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æ½ê»é¼¿ç¾»é¿é¾é»½ëéë¿»èê뼿¾é¼¿ï½ æ »²¼

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-13

Task 9—Test and Verify the Configuration Complete the following steps to test your configuration: Step 1

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

Step 2

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

Step 3

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

Step 4

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

Step 5

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

Lab 5-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

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

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

—

Enforce password encryption to protect device passwords.

—

Disable unnecessary network services.

Log branch office router events: —

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

—

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

—

Set accurate time-stamping for log and debug messages.

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

Copyright

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

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-15

—

Allow Telnet to the perimeter router only from the student system inside the branch office network.

—

Authenticate Telnet sessions with usernames and passwords entered into the perimeter 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.

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

Copyright

2003, Cisco Systems, Inc.

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

Task 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: ¾®Ðø½±²º·¹÷ý ¾¿²²»® ´±¹·² ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÿ ¾®Ðø½±²º·¹÷ý ¾¿²²»® »¨»½ ÿDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÿ

Step 2

(where P = pod number) Enable password encryption and assign a secret enable password to protect the router’s passwords: ¾®Ðø½±²º·¹÷ý -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ¾®Ðø½±²º·¹÷ý »²¿¾´» -»½®»¬ -»½®»¬

Step 3

(where P = pod number) Disable unnecessary network and router services to limit the exposure to direct attacks against the router: ¾®Ðø½±²º·¹÷ý ²± ·° -±«®½»ó®±«¬» ¾®Ðø½±²º·¹÷ý ²± ½¼° ®«² ¾®Ðø½±²º·¹÷ý ²± -»®ª·½» º·²¹»® ¾®Ðø½±²º·¹÷ý ²± -»®ª·½» ¬½°ó-³¿´´ó-»®ª»®¾®Ðø½±²º·¹÷ý ²± -»®ª·½» «¼°ó-³¿´´ó-»®ª»®¾®Ðø½±²º·¹÷ý ²± ·° ¸¬¬° -»®ª»® ¾®Ðø½±²º·¹÷ý ²± ·° ¾±±¬° -»®ª»® ¾®Ðø½±²º·¹÷ý ²± ·° ¼±³¿·²ó´±±µ«° ¾®Ðø½±²º·¹÷ý ²± ·° ®½³¼ ®-¸ó»²¿¾´» ¾®Ðø½±²º·¹÷ý ²± ·° ®½³¼ ®½°ó»²¿¾´»

Note

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

¾®Ðø½±²º·¹ó·º÷ý ²± ·° °®±¨§ó¿®° ¾®Ðø½±²º·¹ó·º÷ý ²± ½¼° »²¿¾´» ¾®Ðø½±²º·¹ó·º÷ý ²± ·° ®»¼·®»½¬¾®Ðø½±²º·¹ó·º÷ý ²± ·° ¼·®»½¬»¼ó¾®±¿¼½¿-¬ Step 4

(where P = pod number) Enable logging to the Syslog server to provide a method to monitor router events including attacks: ¾®Ðø½±²º·¹÷ý -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» ¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ±²

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-17

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

(where P = pod number)

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

Step 2

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

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

¾®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì ¾®Ðø½±²º·¹ó´·²»÷ý °¿--©±®¼ ½·-½± ¾®Ðø½±²º·¹ó´·²»÷ý ¿½½»--ó½´¿-- ï ·² ¾®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ïë ¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´ Step 3

(where P = pod number) Assign a password to the console line to prevent access by unauthorized users: ¾®Ðø½±²º·¹ó´·²»÷ý ´·²» ½±² ð ¾®Ðø½±²º·¹ó´·²»÷ý °¿--©±®¼ ½·-½± ¾®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ïë ¾®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

Step 4

(where P = pod number) Create a local user account on the router that is used to log into the router: ¾®Ðø½±²º·¹÷ý «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ -¬«¼»²¬

Step 5

(where P = pod number) Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU time for system processes: ¾®Ðø½±²º·¹÷ý -½¸»¼«´»® ¿´´±½¿¬» ¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)

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

Lab 5-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

Step 3

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

Step 4

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

Step 5

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

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

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

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

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

(where P = pod number) Q10)

The interface name is specified instead of the IP address. Why might this be preferred instead of specifying the 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 ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðÐ ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðÐ ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòÐòð ðòðòðòîëë ¿²§ ´±¹

(where P = pod number) Q11)

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

Step 2

Copyright

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

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-19

Note

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

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

(where P = pod number) Create an ACL that filters eigrp routing updates to the branch office router and network: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ »·¹®° ¸±-¬ ïéîòîêòîêòïðÐ ¿²§ ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ »·¹®° ¿²§ ¿²§ ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ¿²§ ¿²§ ´±¹

Step 4

(where P = pod number) Apply the ACL inbound to the router’s public interface to prevent traffic from entering the branch office network: ¾®Ðø½±²º·¹÷ý ·²¬ »ðñï ¾®Ðø½±²º·¹ó·²¬÷ý ·° ¿½½»--ó¹®±«° ïðï ·²

Step 5

(where P = pod number) Create an ACL that only allows outbound traffic originating from the internal network. Warning

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

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

(where P = pod number) Apply the ACL inbound to the router’s private interface to allow the branch office networks to initiate outbound connections: ¾®Ðø½±²º·¹÷ý ·²¬ »ðñð ¾®Ðø½±²º·¹ó·²¬÷ý ·° ¿½½»--ó¹®±«° ïðî ·² ¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)

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

Lab 5-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

RealAudio ¾®Ðø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ¾®Ðø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ¾®Ðø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ¾®Ðø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ¾®Ðø½±²º·¹÷ý ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ¾®Ðø½±²º·¹÷ý ·²¬ »ðñð ¾®Ðø½±²º·¹ó·º÷ý ·° ·²-°»½¬ ¾®¿²½¸º© ·²

(where P = pod number) Q12)

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

Step 2

Configure an IOS IDS on the inside interface to perform the following: Disable informational signatures Alarm and drop attack signatures Report the attacks to a Syslog server ¾®Ðø½±²º·¹÷ý ²± ·° ¿«¼·¬ ·²º± ¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ²±¬·º§ ´±¹ ¾®Ðø½±²º·¹÷ý ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ¾®Ðø½±²º·¹÷ý ·²¬ »ðñð ¾®Ðø½±²º·¹ó·º÷ý ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)

Task 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

(where P = pod number) Establish a Telnet session to the branch office router from the branch office PC: ½æÄâ ¬»´²»¬ ïðòîòÐòï

(where P = pod number) If you are unable to telnet to your branch office router, console into your branch office router and check the ACLs applied to your VTY lines and inside interface. Step 3

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

Step 4

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

Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-21

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

(where P = pod number) Compare your configuration to the following: ¾®ïý ©®·¬» ¬»®³·²¿´ Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±² æ îëîï ¾§¬»ÿ ª»®-·±² ïîòî -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü°¾ØÚü®ßèϽ´¹ÞÙ«ìÊí½´éð뽦ºð »²¿¾´» °¿--©±®¼ é ïðìÜðððßðêïè ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ïìðìðêïÛðèðïîìíÚ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ÿ ÿ ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° --¸ ¬·³»ó±«¬ ïîð ·° --¸ ¿«¬¸»²¬·½¿¬·±²ó®»¬®·»- í ÿ ½¿´´ ®-ª°ó-§²½ ÿ ÿ ÿ ÿ

Lab 5-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

ÿ ÿ ÿ ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòîòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ²¿¬ ·²-·¼» ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ²¿¬ ±«¬-·¼» ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ²¿¬ ·²-·¼» -±«®½» -¬¿¬·½ ïðòîòïòïï ïéîòîêòîêòïïï ·° ½´¿--´»-²± ·° ¸¬¬° -»®ª»® ·° °·³ ¾·¼·®ó»²¿¾´» ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ Copyright

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-23

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

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

²± ½¼° ®«² ÿ ¼·¿´ó°»»® ½±® ½«-¬±³ ÿ ÿ ÿ ÿ ¾¿²²»® »¨»½ ÂÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ðêðëðêíîìÚìï ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

Lab 5-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Answers Q1)

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

Q2)

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

Q3)

Copyright

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

Would you recommend being more restrictive? Why? A)

Q7)

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

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

Q6)

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

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

Q5)

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

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

Q4)

The default interface names are outside and inside. The security levels are important to define the traffic flows that require access controls to permit or deny traffic.

It depends on the 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.

Why is it important to restrict outbound access to “known” internal network addresses and hosts?

2003, Cisco Systems, Inc.

SAFE Small Network Design Lab 5-25

A)

Q8)

What threat do these ACL entries help mitigate? A)

Q9)

This might be preferred in those network environments where the branch office is dynamically assigned an IP address by the ISP.

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

Q12)

Device logging enables the network security administrator to visibility into what traffic is being allowed or denied. The 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.

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

Q11)

These ACL entries are used to mitigate IP spoofing attacks where the attacker uses internal addresses.

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

Q10)

This prevents internal users from creating their own networks and accessing outside networks without prior approval.

Allowing ICMP traffic is ultimately determined by a 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.

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

Other common protocols that could be added are TFTP, HTTP, and Java. The protocols are covered to some degree by TCP and UDP but provide more specific inspection.

Lab 5-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

6

SAFE SMR Midsize Network Design Overview This chapter includes the following topics: Objectives Midsize network corporate Internet module Midsize network corporate Internet module design guidelines Midsize network campus module Midsize network campus module design guidelines Midsize network WAN module Implementation—ISP router and edge router Implementation—IOS Firewall Implementation—PIX Firewall Implementation—NIDS Implementation—VPN Concentrator

Implementation—Layer 3 switch Summary Lab exercise

6-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Objectives This section lists the chapter’s objectives.

Objectives

Upon completion of this chapter, you will be able to perform the following tasks: • Identify the functions of modules and the key devices in a Midsize network. • Understand specific threats and mitigation roles of Cisco devices. • Recommend alternative devices for network implementation. • Implement specific configurations to apply the mitigation roles.

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—6-2

SAFE SMR Midsize Network Design

6-3

Midsize Network Corporate Internet Module The SAFE: Extending the Security Blueprint to Small, Midsize, and Remote-User Networks (SAFE SMR) midsize network design consists of three modules: the corporate Internet module, the campus module, and the WAN module.

SAFE Design for Midsize Network SP edge

Midsize network or branch edge

Midsize network or branch Campus

PSTN module

Corporate Internet module

Campus module Management server

PSTN

Corporate users

ISP edge module

Internet

Frame or ATM module

Public services

WAN module

Corporate servers

FR/ATM © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-4

As in the small network design, the corporate Internet module has the connection to the Internet, and terminates VPN traffic and public-services traffic (Domain Name System [DNS], HTTP, File Transfer Protocol [FTP], and Simple Mail Transfer Protocol [SMTP]). Dial-in traffic also terminates at the corporate Internet module. The campus module contains the Layer 2 and Layer 3 switching infrastructure along with all the corporate users, management servers, and intranet servers. From a WAN perspective, there are two options for the remote sites connecting into the midsize design. The first is a private WAN connection using the WAN module; the second is an IPSec virtual private network (VPN) into the corporate Internet module. Most of the discussion on this design is based on the midsize network operating as the head-end for a corporation. Specific design changes when used as a branch are also included.

6-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Corporate Internet 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

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

PSTN

Internet

Public services

CSI 1.1—6-5

The goal of the corporate Internet module for a midsize network is to provide internal users with connectivity to Internet services and Internet users access to information on the public servers (DNS, FTP, HTTP, and SMTP). Additionally, this module terminates VPN traffic from remote users and remote sites as well as traffic from traditional dial-in users. The following are key devices used in the corporate Internet module for a midsize network: Dial-in 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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-5

VPN Concentrator—Authenticates individual remote users and terminates their IPSec tunnels Edge router—Provides basic filtering and Layer 3 connectivity to the Internet

6-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats and Mitigation Roles

The following threats can be expected: • Unauthorized access • Application layer attacks • Virus and Trojan horse attacks • Password attacks • DoS

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

CSI 1.1—6-6

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-7

Expected Threats and Mitigation Roles (cont.)

• IP spoofing • Packet sniffers • Network reconnaissance • Trust exploitation • Port redirection

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

CSI 1.1—6-7

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.

6-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-9

Midsize Network Attack Mitigation Roles for Corporate Internet Module—Overview Authenticate users and terminate analog dial

Authenticate users and terminate IPSec

Private VLANs

PSTN

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

Focused Layer 4–7 analysis

Spoof mitigation basic filtering Spoof mitigation, and rate-limiting

SMTP content inspection

Internet

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

Focused Layer 4–7 analysis

HIDS for local attack mitigation

CSI 1.1—6-8

The overall roles and relative location of each device are detailed in the figure. Each device will be discussed in detail in the following sections.

6-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Corporate Internet Module Design Guidelines This section details the functionality of each of the devices within the corporate Internet module.

Design Guidelines ISP Router

PSTN

Spoof mitigation, and rate-limiting

Internet

Public services

The following are the primary functions of the ISP router: • Provides Internet connectivity • Rate-limits non-essential traffic • Provides RFC 1918 and 2827 filtering © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-10

The primary function of the customer-edge router in the ISP (ISP router) is to provide connectivity to the Internet or ISP network. The egress of the ISP router rate limits nonessential traffic that exceeds prespecified thresholds in order to mitigate against distributed denial of service (DdoS) attacks. Finally, at the egress of the ISP router, RFC 1918 and RFC 2827 filtering is configured to mitigate against source-address spoofing of local networks and private address ranges.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-11

Design Guidelines for the Edge Router

PSTN

Spoof mitigation and basic filtering Internet

Public services

• The edge router establishes a demarcation point. • Filtering on the edge router should be configured to allow only expected traffic to expected destinations. • RFC 1918 and 2827 filtering should be enabled on the edge router. • The edge router should be configured to drop most fragmented packets. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-11

The function of the edge router on the midsize network is to provide the demarcation point between the ISP network and the midsize network. At the ingress of the edge router on the midsize network, basic filtering limits access to allow only expected IP traffic. This provides a coarse filter for the most basic attacks. RFC 1918 and RFC 2827 filtering is also provided as a verification of the 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.

6-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines for a Firewall Stateful packet filtering, basic Layer 7 filtering, host DoS mitigation, authenticate remote sites, and terminate IPSec

PSTN

Internet

Public services

The firewall’s primary functions include the following: • Provides connection-state enforcement • Terminates site-to-site IPSec VPNs • Provides DMZs © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-12

The primary function of the PIX Firewall is to provide connection-state enforcement and detailed filtering for sessions initiated through the firewall. The firewall also acts as a termination point for site-to-site IPSec VPN tunnels for both remote site production and remote site management traffic. There are multiple segments off the firewall. The first is the public services segment (Demilitarized Zone), which contains all the publicly addressable hosts. The second is for remote access VPN and dial-in. DNS should be locked down to respond only to desired commands and eliminate any unnecessary responses that might assist hackers in network reconnaissance. This includes preventing zone transfers from anywhere except legitimate secondary DNS servers. The SMTP server includes mail-content inspection services that mitigate virus attacks and Trojan horse attacks generated against the internal network, which are usually introduced through the mail system. The firewall itself filters SMTP messages at Layer 7 to allow only necessary commands to the mail server. Publicly addressable servers have some protection against TCP SYN floods through mechanisms such as the use of half-open connection limits on the firewall. From a filtering standpoint, in addition to limiting traffic on the public services segment to relevant addresses and ports, filtering in the opposite direction also occurs. If an attack compromises one of the public servers (by circumventing the firewall, host-based intrusion detection system [HIDS], and networkbased intrusion detection system [NIDS]), that server should not be able to further attack the network. To mitigate this type of attack, specific filtering prevents any unauthorized requests from being generated by the public servers to any other location. As an example, the web server should be Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-13

filtered so that it cannot originate requests of its own, but merely respond to requests from clients. This setup helps prevent a hacker from downloading additional utilities to the compromised device after the initial attack. It also helps stop unwanted sessions from being triggered by the hacker during the primary attack. An attack that generates an xterm from the web server through the firewall to the 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.

6-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines for Intrusion Detection Focused Layer 4–7 analysis

PSTN

Internet

Focused Layer 4–7 analysis

Public services

The following are the primary NIDS functions: • Detects attacks on ports that the firewall permits • Provides final analysis of attacks • Provides TCP shunning or resets © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-13

The public services segment includes an NIDS appliance. The primary function of an NIDS is to detect attacks on ports that the firewall is configured to permit. These attacks are most often application-layer attacks against specific services. The NIDS on the public services segment should be set in a restrictive stance because signatures matched here have successfully passed through the firewall already. Each of the servers has and HIDS on it as well. The primary function of an HIDS is to monitor against any rogue activity that occurs at the operating-system level as well as in common server applications (FTP, HTTP, SMTP, and so on). The NIDS appliance between the private interface of the firewall and the internal router provides a final analysis of attacks. Very few attacks should be detected on this segment because only responses to initiated requests, a few select ports from the public services segment, and traffic from the remote access segment are allowed to the inside. Only sophisticated attacks should be seen on this segment because they could mean that a system on the public services segment has been compromised and the hacker is attempting to take advantage of this foothold to attack the internal network. For example, if the public SMTP server was compromised, a hacker might try to attack the internal mail server over TCP port 25, which is permitted to allow mail transfer between the two hosts. If attacks are seen on this segment, the responses to those attacks should be more severe than those on other segments because they probably indicate that a compromise has already occurred. The use of TCP resets or shunning to thwart, for example, the SMTP attack mentioned previously, should be seriously considered.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-15

Design Guidelines for the Remote Access VPN

PSTN Authenticate users and terminate IPSec

Internet

Public services

• The VPN Concentrator provides the following: – Secure connectivity – Authenticate users © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-14

The primary function of the remote access VPN Concentrator is to provide secure connectivity to the midsize network for remote users. Following termination of the VPN tunnel, traffic is sent through a firewall to ensure that VPN users are appropriately filtered. This setup also enables IDS shunning to take place on the firewall. This scenario is in contrast to many deployments today that place the firewall in front of the VPN device. When placed in front, no visibility into the specific types of user traffic is possible because the traffic is still encrypted. Via IPSec policy sent from the Concentrator to the client, users are prevented from enabling split tunneling, thereby forcing users to access the Internet via the corporate connection. The IPSec parameters used are Triple Data Encryption Standard (3DES) for encryption and secure hash algorithm (SHA) and hash-based message authentication code (HMAC) for data integrity.

6-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines for Dial-In Access Users Authenticate users and terminate analog dial

PSTN

Internet

Public services

Traditional dial-in users are terminated on an access router with built-in modems. CHAP is used to authenticate the user along with the AAA server. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-15

The traditional dial-in users are terminated on an access router with built-in modems. When the Layer 2 connection is established between the user and the server, three-way Challenge Handshake Authentication Protocol (CHAP) is used to authenticate the user. As in the remote access VPN service, the authentication, authorization, and accounting (AAA) server is used for authentication. When authenticated, the users are provided with IP addresses from an IP pool.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-17

Design Guidelines for the Inside Router

PSTN

Demarcation

Internet

Public services

• The primary function of the inside router is to provide Layer 3 separation and routing between the corporate Internet module and the campus module. • The inside router functions strictly as a router with no ACLs restricting traffic across either interface. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-16

The primary function of the inside router is to provide Layer 3 separation and routing between the corporate Internet module and the campus module. This device functions strictly as a router with no ACLs restricting traffic across either interface. Because routing information itself can be used in a DoS attack, authentication of routing updates between devices may be used to mitigate such an attack. The inside router provides a final point of demarcation between the routed intranet and the outside world. Because most firewalls are configured without routing protocols, it is important to provide a point of routing within the corporate Internet module that does not rely on the rest of the network.

6-18

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Alternatives NIDS and URL filtering

PSTN

Stateful firewall Eliminate

Internet

Public services

Design alternatives include the following: • A stateful firewall on an edge router • An NIDS on the outside firewall • Eliminate the inside router • A URL-filtering server © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-17

This SAFE SMR corporate Internet module has several alternative designs: Rather than implementing basic filtering on the edge router to the midsize network, a network administrator may choose to implement a stateful firewall on this device as well. Having two stateful firewalls provides more of a defense-in-depth approach to security within the module. Depending on the network 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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-19

The addition of content inspection beyond the mail-content inspection already specified could also be used. For example, a URL-filtering server could be placed on the public services segment to filter the types of web pages that employees can access.

6-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Campus Module This section covers the midsize network campus module.

Midsize Network Campus Module Key Devices The following are key devices: • Layer 3 switch • Layer 2 switch • Corporate servers To the – SMTP or POP3 corporate Internet module – File and print • User workstations • NIDS appliance • Management hosts – SNMP – Syslog – TACACS+ or RADIUS – NIDS host

Management server Corporate users

Corporate servers

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

CSI 1.1—6-19

The midsize network campus module contains end-user workstations, corporate intranet servers, management servers, and the associated Layer 2 and Layer 3 infrastructure required to support the devices. All the campus modules from SAFE Enterprise have been combined into a single module. This setup more accurately reflects the smaller size of midsize networks, and reduces the overall cost of the design. As in the corporate Internet module, the redundancy that would normally be found in an enterprise design has been removed from the midsize network design. The following are the midsize network campus module key devices: Layer 3 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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-21

NIDS appliance—Provides Layer 4-to-Layer 7 monitoring of key network segments in the module Management hosts—Hosts designated for device management

6-22

—

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

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Expected Threats and Mitigation Roles The following threats are expected to the SAFE SMR Midsize Network Campus Module: • Packet 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

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

CSI 1.1—6-20

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-23

Expected Threats and Mitigation Roles (cont.)

• 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

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

CSI 1.1—6-21

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

6-24

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Midsize Network Attack Mitigation Roles for the Campus Module Management server To the corporate Internet module

Focused Layer 4–7 analysis

HIDS for local attack mitigation

Host virus scanning

Corporate users

Corporate servers

Layer 3 and 4 filtering of management traffic, private VLANs, and RFC filtering

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

CSI 1.1—6-22

The campus module performs the following actions: The NIDS performs focused Layer 4 through 7 analysis. The Layer 3 switch provides Layer 3 and 4 filtering of management traffic, private VLANs, and RFC 2827 filtering. Hosts provide virus scanning. The HIDS provides local attack mitigation.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-25

Midsize Network Campus Module Design Guidelines This section details the functionality of each of the devices within the campus module.

Design Guidelines for the Core Switch Management server To the corporate Internet module

Corporate users

Layer 3 and 4 filtering of management traffic, private VLANs, and RFC 2827 filtering

Corporate servers

The following are the primary functions of the core switch: • • • •

Provides routing and switching for internal traffic Provides separate VLANs and private VLANs Implements internal access control RFC 2827 filtering

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

CSI 1.1—6-24

The primary function of the core switch is to provide routing and switching for production and management traffic, distribution layer services (routing, quality of service [QoS], and access control) for the distribution and access switches, connectivity for the corporate and management servers, and advanced services such as traffic filtering between the subnets. In the figure, a Layer 3 switch is used instead of a Layer 2 switch in order to provide separate VLANs for the following: Corporate server segment Management server segment Corporate user segment Connectivity to the WAN module and to the corporate Internet module The Layer 3 switch provides a line of defense and prevention against internally originated attacks. It can mitigate the chance of a department accessing confidential information on another 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 6-26

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VLAN and filter access to it, ensuring that only R and D staffs have access to it. For performance reasons, it is important that this access control be implemented on a hardware platform that can deliver filtered traffic at near wire rates. This setup generally dictates the use of Layer 3 switching, as opposed to more traditional dedicated routing devices. This same access control can also prevent local source-address spoofing through the use of RFC 2827 filtering. RFC 2827 filtering should be implemented on the corporate user and corporate intranet server VLANs. Within each of the VLANs, private VLANs can be used to mitigate trust-exploitation attacks between the devices. For instance, within the corporate server segment, the individual servers may not have any requirement to communicate with each other. They need to communicate only with devices connected to the corporate user segment. To provide a further line of defense for the management servers, extensive Layer 3 and Layer 4 filtering is configured outbound on the VLAN interface connecting to the management server segment. The ACL limits connectivity to and from the management servers only to those devices (via IP addresses) under their control, and only for those protocols and services (via port number) that are required. This also includes access control for management traffic destined for the remote site devices. This traffic is encrypted by the firewall and sent to the remote sites. Allowing only established connections back through the ACL further controls access to the managed devices.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-27

Design Guidelines for Intrusion Detection Management server To the corporate Internet module

Corporate users

Focused Layer 4–7 analysis

Corporate servers

Intrusion detection should monitor internal traffic for suspicious activity. Very few attacks should be detected.

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

CSI 1.1—6-25

The campus module also includes an NIDS appliance. The switch port that connects to the NIDS appliance is configured such that traffic from all VLANs that require monitoring is mirrored to the monitoring port of the appliance. Very few attacks should be detected here because this NIDS appliance provides analysis against attacks that may originate from within the campus module itself. For instance, if a user workstation was compromised because of an unknown modem connection to that host, the NIDS could detect suspicious activity originating from within the campus. Other internal attacks could originate from disgruntled employees, workstations left where unauthorized people can gain access to them, or Trojan horse applications inadvertently loaded on portable PCs. Each of the corporate intranet and management servers also has an HIDS installed.

6-28

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Alternatives The following design alternatives are available:

Integrated IDS module in the core switch

• If the network is To the small enough, corporate incorporate Layer 2 Internet module switch functionality into the core switch. • Separate the router and Layer 2 switch instead of the core switch. • Replace the NIDS appliance with the IDS module in the core switch.

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

Integrate switch functionality

Management server Corporate users

Corporate servers Separate router and Layer 2 switch

CSI 1.1—6-26

If the midsize network is small enough, the functionality of the distribution and access switches can be rolled into the core switch, and the distribution and access switches can be eliminated. In this case, the end-user workstations would be connected directly to the core switch. Private VLAN functionality would be implemented on the core switch in order to mitigate trustexploitation attacks. If the performance requirements of the internal network are not high, a separate router and Layer 2 switch could be used for the core and distribution instead of the higher-performing Layer 3 switch. If desired, the separate NIDS appliance can be replaced with an integrated IDS that fits into the core switch. This setup provides higher traffic throughput into the IDS because it sits on the backplane of the switch, rather than being connected via a single 10/100-Mbps Ethernet port. ACLs on the switch can be used to control what traffic is sent to the IDS.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-29

Midsize Network WAN Module This section explains the Midsize Network WAN Module. The WAN module is included only when connections to remote locations over a private network are required. This requirement may occur when stringent QoS requirements cannot be met by an IPSec VPN, or when legacy WAN connections are in place without a compelling cost justification to migrate to IPSec.

Midsize Network WAN Module Key Devices and Expected Threats

FR/ATM

To the campus module

• Note the following about the WAN module: – The WAN module is included only when connections to remote locations over a private network are required – The only key device is the IOS Router • The following are expected threats: – IP spoofing – Unauthorized access

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

CSI 1.1—6-28

The IOS router is a key device for the midsize network WAN. It provides routing, access control, and QoS mechanisms to remote locations. The following are mitigated threats for the midsize network WAN: IP 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.

6-30

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Design Guidelines and Alternatives Cisco IOS Router with a firewall

To the campus module

FR/ATM

IPSec tunnel VPN tunnel

• Use IPSec for additional privacy • Run a firewall on the WAN router © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-29

The amount of security placed in the WAN module depends on the level of trust for the remote sites and the ISP to which you are connecting. Security is provided by using IOS security features. In this design, inbound ACLs applied to the serial interface are used to block all unwanted traffic from accessing the midsize network. Inbound ACLs applied to the Ethernet interface can be used to further limit what traffic passes from the midsize network back to the remote sites. Alternatives involve organizations that are very concerned about information privacy and encrypt traffic across their classic WAN links. Similar to site-to-site VPNs, IPSec can be used to achieve this level of information privacy. Additionally, running a firewall on the WAN router can provide additional access control options when compared with the basic ACLs used in the SAFE design.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-31

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 PSTN Spoof mitigation and (D)DoS rate-limiting

Internet

Public services

The following are necessary commands for the ISP router: • Spoof mitigation and RFC filtering – access-list – access-group • (D)DoS rate-limiting © 2003, Cisco Systems, Inc. All rights reserved.

– rate-limit

CSI 1.1—6-31

Starting at the customer edge router in the ISP, the egress of the ISP rate limits nonessential traffic that exceeds pre-specified thresholds in order to mitigate DDoS attacks. Also at the egress of the ISP router, RFC 1918 and RFC 2827 filtering mitigate source-address spoofing of local networks and private address ranges. At the ingress of the firewall, RFC 1918 and RFC 2827 filtering are first provided as a verification of the 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.

6-32

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco Edge Router— Implementation Commands Midsize network or branch edge corporate Internet module

The following are necessary commands for the Cisco edge router:

PSTN

• access-list • access-group Internet

Public services

Spoof mitigation and basic filtering

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

CSI 1.1—6-32

The function of the edge router on the midsize network is to provide the demarcation point between the ISP network and the midsize network. At the ingress of the edge router on the midsize network, basic filtering limits access to allow only expected IP traffic, providing a coarse filter for the most basic attacks. RFC 1918 and RFC 2827 filtering are also provided here as a verification of the 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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-33

Implementation Commands—Spoof Mitigation and RFC Filtering router(config)#

¿½½»--ó´·-¬ ¿½½»--ó´·-¬ó²«³¾»® ż§²¿³·½ ¼§²¿³·½ó²¿³» Ŭ·³»±«¬ ³·²«¬»-Ãà ¥¼»²§ ¤ °»®³·¬£ °®±¬±½±´ -±«®½» -±«®½»ó©·´¼½¿®¼ ¼»-¬·²¿¬·±² ¼»-¬·²¿¬·±²ó©·´¼½¿®¼ Å°®»½»¼»²½» °®»½»¼»²½»Ã Ŭ±- ¬±-à Ŵ±¹ ¤ ´±¹ó·²°«¬Ã Ŭ·³»ó®¿²¹» ¬·³»ó®¿²¹»ó²¿³»Ã • The access-list command enables you to specify if an IP address is permitted or denied access to a port or protocol.

®±«¬»®ø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹ router(config-if)#

·° ¿½½»--ó¹®±«° ¥¿½½»--ó´·-¬ó²«³¾»® ¤ ¿½½»--ó´·-¬ó ²¿³»£¥·² ¤ ±«¬£ • The access-group command binds an ACL to an interface.

®±«¬»®ø½±²º·¹ó·º÷ý ·° ¿½½»--ó¹®±«° ïðï ·² © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-33

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

6-34

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the access-list command is as follows: access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range time-rangename] access-list-number

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

dynamic dynamic-name

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

timeout minutes

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

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an Internet protocol. It can be one of the keywords eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim, tcp, or udp, or an integer in the range from 0 to 255 representing an IP number. To match any IP (including ICMP, TCP, and UDP) use the ip keyword.

source

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

source-wildcard

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-35

destination

Number of the network or host to which the packet is being sent. There are three alternative ways to specify the destination: Use a 32-bit quantity in four-part, dotted-decimal format. Use the any keyword as an abbreviation for the destination and destination-wildcard of 0.0.0.0 255.255.255.255. Use a host destination as an abbreviation for a destination and destination-wildcard of destination 0.0.0.0.

destination-wildcard

Wildcard bits to be applied to the destination. There are three alternative ways to specify the destination wildcard: Use a 32-bit quantity in four-part, dotted-decimal format. Place 1s in the bit positions you want to ignore. Use the any keyword as an abbreviation for a destination and destination-wildcard of 0.0.0.0 255.255.255.255. Use host destination as an abbreviation for a destination and destination-wildcard of destination 0.0.0.0.

precedence precedence

(Optional.) Packets can be filtered by precedence level, as specified by a number from 0 to 7, or by name.

tos tos

(Optional.) Packets can be filtered by type of service level, as specified by a number from 0 to 15, or by name.

log

(Optional.) Causes an informational logging message about the packet that matches the entry to be sent to the console. (The level of messages logged to the console is controlled by the logging console command.) The message includes the ACL number, whether the packet was permitted or denied; the protocol, whether it was TCP, UDP, ICMP, or a number; and, if appropriate, the source and destination addresses and source and destination port numbers. The message is generated for the first packet that matches, and then at five-minute intervals, including the number of packets permitted or denied in the prior five-minute interval. The logging facility might drop some logging message packets if there are too many to be handled or if there is more than one logging message to be handled in one second. This behavior prevents the router from crashing due to too many logging packets. Therefore, the logging facility should not be used as a billing tool or an accurate source of the number of matches to an ACL.

log-input

(Optional.) Includes the input interface and source MAC address or VC in the logging output.

time-range time-range-name

(Optional.) Name of the time range that applies to this statement. The name of the time range and its restrictions are specified by the time-range command.

The syntax for the access-group command is as follows: ip access-group {access-list-number | access-list-name}{in | out}

6-36

access-list-number

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

access-list-name

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

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

The IOS Firewall

PSTN

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

Internet

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

Public services

CSI 1.1—6-35

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

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-37

Private VLANs prevent a compromised public server from attacking other servers on the same segment. This traffic is not even detected by the firewall, a fact that explains why private VLANs are critical.

6-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IOS 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 – access-list – access-group • Host DoS mitigation – ip inspect • Authenticate remote site, users, and logging – aaa new-model – tacacs-server – aaa authentication login – aaa authorization exec – aaa accounting exec – login authentication © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-36

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 —

ip inspect—Defines the application protocols to inspect.

Authenticate remote site (and logging)

Copyright

—

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.

—

tacacs-server—Defines the TACACS server.

—

aaa authentication login—Enables AAA authentication at login.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-39

6-40

—

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 SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

CSI 1.1—6-37

IPSec commands—Provide for IPSec tunnel termination

Copyright

—

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 AAA server group to use for preauthentication.

—

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.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-41

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 PSTN – icmp – attack guard commands (except for frag guard, these are on by default) – static • Spoof mitigation and RFC filtering Internet – access-list – access-group

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

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

Public services

CSI 1.1—6-39

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 Host DoS mitigation and basic layer 7 filtering —

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

Spoof mitigation and RFC filtering

6-42

—

access-list—Creates an ACL

—

access-group—Binds the ACL to an interface

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

PIX Firewall—Implementation Commands Summary (cont.) • Authenticate the remote site (and PSTN logging) – aaa-server – aaa authentication – logging on • Terminate IPSec – sysopt connection permit-ipsec – isakmp enable Internet – isakmp key – isakmp policy – crypto ipsec transform-set Stateful packet filtering, basic Layer 7 filtering, host DoS – crypto map

Public services

mitigation, authenticate remote sites, and terminate IPSec

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

CSI 1.1—6-40

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

Copyright

—

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

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-43

Implementation—NIDS This section explains the Cisco Intrusion Detection System (IDS) Sensor setup configuration tasks. The configuration tasks are presented using the IDS Device Manager (IDM).

NIDS Implementation— IDM Sensor Setup Tasks The following are the tasks to setup the Sensor: • Configure the 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. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-42

A Cisco IDS Sensor is initialized using the sysconfig-sensor Sensor command. Once the Sensor has been initialized, configuration of the Sensor is done via a platform such as IDM or IDS Management Center (MC). You can change the parameters configured during Sensor initialization by completing the following Sensor setup tasks: Configure the 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.

6-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-45

Network Settings Choose Device>Sensor Setup>Network.

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

CSI 1.1—6-43

Complete the following steps to configure the Sensor’s network parameters: Step 1

Launch your web browser and specify the Sensor as the location: ¸¬¬°-æññ-»²-±®Á·°Á¿¼¼®»--

6-46

Step 2

Log in to the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Device from the area bar. The Device sub-area bar is displayed.

Step 4

Select Sensor Setup from the sub-area bar. The Sensor Setup table of contents (TOC) is displayed.

Step 5

Select Network from the TOC. The 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

Alphanumeric identifier for the IEV host.

Host ID

1–65535

Numeric identifier for the IEV host.

Organization 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

The IP address of the IEV host.

PostOffice Port

1025–65535

The UDP port number used for IDS communication.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 7

Choose the alarm severity level from the Route Up Alarm Level drop-down menu.

Step 8

Choose the alarm severity level from the Route Down Alarm Level drop-down menu.

Step 9

Enter the values listed in the following table for the Cisco IDS settings: Cisco IDS Settings

Parameter Values

Description

Heartbeat interval multiplier

The number of times the heartbeat packet is sent to a Cisco IDS host before the route is declared down.

IP address

The IP address of the Sensor (for example, 10.10.10.3).

Netmask

The subnet mask for the Sensor (for example, 255.255.255.0).

Default route

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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-47

Network Access Control Choose Device>Sensor Setup>Allowed Hosts.

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

CSI 1.1—6-44

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 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Allowed Hosts from the TOC. The list of allowed networks and hosts is displayed in the work content area.

Step 4

Select Add from the work content area. The Adding information is displayed in the work content area.

Step 5

Enter the network address in the Network address field. Note

Step 6

6-48

Include the trailing period when entering network addresses (for example, to enter the network 10.0.1.0/24, enter 10.0.1. in the network address field).

Click OK to save the Sensor’s allowed hosts settings.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Access Services Choose Device>Sensor Setup>Remote Access.

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

CSI 1.1—6-45

The Remote access configuration option enables the network security administrator to disable insecure communication protocols such as Telnet and FTP.

Note

SSH is enabled by default and cannot be disabled.

Complete the following steps to enable or disable Telnet or FTP access to the Sensor: Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Remote Access from the TOC. The 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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-49

Time Choose Device>Sensor Setup>Time.

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

CSI 1.1—6-46

The Time configuration option enables the network security administrator to modify the date, time, and time zone for the Sensor appliance. Complete the following steps to set the date and time:

6-50

Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Time from the TOC. The 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.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Account Password Choose Device>Sensor Setup>Password.

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

CSI 1.1—6-47

The Password configuration option enables the user to change the password for the account used to log into IDM. Complete the following steps to change the account’s password: Step 1

Select Device from the area bar. The Device sub-area bar is displayed.

Step 2

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 3

Select Password from the TOC. The user name whose password is to be changed is displayed in the work content area.

Step 4

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-51

Applying Sensor Configuration Choose Apply Changes and Select Finish.

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

CSI 1.1—6-48

The Sensor configuration settings are saved by the Director and must be transferred to the Sensor. Complete the following steps to apply the configuration settings to the Sensor:

6-52

Step 1

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 2

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation— Event Logging

• The Sensor by default logs all events locally: – Logs events by severity – Logs events by type • The Sensor can transfer archived copies of log files offline to an FTP server: – Network access to the FTP server – FTP username and password – Directory with write permissions © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-49

The Cisco IDS logging service, loggerd, is enabled by default, and the Sensor is configured to log events of all types locally. The events logged may be based on severity and type. The Sensor is capable of transferring archived copies of log files offline to an FTP server. The following are the requirements for the network log file transfer feature: Network access to an FTP server FTP username and password Directory where the FTP user has write privileges

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-53

NIDS Implementation— Event Logging (cont.)

• The IP logging feature captures packets from an attacking host: – Logs packets automatically when IP Log is a signature response – Logs packets if the source address is entered manually • Requires that event logging is enabled • The IP log file is in tcpdump format

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

CSI 1.1—6-50

The Sensor IP logging feature captures IP packets from an attacking host. The Sensor may be configured to capture packets automatically when the signature action is IP Log. The Sensor may be configured to capture packets if the network security administrator specifies the source address. The IP logging feature requires that the 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.

6-54

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Event Logging Choose Configuration>Logging>Event Logging.

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

CSI 1.1—6-51

Complete the following steps to configure event logging: Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Logging from the sub-area bar. The Logging TOC is displayed.

Step 3

Select Event Logging from the Logging TOC options. The Event logging settings are displayed in the work content area.

Step 4

Select or de-select the Enable check box to disable or enable the 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

Copyright

Click OK to save the event logging settings.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-55

Log File Transfers Choose Configuration>Logging>Exporting Event Logs.

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

CSI 1.1—6-52

Complete the following steps to configure the Sensor to transfer the log files offline to an FTP server: Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Logging from the sub-area bar. The Logging TOC is displayed.

Step 3

Select Exporting Event Logs from the Logging TOC options. The Exporting Event Logs settings are displayed in the work content area.

Step 4

Select or de-select the Export Archived Event Log files to enable or disable the exporting feature.

Step 5

Enter the following parameters in their respective fields: Cisco IDS Settings

Parameters

Description

Target FTP Server IP Address

The IP address of the FTP server.

Target FTP Directory

Directory where the log files will be transferred.

Username

The username to use for the FTP connection.

Password

The password to use for the FTP connection.

Note Step 6

6-56

The user must have write access to the target FTP directory on the FTP server.

Click OK to save the Exporting Event Logs settings.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation— Sensing Overview

• The Sensor has parameters that affect the sensing function and that are not necessarily specific to a particular signature or set of signatures. • The following are the global sensing parameters: – Internal network – Sensing properties – Level of traffic logging

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

CSI 1.1—6-53

The Sensor has configuration parameters that affect the sensing function. These parameters are not necessarily specific to a particular signature or set of signatures. The following are the global sensing parameters: Internal network Sensing properties Level of traffic logging

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-57

Internal Networks Choose Configuration>Sensing Engine>Internal Networks.

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

CSI 1.1—6-54

The internal network configuration parameter defines the list of networks that are considered as protected by the Sensor. This information is used to define inside (IN) and outside (OUT) network for alarm events. Inside networks are those defined as internal networks. All other networks are identified as outside networks. The internal network definition is used for two purposes: Alarm 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 1

Launch your web browser and specify the Sensor as the location: ¸¬¬°-æññ-»²-±®Á·°Á¿¼¼®»--

6-58

Step 2

Log into the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 5

Select Internal Networks from the TOC. The list of internal network addresses is displayed in the work content area.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 6

Click Add in the work content area. The network address field is displayed.

Step 7

Enter the network address in the Network Address field. Note

Internal networks may be represented by a single IP address, 10.1.1.1; a range of IP addresses, 10.1.1.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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-59

Sensing Properties Choose Configuration>Sensing Engine>Sensing Properties.

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

CSI 1.1—6-55

Complete the following steps to configure the Sensor’s sensing properties: Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select Sensing Properties from the TOC. The 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 Sensing Interface

Parameter Value Custom–Enables the network security administrator to enter a user-defined interface name.

Description This is the Sensor’s monitoring interface device name. Automatic is the default value.

Automatic–Enables the Sensor to detect the correct monitoring interface’s device name. Traffic Flow Severity

High Medium Low

The alarm severity level assigned to the Traffic Flow signatures. The default security level is High.

Informational Traffic Flow Timeout

6-60

Cisco SAFE Implementation 1.1

0–65000

The number of seconds required to trigger the Traffic Flow signature.

Copyright

2003, Cisco Systems, Inc.

Cisco IDS Setting Link Status Alarm Level

Parameter Value High Medium Low

Description The alarm severity level assigned to the Link status signature. The default security level is Low.

Informational Storage Timeout Seconds

Step 5

Copyright

10–600

The number of seconds to wait before deleting stored history after the host goes silent.

Click OK to save the Sensor’s sensing properties.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-61

Level of Traffic Logging Choose Configuration>Sensing Engine>Signature Configuration> Level of Traffic Logging.

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

CSI 1.1—6-56

The Level of Traffic Logging configuration option is used for TCP and UDP connection signatures. This defines the types of TCP connection packets and UDP traffic that is logged: Complete the following steps to configure the Sensor’s level of traffic logging: Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select Level Of Traffic Logging from the TOC. The current Level of Traffic logging value is displayed in the work content area.

Step 4

Choose the traffic logging level from the Level Of Traffic Logging drop-down menu. The following are the level options: None TCP connection requests & UDP traffic (which is the default) TCP connection requests, SYN-ACK, FIN, RST & UDP traffic TCP SYN-ACK packets from the specified port & UDP traffic

Step 5

6-62

Click OK to save the traffic logging level.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

NIDS Implementation— Signature Overview • The sensing engines and signatures are the core technologies of the Cisco IDSs. • The signatures are researched and developed by Cisco security engineers. • The sensing engines use the signature information to determine if the network traffic is considered malicious activity. • The sensing engines are designed to perform pattern matching, stateful pattern matching, protocol decodes, and heuristic methods. © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-57

The sensing engines and signatures are the core technology of the Cisco IDS. The Cisco Countermeasure Response Team (CRT) researches new vulnerabilities and develops signatures that detect the new threats. The signatures are used by the sensing engine to perform the actual intrusion detection analysis. The sensing engines are designed to perform a blend of the intrusion detection analysis techniques, which include the following: Pattern matching Stateful pattern matching Protocol analysis (decoding) Heuristic methods

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-63

NIDS Implementation— Signature Overview (cont.) • The Director enables the network security administrator to view the signatures, which are categorized by the following: – Signature groups – TCP connection signatures – UDP connection signatures – String signatures – ACL violation signatures • Basic signature configuration includes the following: – Enabling or disabling the signature – Assigning the severity level – Assigning the signature action © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—6-58

The Director enables the network administrator to view the IDS signature, which are categorized by the following: Signature groups Custom signatures TCP connection signatures UDP connection signatures String signatures ACL violation signatures Each signature has the following basic configurable parameters: Enable 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

6-64

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Signature Groups Choose Configuration>Sensing Engine>Signature Configuration>Signature Group.

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

CSI 1.1—6-59

The Cisco CRT has grouped the signatures according to either an application or protocol. The signature groupings are listed in the following table: All Signatures Authorization Failure Signatures BackOrifice Signatures Custom Signatures Cisco IOS Signatures DNS Signatures Distributed DOS Signatures FTP Signatures Fingers Signatures ICMP Signatures IDENT Signatures IMAP Signatures Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-65

INN Signatures IP Fragmentation Signatures IP Header Signatures LPR Signatures Loki Signatures POP Signatures PostOffice Comm Status Signatures RPC-based Application Signatures Rlogin Signatures SATAN Signatures SMTP/Sendmail Signatures SNMP Signatures SQL Signatures SSH Signatures Security Violation Signatures String Match Signatures TCP Header Signatures TCP Hijack Signatures Telnet Signatures UDP Application Signatures UDP Header Signatures WWW Signatures Windows/NetBIOS Signatures 6-66

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Note

Copyright

The signature groups may change in subsequent releases.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-67

Custom Signatures Choose Configuration>Sensing Engine>Signature Configuration>Custom Signatures.

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

CSI 1.1—6-60

The custom signatures are those signatures that the network security administrator has tuned or created. These signatures are associated with a signature micro-engine. The following are the signature micro-engines available: Atomic.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.

6-68

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-69

String Signatures Choose Configuration>Sensing Engine>Signature Configuration>String Signatures.

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

CSI 1.1—6-61

String pattern matching signatures are based on searching to content (data) of a particular TCP session. The string pattern is in regular expression similar to regular expression used in programming languages such as Perl or Python.

Note

It is recommended that you add new string-matching signatures by using the STRING signature micro-engines.

Complete the following steps to add a string signature:

6-70

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Sensor Engine from the sub-area bar. The Sensor Engine TOC is displayed.

Step 3

Select String Signatures from the TOC. A list of string signatures is displayed in the work content area.

Step 4

Click Add. The Adding fields are displayed in the work content area.

Step 5

Enter the TCP port number in the Port field.

Step 6

Choose the direction from the Direction drop-down menu.

Step 7

Enter the number of occurrences the string must occur to trigger the signature in the Occurrences field.

Step 8

Enter the string pattern in the Regular Expression field.

Step 9

Enter user comments to associate with the signature.

Step 10

Choose the signature severity level from the Severity drop-down menu.

Step 11

Select the signature action by selecting the Block, IP Log, or Reset check boxes.

Step 12

Click OK to save the string signature. The signature is displayed in the list of string signatures.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 13

Copyright

Click the Edit icon next to the signature’s Enabled circle to tune the signature.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-71

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.

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

CSI 1.1—6-62

The IDS Event Viewer (IEV) software is included with the Sensor software. You must complete the following tasks to begin using IEV to monitor events from an IDS device:

6-72

Step 1

Add the IEV host as a remote event 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.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Sensor Remote Host Choose Configuration>Communication>Remote Hosts and Select Add.

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

CSI 1.1—6-63

Complete the following steps to add the IEV host as a remote event destination: Step 1

Launch your web browser and specify the Sensor as the location: ¸¬¬°-æññ-»²-±®Á·°Á¿¼¼®»--

Step 2

Log into the IDM as the netrangr user. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Communications from the sub-area bar. The Communications TOC is displayed.

Step 5

Select Remote Hosts from the TOC. The remote host options are displayed in the work content area.

Step 6

Click Add. The Adding window opens in the work content area.

Step 7

Enter the values listed in the following table and accept the default values for the other parameters.

Copyright

Cisco IDS Settings

Parameters

Description

Host Name

Alphanumeric identifier for the IEV host.

Host ID

1–65535

Numeric identifier for the IEV host.

Organization 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

The IP address of the IEV host.

PostOffice Port

1025–65535

The UDP port number used for IDS communication.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-73

Step 8

6-74

Cisco IDS Settings

Parameters

Description

Heartbeat

1–65535

Time interval that the Cisco IDS Communication Infrastructure uses when transmitting route verification messages.

Click OK to accept the host values. The IEV host is displayed in the list of remote hosts.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Sensor Remote Event Destination Choose Configuration>Communication>Remote Hosts>Event Destinations and Select Add.

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

CSI 1.1—6-64

Complete the following steps to add the event destination: Step 1

Select Event Destinations from the Remote Hosts TOC options. The list of event destinations is displayed in the work content area.

Step 2

Accept the default event destination identification number.

Step 3

Click Add. The Add Destination window opens.

Step 4

Choose the IEV host from the host drop-down menu.

Step 5

Choose the alarm severity from the Level drop-down menu to send medium events to the IEV host.

Step 6

Choose the Cisco IDS service from the Service drop-down menu.

Step 7

Select the types of events to send to the IEV host.

Step 8

Click OK to accept the event destination values. The IEV host is displayed in the list of event destinations.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-75

Applying Sensor Configuration Choose Apply Changes and Select Finish.

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

CSI 1.1—6-65

Complete the following steps to apply the Sensor configuration:

6-76

Step 1

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 2

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed. The Sensor is configured to capture traffic and ready to send events to the IEV.

Step 3

Select Logout from the IDM toolbar.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Download Choose Monitoring>IDS Event Viewer.

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

CSI 1.1—6-66

Complete the following steps to download the IEV software from the Sensor: Step 1

Launch your web browser and specify the Sensor as the location by entering the following: ¸¬¬°-æññ-»²-±®Á·°Á¿¼¼®»--

Step 2

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 3

Select Monitoring from the area bar. The Monitoring sub-area bar is displayed.

Step 4

Select IDS Event Viewer from the sub-area bar. The IDS Event Viewer data is displayed in the Content Area. Notice that Monitoring>IDS Event Viewer is displayed in the path bar.

Step 5

Select Download the Windows NT/2000 IDS Event Viewer from the Downloads section.

Step 6

Save the IEV installation application (iev-win.exe) to your hard disk. Note the destination location. This information is needed in the next task. Notice the IEV readme file is available for download. It is recommended to download this file and review the information prior to installing the IEV.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-77

IEV Installation

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

CSI 1.1—6-67

The IEV installation application is a wizard-based installation program. Complete the following steps to install the IEV application:

6-78

Step 1

Launch the IEV installation application from the location where it was saved. The Cisco IDS Event Viewer Welcome window opens.

Step 2

Click Next to continue the installation wizard process. The Select Destination Location window opens.

Step 3

Specify the destination folder if the default location is not acceptable.

Step 4

Click Next to continue with the wizard installation process. The Select Program Manager window opens.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Installation (cont.)

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

CSI 1.1—6-68

Step 5

Enter the Program Manager group if the default location is not acceptable.

Step 6

Click Next to continue with the installation wizard process. The Start installation window opens.

Step 7

Click Back if any mistakes were made.

Step 8

Click Next to continue with the installation wizard process. The Installing window displays the IEV installation progress.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-79

IEV Installation (cont.)

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

Step 9

The IEV application files are copied to the destination location. The IEV file copy process takes approximately 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: Cisco IDS Settings

Parameters

Description

Port Number

1025–65535

The UDP port number used for IDS communication.

Organization Name

Alphanumeric identifier for a group of Cisco IDS components (for example, securitynoc).

Organization ID

1–65535

Numeric identifier for a collection of Cisco IDS components.

Host Name

Alphanumeric identifier for the Cisco Director (for example, director1).

Host ID

1–65535

Numeric identifier for the Cisco IDS Director.

Note

6-80

CSI 1.1—6-69

This step does not add an IDS device to monitor. Adding a device to the IEV is described in the next step.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IEV Installation (cont.)

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

CSI 1.1—6-70

Step 11

Click Finish to complete the IEV installation wizard process. The Install dialog window opens.

Step 12

Click OK to restart the system and complete the installation process. Review the log.txt file under Cisco IDS Event Viewer\IEV\bin directory. It should only contain this message: “Cisco IDS Event Viewer service successfully started”.

Note

Do not remove the c:\my.cnf file. The MySQL server used by the IEV requires this file.

The IEV application requires supporting Cisco IDS services and applications. These services and applications are initialized after the system is rebooted. The Cisco IDS services and applications are as follows: CSIDS Data Feed 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

Copyright

The Cisco IDS Event Viewer service depends on the CSIDS Data Feed and MySQL services. If you want to stop receiving alarms, you can stop the CSIDS Data Feed service, which will stop the Cisco IDS Event Viewer service. Later you can restart the Cisco IDS Event Viewer service, which will cause the CSIDS Data Feed service to resume receiving and storing alarms.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-81

Add IDS Devices Choose File>New>Devices.

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

CSI 1.1—6-71

The IEV installation process does not prompt you to add an IDS device to monitor. Complete the following steps to add an IDS device to the IEV:

6-82

Step 1

Choose Start>Programs>Cisco Systems>Cisco IDS Event Viewer>Cisco IDS Event Viewer to launch the IEV. The Cisco IDS Event Viewer application opens.

Step 2

Choose File>New Devices from the main menu. The Device Properties window opens.

Step 3

Enter the new Sensor information in the fields and click OK to save the information. The IDS device appears in the Devices folder. The following table contains the Sensor communication parameters and a description of each: CIDS Settings

Parameters

Description

IP Address

The IP address of the Sensor.

Organization Name

Alphanumeric identifier for a group of Cisco IDS components (for example, securitynoc).

Organization ID

1–65535

Numeric identifier for a collection of Cisco IDS components.

Host Name

Alphanumeric identifier for the Sensor (for example, sensor1).

Host ID

1–65535

Numeric identifier for the Sensor.

PostOffice Port

1025–65535

The UDP port number used for IDS communication.

Heartbeat

1–65535

Time interval that the Cisco IDS communication infrastructure uses when transmitting route verification messages.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

PSTN

Authenticate users and terminate IPSec

– Identity – General – IPSec

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

Internet

Public services

CSI 1.1—6-73

Implementation on the Concentrator includes but is not limited to setting up the following: The IKE proposals that are used Group configuration

Copyright

—

Identity

—

General

—

IPSec

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-83

Activate IKE Proposal

3002/Unity Client 2.5 Client Certicom Client

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

CSI 1.1—6-74

The Concentrator can handle three types of remote clients: Cisco client, Altiga client, and Certicom client. Before the Concentrator can interface with these clients, you must make sure that the appropriate IKE proposal is configured, activated, and prioritized.In remote access connections, the client sends IKE proposals to the Concentrator. The Concentrator functions only as a responder. As the responder, the Concentrator checks the active IKE proposal list, in priority order, to see if it can find a proposal that matches with parameters in the 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.

6-84

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Within the User Management>Groups>Modify training window, you can view or modify individual group parameters. There are four tabs located under User Management>Groups: Identity 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:

Copyright

—

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.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-85

Error! Not a valid link.

The General tab can be broken down into three sections: The top section defines access rights and privileges. The center section is used for WINS and DNS information used by the client. The bottom section defines which tunneling protocols this group supports. Within the General tab, you can configure the following parameters: Access Hours drop-down 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.

6-86

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-87

Error! Not a valid link.

The IPSec tab enables you to configure IPSec parameters that apply to this group. The window can be divided into two sections: IPSec and remote access parameters. IPSec parameters can be set as follows: IPSec SA drop-down 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 check box, the Concentrator prompts the user for an identification and password whenever a re-key occurs. The default is disabled. Tunnel Type drop-down menu—Click the drop-down menu and choose the remote access tunnel type. Choose Remote access for IPSec client to LAN applications.

6-88

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation—Layer 3 Switch This section describes the implementation of the Layer 3 switch in the SAFE SMR medium network campus module.

Error! Not a valid link.

The following commands and features are used to implement SAFE SMR on a Layer 3 switch: Layer 3 and 4 filtering (and RFC filtering) —

access-list command

—

access-group command

Trust Exploitation —

set vlan command (Configures private VLANs, if practical)

CAM Table Overflow and ARP Spoofing Attacks

Copyright

—

set port security command

—

show port command

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-89

Error! Not a valid link.

As with most devices using Cisco IOS or Cisco IOS-like commands, ACLs can be used to implement Layer 3 and 4 filtering. The syntax for the access-list command is as follows: access-list access-list-number [dynamic dynamic-name [timeout minutes]] {deny | permit} protocol source sourcewildcard destination destination-wildcard [precedence precedence] [tos tos] [log | log-input] [time-range timerange-name] access-list-number

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

dynamic dynamic-name

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

timeout minutes

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

deny

Denies access if the conditions are matched.

permit

Permits access if the conditions are matched.

protocol

Name or number of an IP. It can be one of the keywords eigrp, gre, icmp, igmp, igrp, ip, ipinip, nos, ospf, pim, tcp, or udp, or an integer in the range from 0 to 255 representing an IP number. To match any IP (including ICMP, TCP, and UDP) use the ip keyword.

source

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

source-wildcard

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

6-90

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

destination

Number of the network or host to which the packet is being sent. There are three alternative ways to specify the destination: Use a 32-bit quantity in four-part, dotted-decimal format. Use the any keyword as an abbreviation for the destination and destination-wildcard of 0.0.0.0 255.255.255.255. Use host destination as an abbreviation for a destination and destination-wildcard of destination 0.0.0.0.

destination-wildcard

Wildcard bits to be applied to the destination. There are three alternative ways to specify the destination wildcard: Use a 32-bit quantity in four-part, dotted-decimal format. Place 1s in the bit positions you want to ignore. Use the any keyword as an abbreviation for a destination and destination-wildcard of 0.0.0.0 255.255.255.255. Use host destination as an abbreviation for a destination and destination-wildcard of destination 0.0.0.0.

precedence precedence

(Optional.) Packets can be filtered by precedence level, as specified by a number from 0 to 7, or by name.

tos tos

(Optional.) Packets can be filtered by type of service level, as specified by a number from 0 to 15, or by name.

log

(Optional.) Causes an informational logging message about the packet that matches the entry to be sent to the console. (The level of messages logged to the console is controlled by the logging console command.) The message includes the access list number, whether the packet was permitted or denied; the protocol, whether it was TCP, UDP, ICMP, or a number; and, if appropriate, the source and destination addresses and source and destination port numbers. The message is generated for the first packet that matches, and then at 5-minute intervals, including the number of packets permitted or denied in the prior 5-minute interval. The logging facility might drop some logging message packets if there are too many to be handled or if there is more than one logging message to be handled in 1 second. This behavior prevents the router from crashing due to too many logging packets. Therefore, the logging facility should not be used as a billing tool or an accurate source of the number of matches to an ACL.

log-input

(Optional.) Includes the input interface and source MAC address or VC in the logging output.

time-range time-range-name

(Optional.) Name of the time range that applies to this statement. The name of the time range and its restrictions are specified by the time-range command.

The syntax for the access-group command is as follows: ip access-group {access-list-number | access-list-name}{in | out}

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-91

6-92

access-list-number

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

access-list-name

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

in

Filters on inbound packets.

out

Filters on outbound packets.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Private VLANs (PVLANs) are available on the Catalyst 6000 running Cat operating system 5.4 or later, and are available on the Catalyst 4000, 2980G, 2980G-A, 2948G, and 4912G running Cat operating system 6.2 or later. PVLANs are a tool that enables the segregating of traffic at Layer 2 and turning a broadcast segment into a non-broadcast multi-access-like segment. Traffic that comes to a switch from a promiscuous port (that is, a port that is capable of forwarding both primary and secondary VLANs) is able to go out on all the ports that belong to the same primary VLAN. Traffic that comes to a switch from a port mapped to a secondary VLAN (it can be either an isolated, a community, or a two-way community VLAN) can be forwarded to a promiscuous port or a port belonging to the same community VLAN. Multiple ports mapped to the same isolated VLAN cannot exchange any traffic.

Note

You must configure a private VLAN on the supervisor engine.

Valid values for pvlan-type are as follows: 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 Multilayer 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]

Copyright

vlans

Number identifying the VLAN; valid values are from 1 to 1000, and from 1025 to 4094.

pvlan-type

(Optional.) Keyword and options to specify the PVLAN type.

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-93

Error! Not a valid link.

Configuring port security on the switch can mitigate these attacks. This option provides for either the specification of the MAC addresses on a particular switch port or the specification of the number of MAC addresses that can be learned by a switch port. When an invalid MAC is detected on the port the switch can either block the offending MAC address or shutdown the port. The syntax for the set port security command is as follows: set port security mod/port... [enable | disable] [mac_addr] [age {age_time}] [maximum {num_ of_mac}] [shutdown {shutdown_time}] [violation {shutdown | restrict}] mod/port...

Number of the module and the port on the module.

enable

(Optional.) Enables port security.

disable

(Optional.) Disables port security.

mac_addr

(Optional.) Secure MAC address of the enabled port.

age age_time

(Optional.) Specifies the duration for which addresses on the port will be secured; valid values are 0 (to disable) and from 1 to 1440 (minutes).

maximum num_of_mac

(Optional.) Specifies the maximum number of MAC addresses to secure on the port; valid values are from 1 to 1025.

shutdown shutdown_time

(Optional.) Specifies the duration for which a port will remain disabled in case of a security violation; valid values are 0 (to disable) and from 1 to 1440 (minutes).

violation

(Optional.) Specifies the action to be taken in the event of a security violation.

shutdown

Shuts down the port in the event of a security violation.

restrict

Restricts packets from unsecure hosts.

The syntax for the show port command is as follows: show port security [mod[/port]] show port security statistics {mod[/port]} show port security statistics system

6-94

mod

(Optional.) Number of the module.

port

(Optional.) Number of the port on the module.

statistics

Displays security statistics.

system

Displays system-wide configuration information.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Summary Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-95

Error! Not a valid link.

6-96

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Error! Not a valid link.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design

6-97

Lab Exercise—Medium Network Design Implementation Complete the following lab exercise to practice what you learned in this chapter.

Objectives In this exercise you will complete the following tasks: Assign the 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.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-1

Network Security Policy You will implement this network security policy in this lab: Monitor traffic on the internal network for attacks. Centrally manage network-based IDS appliances. Block attacks at the PIX Firewall if detected by the Sensor.

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

Lab Visual Objective VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24 .150

.10P e0/1

Branch

brP .1 e0/0

10.2.P.0/24

RBB .1

10.2.P.11 .2

Branch

e0/1

172.30.P.0/24

e0/0

192.168.P.0/24

rP .150 .2 e0 172.16.P.0/24

PSS WWW FTP

pub

priv

.1 e4

.1 e2

DMZ .5

pP .5

.1 e1

172.18.P.0/24

cP

.50

Super Server WWW FTP

.10

.4

10.0.P.0 /24

.100

RTS

sensorP

Student

10.0.P.11

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

CSI 1.1—6-1

Setup You should not have to configure any routing or addressing of interfaces on lab equipment in this exercise. You may find that your 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

Lab 6-2

Access the terminal server as directed by your instructor:

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

½æÄ ¬»´²»¬ ïðòðòÐòïðð

(where P = pod number) Step 2

Access the Sensor via its console port as directed by your instructor: ®¬-â -Ð

(where P = pod number) Step 3

Log into the Sensor as the root user with the default password attack: ¬¬§¿ ´±¹·²æ ®±±¬ п--©±®¼æ ¿¬¬¿½µ

Step 4

Execute the sysconfig-sensor utility on the Sensor. The Cisco IDS Sensor Initial Configuration Utility menu appears. ý -§-½±²º·¹ó-»²-±®

Step 5

Enter y if prompted to write the values to disk. Select the options from the main menu listed in the following table and assign the lab settings: Cisco IDS Options/Parameters

Lab Settings

IP Address

10.0.P.4

IP Netmask

255.255.255.0

IP Host Name

sensorP

Default Route

Local: 10.0.P.1

(where P = pod number) Q1)

In what situations would you not need a default route assigned to the Sensor? A)

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

(where P = pod number) Q2)

Would you recommend being more restrictive? What other network addresses might be included, if any? A)

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-3

Step 3

When finished entering addresses, press Enter to exit.

Step 4

Enter y when prompted to write the network access configuration to disk.

Task 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

(where P = pod number) Step 3

Enter y when prompted if IDM will be used to manage the Sensor. The Communication Infrastructure settings are displayed.

Step 4

Verify that the settings are correct and enter y when prompted to create the configuration files. Enter n if any mistakes are made. Then enter y when prompted to enter the values again and repeat steps 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.

Lab 6-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Launch your web browser and specify the Sensor as the location: ¸¬¬°-æññïðòðòÐòì

Step 2

(where P = pod number) Click Yes when prompted to accept the Sensor’s certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Device from the area bar. The Device sub-area bar is displayed.

Step 5

Select Sensor Setup from the sub-area bar. The Sensor Setup table of contents (TOC) is displayed.

Step 6

Select Network from the TOC. The 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:

Copyright

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

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-5

Cisco IDS Parameters

Lab Values

Description

Netmask

255.255.255.0

The subnet mask for the Sensor (for example, 255.255.255.0).

Default route

Local: 10.0.P.1

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

Step 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed.

Task 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: ¸¬¬°-æññïðòðòÐòì

(where P = pod number) Step 2

Click Yes when prompted to accept the Sensor’s certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 5

Select Communications from the sub-area bar. The Communications TOC is displayed.

Step 6

Select Remote Hosts from the TOC. The remote host options are displayed in the work content area.

Step 7

Click Add. The Adding window is displayed in the content area.

Step 8

Enter the values listed in the following table and accept the default values for all other parameters:

Lab 6-6

Cisco IDS Parameters

Lab Values

Description

Host Name

ievP

Alphanumeric identifier for the IEV host.

Host ID

12

Numeric identifier for the IEV host.

Organization Name

podP

Alphanumeric identifier for a group of Cisco IDS Components.

Organization ID

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.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco IDS Parameters

Lab Values

Description

Heartbeat

5

Time interval that the Cisco IDS Communication Infrastructure uses when transmitting route verification messages.

(where P = pod number) Step 9

Click OK to accept the host values. The IEV host is displayed in the list of remote hosts.

Step 10

Select Event Destinations from the Remote Hosts TOC options. The list of event destinations is displayed in the work content area.

Step 11

Click Add. The Add Destination window opens.

Step 12

Choose the IEV host, ievP.podP, from the host drop-down menu.

Step 13

Choose the alarm severity level, Low, from the Level drop-down menu to send low events to the IEV host.

Step 14

Choose the Cisco IDS Service, smid, from the Service drop-down menu.

Step 15

Select Cisco IDS event types to send to the IEV host: Alarms, Errors, and Commands.

Step 16

Click OK to accept the event destination values. The IEV host is displayed in the list of event destinations.

Step 17

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 18

Click Finish to apply your changes to the Sensor. When the changes are successfully applied, a message is displayed. The Sensor is now configured to capture traffic and ready to send events to the IEV.

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-7

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: Cisco IDS Parameters

Lab Values

Description

Port Number

45000

The UDP port number used for IDS communication

Organization Name

podP

Alphanumeric identifier for a group of Cisco IDS components

Organization ID

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

(where P = pod number) Step 8

Click Finish to complete the IEV installation wizard process. The Install dialog window opens.

Step 9

Click OK to restart the system and complete the installation process.

Task 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 Viewer to launch the IEV. The Cisco IDS Event Viewer application opens.

Step 2

Choose File>New Device from the main menu. The Device Properties window opens.

Lab 6-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Enter the new Sensor information and click OK to save the information. The IDS device appears in the Device Folders. The following table contains the Sensor communication parameters and a description of each:

Step 3

Cisco IDS Parameters

Lab Values

Description

IP Address

10.0.P.4

The IP address of the Sensor

Organization Name

podP

Alphanumeric identifier for a group of Cisco IDS components

Organization ID

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

(where P = pod number)

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: Launch your web browser and specify the Sensor as the location. To do this, enter the following in the URL field of your web browser:

Step 1

¸¬¬°-æññïðòðòÐòì

(where P = pod number) Step 2

Click Yes when prompted to accept the Sensor’s certificate.

Step 3

Log into the IDM as user netrangr. The default netrangr password is attack.

Step 4

Select Device from the area bar. The Device sub-area bar is displayed.

Step 5

Select Sensor Setup from the sub-area bar. The Sensor Setup TOC is displayed.

Step 6

Select Remote Access from the TOC. The 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 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-9

Step 12

Attempt to establish a Telnet session to your Sensor. Access should be denied because your 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 ca zeroize command and repeat the ca gen command.

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

(where P = pod number) Step 2

Create a static mapping to the student PC on the outside network: Note

This step is needed to demonstrate the IDS functionality and is not required in a production environment.

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

(where P = pod number)

Note

The order of the existing ACL must be modified to permit the following entry.

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

(where P = pod number)

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

Lab 6-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Q3)

In what situations might Telnet be chosen instead of SSH? A)

Establish an SSH session as user pix to the PIX Firewall:

Step 2

²»¬®¿²¹®à-»²-±®Ðæñ«-®ñ²®â --¸ Š´ °·¨ ïðòðòÐòï

(where P = pod number) Accept the PIX Firewall’s SSH key by entering yes when prompted.

Step 3

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: Launch your web browser and specify the Sensor as the location:

Step 1

¸¬¬°-æññïðòðòÐòì

(where P = pod number) Step 2

Log into the Cisco IDM as user netrangr. The default netrangr password is attack.

Step 3

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 4

Select Sensing Engine from the sub-area bar. The Sensing Engine TOC is displayed.

Step 5

Select Signature Groups from the Sensing Engine TOC. A list of signature groups is displayed in the work content area.

Step 6

Select All Signatures from the list of Signature Groups. The list of All Signatures is displayed.

Step 7

Select Page 18 Sigid [5070-5085] from the drop-down menu at the bottom of the page.

Step 8

Click the Go to Page button. The list of Signatures is displayed.

Step 9

Select the Edit icon for the WWWinNt cmd.exe access 5081. The Editing window opens.

Step 10

Choose High from the Severity drop-down menu.

Step 11

Select the Block check box from the list of Actions.

Step 12

Change the MinHits value to 1 to enable the signature to trigger after one failed login attempt.

Step 13

Click OK to save the signature settings. The list of Signatures is displayed. Notice that the WWWinNt cmd.exe Access Signature severity is High and that the action is set to block.

Step 14

Select Page 20 Sigid [5103-5117] from the drop-down menu at the bottom of the page.

Step 15

Click the Go to Page button. The list of Signature is displayed.

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-11

Q4)

Are these signatures good candidates to perform IP blocking if detected? Why or why not? A)

Step 16

Select the Edit icon for WWWIIS Unicode Attack Signature 5114. The Editing window opens.

Step 17

Choose Log from the Severity drop-down menu.

Step 18

Change the MinHits value to 1 to enable the signature to trigger after one failed login attempt.

Step 19

Click OK to save the signature settings. The list of Signatures is displayed. Notice that the WWWIIS Unicode Attack Signature severity is High and that the action is set to block.

Step 20

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 21

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed.

Task 15—Configure the Sensor’s Blocking Properties Complete the following steps to configure the Sensor’s blocking properties: Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Blocking from the sub-area bar. The Blocking TOC is displayed.

Step 3

Select Blocking Properties from the Blocking TOC. The 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: Cisco IDS Settings

Parameters

Description

Minutes of Block

10

The duration the block is enforced

Maximum Block Entries

100

The maximum number of access control entries the Sensor can add to an ACL

Step 6

Select the Enable Policy Violations Logging check box to enable logging of policy violations.

Step 7

Deselect the Allow the Sensor IP to be Blocked check box to disable the ability to block the 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.

Step 10

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed.

Task 16—Add a PIX Firewall as a Blocking Device Complete the following steps to add a PIX Firewall as a blocking device:

Lab 6-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 1

Select Configuration from the area bar. The Configuration sub-area bar is displayed.

Step 2

Select Blocking from the sub-area bar. The Blocking TOC is displayed.

Step 3

Select Blocking Devices from the Blocking TOC. A list of the 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: Cisco IDS Settings

Parameters

Description

IP Address

10.0.P.1

The IP address of the blocking device

NAT Address

Leave blank

The translated Sensor IP address

Username

pix

The username used to access the managed device

Password

cisco

The username’s password

Enable Password

enable

The blocking device’s enable or secret password

(where P = pod number) Step 6

Choose PIX from the Device Type drop-down menu.

Step 7

Select the Enable SSH check box.

Step 8

Click OK to save the Blocking 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.

Step 10

Select Apply Changes from the IDM toolbar. The Finished option is displayed in the work content area.

Step 11

Click Finish to apply your changes to the Sensor. The Changes were applied successfully message is displayed. Q5)

List some guidelines to follow when deciding how to implement IP blocking. A)

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

Copyright

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-13

URL

Signature Name

http://192.168.P.10/msadc/samples/selector/showcode.asp

WWW IIS Showcode.asp Access

http://192.168.P.10/scripts/..%c0%af../winnt/system32

WWW IIS Unicode Attack

http://192.168.P.10/ scripts/..%35c../winnt/system32/cmd.exe?/c+dir

WWW WinNT cmd.exe

(where P = pod number)

Note Step 4

No spaces should be entered in the URL.

View the alarms generated in the IEV. Select a signature that was configured to perform a Block if detected. Q6)

Were all the attacks detected by the Sensor and reported to the IEV? Why or why not? A)

Note

You can view the blocked hosts directly from the PIX Firewall by issuing the show shun command.

Step 5

Select Administration from the area bar. The Administration sub-area bar is displayed.

Step 6

Select Manual Blocking from the sub-area bar. A list of blocking devices and the list of blocked hosts and networks is displayed in the content area. Complete the following sub-steps: 1. Notice the status of the Net Device. The status should be Active. 2. Notice the list of blocked devices. The list includes addresses from other pods because you are monitoring the same network.

Note

Step 7

You can view the blocked hosts directly from the PIX Firewall by issuing the show shun command.

Select Unblock All to remove all of the addresses from the list of blocked devices.

Lab 6-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Answers Q1)

In what situations would you not need a default route assigned to the Sensor? A)

Q2)

Would you recommend being more restrictive? What other network addresses might be included, if any? A)

Q3)

Q6)

Copyright

Allowing insecure communication is ultimately determined by a 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.

Are these signatures good candidates to perform IP blocking if detected? Why or why not? A)

Q5)

In general allowing entire network segments is not desirable unless all of the management workstations reside on that particular network. It is recommended to be as restrictive as possible when defining what hosts can manage the Sensor.

In what situations might Telnet be chosen instead of SSH? A)

Q4)

A default route assigned to the Sensor is not needed when the Sensor does not need to communicate with devices on another network. The typical scenario occurs when the IDS Director is on the same network and the Sensor is not performing blocking.

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

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.

Were all the attacks detected by the Sensor and reported to the IEV? Why or why not?

2003, Cisco Systems, Inc.

SAFE SMR Midsize Network Design Lab 6-15

A)

No. The Sensor did not detect all of the signatures once a “block” signature was detected. After the block occurred, the PIX Firewall denied the traffic from the source.

Lab 6-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

7

Remote User Network Implementation Overview This chapter introduces the Cisco Remote User Network implementation strategy and components. It includes the following topics: Design overview Key devices and threat mitigation Software access option Remote site firewall option VPN Hardware Client option Remote site router option Summary

Objectives This section lists the objectives of this chapter.

Objectives Upon completion of this chapter, you will be able to perform the following tasks: • Describe the key devices in a remote user network. • List the threats mitigated. • Discuss the four different options for providing remote user connectivity. • Understand the mitigation roles of each of the following: – VPN Software Client – PIX Firewall – VPN Hardware Client – IOS Firewall • Implement specific configurations to apply the mitigation roles.

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

7-2

Cisco SAFE Implementation 1.1

CSI 1.1—7-2

Copyright

2003, Cisco Systems, Inc.

Design Overview This section gives a brief overview of the SAFE: Extending the Security Blueprint to Small, Midsize, and Remote-User Networks (SAFE SMR) Remote-User network implementation.

Remote User Connectivity ISP edge module

There are four options for remote-user connectivity: • Covers both mobile and home-office workers • Contains hardware, software, and combined designs

ISP

VPN Software Client with personal firewall

Software access option

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

Broadban d access device Home office firewall with VPN

Broadband access device Hardware VPN Client

Remote site Hardware VPN firewall option Client option

Broadband access device (optional) Router with firewall and VPN

Remote site router option

CSI 1.1—7-4

Remote connectivity applies to both mobile workers and home-office workers. The primary focus of these designs is providing connectivity from the remote site to the corporate headquarters and through some means, the Internet. The following four options include software-only, software-with-hardware, and hardware-only solutions: Software 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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-3

IPSec Remote-User to LAN—Tunneling

VPN private IP 10.0.1.5

Telecommuter or mobile worker

ISP Internet

VPN public IP 192.168.1.5 Application server 10.0.1.10

Adapter (NIC) IP address 172.31.1.1 Client IP address 10.0.1.20

The result of implementing IPSec remote-user to LAN tunneling is that the security perimeter of your organization is extended to include remote sites.

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

CSI 1.1—7-5

A VPN is defined as customer connectivity deployed on a shared infrastructure with the same policies as a private network. The shared infrastructure can leverage a service provider IP, Frame Relay, ATM backbone, or the Internet. The result is that the security perimeter of the organization is extended to the remote site. The Cisco end-to-end hardware and Cisco IOS software networking products enables a complete access VPN solution by providing the following: Sophisticated security for sensitive private transmissions over the public infrastructure Quality of Service (QoS) through traffic differentiation Reliability for mission-critical applications Scalability for supporting large bandwidth of data Comprehensive network management

7-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

IPSec Remote-User to LAN Components VPN head-end device

ISP

Application server

ISP

Telecommuter or mobile worker

Internet

PPP connectivity dial access IPSec tunnel or session

• • • •

Client software or hardware PPP protocol (for dial access) IPSec protocol VPN head-end device

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

CSI 1.1—7-6

IPSec remote-user-to-LAN components consist of the following: Cisco VPN Software Client —

Resides on a PC

—

Terminates one end of the tunnel

IPSec and Internet Key Exchange (IKE) —

Establishes a secure tunnel or session through the Internet to a Cisco VPN Concentrator

—

For dialup applications, IPSec relies on Point-to-Point Protocol (PPP) to establish the physical connection to the local ISP and Internet

Concentrator

Copyright

—

Terminates the tunnels and sessions

—

Encrypts, authenticates, and encapsulates data

—

May provide both authentication and data encryption options

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-5

Key Devices and Threat Mitigation This section provides details of the key devices for remote-user network implementation.

SAFE Remote User—Key Devices ISP

Broadband access device

The following are the key devices: Firewall with a VPN or a router with a firewall and VPN

Hub Hardware or Software VPN Client

Key devices

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

Broadband access device Firewall with VPN support Layer 2 hub Personal firewall software Router with firewall and VPN support • VPN Software Client • VPN Hardware Client • • • • •

CSI 1.1—7-8

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

7-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Hardware Client—Provides secure, end-to-end encrypted tunnels between the remote site and the corporate head-end

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-7

Mitigated Remote User Threats

The following threats are common to most remote user networks: • Unauthorized access • Network reconnaissance • Virus and Trojan horse attacks • IP spoofing • Man-in-the-middle attacks

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

CSI 1.1—7-9

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.

7-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Mitigation Options Overview

There are four basic options available to mitigate threats: • Hardware options – Remote-site firewall – VPN Hardware Client – Remote-site router • Software option—Software access

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

CSI 1.1—7-10

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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-9

Software Access Option This section provides details of the software access option for remote users.

Software Access Option— Attack Mitigation Roles ISP Edge Module

ISP

VPN Software Client with a personal firewall

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

Software access option

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

CSI 1.1—7-12

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

7-10

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Software Access Option— Design Guidelines • Geared toward mobile and home office worker • Remote user needs VPN software and Internet access • Authentication and configuration are controlled from the headquarters • Split tunneling is disabled when the VPN tunnel is operational • Personal firewall software is recommended to protect the remote user when split tunneling is not enabled or the VPN is not connected • Virus scanning software is recommended

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

ISP Edge Module

ISP

VPN Software Client with a personal firewall

Software access option

CSI 1.1—7-13

The software access option is geared toward the mobile worker as well as the home-office worker. All the remote user requires is a PC with Cisco VPN Client software and connectivity to the Internet or ISP network via a dial-in or Ethernet connection. The primary function of the VPN Software Client is to establish a secure, encrypted tunnel from the client device to a VPN head-end device. Access and authorization to the network are controlled from the headquarters location when filtering takes place on the firewall, and on the client itself if access rights are pushed down via policy. The remote user is first authenticated, and then receives IP parameters such as a virtual IP address, which is used for all VPN traffic, and the location of name servers (Domain Name System [DNS] and Windows Internet Name Service [WINS]). Split tunneling can also be enabled or disabled via the central site. For the SAFE design, split tunneling was disabled, making it necessary for all remote users to access the Internet via the corporate connection when they have a VPN tunnel established. Because the remote user may not always want the VPN tunnel established when connected to the Internet or ISP network, personal firewall software is recommended to mitigate unauthorized access to the PC. Virusscanning software is also recommended to mitigate viruses and Trojan horse programs infecting the PC.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-11

Software Access Option— Implementation ISP Edge Module

The Cisco VPN Client version 3.5 or higher is the recommended product for implementation of the software access option: • Provides integrated VPN and firewall functionality

ISP

VPN Software Client with a personal firewall

• Simple install process • Configured via the head-end VPN termination device Software access option

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

CSI 1.1—7-14

It is recommended that you use the latest level of the VPN Software Client unless technical specifications or compatibility issues require an earlier version. The Cisco VPN Client version 3.5 or higher is the recommended product for implementation of the software access option: Provides integrated VPN and firewall functionality Simple install process Configured via the head-end VPN termination device

7-12

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Windows Client

192.168.1.5

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

CSI 1.1—7-15

The VPN Windows Client is a software program that runs on Windows 95, 98, ME, 2000, XP, and NT 4.0. The VPN Client on a remote PC, communicating with a Concentrator at an enterprise or service provider, creates a secure connection over the Internet that enables you to access a private network as if you were an on-site user. The figure displays the VPN Client window. From this window, you can launch the new connection wizard, change or set optional parameters, and launch the VPN Client. The Connection Entry field enables you to provide a unique name for this VPN connection. The address of the Concentrator’s public interface is configured in the field Host name or IP address of the remote server.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-13

Cisco VPN Client Options

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

CSI 1.1—7-16

The Options drop-down menu enables you to configure or change optional parameters. By clicking the Options button, the following options become available: Clone 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.

7-14

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-15

Properties Tabs

• General • Authentication • Connections

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

CSI 1.1—7-17

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.

7-16

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Properties—General Tab Win 95/98/ME

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

Win-NT 4/2000/XP

CSI 1.1—7-18

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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-17

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:

7-18

—

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.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Properties—Authentication Tab

The end-user never sees the password after initial configuration.

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

CSI 1.1—7-19

The Concentrator and VPN Client connection can be authenticated with either the group name and password, or digital certificates. The Authentication tab enables you to set your authentication information. You need to choose one method, group or certificate, via the radio buttons. Within the Group Access Information group box, enter the group name and password in the appropriate fields. The group name and password must match what is configured for this group within the Configuration>User Management>Groups>Identity window. Entries are case sensitive. For certificates to be exchanged, the Certificate radio button must be selected. In the Name dropdown menu, any personal certificates loaded on your PC are listed. Choose the certificate to be exchanged with the Concentrator during connection establishment. If no personal certificates are loaded in your PC, the drop-down menu is blank. Use the Validate Certificate button to check the validity of the VPN Clients’ certificate.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-19

Properties—Connections Tab

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

CSI 1.1—7-20

The last tab is the Connections tab. It defines backup networks and connection to the Internet via dialup networking. A private network may include one or more backup Concentrators to use if the primary Concentrator is not available. Your system administrator tells you whether to enable a backup Concentrator and gives you its address. If the VPN Client cannot reach the primary Concentrator, the VPN Client tries a backup Concentrator. Select the Enable backup server(s) check box to enable this feature. Once selected, click Add to enter the IP address of the backup Concentrator. Your VPN Client then attempts to connect to your primary Concentrator first. If that Concentrator cannot be reached, the VPN Client accesses the backup list for the addresses of available backup Concentrators. Connecting to a private network using a dialup connection is typically a two-step process: Step 1

Use a dialup connection to your ISP.

Step 2

Use the VPN Client to connect to the private network. Connecting to the Internet via dialup networking automatically launches the DUN connection before making the VPN connection. It makes connecting to the ISP and Concentrator a one-step process. To enable the option, select the Connect to the Internet via dialup check box.

7-20

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Site Firewall Option This section provides details of the remote site firewall access option for remote users.

Remote Site Firewall— Attack Mitigation Roles

ISP

Broadband access device

Stateful packet filtering, basic Layer 7 filtering, Host DoS mitigation, authenticate remote site, and terminate IPSec

Home office firewall with a VPN

Virus scanning for local attack mitigation

Remote site firewall option

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

CSI 1.1—7-22

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-21

Remote Site Firewall— Design Guidelines • Geared toward a home-office worker or a very small branch office • Firewall provides connection-state enforcement • Termination point for site-to-site IPSec – For remote management and production – Client does not need individual software (firewall or VPN) – NAT is not used in IPSec tunnel – Device authentication is used at head-end – Allows split tunneling • Authentication is controlled from the headquarters • Virus checking software is still recommended • Personal firewall software can be used to protect the remote user when split tunneling is not enabled • You can use an IDS on a PIX Firewall © 2003, Cisco Systems, Inc. All rights reserved.

ISP

Broadband access device Home office firewall with a VPN

Remote site firewall option

CSI 1.1—7-23

The remote-site firewall option is geared toward the home-office worker, or potentially a very small branch office. With this option, it is expected that the remote site have some form of broadband access available from a service provider. The firewall is installed behind the DSL or cable modem. The primary function of the firewall is to establish the secure, encrypted tunnel between itself and a VPN head-end device, as well as providing connection-state enforcement and detailed filtering for sessions initiated through it. Individual PCs on the remote-site network do not need VPN client software to access corporate resources. Additionally, because the stateful firewall protects access to the Internet, personal firewall software is not necessarily required on the individual PCs. However, if the network administrator wants an additional level of security, personal firewall software can also be implemented on remote-site PCs. This setup may be useful if the home worker also travels and connects to the Internet directly over some public network. Because the corporate headquarters has a stateful firewall protecting the hosts, the remote site can have direct access to the Internet, rather than passing all traffic back through the corporate headquarters. Unless NAT is used when communicating with the headquarters, the IP addresses of the remote-site devices should be assigned in such a manner as to not overlap addressing space in the headquarters location or another remote site. Remote-site devices that require direct access to the Internet will require address translation to a registered address. This address translation can be achieved by translating all Internet-bound sessions to the public IP address of the firewall itself. Access and authorization to the corporate network and the Internet are controlled by the configuration of both the remote-site firewall and the VPN head-end device. Configuration and security management of the remote-site firewall can be achieved via an IPSec tunnel from the public side of the firewall back to the corporate headquarters. This setup ensures that the remotesite user is not required to perform any configuration changes on the home-office firewall. Authentication should be set up on the firewall to prevent a local user from inadvertently 7-22

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

modifying their firewall configuration and thereby compromise the security policy of that device. Individual users at the remote site who access the corporate network are not authenticated with this option. Instead, the remote-site firewall and VPN head-end use device authentication. Virus-scanning software is still recommended to mitigate against viruses and Trojan horse programs infecting individual PCs at the remote site—just like all the PCs in the entire corporation.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-23

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

Broadband access device Home office firewall with a VPN

Remote site firewall option

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

CSI 1.1—7-24

The following mitigation roles and commands are used to implement the policy on the Cisco PIX Firewall: Stateful packet filtering (this is the default for the PIX Firewall) Host DoS mitigation —

ip verify reverse-path 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

Spoof mitigation and RFC filtering

7-24

—

access-list—Creates an ACL

—

access-group—Binds the ACL to an interface

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Broadband access device Home office firewall with a VPN

Remote site firewall option

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

CSI 1.1—7-25

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-25

Terminate IPSec—Sysopt connection permit-ipsec and isakmp enable pixfirewall(config)#

-§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½ • Implicitly permit any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections.

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

pixfirewall(config)#

·-¿µ³° »²¿¾´» ·²¬»®º¿½»ó²¿³» • Used to enable ISAKMP negotiation on the interface on which the IPSec peer will communicate with the PIX Firewall. This is enabled by default.

°·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° »²¿¾´» ±«¬-·¼» © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-26

The sysopt connection permit-ipsec command implicitly permits any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections. The isakmp enable command is used to enable ISAKMP negotiation on the interface on which the IPSec peer will communicate with the PIX Firewall. Use the no isakmp enable command to disable IKE. The syntax for the sysopt connection command is as follows: sysopt connection permit-ipsec connection permit-ipsec

Implicitly permit any packet that came from an IPSec tunnel and bypass the checking of an associated access-list, conduit, or access-group command statement for IPSec connections.

The syntax for the isakmp enable command is as follows: isakmp enable interface-name interface-name

7-26

Cisco SAFE Implementation 1.1

The name of the interface on which to enable ISAKMP negotiation.

Copyright

2003, Cisco Systems, Inc.

Terminate IPSec—isakmp key pixfirewall(config)#

·-¿µ³° µ»§ µ»§-¬®·²¹ ¿¼¼®»-- °»»®ó¿¼¼®»-Ų»¬³¿-µ ³¿-µÃ Ų±ó¨¿«¬¸Ã Ų±ó½±²º·¹ó³±¼»Ã • Specifies the authentication pre-shared key. • You can use any combination of alphanumeric characters up to 128 bytes. The pre-shared key must be identical at both peers.

°·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïéîòîêòîêòïðï ²»¬³¿-µ îëëòîëëòîëëòð

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

CSI 1.1—7-27

To configure a pre-shared authentication key and associate the key with an IPSec peer address or hostname, use the isakmp key address command. Use the no isakmp key address command to delete a pre-shared authentication key and its associated IPSec peer address. You would configure the pre-shared key at both peers whenever you specify pre-shared key in an IKE policy. Otherwise, the policy cannot be used because it will not be submitted for matching by the IKE process. A netmask of 0.0.0.0. can be entered as a wildcard indicating that any IPSec peer with a given valid pre-shared key is a valid peer.

Note

The PIX Firewall or any IPSec peer can use the same authentication key with multiple peers, but this is not as secure as using a unique authentication key between each pair of peers.

The no-xauth or no-config-mode command options are to be used only if the following criteria are met: You are using the pre-shared key authentication method within your IKE policy. The security gateway and VPN Client peers terminate on the same interface. The Xauth or IKE Mode Configuration feature is enabled for VPN Client peers. Both the Xauth and IKE Mode Configuration features are specifically designed for remote VPN Clients. The Xauth feature enables the PIX Firewall to challenge the peer for a username and password during IKE negotiation. The IKE Mode Configuration enables the PIX Firewall to

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-27

download an IP address to the peer for dynamic IP address assignment. Most security gateways do not support the Xauth and IKE Mode Configuration features. If you have the no-xauth command option configured, the PIX Firewall does not challenge the peer for a username and password. Similarly, if you have the no-config-mode command option configured, the PIX Firewall does not attempt to download an IP address to the peer for dynamic IP address assignment. The syntax for the isakmp key command is as follows: isakmp key keystring address peer-address [netmask mask] [no-xauth] [no-config-mode]

7-28

key keystring

Specifies the authentication pre-shared key. Use any combination of alphanumeric characters up to 128 bytes. This pre-shared key must be identical at both peers.

address peer-address

Specifies the IPSec peer's IP address for the pre-shared key.

netmask mask

(Optional.) The netmask of 0.0.0.0. can be entered as a wildcard indicating that the key could be used for any peer that does not have a key associated with its specific IP address.

no-xauth

Only use this if you enabled the Xauth feature, and you have an IPSec peer that is a gateway. This option associates a given preshared key with a gateway and allows an exception to the Xauth feature enabled by the crypto map client authentication command.

no-config-mode

Only use this if you enabled the IKE Mode Configuration feature, and you have an IPSec peer that is a gateway. This option associates a given pre-shared key with a gateway and allows an exception to the IKE Mode Configuration feature enabled by the crypto map client configuration address command.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSec—isakmp policy pixfirewall(config)#

·-¿µ³° °±´·½§ °®·±®·¬§ »²½®§°¬·±² ¼»- ¤ í¼»·-¿µ³° °±´·½§ °®·±®·¬§ ¸¿-¸ ³¼ë ¤ -¸¿ ·-¿µ³° °±´·½§ °®·±®·¬§ ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ¤ ®-¿ó-·¹ ·-¿µ³° °±´·½§ °®·±®·¬§ ¹®±«°ï ¤ î ·-¿µ³° °±´·½§ °®·±®·¬§ ´·º»¬·³» -»½±²¼• Sets the various parameters of the IKE policy that will be used

°·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»°·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° °±´·½§ ï𠸿-¸ -¸¿ °·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó -¸¿®» °·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° °±´·½§ ïð ¹®±«° ï °·¨º·®»©¿´´ø½±²º·¹÷ý ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-28

The isakmp policy command enables you to negotiate IPSec SAs and enable IPSec secure communications. Several parameters can be configured with this command as illustrated in the figure. The syntax for the isakmp policy command is as follows: isakmp policy priority encryption des | 3des policy priority

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 65,534, with 1 being the highest priority and 65,534 the lowest.

encryption 3des

Specifies that the 3DES encryption algorithm is to be used in the IKE policy.

encryption des

Specifies 56-bit DES-CBC as the encryption algorithm to be used in the IKE policy.

The syntax for the isakmp policy command is as follows: isakmp policy priority hash md5 | sha

Copyright

policy priority

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 65,534, with 1 being the highest priority and 65,534 the lowest.

hash md5

Specifies MD5 (HMAC variant) as the hash algorithm to be used in the IKE policy.

hash sha

Specifies SHA-1 (HMAC variant) as the hash algorithm to be used in the IKE policy. This is the default hash algorithm.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-29

The syntax for the isakmp policy command is as follows: isakmp policy priority authentication pre-share | rsa-sig policy priority

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 65,534, with 1 being the highest priority and 65,534 the lowest.

authentication pre-share

Specifies pre-shared keys as the authentication method.

Authentication rsa-sig

Specifies RSA signatures as the authentication method. RSA signatures provide non-repudiation for the IKE negotiation. This basically means you can prove to a third party whether you had an IKE negotiation with the peer.

The syntax for the isakmp policy command is as follows: isakmp policy priority group1 | 2 policy priority

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 65,534, with 1 being the highest priority and 65,534 the lowest.

group 1

Specifies that the 768-bit Diffie-Hellman group is to be used in the IKE policy. This is the default value.

group 2

Specifies that the 1024-bit DH group 2 be used in the IKE policy.

The syntax for the isakmp policy command is as follows: isakmp policy priority lifetime seconds

7-30

policy priority

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 65,534, with 1 being the highest priority and 65,534 the lowest.

lifetime seconds

Specifies how many seconds each security association should exist before expiring. Use an integer from 120 to 86,400 seconds (one day).

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSec—crypto ipsec transform-set

pixfirewall(config)#

½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ¬®¿²-º±®³ó-»¬ó²¿³» ¬®¿²-º±®³ï Ŭ®¿²-º±®³î Ŭ®¿²-º±®³íÃà • Create, view, or delete IPSec SAs, SA global lifetime values, and global transform sets. • You can specify up to three transforms. Transforms define the IPSec security protocols and algorithms. Each transform represents an IPSec security protocol (ESP, AH, or both) plus the algorithm you want to use.

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

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

CSI 1.1—7-29

The crypto ipsec transform-set command defines a transform set. To delete a transform set, use the no crypto ipsec transform-set command. To view the configured transform sets, use the show crypto ipsec transform-set command. A transform set specifies one or two IPSec security protocols (either Encapsulating Security Payload [ESP] or Authentication Header [AH], or both) and specifies which algorithms to use with the selected security protocol. During the IPSec SA negotiation, the peers agree to use a particular transform set when protecting a particular data flow. You can configure multiple transform sets, and then specify one or more of these transform sets in a crypto map entry. The transform set defined in the crypto map entry is used in the IPSec SA negotiation to protect the data flows specified by that crypto map 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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-31

In a transform set you can specify the AH protocol, the ESP protocol, or both. If you specify an ESP protocol in a transform set, you can specify just an ESP encryption transform or both an ESP encryption transform and an ESP authentication transform. Examples of acceptable transform combinations are as follows: ah-md5-hmac esp-des esp-des and esp-md5-hmac ah-sha-hmac and esp-des and esp-sha-hmac If one or more transforms are specified in the crypto ipsec transform-set command for an existing transform set, the specified transforms will replace the existing transforms for that transform set. If you change a transform set definition, the change is only applied to crypto map entries that reference the transform set. The change will not be applied to existing SAs, but will be used in subsequent negotiations to establish new SAs. If you want the new settings to take effect sooner, you can clear all or part of the security association database by using the clear [crypto] ipsec sa command. The syntax for the crypto ipsec transform-set command is as follows: crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

7-32

transform-set-name

Specifies the name of the transform set to create or modify.

transform1 transform2 transform3

Specifies up to three transforms. Transforms define the IPSec security protocols and algorithms. Each transform represents an IPSec security protocol (ESP, AH, or both) plus the algorithm you want to use.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Implementation Commands— Terminate IPSec (cont.) pixfirewall(config)#

½®§°¬± ³¿° ³¿°ó²¿³» -»¯ó²«³ ·°-»½ó·-¿µ³° ¤ ·°-»½ó³¿²«¿´ ż§²¿³·½¼§²¿³·½ó³¿°ó²¿³»Ã ½®§°¬± ³¿° ³¿°ó²¿³» -»¯ó²«³ ³¿¬½¸ ¿¼¼®»-- ¿½´Á²¿³» ½®§°¬± ³¿° ³¿°ó²¿³» -»¯ó²«³ -»¬ °»»® ¸±-¬²¿³» ¤ ·°ó¿¼¼®»-½®§°¬± ³¿° ³¿°ó²¿³» -»¯ó²«³ -»¬ ¬®¿²-º±®³ó-»¬ ¬®¿²-º±®³ó-»¬ó²¿³»ï Å ¬®¿²-º±®³ó-»¬ó²¿³»êà ½®§°¬± ³¿° ³¿°ó²¿³» ·²¬»®º¿½» ·²¬»®º¿½»ó²¿³» • Sets the various parameters of the IKE policy that will be used.

°·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° °·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ î𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÐÍÍ °·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ °»»® ïéîòîêòîêòïðï °·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ °·¨º·®»©¿´´ø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼» © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-30

To create or modify a crypto map entry, use the crypto map ipsec-manual | ipsec-isakmp command. To create or modify an ipsec-manual crypto map entry, use the ipsec-manual option of the command. To create or modify an ipsec-isakmp crypto map entry, use the ipsec-isakmp option of the command. Use the no crypto map command to delete a crypto map entry or set. Crypto maps provide two functions: filtering and classifying traffic to be protected, and defining the policy to be applied to that traffic. The first use affects the flow of traffic on an interface; the second affects the negotiation performed (via IKE) on behalf of that traffic. IPSec crypto maps link together definitions of the following: What traffic should be protected Which IPSec peers to which the protected traffic can be 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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-33

entry with a lower seq-num is evaluated before a map entry with a higher seq-num; that is, the map entry with the lower number has a higher priority. The syntax for the crypto map map-name command is as follows: crypto map map-name seq-num ipsec-isakmp | ipsec-manual [dynamicdynamic-map-name] map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

ipsec-isakmp

Indicates that IKE will be used to establish the IPSec SAs for protecting the traffic specified by this crypto map entry.

ipsec-manual

Indicates that IKE will not be used to establish the IPSec SAs for protecting the traffic specified by this crypto map entry.

dynamic

(Optional.) Specifies that this crypto map entry is to reference a pre-existing dynamic crypto map.

dynamic-map-name

(Optional.) Specifies the name of the dynamic crypto map set to be used as the policy template.

The syntax for the crypto map map-name command is as follows: crypto map map-name seq-num match address acl_name map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

match address

Specifies an ACL for a crypto map entry.

acl_name

Identifies the named encryption ACL. This name should match the name argument of the named encryption ACL being matched.

The syntax for the crypto map map-name command is as follows: crypto map map-name seq-num set peer hostname | ip-address map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

set peer

Specifies an IPSec peer in a crypto map entry.

hostname

Specifies a peer by its hostname. This is the peer's hostname concatenated with its domain name (for example, myhost.example.com).

ip-address

Specifies a peer by its IP address.

The syntax for the crypto map map-name command is as follows: crypto map map-name seq-num set transform-set transform-set-name1 [transform-set-name6]

7-34

map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

set transform-set

Specifies which transform sets can be used with the crypto map entry.

transform-set-name

The name of the transform set. For an ipsec-manual crypto map entry, you can specify only one transform set. For an ipsec-isakmp or dynamic crypto map entry, you can specify up to six transform sets.

The syntax for the crypto map map-name command is as follows: crypto map map-name interface interface-name map map-name

The name of the crypto map set.

seq-num

The number you assign to the crypto map entry.

set transform-set

Specifies which transform sets can be used with the crypto map entry.

transform-set-name

The name of the transform set. For an ipsec-manual crypto map entry, you can specify only one transform set. For an ipsec-isakmp or dynamic crypto map entry, you can specify up to six transform sets.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-35

VPN Hardware Client Option This section covers the use of the Cisco VPN Hardware Client for remote access.

Hardware VPN Client— Attack Mitigation Roles

ISP

Broadband access device

Authenticate remote site and terminate IPSec

Hardware VPN Client

Personal firewall and virus scanning for local attack mitigation

Hardware VPN Client option

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

CSI 1.1—7-32

The following are the mitigation roles for the VPN Hardware Client: 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 Personal firewall and virus scanning for local attack mitigation—Provides firewall inspection and allays the risk of virus infection at the remote site

7-36

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Hardware VPN Client— Design Guidelines • Same guidelines as Remote Site Firewall option except that the Hardware VPN Client does not have resident stateful firewall • Use a personal firewall on individual hosts (if split tunneling will be used) • If no personal firewall is in use, security behind the VPN device is dependent upon NAT (with split tunneling enabled) • Access and authentication are controlled from the headquarters • Configuration and security management is done from the headquarters • VPN Client software is not needed

ISP

Broadband access device Hardware VPN Client

Hardware VPN Client option

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

CSI 1.1—7-33

The VPN Hardware Client option is identical to the remote-site firewall option except that the VPN Hardware Client does not have a resident stateful firewall. This setup requires use of a personal firewall on the individual hosts, particularly when split tunneling is enabled. Without the personal firewall, the security of the individual hosts behind the VPN device is dependant upon the attacker being unable to circumvent NAT. This is because when split tunneling is enabled, connections to the Internet pass through a many-to-one NAT translation and do not undergo any filtering at Layer 4 and above. With split tunneling disabled, all access to the Internet must be through the corporate headquarters. This setup partially mitigates the requirement for personal firewalls on the end systems. Using a VPN Hardware Client offers two primary advantages: As with the VPN Software Client, access and authorization to the corporate network and the Internet are controlled centrally from the headquarters’ location. Configuration and security management of the VPN Hardware Client device itself is done via a Secure Sockets Layer (SSL) connection from the central site. This setup ensures that the remote-site user is not required to perform any configuration changes on the VPN Hardware Client. Individual PCs on the remote-site network do not need VPN Client software to access corporate resources. However, individual users at the remote site who access the corporate network are not authenticated with this option. Instead, the VPN Hardware Client and VPN head-end Concentrator authenticate each other.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-37

Hardware VPN 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

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

CSI 1.1—7-34

Once connected, the administrator must gain access to the VPN 3002 Hardware Client Manager. To gain access, complete the following steps: Step 1

The VPN 3002 comes from the factory with a private interface IP address of 192.168.10.1. Hook up a PC to the private port and configure the 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.

7-38

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

GUI

Toolbar Table of contents

Manager screen

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

CSI 1.1—7-35

The main window of the VPN 3002 Manager after logging into the device is made up of the following: The top frame (VPN 3002 Manager toolbar) provides quick access to Manager functions, configuration, administration, and monitoring. The left frame (table of contents [TOC]) provides the TOC to the 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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-39

Quick Configuration

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

CSI 1.1—7-36

There are two ways to configure the VPN 3002: Quick Configuration and the main menu. The goal of Quick Configuration is to provide the minimal parameters needed for operation. You can access Quick Configuration from the Configuration>Quick window. The VPN 3002 Quick Configuration can be run multiple times.

7-40

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Quick Configuration Example Screens

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

CSI 1.1—7-37

Quick Configuration guides you through the windows necessary to get a single tunnel up and running. Use the main menu to tune an application or configure features individually. The windows in the figure illustrate some of the IPSec remote access configuration screens using Quick Configuration.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-41

Launching the Client

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

CSI 1.1—7-38

The VPN 3002 is configured, and now the tunnel needs to be established. In Client Mode, by default, there is no tunnel established. There are two ways to initiate a tunnel: By clicking Connect Now, under the Monitoring>System Status window By sending traffic to the VPN Hardware Client destined for the remote end You can verify the configuration by trying to ping an interface on the remote Concentrator. The VPN 3002 recognizes the remote-bound traffic and attempts to establish a tunnel. If a tunnel is established, it is viewable on this screen. If the tunnel does not come up, check the event log of the VPN 3002 and the Concentrator.

7-42

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Remote Site Router Option This section summarizes the remote-site router option and provides configuration details.

Remote Site Router— Attack Mitigation Roles

ISP

Broadband access device Router with a firewall and a VPN

Host DoS mitigation, stateful packet filtering, basic Layer 7 filtering, authenticate the remote site, and terminate IPSec

Virus scanning for local attack mitigation

Remote site firewall option

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

CSI 1.1—7-40

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-43

Remote Site Router— Design Guidelines • Same guidelines as the remote site firewall option • The router can support QoS, routing, and more encapsulation options • Broadband capability can be integrated into the router: – This removes the need for a separate broadband access device – This is typically managed by a service provider • An IDS on a router can be used (this is not available on Cisco 800 series routers)

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

ISP

Broadband access device Router with a firewall and a VPN

Remote site firewall option

CSI 1.1—7-41

The remote-site router option is nearly identical to the remote-site firewall option with a few exceptions. When deployed behind a standalone broadband access device, the only difference is the router can support advanced applications such as QoS, routing, and more encapsulation options. Additionally, if the broadband capability is integrated into the router, a standalone broadband access device is not needed. This option requires that your ISP allow you to manage the broadband router itself, which is an uncommon scenario.

7-44

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Cisco 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 – access-list – access-group • Host DoS mitigation and basic layer 7 filtering – ip inspect • Authenticate remote site (and logging) – aaa new-model – tacacs-server – aaa authentication login – aaa authorization exec – aaa accounting exec – login authentication

ISP

Broadband access device Router with a firewall and a VPN

Remote site firewall option

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

CSI 1.1—7-42

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)

Copyright

—

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.

—

tacacs-server—Defines the TACACS server.

—

aaa authentication login—Enables AAA authentication at login.

—

aaa authorization exec—Restricts network access to a user.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-45

7-46

—

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 SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Broadband access device Router with a firewall and a VPN

Remote site firewall option

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

CSI 1.1—7-43

IPSec commands—Provide for IPSec tunnel termination

Copyright

—

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 AAA server group to use for pre-authentication.

—

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.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-47

Terminate IPSec—Enable IKE and Define IKE Policy router(config)#

½®§°¬± ·-¿µ³° »²¿¾´» • Enable Internet Key Exchange.

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ·-¿µ³° »²¿¾´» router(config)#

½®§°¬± ·-¿µ³° °±´·½§ °®·±®·¬§ • Defines an Internet Key Exchange policy • Invokes the Internet Security Association Key Management Protocol policy configuration (configisakmp) command mode.

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ·-¿µ³° °±´·½§ ïïð ®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-44

IKE is enabled by default. IKE does not have to be enabled for individual interfaces, but is enabled globally for all interfaces at the router. If you do not want IKE to be used in your IPSec implementation, you can disable IKE at all your IPSec peers. If you disable IKE at one peer, you must disable it at all your IPSec peers. If you disable IKE, you will have to make the following concessions at the peers: You must manually specify all the IPSec SAs in the crypto maps at the peers. The IPSec SAs of the peers never time out for a given IPSec session. During IPSec sessions between the peers, the encryption keys never change. Anti-replay services are not available between the peers. Certification Authority (CA) support cannot be used. IKE negotiations must be protected, so each IKE negotiation begins by agreement of both peers on a common (shared) IKE policy. This policy states which security parameters will be used to protect subsequent IKE negotiations and mandates how the peers are authenticated. After the two peers agree upon a policy, the security parameters of the policy are identified by an SA established at each peer, and these SAs apply to all subsequent IKE traffic during the negotiation. You can create multiple, prioritized policies at each peer to ensure that at least one policy will match the policy of a remote peer.

7-48

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the crypto isakmp command is as follows: crypto isakmp enable

This command has no keywords or arguments. The syntax for the crypto isakmp policy command is as follows: crypto isakmp policy priority priority

Copyright

2003, Cisco Systems, Inc.

Uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 10,000, with 1 being the highest priority and 10,000 the lowest.

Remote User Network Implementation

7-49

Terminate IPSec—ISAKMP Policy Configuration Router (config-isakmp) #

»²½®§°¬·±² ¥¼»- ¤ í¼»-£ ¸¿-¸ ¥-¸¿ ¤ ³¼ë£ ¿«¬¸»²¬·½¿¬·±² ¥®-¿ó-·¹ ¤ ®-¿ó»²½® ¤ °®»ó-¸¿®»£ ¹®±«° ¥ï ¤ î£ ´·º»¬·³» -»½±²¼• While in the ISAKMP policy configuration command mode, the following commands are available to specify the parameters in the policy. If you do not specify one of these commands for a policy, the default value will be used for that parameter.

®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý »²½®§°¬·±² í¼»®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý ¸¿-¸ -¸¿ ®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý ¹®±«° ï ®±«¬»®ø½±²º·¹ó·-¿µ³°÷ý ´·º»¬·³» èêìðð © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-45

If you are interoperating with a device that supports only one of the values for a parameter, your choice is limited to the value supported by the other device. Aside from this, there is often a trade-off between security and performance, and many of these parameter values represent such a trade-off. You should evaluate the level of security risks for your network and your tolerance for these risks. After doing that, the following tips might help you select which value to specify for each parameter: The encryption algorithm has two options: 56-bit Data Encryption Standard-cipher block chaining (DES-CBC), and 168-bit DES. The hash algorithm has two options: Secure Hash Algorithm-1 (SHA-1), and Message Digest 5 (MD5). MD5 has a smaller digest and is considered to be slightly faster than SHA1. There has been a demonstrated successful (but extremely difficult) attack against MD5; however, the hashed message authentication code (HMAC) variant used by IKE prevents this attack. The authentication method has three options: Rivet, Shamir, and Adelman (RSA) signatures, RSA encrypted nonces, and pre-shared keys. —

7-50

RSA signatures provide nonrepudiation for the IKE negotiation (you can prove to a third party after the fact that you did indeed have an IKE negotiation with the remote peer). RSA signatures allow the use of a CA. Using a CA can dramatically improve the manageability and scalability of your IPSec network. Additionally, RSA signature-based authentication uses only two public key operations, whereas RAS encryption uses four public key operations, making it costlier in terms of overall performance.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

—

RSA encrypted nonces provide repudiation for the IKE negotiation (you cannot prove to a third party that you had an IKE negotiation with the remote peer). RSA encrypted nonces require that peers possess each 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}

Copyright

1

Specifies the 768-bit DH group.

2

Specifies the 1024-bit DH group.

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-51

The syntax for the lifetime command is as follows: lifetime seconds seconds

7-52

Cisco SAFE Implementation 1.1

Number of seconds that each SA should exist before expiring. Use an integer from 60 to 86,400 seconds.

Copyright

2003, Cisco Systems, Inc.

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

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»®±«¬»®ø½º¹ó½®§°¬±ó¬®¿²-÷ý © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-46

Complete the following steps at each peer that uses pre-shared keys in an IKE policy to configure pre-shared keys: Set the ISAKMP identity of each peer. Each 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.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-53

The syntax for the crypto isakmp key command is as follows: crypto isakmp key keystring address peer-address [mask] keystring

Specifies the pre-shared key. Use any combination of alphanumeric characters up to 128 bytes. This pre-shared key must be identical at both peers.

address

Use this keyword if the remote peer ISAKMP identity was set with its IP address.

peer-address

Specifies the IP address of the remote peer.

mask

(Optional.) Specifies the subnet address of the remote peer. (The argument can be used only if the remote peer ISAKMP identity was set with its IP address.)

The syntax for the crypto ipsec transform-set command is as follows: crypto ipsec transform-set transform-set-name transform1 [transform2 [transform3]]

7-54

transform-set-name

Specifies the name of the transform set to create (or modify).

transform1 transform2 transform3

Specifies up to three "transforms." These transforms define the IPSec security protocols and algorithms.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate 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

®±«¬»®ø½±²º·¹÷ý ½®§°¬± ³¿° ³§³¿° ïð ·°-»½ó·-¿µ³° ®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-47

After you define a transform set, you are put into the crypto transform configuration mode. While in this mode you can change the mode to either tunnel or transport. This change applies only to the transform set just defined. If the traffic to be protected has the same IP address as the IPSec peers and transport mode is specified, during negotiation the router requests transport mode but accepts either transport or tunnel mode. If tunnel mode is specified, the router requests tunnel mode and accepts only tunnel mode. If you do not change the mode when you first define the transform set, but later decide you want to change the mode for the transform set, you must re-enter the transform set (specifying the transform name and all its transforms) and then change the mode. If you use this command to change the mode, the change only affects the negotiation of subsequent IPSec SAs via crypto map entries, which specify this transform set. (If you want the new settings to take effect sooner, you can clear all or part of the SA database.) Crypto map entries created for IPSec pull together the various parts used to set up IPSec SAs including the following: Which traffic should be protected by IPSec (per a crypto ACL) The granularity of the flow to be protected by a set of SAs Where IPSec-protected traffic should be sent (who the remote IPSec peer is) The local address to be used for the IPSec traffic

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-55

What IPSec security should be applied to this traffic (selecting from a list of one or more transform sets) Whether SAs are manually established or are established via IKE Other parameters that might be necessary to define an IPSec SA The syntax for the mode command is as follows: mode [tunnel | transport] tunnel | transport

(Optional.) Specifies the mode for a transform set: either tunnel or transport mode. If neither tunnel nor transport is specified, the default (tunnel mode) is assigned.

The syntax for the crypto map command is as follows: crypto map map-name seq-num ipsec-isakmp [dynamic dynamic-map-name] [discover]

7-56

map-name

The name that identifies the crypto map set. This is the name assigned when the crypto map was created.

seq-num

The number you assign to the crypto map entry.

ipsec-isakmp

Indicates that IKE will be used to establish the IPSec SAs for protecting the traffic specified by this crypto map entry.

dynamic

(Optional.) Specifies that this crypto map entry is to reference a preexisting dynamic crypto map. Dynamic crypto maps are policy templates used in processing negotiation requests from a peer IPSec device. If you use this keyword, none of the crypto map configuration commands will be available.

dynamic-map-name

(Optional.) Specifies the name of the dynamic crypto map set that should be used as the policy template.

discover

(Optional.) Enables peer discovery. By default, peer discovery is not enabled.

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Terminate IPSec—Identify an ACL and Specify Transform Sets Router (config-crypto-map) #

³¿¬½¸ ¿¼¼®»-- ¿½½»--ó´·-¬ó·¼ • Identifies the extended ACL

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

Router (config-crypto-map) #

-»¬ ¬®¿²-º±®³ó-»¬ ¬®¿²-º±®³ó-»¬ó²¿³» Ŭ®¿²-º±®³ó-»¬ó²¿³»îòòò¬®¿²-º±®³ó-»¬ó²¿³»êà • Specifies which transform sets can be used with the crypto map entry

®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-48

The match address command is required for all static crypto map entries. If you are defining a dynamic crypto map entry (with the crypto dynamic-map command), this command is not required but is strongly recommended. Use this command to assign an extended ACL to a crypto map entry. You also need to define this ACL using the access-list or ip access-list extended commands. The extended ACL specified with this command is used by IPSec to determine which traffic should be protected by crypto and which traffic does not need crypto protection. (Traffic that is permitted by the ACL is protected. Traffic that is denied by the ACL is not be protected in the context of the corresponding crypto map entry.)

Note

The crypto ACL is not used to determine whether to permit or deny traffic through the interface. An ACL applied directly to the interface makes that determination.

The crypto ACL specified by the match address command is used when evaluating both inbound and outbound traffic. Outbound traffic is evaluated against the crypto ACLs specified by the 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.)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-57

In the case of IPSec, the ACL is also used to identify the flow for which the IPSec SAs are established. In the outbound case, the permit entry is used as the data flow identity (in general), while in the inbound case the data flow identity specified by the peer must be “permitted” by the crypto ACL. The set transform-set command is required for all static and dynamic crypto map entries. Use this command to specify which transform sets to include in a crypto map entry. For an ipsec-isakmp crypto map entry, you can list multiple transform sets with the set transform-set command. List the higher priority transform sets first. If the local router initiates the negotiation, the transform sets are presented to the peer in the order specified in the crypto map entry. If the peer initiates the negotiation, the local router accepts the first transform set that matches one of the transform sets specified in the crypto map entry. The first matching transform set that is found at both peers is used for the SA. If no match is found, IPSec does not establish an SA. The traffic is dropped because there is no SA to protect the traffic. For an ipsec-manual crypto map entry, you can specify only one transform set. If the transform set does not match the transform set at the remote 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]

7-58

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

transform-set-name

Name of the transform set. For an ipsec-manual crypto map entry, you can specify only one transform set. For an ipsec-isakmp or dynamic crypto map entry, you can specify up to 6 transform sets.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-59

Terminate IPSec—Specify an IPSec Peer and Apply a Crypto Map to the Interface Router (config-crypto-map) #

-»¬ °»»® ·°ó¿¼¼®»-• Specifies the IPSec peer

®±«¬»®ø½±²º·¹ó½®§°¬±ó³¿°÷ý -»¬ °»»® ïçîòïêèòïòî

Router (config-if) #

½®§°¬± ³¿° ³¿°ó²¿³» • Applies a previously defined crypto map set to an interface

®±«¬»®ø½±²º·¹ó·º÷ý ½®§°¬± ³¿° ³§³¿° © 2003, Cisco Systems, Inc. All rights reserved.

CSI 1.1—7-49

Use the set peer command to specify an IPSec peer for a crypto map. This command is required for all static crypto maps. If you are defining a dynamic crypto map (with the crypto dynamic-map command), this command is not required, and in most cases is not used (because, in general, the peer is unknown). For ipsec-isakmp crypto map entries, you can specify multiple peers by repeating this command. The peer that packets are actually sent to is determined by the last peer that the router heard from (received either traffic or a negotiation request from) for a given data flow. If the attempt fails with the first peer, IKE tries the next peer on the crypto map list. For ipsec-manual crypto entries, you can specify only one IPSec peer per crypto map. If you want to change the peer, you must first delete the old peer and then specify the new peer. You can specify the remote IPSec peer by its hostname only if the hostname is mapped to the 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.

7-60

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

The syntax for the set peer command is as follows: set peer {hostname | ip-address} hostname

Specifies the IPSec peer by its hostname. This is the peer's hostname concatenated with its domain name (for example, myhost.example.com).

ip-address

Specifies the IPSec peer by its IP address.

The syntax for the crypto map command is as follows: crypto map map-name map-name

Name that identifies the crypto map set. This is the name assigned when the crypto map was created. When the no form of the command is used, this argument is optional. Any value supplied for the argument is ignored.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation

7-61

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

Summary

• The following are the key devices in a remote user network: – Broadband access devices – Firewalls with VPN support – Layer 2 hubs – Personal firewall software – Routers with firewall and VPN support – VPN Software Clients – VPN Hardware Clients

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

7-62

Cisco SAFE Implementation 1.1

CSI 1.1—7-51

Copyright

2003, Cisco Systems, Inc.

Summary (cont.) • The following threats can be expected: – Unauthorized access – Network reconnaissance – Virus and Trojan horse attacks – IP spoofing – Man-in-the-middle attacks • Four basic options are available to mitigate threats: one software-based and three hardware-based options.

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

Copyright

2003, Cisco Systems, Inc.

CSI 1.1—7-52

Remote User Network Implementation

7-63

Lab Exercise—Remote User Network Design Implementation Complete the following lab exercise to practice what you learned in this chapter. The lab exercise has the following sub-sections: Section 1—Site-to-site VPN configuration Section 2—Client-to-LAN VPN configuration Section 3—Perimeter router configuration Section 4—Network device management (Optional.)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-1

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

Error! Not a valid link.

Section 1—Site-to-Site VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives In this lab exercise you will configure a site-to-site VPN by completing the following tasks: Prepare for configuring IPSec pre-shared keys on the PIX Firewall. Configure IKE parameters on the PIX Firewall. Configure IPSec parameters on the PIX Firewall. Configure routing and IKE parameters on the branch office router. Configure IPSec parameters on the branch office router. Configure no NAT in the VPN tunnel. Verify the IPSec configuration.

Network Security Policy XYZ Company wants to use the branch office Cisco IOS Router and the corporate Cisco PIX Firewall to create a virtual private network (VPN) over the Internet between the branch office site, and the internal corporate and Demilitarized Zone DMZ networks. The following are the objectives to be completed in this section: IPSec will be configured between the branch office router and the local PIX Firewall to use pre-shared keys. Branch office users will have access to the internal corporate and the DMZ network through the VPN tunnel. Corporate users will have access to the branch office network through the VPN tunnel. There will be no Network Address Translation (NAT) used in the VPN tunnel.

Lab 7-2

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Setup Before starting this lab exercise, set up your equipment as follows: Ensure that your PIX Firewall is turned on. Access the PIX 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: °·¨Ðø½±²º·¹÷ý -§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½

(where P = pod number)

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: °·¨Ðø½±²º·¹÷ý ·-¿µ³° »²¿¾´» ±«¬-·¼»

Step 2

(where P = pod number) Configure the Internet Security Association Key Management Protocol (ISAKMP) pre-shared key to point to the outside IP address of the branch office router. Use the default ISAKMP identity mode of address: °·¨Ðø½±²º·¹÷ý ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïéîòîêòîêòïðÐ ²»¬³¿-µ îëëòîëëòîëëòð

(where P = pod number) Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-3

Step 3

Create an IKE policy by completing the following sub-steps. Use the following parameter values: Policy priority 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: °·¨Ðø½±²º·¹÷ý ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìðð

Step 4

(where P = pod number) View all existing IKE policies: °·¨Ðø½±²º·¹÷ý -¸±© ·-¿µ³° °±´·½§

(where P = pod number)

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

Lab 7-4

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Peer network address—IP address of branch office network Access list name—NONAT_INSIDE Access list name—NONAT_PSS Protocol—Any Internet protocol °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòÐòð îëëòîëëòîëëòð ïðòîòÐòð îëëòîëëòîëëòð °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëòð ïðòîòÐòð îëëòîëëòîëëòð

Step 2

(where P = pod number) Configure NAT so that the addresses in the VPN tunnel are not translated for the internal corporate network: °·¨Ðø½±²º·¹÷ý ²¿¬ ø·²-·¼»÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ

Step 3

(where P = pod number) Configure NAT so that the addresses in the VPN tunnel are not translated for the public services segment server: °·¨Ðø½±²º·¹÷ý ²¿¬ øÐÍÍ÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ

Step 4

(where P = pod number) Configure an IPSec transform set (IKE phase two parameters). Use the following parameter values: Transform name—myset ESP protocols—3des Mode—tunnel °·¨Ðø½±²º·¹÷ý ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»-

Step 5

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-5

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. °·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬

Step 6

(where P = pod number) Apply the crypto map set to the outside interface: °·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼»

Step 7

(where P = pod number) Verify your crypto map configuration: °·¨Ðø½±²º·¹÷ý -¸±© ½®§°¬± ³¿°

Step 8

(where P = pod number) Save your configuration: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

Step 9

(where P = pod number) Verify your PIX Firewall configuration is similar to the following configuration for pix1: °·¨Ðý ©®·¬» ¬»®³·²¿´

Lab 7-6

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ·²¬ºì -»½«®·¬§î𠲿³»·º »¬¸»®²»¬ë ·²¬ºë -»½«®·¬§îë »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï ¼±³¿·²ó²¿³» °±¼ïò½±³ º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬» ²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ©©©ó°®·ª¿¬» ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòï𠻯 ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-7

·²¬»®º¿½» »¬¸»®²»¬ð ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± -¸«¬¼±©² ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ·²¬ºì ïëð𠳬« ·²¬ºë ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ·²¬ºì ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºì ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºë ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëòð ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì ²¿¬ ø·²-·¼»÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ ²¿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð 𠲿¬ øÐÍÍ÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòïòïð ïðòðòïòïï ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» Lab 7-8

Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» -§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½ ²± -§-±°¬ ®±«¬» ¼²¿¬ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ ï𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁ×ÒÍ×ÜÛ ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ îð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ î𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÐÍÍ ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼» ·-¿µ³° »²¿¾´» ±«¬-·¼» ·-¿µ³° µ»§ öööööööö ¿¼¼®»-- ïéîòîêòîêòïðï ²»¬³¿-µ îëëòîëëòîëëòð ·-¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ·-¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»·-¿µ³° °±´·½§ ï𠸿-¸ -¸¿ ·-¿µ³° °±´·½§ ïð ¹®±«° ï ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìð𠬻´²»¬ ¬·³»±«¬ ë --¸ ïðòðòïòì îëëòîëëòîëëòîëë ·²-·¼» --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æê缿ééï¿íïìðë¿ê¼è¼¾ºº¿º¼ç¿éº¾è¿¿ æ »²¼

Task 4—Configure Routing and IKE Parameters on the Branch Office Router Complete the following steps to configure IKE on the branch office router: Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-9

Step 1

Add a static route to the corporate internal networks: ¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïéîòïêòÐòð îëëòîëëòîëëòð ïçîòïêèòÐòî ¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòðòÐòð îëëòîëëòîëëòð ïçîòïêèòÐòî

Step 2

(where P = pod number) Add ACL entries to permit traffic between the internal corporate networks and the branch office network. Note

The order of the existing ACL must be modified to permit the following entries.

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

Step 3

(where P = pod number) Enable IKE and ISAKMP on the router: ¾®Ðø½±²º·¹÷ý ½®§°¬± ·-¿µ³° »²¿¾´»

Step 4

(where P = pod number) Configure the ISAKMP pre-shared key to point to the outside IP address of the PIX Firewall: ¾®Ðø½±²º·¹÷ý ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòÐòî

Step 5

(where P = pod number) Create an IKE policy by completing the following sub-steps. Use the following parameter values: Policy priority number—110 Encryption algorithm—3des Hash algorithm—sha Authentication method—pre-share Diffie-Hellman group identifier—1 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:

Lab 7-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¾®Ðø½±²º·¹ó·-¿µ³°÷ý ¸¿-¸ -¸¿

(where P = pod number) 4. Set authentication to use pre-shared keys: ¾®Ðø½±²º·¹ó·-¿µ³°÷ý ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®»

(where P = pod number) 5. Set the DH group: ¾®Ðø½±²º·¹ó·-¿µ³°÷ý ¹®±«° ï

(where P = pod number) 6. Set the IKE SA lifetime: ¾®Ðø½±²º·¹ó·-¿µ³°÷ý ´·º»¬·³» èêìðð

(where P = pod number) 7. Exit the config-isakmp mode: ¾®Ðø½±²º·¹ó·-¿µ³°÷ý »²¼

(where P = pod number) 8. Examine the crypto policy suite: ¾®Ðý -¸±© ½®§°¬± ·-¿µ³° °±´·½§

(where P = pod number)

Task 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: ¾®Ðý ½±²º·¹ ¬»®³·²¿´

Step 2

(where P = pod number) Define a transform set. Use the following parameters: Transform name—myset ESP protocols—3des Mode—tunnel ¾®Ðø½±²º·¹÷ý ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»¾®Ðø½º¹ó½®§°¬±ó¬®¿²-÷ý ³±¼» ¬«²²»´ ¾®Ðø½º¹ó½®§°¬±ó¬®¿²-÷ý »²¼

Step 3 Copyright

(where P = pod number) Save your configuration: 2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-11

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

Step 4

(where P = pod number) Verify your configuration: ¾®Ðý -¸±© ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬

(where P = pod number)

Configure Crypto ACLs Complete the following steps to configure the crypto ACLs. Create an ACL to select traffic to protect. The ACL should encrypt traffic between the VPN devices. Use the following parameters: Traffic permitted—all Peer address—The PIX Firewall’s outside interface ACL number—103 Protocol—Any Internet protocol Step 5

Ensure that you are in configuration mode: ¾®Ðø½±²º·¹÷ý ½±²º·¹ ¬»®³·²¿´

Step 6

(where P = pod number) Create the crypto ACL: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïéîòïêòÐòð ðòðòðòîëë ´±¹ ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòÐòð ðòðòðòîëë ´±¹

(where P = pod number)

Configure Crypto Maps Complete the following steps to configure a crypto map. Use the following parameters: Crypto map name—mymap Map number—10 Key exchange type—isakmp Peer—192.168.P.2 (where P = pod number) transform set—myself match address—103

Lab 7-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Set the name of the map, the map number, and the type of key exchange to be used:

Step 7

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

(where P = pod number) Specify the extended ACL to use with this map:

Step 8

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

(where P = pod number) Specify the transform set you defined earlier:

Step 9

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

Step 10

(where P = pod number) Assign the VPN peer using the hostname or IP address of the peer: ¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý -»¬ °»»® ïçîòïêèòÐòî

Step 11

(where P = pod number) Exit the crypto map configuration mode: ¾®Ðø½±²º·¹ó½®§°¬±ó³¿°÷ý »²¼

(where P = pod number) Step 12 Check your configuration: ¾®Ð ý -¸±© ½®§°¬± ³¿°

(where P = pod number)

Apply the Crypto Map to an Interface Complete the following steps to assign the crypto map to the appropriate router interface. Use the following parameters: Interface to 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: ¾®Ðø½±²º·¹ó·º÷ý ½®§°¬± ³¿° ³§³¿°

Step 15

(where P = pod number) Exit interface configuration mode: ¾®Ðø½±²º·¹ó·º÷ý »²¼

(where P = pod number) Step 16 Save the configuration: ¾®Ðý ©®·¬» ³»³±®§

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-13

Task 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: ¾®Ðý ½´»¿® ·° ²¿¬ ¬®¿²- ö

Step 2

(where P = pod number) Remove the previously configured NAT statement: ¾®Ðø½±²º·¹÷ý ²± ·° ²¿¬ ·²-·¼» -±«®½» -¬¿¬·½ ïðòîòÐòïï ïéîòîêòîêòïïÐ

Step 3

(where P = pod number) Create an ACL that defines traffic destined to the corporate network is not translated (no-NAT) and all other traffic is translated (NAT): ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïéîòïêòÐòð ðòðòðòîëë ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòÐòð ðòðòðòîëë

Step 4

(where P = pod number) Continue creating an ACL that defines traffic destined to the corporate network is not translated (no-NAT) and all other traffic is translated (NAT): ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðì °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ¿²§

Step 5

(where P = pod number) Configure the following route map to set up no NAT in the VPN tunnel: ¾®Ðø½±²º·¹÷ý ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ïð ¾®Ðø½±²º·¹ó®±«¬»ó³¿°÷ý ³¿¬½¸ ·° ¿¼¼®»-- ïðì ¾®Ðø½±²º·¹÷ý ·° ²¿¬ ·²-·¼» -±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» »¬¸»®²»¬ðñï ±ª»®´±¿¼

Step 6

(where P = pod number) Save the configuration to memory: ¾®Ðý ©®·¬» ³»³±®§

Step 7

(where P = pod number) Check your configuration against the following example configuration for branch office router 1: ¾®ïý ©®·¬» ¬»®³·²¿´ Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ

Lab 7-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü-½»ðü荒³²¹Ø©¾òÚÞÕÆÑÒݽÉÆëò »²¿¾´» °¿--©±®¼ é ïðìÜðððßðêïè ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðîïëïðìÛðÚðíðïíë ÿ ÿ ÿ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ÿ ÿ ÿ ÿ ÿ ÿ ½®§°¬± ·-¿µ³° °±´·½§ ïïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòïòî ÿ ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ³§³¿° ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïçîòïêèòïòî -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ³¿¬½¸ ¿¼¼®»-- ïðí ÿ Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-15

ÿ ÿ ÿ ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòîòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ½®§°¬± ³¿° ³§³¿° ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ²¿¬ ·²-·¼» -±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ Lab 7-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï ¼»²§

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðì ¼»²§

·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

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

·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

¿½½»--ó´·-¬ ïðì °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ²± ½¼° ®«² ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ï𠳿¬½¸ ·° ¿¼¼®»-- ïðì ÿ ÿ ÿ ¾¿²²»® »¨»½ ÂÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ðêðëðêíîìÚìï ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-17

»²¼

(where P = pod number)

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. °·¨Ðø½±²º·¹÷ý -¸±© ½®§°¬± ·°-»½ -¿

Step 3

Step 4

(where P = pod number) Clear the crypto SAs and complete Steps 1 and 2 on the branch office PC to verify connectivity from the branch office PC to the student PC, and to the public services segment server’s private address. Confirm your configuration on the branch office router: ¾®Ðý -¸±© ½®§°¬± ·°-»½ -¿

Step 5

(where P = pod number) Confirm that the branch office network addresses have not been translated: ¾®Ðý -¸±© ·° ²¿¬ ¬®¿²-

Step 6

(where P = pod number) Confirm that the appropriate ACL hit-counters are being incremented: ¾®Ðý -¸±© ¿½½»--ó´·-¬-

(where P = pod number)

Lab 7-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Section 2—Client-to-LAN VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives In this lab exercise, complete the following tasks to enable remote access via VPN: Configure the Cisco VPN Client. Reset the Concentrator via CLI. Configure the Concentrator via CLI. Configure the PIX Firewall. Configure the VPN Concentrator using Quick Configuration via the web interface. Configure the VPN Concentrator via the web interface. Configure the branch office router. Test and verify the IPSec configuration.

Network Security Policy In this lab exercise, you will configure the perimeter router, the Cisco VPN Concentrator, and other managed devices according to the following VPN security policy: A VPN tunnel will secure communication between the Cisco VPN Client PC and the Concentrator. The private interface of the Concentrator is connected to an interface of the PIX Firewall. Traffic is inspected by the PIX Firewall on the network attached to the Concentrator. The VPN Client PC must be able to access the corporate internal network. The VPN Client PC must be able to access the branch office network through the VPN tunnel between the corporate and branch office networks.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-19

Setup Before starting this lab exercise, set up your equipment as follows: Ensure that your Concentrator is turned on. Access the perimeter 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.

Lab 7-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 12

Select Properties.

Step 13

Select the General tab, in the Properties window. The properties for studentP window opens. The following items should be checked on a Windows system: IPSec through NAT mode should be allowed. The Peer Response Timeout should be 90. Allow local LAN access to be checked.

Note Step 14

Split Tunneling should not be allowed in a production environment.

Select the Authentication tab and verify that the group name spelling is correct. (It is case sensitive.)

Note

If needed, you can edit the Group Password here in the Authentication tab.

Step 15

Select the Connections tab. Leave the fields blank.

Step 16

Click OK.

Step 17

Close the VPN Client window by clicking the Close button.

Task 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 Step 1

Check with your instructor to see if this needs to be done.

You are prompted for a login. You may have to press Enter to get a login prompt. Enter the login name and password as follows: 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: ï÷ ݱ²º·¹«®¿¬·±² î÷ ß¼³·²·-¬®¿¬·±² í÷ Ó±²·¬±®·²¹ ì÷ Í¿ª» ݸ¿²¹»- ¬± ݱ²º·¹ Ú·´» Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-21

ë÷ Ø»´° ײº±®³¿¬·±² ê÷ Û¨·¬ Ó¿·² óâ Step 2

Reboot the system by entering the following commands: Ó¿·² óâ î øß¼³·²·-¬®¿¬·±²÷ ß¼³·² óâ í øͧ-¬»³ λ¾±±¬÷ ß¼³·² óâ î øͽ¸»¼«´» λ¾±±¬÷ ß¼³·² óâ í øλ¾±±¬ ×¹²±®·²¹ ݱ²º·¹«®¿¬·±² Ú·´»÷ ß¼³·² óâ î øλ¾±±¬ ²±©÷

The system reboots at this point. Reboot takes several minutes. Step 3

Proceed to Task 3 when the reboot is complete and you get a login prompt.

Note

Do not close the console window. The reboot will take several minutes to reload the default configuration to online memory.

Task 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 Step 1

You may have to press Enter several times to get a login prompt.

Log into the console by entering the login name and password as follows: 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

Step 3

A Concentrator received from the factory presents a slightly different order of prompts than one that was rebooted to factory defaults.

Enter the IP address for Ethernet 1 (Private): Ï«·½µ Û¬¸»®²»¬ ïóâ Åðòðòðòðà ïéîòïèòÐòë

Step 4

(where P = pod number) Enter the subnet mask for Ethernet 1:

Lab 7-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Ï«·½µ Û¬¸»®²»¬ ïóâ Åîëëòðòðòðà îëëòîëëòîëëòð Ï«·½µ Û¬¸»®²»¬ ïóâ Å í à í øïðñïðð Ó¾°- ¿«¬± ¼»¬»½¬÷ Ï«·½µ Û¬¸»®²»¬ ïóâ Å ï à ï øØ¿´ºñÚ«´´ñß«¬±÷ Step 5

Complete the rest of the prompts: Ï«·½µ óâ ¸ ø¸ ·- ¬¸» -¸±®¬ ½«¬ ½±³³¿²¼ ¬± ¬¸» ¬±° ´»ª»´ ³»²«ò÷ Ó¿·² óâ ì øÍ¿ª» ½¸¿²¹»- ¬± ¬¸» ½±²º·¹ º·´»ò÷ Ó¿·² óâ ê ø»¨·¬÷

Warning Step 6

If you do not exit, the CLI will take you through the Quick Configuration via the GUI instead.

Do not close the console window. Proceed to the next section.

Configure the Public LAN Interface Via CLI Complete the following steps via the console to configure the public Ethernet interface via the CLI: Step 7

Log in if you are not already logged in, by entering the login name and password as follows: 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: Ó¿·²óâ ï øݱ²º·¹«®¿¬·±²÷ ݱ²º·¹óâ î øͧ-¬»³ Ó¿²¿¹»³»²¬÷ ͧ-¬»³ óâ ì ø×Р᫬·²¹÷

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-23

᫬·²¹ óâ î øÜ»º¿«´¬ Ù¿¬»©¿§-÷ ᫬·²¹ óâ ï øÍ»¬ Ü»º¿«´¬ Ù¿¬»©¿§÷ ᫬·²¹ óâ ïçîòïêèòÐòïëð

(where P = pod number) ᫬·²¹ óâ î øÍ»¬ Ü»º¿«´¬ Ù¿¬»©¿§ Ó»¬®·½÷ ᫬·²¹ óâ Åïà ï øÍ»´»½¬ ¬¸» ¼»º¿«´¬ ±º ï÷ ᫬·²¹ óâ ¸ Ó¿·² óâ ì øÍ¿ª» ½¸¿²¹»- ¬± ݱ²º·¹ º·´»÷

Configure a Static Route to the Internal Network Complete the following steps via the CLI to configure a static route to the internal network: Step 10

Complete the following actions from the main menu to configure a static route: Ó¿·²óâ ï øݱ²º·¹«®¿¬·±²÷ ݱ²º·¹óâ î øͧ-¬»³ Ó¿²¿¹»³»²¬÷ ͧ-¬»³ óâ ì ø×Р᫬·²¹÷ ᫬·²¹ óâ ï øͬ¿¬·½ ®±«¬»-÷ ᫬·²¹ óâ ï øß¼¼ ͬ¿¬·½ ᫬»÷ ᫬·²¹ óâ ïðòðòÐòð øÒ»¬ ß¼¼®»--÷ ᫬·²¹ óâ îëëòîëëòîëëòð øÍ«¾²»¬ ³¿-µ÷ ᫬·²¹ óâ ï øÜ»-¬·²¿¬·±² ·- ᫬»®÷ ᫬·²¹ óâ ïéîòïèòÐòï ø᫬»® ß¼¼®»--÷

(where P = pod number) ᫬·²¹ óâ ï ø᫬» Ó»¬®·½÷ ᫬·²¹ óâ ¸ Ó¿·² óâ ì øÍ¿ª» ½¸¿²¹»- ¬± ݱ²º·¹ º·´»÷ Ó¿·² óâ ê øÛ¨·¬÷ Step 11

Exit the console access and proceed to the next lab steps.

Task 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: °·¨Ðø½±²º·¹÷ý ²¿³»·º »ì ®¿ª°² -»½«®·¬§éë

Step 3

(where P = pod number) Enable the Ethernet 4 interface for 100 Mbps Ethernet full duplex communication: °·¨Ðø½±²º·¹÷ý ·²¬»®º¿½» »ì ïð𺫴´

Step 4

(where P = pod number) Assign an IP address to the remote access VPN network interface: °·¨Ðø½±²º·¹÷ý ·° ¿¼¼®»-- ®¿ª°² ïéîòïèòÐòï îëëòîëëòîëëòð

Lab 7-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 5

(where P = pod number) Configure a static translation on the PIX Firewall between the internal network and the remote access VPN network: °·¨Ðø½±²º·¹÷ý -¬¿¬·½ ø·²-·¼»ô®¿ª°²÷ ïðòðòÐòð ïðòðòÐòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð

Step 6

(where P = pod number) Configure a static translation on the PIX Firewall between the public services segment network and the remote access VPN network: °·¨Ðø½±²º·¹÷ý -¬¿¬·½ ø®¿ª°²ô °--÷ ïðòðòøÐõîð÷òð ïðòðòøÐõîð÷òð ²»¬³¿-µ îëëòîëëòîëëòð ð ð

Step 7

(where P = pod number) Add an ACL named “RAVPN” to the PIX Firewall to allow Concentrator traffic to the internal network at 10.0.P.0: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ¿²§

Step 8

(where P = pod number) Apply the ACL to the ravpn interface of the PIX Firewall: °·¨Ðø½±²º·¹÷ý ¿½½»--ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°²

Step 9

(where P = pod number) Configure a static route on the PIX Firewall to route outbound traffic to the VPN Client: °·¨Ðø½±²º·¹÷ý ®±«¬» ®¿ª°² ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ïéîòïèòÐòë ï

(where P = pod number) Step 10 Configure the PIX Firewall to allow the remote VPN users to access the public services segment, Internet, and branch office networks: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ °»®³·¬ ·° ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ïðòîòÐòð îëëòîëëòîëëòð °·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ í𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÎßÊÐÒ °·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ °»»® ïéîòîêòîêòïðÐ °·¨Ðø½±²º·¹÷ý ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ °·¨Ðø½±²º·¹÷ý ²¿¬ ø®¿ª°²÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ °·¨Ðø½±²º·¹÷ý ²¿¬ ø®¿ª°²÷ î ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ð ð

(where P = pod number) Step 11 Save your configuration and compare it to the following sample configuration from pix1: °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§ °·¨ïø½±²º·¹÷ý ©®·¬» ¬»®³·²¿´ æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ®¿ª°² -»½«®·¬§éë

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-25

²¿³»·º »¬¸»®²»¬ë ·²¬ºë -»½«®·¬§îë »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï ¼±³¿·²ó²¿³» °±¼ïò½±³ º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬» ²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ©©©ó°®·ª¿¬» ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòï𠻯 ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± -¸«¬¼±©² Lab 7-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ®¿ª°² ïëð𠳬« ·²¬ºë ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ®¿ª°² ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ®¿ª°² ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºë ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëòð ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì ²¿¬ ø·²-·¼»÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ ²¿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð 𠲿¬ øÐÍÍ÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ ²¿¬ ø®¿ª°²÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ ²¿¬ ø®¿ª°²÷ î ïðòðòîïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòïòïð ïðòðòïòïï ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ ø·²-·¼»ô®¿ª°²÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø®¿ª°²ôÐÍÍ÷ ïðòðòîïòð ïðòðòîïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°² Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-27

®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ®±«¬» ®¿ª°² ïðòðòîïòð îëëòîëëòîëëòð ïéîòïèòïòë ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» -§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½ ²± -§-±°¬ ®±«¬» ¼²¿¬ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ ï𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁ×ÒÍ×ÜÛ ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ îð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ î𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÐÍÍ ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ íð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ í𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÎßÊÐÒ ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼» ·-¿µ³° »²¿¾´» ±«¬-·¼» ·-¿µ³° µ»§ öööööööö ¿¼¼®»-- ïéîòîêòîêòïðï ²»¬³¿-µ îëëòîëëòîëëòð ·-¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ·-¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»·-¿µ³° °±´·½§ ï𠸿-¸ -¸¿ ·-¿µ³° °±´·½§ ïð ¹®±«° ï ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìð𠬻´²»¬ ¬·³»±«¬ ë --¸ ïðòðòïòì îëëòîëëòîëëòîëë ·²-·¼» --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æç½è»î¼¿¿»¼èêðï½»éè¿ë½¼è翽íííè¾¼ æ »²¼

Lab 7-28 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

(where P = pod number)

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-29

Default Gateway—192.168.P.150 (where P = pod number) Step 9

Click Continue. The Protocol screen is displayed.

Configuration>Quick>Protocols Complete the following steps to enable the tunneling protocols for this lab exercise: Step 10

Configure the following Protocol parameter values: 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>Authentication Complete the following steps to identify what type of authentication server to use for this lab exercise: Step 14

Choose Internal Server from the Select Server type drop-down menu.

Step 15

Click Continue. The User Database screen is displayed.

Configuration>Quick>User Database Complete the following steps to configure the user parameters for this lab exercise: Step 16

Enter the following User Database parameter values: Username—studentP (where P = pod number)

Lab 7-30 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Group Name—podP_group (where P = pod number) 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>Done You have completed the quick configuration steps. Complete the following steps to save the quick configuration: Step 22

Click the Save Needed icon to save your configuration.

Step 23

Click OK in the Save Successful window.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-31

Task 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

Step 3

If Cisco VPN Client-3DES-MD5 is not at the top of the Active Proposals list, click the Move Up button to place it there. If it is already there, proceed on to Step 3.

Click the Save Needed icon to save the configuration if needed.

Configuration>System>IP Routing>Default Gateways Complete the following steps to define the 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: Default Gateway—192.168.P.150 (where P = pod number) 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.

Lab 7-32 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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 14

Click Add. The Manager address is displayed in the Manager Workstations list.

Step 15

Click Add to add student users accessing the concentrator from the VPN network. The Add a manager screen is displayed.

Step 16

Enter the following Manager Address parameter values so only this IP range can access the Concentrator with User rights: IP Address—10.0.(P+20).0 (where P = pod number) IP Mask—255.255.255.240 Access Group—Group 5 (User)

Step 17

Click Add. The Manager address is displayed in the Manager Workstations list.

Step 18

Click the Save Needed icon to save the configuration.

Disable Insecure Management Protocols Complete the following steps to disable insecure management protocols: Step 19

Choose Configuration>System>Management Protocols. The list of management protocols is displayed.

Step 20

Select FTP. The Configure the FTP server screen is displayed.

Step 21

Disable FTP and click Apply.

Step 22

Select TFTP. The Configure the TFTP server screen is displayed.

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-33

Step 23

Disable TFTP and click Apply.

Step 24

Select Telnet. The Configure the Telnet server screen is displayed.

Step 25

Disable Telnet by selecting the check box next to Telnet.

Step 26

Enable Telnet/SSL by selecting the check box next to Telnet/SSL.

Step 27

Click Apply.

Step 28

Select SNMP. The Configure the SNMP server screen is displayed.

Step 29

Disable SNMP and click Apply.

Step 30

Select HTTP/HTTPS. The Configure the HTTP server screen is displayed.

Step 31

Disable HTTP by selecting the check box next to HTTP.

Step 32

Enable HTTPS by selecting the check box next to HTTPS.

Step 33

Click Apply. The HTTP server is automatically restarted to disable HTTP access. Note

Your session is terminated and requires you to log in again.

Configure Split Tunneling This section is only necessary in a remote lab environment. Complete the following steps to configure split tunneling to allow Netmeeting access to the Cisco VPN Client throughout the VPN configuration and testing: Step 34

Choose Configuration>Policy Management>Traffic Management>Network Lists.

Step 35

Click the Add button.

Step 36

Enter Student PC in the List Name field.

Step 37

Enter 192.168.P.10/0.0.0.0 in the Network List field. (where P = pod number)

Step 38

Click the Add button.

Step 39

Choose Configuration>User Management>Groups.

Step 40

Select podP_group in the Group Name field. (where P = pod number)

Step 41

Click the Modify Group button.

Step 42

Select the Mode Config tab.

Step 43

Select the Allow the networks in the list to bypass tunnel check box.

Step 44

Click Apply.

Step 45

Choose Student PC from the drop-down menu next to the Split Tunneling Network List Attribute.

Step 46

Click Apply.

Step 47

Click the Save Needed icon to save the configuration.

Lab 7-34 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

Step 2

(where P = pod number) Add an ACL entry to define that traffic from the branch office network to the Concentrator network is encrypted: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòøÐõîð÷òð ðòðòðòîëë

Step 3

(where P = pod number) Add an ACL to define that traffic from the branch office network is not translated (no-NAT) when going to the Concentrator network: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðì ¼»²§ ·° ïðòîòÐòð ðòðòðòîëë ïðòðòøÐõîð÷òð ðòðòðòîëë

Step 4

(where P = pod number) Add a static route to the VPN Client pool network: ¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòðòøÐõîð÷òð îëëòîëëòîëëòð ïçîòïêèòÐòî

Step 5

(where P = pod number) Save your configuration and compare your configuration to the following sample configuration from br1: ¾®Ðý ©®·¬» ³»³±®§ ¾®ïý ©®·¬» ¬»®³·²¿´ Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü-½»ðü荒³²¹Ø©¾òÚÞÕÆÑÒݽÉÆëò »²¿¾´» °¿--©±®¼ é ïðìÜðððßðêïè ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðîïëïðìÛðÚðíðïíë ÿ ÿ

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-35

ÿ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ÿ ÿ ÿ ÿ ÿ ÿ ½®§°¬± ·-¿µ³° °±´·½§ ïïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòïòî ÿ ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ³§³¿° ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïçîòïêèòïòî -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ³¿¬½¸ ¿¼¼®»-- ïðí ÿ ÿ ÿ ÿ ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòîòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² Lab 7-36 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ½®§°¬± ³¿° ³§³¿° ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ²¿¬ ·²-·¼» -±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼ ·° ½´¿--´»-·° ®±«¬» ïðòðòîïòð îëëòîëëòîëëòð ïçîòïêèòïòî ·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòîïòð ðòðòðòîëë ¿²§ Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-37

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

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðì ¼»²§

·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

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

·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

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

·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë

¿½½»--ó´·-¬ ïðì °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ²± ½¼° ®«² ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ï𠳿¬½¸ ·° ¿¼¼®»-- ïðì ÿ ÿ ÿ ¾¿²²»® »¨»½ ÂÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ðêðëðêíîìÚìï ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

(where P = pod number)

Lab 7-38 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-39

Student PC—10.0.P.11 (where P = pod number) Step 5

Verify that the VPN Client system can access the following web servers: Corporate public services segment server—172.16.P.50 (where P = pod number) Student PC—10.0.P.11 (where P = pod number) Branch office PC—10.2.P.11 (where P = pod number)

Step 6

Verify that the student 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) Branch office PC—10.2.P.11 (where P = pod number)

Lab 7-40 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Section 3—Perimeter Router Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives In this lab exercise you will complete the following tasks: Secure the perimeter router network services. Configure the PIX Firewall to allow management services. Secure management access to the perimeter router. Configure the perimeter router to only allow IPSec traffic to the PIX Firewall and Concentrator. Test and verify the perimeter router configuration.

Network Security Policy You will implement this network security policy in this lab exercise: Secure the perimeter router network services: —

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

—

Enforce password encryption to protect device passwords.

—

Disable unnecessary network services.

Log perimeter router events: —

Send perimeter router Syslog output to the Student PC.

—

Log informational events on the perimeter router to the Syslog server.

—

Set accurate time-stamping for log and debug messages.

Control administrator access to the perimeter router to prevent unauthorized access:

Copyright

—

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

—

Allow Telnet to the perimeter router only from the student PC.

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-41

—

Authenticate Telnet sessions with usernames and passwords entered into the perimeter router’s local security database.

—

The administrator attempts to log into the Syslog server.

Setup You should not have to configure any routing or addressing of interfaces on lab equipment in this lab exercise. Before starting this lab exercise, set up your equipment so that you can do the following from the Student PC: Ping the perimeter 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: ®Ðø½±²º·¹÷ý ¾¿²²»® ´±¹·² ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÿ ®Ðø½±²º·¹÷ý ¾¿²²»® »¨»½ ÿÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÿ

Step 2

(where P = pod number) Enable password encryption and assign a secret enable password to protect the router’s passwords: ®Ðø½±²º·¹÷ý -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ®Ðø½±²º·¹÷ý »²¿¾´» -»½®»¬ -»½®»¬

Step 3

(where P = pod number) Disable unnecessary network and router services to limit the exposure to direct attacks against the router: ®Ðø½±²º·¹÷ý ²± ·° -±«®½»ó®±«¬» ®Ðø½±²º·¹÷ý ²± ½¼° ®«² ®Ðø½±²º·¹÷ý ²± -»®ª·½» º·²¹»® ®Ðø½±²º·¹÷ý ²± -»®ª·½» ¬½°ó-³¿´´ó-»®ª»®®Ðø½±²º·¹÷ý ²± -»®ª·½» «¼°ó-³¿´´ó-»®ª»®®Ðø½±²º·¹÷ý ²± ·° ¸¬¬° -»®ª»® ®Ðø½±²º·¹÷ý ²± ·° ¾±±¬° -»®ª»® ®Ðø½±²º·¹÷ý ²± ·° ¼±³¿·²ó´±±µ«° ®Ðø½±²º·¹÷ý ²± ·° ®½³¼ ®-¸ó»²¿¾´» ®Ðø½±²º·¹÷ý ²± ·° ®½³¼ ®½°ó»²¿¾´»

Note

Interface configuration commands must be done on each router interface.

®Ðø½±²º·¹ó·º÷ý ²± ·° °®±¨§ó¿®° Lab 7-42 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Step 4

(where P = pod number) Enable logging to a Syslog server to provide a method to monitor router events including attacks: ®Ðø½±²º·¹÷ý -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» ®Ðø½±²º·¹÷ý ´±¹¹·²¹ ±² ®Ðø½±²º·¹÷ý ´±¹¹·²¹ ïçîòïêèòÐòïð ®Ðø½±²º·¹÷ý ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´

(where P = pod number)

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

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

(where P = pod number)

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: ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ï °»®³·¬ ïçîòïêèòÐòïð ´±¹

Step 2

(where P = pod number) 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: ®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì ®Ðø½±²º·¹ó´·²»÷ý °¿--©±®¼ ½·-½± ®Ðø½±²º·¹ó´·²»÷ý ¿½½»--ó½´¿-- ï ·² ®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ë ®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-43

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

Step 3

(where P = pod number) Assign a password to the console line to prevent access by unauthorized users: ®Ðø½±²º·¹ó´·²»÷ý ´·²» ½±² ð ®Ðø½±²º·¹ó´·²»÷ý °¿--©±®¼ ½·-½± ®Ðø½±²º·¹ó´·²»÷ý »¨»½ó¬·³»±«¬ ë ®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ·²°«¬ ²±²» ®Ðø½±²º·¹ó´·²»÷ý ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ´±½¿´

Step 4

(where P = pod number) Create a local user account on the router that is used to log into the router: ®Ðø½±²º·¹÷ý «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ -¬«¼»²¬

Step 5

(where P = pod number) Enable the router feature to prevent CPU cycles from being misallocated by guarantying CPU time for system processes: ®Ðø½±²º·¹÷ý -½¸»¼«´»® ¿´´±½¿¬»

(where P = pod number)

Task 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: ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¸±-¬ ïéîòîêòîêòïðÐ ¸±-¬ ïçîòïêèòÐòî ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¸±-¬ ïéîòîêòîêòïðÐ ¸±-¬ ïçîòïêèòÐòî »¯ ·-¿µ³° ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ¸±-¬ ïéîòîêòîêòïðÐ ¸±-¬ ïçîòïêèòÐòî

Step 2

(where P = pod number) Add ACL entries to only allow IPSec traffic from VPN Clients to the Concentrator: ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¿²§ ¸±-¬ ïçîòïêèòÐòë ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¿²§ ¸±-¬ ïçîòïêèòÐòë »¯ ·-¿µ³° ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï ¼»²§ ·° ¿²§ ¸±-¬ ïçîòïêèòÐòë ®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ¿²§ ¿²§

Step 3

(where P = pod number) Apply the ACL to the perimeter router’s outside interface: ®Ðø½±²º·¹÷ý ·²¬»®º¿½» »ðñï ®Ðø½±²º·¹ó·º÷ý ·° ¿½½»--ó¹®±«° ïðï ·² ®Ðø½±²º·¹ó·º÷ý »²¼

Lab 7-44 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

(where P = pod number)

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: ½æĬ»´²»¬ ïçîòïêèòÐòïëð

(where P = pod number) Note

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

Step 4

Verify that the devices are sending Syslog messages to the student PC Syslog server.

Step 5

Verify that the perimeter router configuration is correct: ®Ðý ©®·¬» ¬»®³·²¿´ Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïüÖ«ºªüñÖÆè¯ëñ¹ßÒ¹ßÝÕݾÊë¾ë·ð »²¿¾´» °¿--©±®¼ é ðìëèðîïëðÝîÛ ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ïìðìðêïÛðèðïîìíÚ ÿ ³»³±®§ó-·¦» ·±³»³ ïë ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° º·²¹»® ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ÿ

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-45

·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïçîòïêèòïòïëð îëëòîëëòîëëòð ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòíðòïòî îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïéîòíðòðòð ²»¬©±®µ ïçîòïêèòïòð ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïçîòïêèòïòïð ¿½½»--ó´·-¬ ï °»®³·¬ ïçîòïêèòïòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî »¯ ·-¿µ³° ¿½½»--ó´·-¬ ïðï ¼»²§

·° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî

¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¿²§ ¸±-¬ ïçîòïêèòïòë ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¿²§ ¸±-¬ ïçîòïêèòïòë »¯ ·-¿µ³° ¿½½»--ó´·-¬ ïðï ¼»²§

·° ¿²§ ¸±-¬ ïçîòïêèòïòë

¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ¿²§ ¿²§ ²± ½¼° ®«² ÿ ÿ ¾¿²²»® »¨»½ ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ë ð °¿--©±®¼ é ïíðêïÛðïðèðí Lab 7-46 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ë ð °¿--©±®¼ é ðìëèðîïëðÝîÛ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

Step 6

(where P = pod number) Verify that the PIX Firewall configuration is correct: °·¨Ðý ©®·¬» ¬»®³·²¿´ æ Í¿ª»¼ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ®¿ª°² -»½«®·¬§éë ²¿³»·º »¬¸»®²»¬ë ·²¬ºë -»½«®·¬§îë »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï ¼±³¿·²ó²¿³» °±¼ïò½±³ º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬» ²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-47

¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ©©©ó°®·ª¿¬» ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòï𠻯 ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±-¬ ïçîòïêèòïòïë𠸱-¬ ïçîòïêèòïòï𠻯 -§-´±¹ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±-¬ ïçîòïêèòïòïë𠸱-¬ ïçîòïêèòïòï𠻯 ¬º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± -¸«¬¼±©² ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ®¿ª°² ïëð𠳬« ·²¬ºë ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ®¿ª°² ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ Lab 7-48 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ®¿ª°² ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºë ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëòð ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì ²¿¬ ø·²-·¼»÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ ²¿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð 𠲿¬ øÐÍÍ÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ ²¿¬ ø®¿ª°²÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ ²¿¬ ø®¿ª°²÷ î ïðòðòîïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòïòïð ïðòðòïòïï ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ ø®¿ª°²ôÐÍÍ÷ ïðòðòîïòð ïðòðòîïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ô®¿ª°²÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°² ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ®±«¬» ®¿ª°² ïðòðòîïòð îëëòîëëòîëëòð ïéîòïèòïòë ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» -§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½ ²± -§-±°¬ ®±«¬» ¼²¿¬

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-49

½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ ï𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁ×ÒÍ×ÜÛ ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ îð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ î𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÐÍÍ ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ íð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ í𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÎßÊÐÒ ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼» ·-¿µ³° »²¿¾´» ±«¬-·¼» ·-¿µ³° µ»§ öööööööö ¿¼¼®»-- ïéîòîêòîêòïðï ²»¬³¿-µ îëëòîëëòîëëòð ·-¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ·-¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»·-¿µ³° °±´·½§ ï𠸿-¸ -¸¿ ·-¿µ³° °±´·½§ ïð ¹®±«° ï ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìð𠬻´²»¬ ¬·³»±«¬ ë --¸ ïðòðòïòì îëëòîëëòîëëòîëë ·²-·¼» --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æïðëðëçíï¿ð½ïî¾¾íºêºí¾»¼¾½èìîî¿ë¼ æ »²¼

Step 7

(where P = pod number) Verify that the student PC can access the following via the web browser: Public services segment server—172.16.P.50 (where P = pod number) VPN Client PC—10.0.(P+20).17 (where P = pod number) Branch office PC—10.2.P.11 (where P = pod number)

Step 8

Verify that the branch office PC can access the following via the web browser: Public services segment server—172.16.P.50 (where P = pod number)

Lab 7-50 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Client PC—10.0.(P+20).17 (where P = pod number) Student PC—10.0.P.11 (where P = pod number) Step 9

Verify the VPN Client PC can access the following via the web browser: Public services segment server—172.16.P.50 (where P = pod number) Student PC—10.0.P.11 (where P = pod number) Branch office PC—10.2.P.11 (where P = pod number)

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-51

Section 4—Network Device Management (Optional.) Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives In this lab exercise, you will complete the following tasks: Configure AAA on the VPN 3000 Concentrator. Configure Syslog on the VPN 3000 Concentrator. Configure the PIX Firewall to secure management access via AAA. Configure the perimeter router to secure management access via AAA. Configure the branch router to secure management access via AAA and to centralize logging. Test centralized management of all network devices.

Network Security Policy In this lab exercise, you will configure the perimeter router, the Concentrator, and other managed devices according to the following VPN security policy: All devices must use Cisco Secure Access Control Server (ACS) for authentication, authorization, and accounting (AAA). Management should be performed in-band and securely.

Setup You should not have to configure any routing or addressing of interfaces on lab equipment in this lab exercise. Before starting this lab exercise, set up your equipment so that you can do the following from the Student PC: Ensure that your VPN Concentrator is turned on. Access the devices via the console ports (except the Concentrator).

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

Lab 7-52 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 2

Choose Administration>Access Rights>AAA Servers>Authentication from the menu.

Step 3

Click Add and enter the following information: Authentication 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: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ¬½° ¸±-¬ ïéîòïèòÐòë ¸±-¬ ïðòðòÐòï𠻯 ¬¿½¿½°·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·½³° ¸±-¬ ïéîòïèòÐòë ¸±-¬ ïðòðòÐòïð »½¸± °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-53

Step 6

Click Add. The Syslog server is listed in the Syslog Server group.

Step 7

Click the Save Needed icon to save your changes.

Step 8

Add an ACL entry to the PIX Firewall to allow traffic from the Concentrator to the Syslog server: °·¨Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ «¼° ¸±-¬ ïéîòïèòÐòë ¸±-¬ ïðòðòÐòïï »¯ -§-´±¹ °·¨Ðø½±²º·¹÷ý ©®·¬» ³»³±®§

(where P = pod number)

Task 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: °·¨ø½±²º·¹÷ý ¬»´²»¬ ïðòðòÐòïï îëëòîëëòîëëòîëë ·²-·¼»

(where P = pod number) Step 2

Define the AAA server parameters: °·¨ø½±²º·¹÷ ý ¿¿¿ó-»®ª»® ³§¬¿½¿½- °®±¬±½±´ ¬¿½¿½-õ °·¨ø½±²º·¹÷ ý ¿¿¿ó-»®ª»® ³§¬¿½¿½- ø·²-·¼»÷ ¸±-¬ ïðòðòÐòïð ½·-½±-¿º»

(where P = pod number) Step 3

Enable AAA authentication for Telnet access to the PIX Firewall: °·¨ø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ¬»´²»¬ ½±²-±´» ³§¬¿½¿½-

(where P = pod number)

Task 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: °·¨ø½±²º·¹÷ý -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòÐòîð ïðòðòÐòïð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð

(where P = pod number) Step 2

Add an ACL entry to the PIX Firewall allowing traffic to the internal AAA server form the perimeter router. Note

The order of the existing INBOUND ACL must be modified to permit the management services. Be sure to bind the ACL to the outside interface.

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

(where P = pod number) Lab 7-54 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 3

Create a new AAA model and define the AAA server on the perimeter router: ®Ðø½±²º·¹÷ý ¿¿¿ ²»©ó³±¼»´ ®Ðø½±²º·¹÷ý ¬¿½¿½-ó-»®ª»® ¸±-¬ ïçîòïêèòÐòîð -·²¹´»ó½±²²»½¬·±² µ»§ ½·-½±-¿º»

(where P = pod number) Step 4

Enable AAA authentication and create the following authentication lists with the specified methods: 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. ®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ´±½¿´ »²¿¾´» ®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½- ´·²»

Step 5

(where P = pod number) Enable AAA authorization for exec sessions that required TACACS+ authentication: ®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ

Step 6

(where P = pod number) Enable AAA accounting for exec sessions authenticated via TACACS+: ®Ðø½±²º·¹÷ý ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ -¬¿®¬ó-¬±° ¹®±«° ¬¿½¿½-õ

Step 7

(where P = pod number) Enable AAA authentication for VTY sessions using the default authentication list: ®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì ®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ¼»º¿«´¬

Step 8

(where P = pod number) Enable AAA authentication for console access using the no_tacacs authentication list: ®Ðø½±²º·¹÷ý ´·²» ½±² ð ®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½®Ðø½±²º·¹ó´·²»÷ý »²¼ ®Ðý ©®·¬» ³»³±®§

Task 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. ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ¸±-¬ ïéîòîêòîêòïðÐ ïðòðòÐòð ðòðòðòîëë

(where P = pod number) Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-55

Step 2

Add an ACL entry that does not perform NAT on the branch office router’s IP address if the router communicates with devices on the corporate office internal network: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ïðì ¼»²§ ·° ¸±-¬ ïéîòîêòîêòïðÐ ïðòðòÐòð ðòðòðòîëë

(where P = pod number) Step 3

Add ACL entries to the PIX Firewall to define IPSec traffic to the branch office router: °·¨ø½±²º·¹÷ý ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòÐòð îëëòîëëòîëëò𠸱-¬ ïéîòîêòîêòïðÐ

(where P = pod number) Step 4

Add an ACL entry that allows the corporate office management server and workstation access to the router on the branch office router: ¾®Ðø½±²º·¹÷ý ¿½½»--ó´·-¬ ï °»®³·¬ ¸±-¬ ïðòðòÐòïï

(where P = pod number) Step 5

Create a new AAA model and define the AAA server: ¾®Ðø½±²º·¹÷ý ¿¿¿ ²»©ó³±¼»´ ¾®Ðø½±²º·¹÷ý ¬¿½¿½-ó-»®ª»® ¸±-¬ ïðòðòÐòïð -·²¹´»ó½±²²»½¬·±² µ»§ ½·-½±-¿º»

(where P = pod number) Step 6

Enable AAA authentication and create the following authentication lists with the specified methods: 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. ¾®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ´±½¿´ »²¿¾´» ¾®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½- ´·²»

(where P = pod number) Step 7

Enable AAA authorization for exec sessions that required TACACS+ authentication: ¾®Ðø½±²º·¹÷ý ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ

Step 8

Enable AAA accounting for exec sessions authenticated via TACACS+: ¾®Ðø½±²º·¹÷ý ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ -¬¿®¬ó-¬±° ¹®±«° ¬¿½¿½-õ

Step 9

Enable AAA authentication for VTY sessions using the default authentication list: ¾®Ðø½±²º·¹÷ý ´·²» ª¬§ ð ì ¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ¼»º¿«´¬

(where P = pod number) Step 10 Enable AAA authentication for console access using the no_tacacs authentication list: ¾®Ðø½±²º·¹÷ý ´·²» ½±² ð ¾®Ðø½±²º·¹ó´·²»÷ý ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½-

(where P = pod number) Lab 7-56 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 11

Add the corporate office Syslog server to the list of logging hosts: ¾®Ðø½±²º·¹÷ý ´±¹¹·²¹ ïðòðòÐòïï ¾®Ðø½±²º·¹÷ý »²¼ ¾®Ðý ©®·¬» ³»³±®§

(where P = pod number)

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

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-57

PIX firewall—10.0.P.11 (where P = pod number) Step 10

Verify the configuration files for the following devices: Perimeter router configuration Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» ¿¿¿ ²»©ó³±¼»´ ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ´±½¿´ »²¿¾´» ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½- ´·²» ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ -¬¿®¬ó-¬±° ¹®±«° ¬¿½¿½-õ »²¿¾´» -»½®»¬ ë üïüÖ«ºªüñÖÆè¯ëñ¹ßÒ¹ßÝÕݾÊë¾ë·ð »²¿¾´» °¿--©±®¼ é ðìëèðîïëðÝîÛ ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ïìðìðêïÛðèðïîìíÚ ÿ ³»³±®§ó-·¦» ·±³»³ ïë ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° º·²¹»® ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïçîòïêèòïòïëð îëëòîëëòîëëòð ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--

Lab 7-58 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

-¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòíðòïòî îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïéîòíðòðòð ²»¬©±®µ ïçîòïêèòïòð ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïçîòïêèòïòïð ¿½½»--ó´·-¬ ï °»®³·¬ ïçîòïêèòïòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî »¯ ·-¿µ³° ¿½½»--ó´·-¬ ïðï ¼»²§

·° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòî

¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¿²§ ¸±-¬ ïçîòïêèòïòë ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¿²§ ¸±-¬ ïçîòïêèòïòë »¯ ·-¿µ³° ¿½½»--ó´·-¬ ïðï ¼»²§

·° ¿²§ ¸±-¬ ïçîòïêèòïòë

¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ¿²§ ¿²§ ²± ½¼° ®«² ¬¿½¿½-ó-»®ª»® ¸±-¬ ïçîòïêèòïòîð -·²¹´»ó½±²²»½¬·±² µ»§ ½·-½±-¿º» ÿ ÿ ¾¿²²»® »¨»½ ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ¾¿²²»® ´±¹·² ÂÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ Ý·-½± ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ë ð °¿--©±®¼ é ïíðêïÛðïðèðí ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ë ð Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-59

°¿--©±®¼ é ðìëèðîïëðÝîÛ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

PIX Firewall configuration Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ®¿ª°² -»½«®·¬§éë ²¿³»·º »¬¸»®²»¬ë ·²¬ºë -»½«®·¬§îë »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï ¼±³¿·²ó²¿³» °±¼ïò½±³ º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»²¿³» ïéîòïêòïòëð ©©©ó°®·ª¿¬» ²¿³» ïçîòïêèòïòïï ©©©ó°«¾´·½ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ©©©ó°®·ª¿¬» ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòï𠻯 ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ©©©ó°«¾´·½ »¯ º¬°

Lab 7-60 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±-¬ ïçîòïêèòïòïë𠸱-¬ ïçîòïêèòïòï𠻯 -§-´±¹ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±-¬ ïçîòïêèòïòïë𠸱-¬ ïçîòïêèòïòï𠻯 ¬º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¸±-¬ ïçîòïêèòïòïë𠸱-¬ ïçîòïêèòïòî𠻯 ¬¿½¿½¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ °»®³·¬ ·° ïéîòïêòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëò𠸱-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ¬½° ¸±-¬ ïéîòïèòïòë ¸±-¬ ïðòðòïòï𠻯 ¬¿½¿½¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·½³° ¸±-¬ ïéîòïèòïòë ¸±-¬ ïðòðòïòïð »½¸± ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ «¼° ¸±-¬ ïéîòïèòïòë ¸±-¬ ïðòðòïòïï »¯ -§-´±¹ ¿½½»--ó´·-¬ ÎßÊÐÒ °»®³·¬ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ °»®³·¬ ·° ïðòðòîïòð îëëòîëëòîëëòð ïðòîòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ïð𺫴´ ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± -¸«¬¼±©² ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ®¿ª°² ïëð𠳬« ·²¬ºë ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ®¿ª°² ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºë ïîéòðòðòï îëëòîëëòîëëòîëë ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæðð Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-61

º¿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ®¿ª°² ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºë ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëòð ¹´±¾¿´ ø±«¬-·¼»÷ î ïçîòïêèòïòîîëóïçîòïêèòïòîëì ²»¬³¿-µ îëëòîëëòîëëòîîì ²¿¬ ø·²-·¼»÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁ×ÒÍ×ÜÛ ²¿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð 𠲿¬ øÐÍÍ÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÐÍÍ ²¿¬ ø®¿ª°²÷ ð ¿½½»--ó´·-¬ ÒÑÒßÌÁÎßÊÐÒ ²¿¬ ø®¿ª°²÷ î ïðòðòîïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ©©©ó°«¾´·½ ©©©ó°®·ª¿¬» ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòïòïð ïðòðòïòïï ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ ø®¿ª°²ôÐÍÍ÷ ïðòðòîïòð ïðòðòîïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ô±«¬-·¼»÷ ïçîòïêèòïòîð ïðòðòïòïð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ ø·²-·¼»ô®¿ª°²÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÎßÊÐÒ ·² ·²¬»®º¿½» ®¿ª°² ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ®±«¬» ®¿ª°² ïðòðòîïòð îëëòîëëòîëëòð ïéîòïèòïòë ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ¿¿¿ó-»®ª»® ³§¬¿½¿½- °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ³§¬¿½¿½- ø·²-·¼»÷ ¸±-¬ ïðòðòïòïð ½·-½±-¿º» ¬·³»±«¬ ïð ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ¬»´²»¬ ½±²-±´» ³§¬¿½¿½²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´»

Lab 7-62 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

-§-±°¬ ½±²²»½¬·±² °»®³·¬ó·°-»½ ²± -§-±°¬ ®±«¬» ¼²¿¬ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ ï𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁ×ÒÍ×ÜÛ ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ ïð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ îð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ î𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÐÍÍ ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ îð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ íð ·°-»½ó·-¿µ³° ½®§°¬± ³¿° ¾®¿²½¸ í𠳿¬½¸ ¿¼¼®»-- ÒÑÒßÌÁÎßÊÐÒ ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ °»»® ïéîòîêòîêòïðï ½®§°¬± ³¿° ¾®¿²½¸ íð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ½®§°¬± ³¿° ¾®¿²½¸ ·²¬»®º¿½» ±«¬-·¼» ·-¿µ³° »²¿¾´» ±«¬-·¼» ·-¿µ³° µ»§ öööööööö ¿¼¼®»-- ïéîòîêòîêòïðï ²»¬³¿-µ îëëòîëëòîëëòð ·-¿µ³° °±´·½§ ïð ¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ·-¿µ³° °±´·½§ ïð »²½®§°¬·±² í¼»·-¿µ³° °±´·½§ ï𠸿-¸ -¸¿ ·-¿µ³° °±´·½§ ïð ¹®±«° ï ·-¿µ³° °±´·½§ ïð ´·º»¬·³» èêìð𠬻´²»¬ ïðòðòïòïï îëëòîëëòîëëòîëë ·²-·¼» ¬»´²»¬ ¬·³»±«¬ ë --¸ ïðòðòïòì îëëòîëëòîëëòîëë ·²-·¼» --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æéçèïºðêêïç»çðï¼ç¿¼ì»½»êè¼ðï»»ìî¼æ »²¼

Branch office router configuration Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» ¿¿¿ ²»©ó³±¼»´ ¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ´±½¿´ »²¿¾´»

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-63

¿¿¿ ¿«¬¸»²¬·½¿¬·±² ´±¹·² ²±Á¬¿½¿½- ´·²» ¿¿¿ ¿«¬¸±®·¦¿¬·±² »¨»½ ¼»º¿«´¬ ¹®±«° ¬¿½¿½-õ ¿¿¿ ¿½½±«²¬·²¹ »¨»½ ¼»º¿«´¬ -¬¿®¬ó-¬±° ¹®±«° ¬¿½¿½-õ »²¿¾´» -»½®»¬ ë üïü-½»ðü荒³²¹Ø©¾òÚÞÕÆÑÒݽÉÆëò »²¿¾´» °¿--©±®¼ é ïðìÜðððßðêïè ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðîïëïðìÛðÚðíðïíë ÿ ÿ ÿ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ÿ ÿ ÿ ÿ ÿ ÿ ½®§°¬± ·-¿µ³° °±´·½§ ïïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòïòî ÿ ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ³§³¿° ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïçîòïêèòïòî -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ Lab 7-64 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

³¿¬½¸ ¿¼¼®»-- ïðí ÿ ÿ ÿ ÿ ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòîòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ¸¿´ºó¼«°´»¨ ²± ½¼° »²¿¾´» ½®§°¬± ³¿° ³§³¿° ÿ ®±«¬»® »·¹®° ï ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ²¿¬ ·²-·¼» -±«®½» ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ±ª»®´±¿¼ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ·° ®±«¬» ïðòðòîïòð îëëòîëëòîëëòð ïçîòïêèòïòî ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòî ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-65

´±¹¹·²¹ ïðòðòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòðòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòîïòð ðòðòðòîëë ¿²§ ¿½½»--ó´·-¬ ïðï ¼»²§

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

·° ïðòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ¸±-¬ ïéîòîêòîêòïðï ïðòðòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðì ¼»²§

·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë

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

·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë

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

·° ïðòîòïòð ðòðòðòîëë ïðòðòîïòð ðòðòðòîëë

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

·° ¸±-¬ ïéîòîêòîêòïðï ïðòðòïòð ðòðòðòîëë

¿½½»--ó´·-¬ ïðì °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ²± ½¼° ®«² ®±«¬»ó³¿° ²¿¬Á·²¬»®²»¬ °»®³·¬ ï𠳿¬½¸ ·° ¿¼¼®»-- ïðì ÿ ¬¿½¿½-ó-»®ª»® ¸±-¬ ïðòðòïòïð -·²¹´»ó½±²²»½¬·±² µ»§ ½·-½±-¿º» ÿ ÿ ¾¿²²»® »¨»½ ÂÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ¿«¬¸»²¬·½¿¬·±² ²±Á¬¿½¿½¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» Lab 7-66 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ðêðëðêíîìÚìï ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

Copyright

2003, Cisco Systems, Inc.

Remote User Network Implementation Lab 7-67

Lab 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-tosite 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. The lab exercise has the following sub-sections: PIX Firewall Initial Configuration DMZ IOS Router Initial Configuration Branch IOS Router Initial Configuration VPN Concentrator Initial Configuration PIX Firewall Configuration Branch Office IOS Router Configuration Site-to-Site VPN Configuration Client-to-LAN VPN Configuration Final Configurations

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-1

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

Lab Visual Objective VPN Client 172.26.26.P

Pod P (1–10) 172.26.26.0/24

.10P e0/1

.150

brP

Branch 10.3.P.0/24

RBB

.1 e0/0 .1

pub 10.3.P.5

cP Branch

priv 10.2.P.1 10.2.P.0/24

192.168.P.0/24

10.2.P.11 .2 e0 172.16.P.0/24

PSS WWW FTP

pP

.1 e4 172.18.P.0/24

.5 e0/1

.1 e2

DMZ drP

.1 e1

.1 e5

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

.50

Super Server WWW FTP

.10

10.0.P.0 /24

RTS

Student © 2003, Cisco Systems, Inc. All rights reserved.

Lab 8-2 Cisco SAFE Implementation 1.1

.100

10.0.P.11 CSI 1.1—8-1

Copyright

2003, Cisco Systems, Inc.

PIX Firewall Initial Configuration Complete the following lab exercise to configure the PIX Firewall.

Objectives In this lab exercise, you will configure the PIX Firewall to provide basic connectivity by completing the following tasks: Initial configuration of the PIX Firewall. Configure global addresses, NAT, routing and statics. Allow outbound traffic from internal networks. Test and verify the configuration.

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

Task 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.2 55.0

ethernet1

inside

100

10.0.P.1/255.255.255.0

ethernet2

PSS

50

172.16.P.1/255.255.25 5.0

ethernet4

DMZ1

70

172.18.P.1/255.255.25 5.0

ethernet5

DMZ2

80

172.19.P.1/255.255.25 5.0

hostname

pixP

(where P = pod number)

Task 2—Configure Global Addresses, NAT, Routing and Statics Complete the following steps to configure a global address pool, NAT, and routing: Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-3

Step 1

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

Global Pool ID

IP Address Range

Netmask

outside

1

192.168.P.33-222

255.255.255.0

(where P = pod number) Step 2

Configure the PIX Firewall to allow all inside hosts to use NAT for outbound access and apply it to the inside interface. For the inside host, use IP address 10.0.P.0 (where P = pod number).

Step 3

Assign the perimeter 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

(where P = pod number) Step 6

Confirm your entries by examining the nat and global configurations.

Step 7

Write the current configuration to Flash memory.

Task 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: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ÜÓÆï -»½«®·¬§éð

Lab 8-4 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²¿³»·º »¬¸»®²»¬ë ÜÓÆî -»½«®·¬§èð »²¿¾´» °¿--©±®¼ èΧîǶק¬éÎÎÈËîì »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ °¿¹»® ´·²»- îì ·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ÜÓÆï ïëð𠳬« ÜÓÆî ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæðð

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-5

º¿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆï ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆî ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëò𠲿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬ ¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æë¾ðï¿êîîéëí¿é¼¼çê»ì껿¾éìðîç»ðºð æ »²¼ ÅÑÕÃ

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)

Lab 8-6 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Student PC—10.0.P.11 (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.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-7

DMZ IOS Router Initial Configuration Complete the following lab exercise to configure the DMZ IOS router.

Objectives In this lab exercise, you will configure the DMZ IOS router to provide basic connectivity by completing the following tasks: Initial configuration of the DMZ IOS router. Test and verify the configuration.

Setup Before starting this lab exercise, make sure the DMZ IOS router is turned on and that your PC has console access to the DMZ IOS router.

Task 1—Initial Configuration of the DMZ IOS Router Complete a write erase on the DMZ IOS Router to use a default configuration. Step 1

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

Step 2

Assign the DMZ IOS Router the parameters as defined in the following tables and enable the interfaces: Ethernet0/0—172.19.P.5/255.255.255.0 (where P = pod number) Ethernet0/1—172.18.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

(where P = pod number)

Lab 8-8 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 4

Compare your configuration to the following: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» ²± -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¼®ï ÿ »²¿¾´» -»½®»¬ ë üïüÆéÆñüÝϼ¦±Ê¬-µ·»ºîµº×ÚܪÚÎï ÿ ³»³±®§ó-·¦» ·±³»³ ïë ·° -«¾²»¬ó¦»®± ÿ ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïéîòïçòïòë îëëòîëëòîëëòð ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòïèòïòë îëëòîëëòîëëòð ÿ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïéîòïçòïòï ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïéîòïçòïòï ·° ®±«¬» ïéîòîêòîêòð îëëòîëëòîëëòð ïéîòïèòïòï ·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïéîòïèòïòï ·° ®±«¬» ïðòíòïòð îëëòîëëòîëëòð ïéîòïèòïòï ²± ·° ¸¬¬° -»®ª»® ÿ ´·²» ½±² 𠬮¿²-°±®¬ ·²°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ÿ ²± -½¸»¼«´»® ¿´´±½¿¬»

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-9

»²¼

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

Lab 8-10 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Branch IOS Router Initial Configuration Complete the following lab exercise to configure the Branch IOS router.

Objectives In this lab exercise, you will configure the Branch IOS router to provide basic connectivity by completing the following tasks: Initial configuration of the Branch IOS router. Test and verify the configuration.

Setup Before starting this lab exercise, make sure the Branch IOS router is turned on and that your PC has console access to the Branch IOS router.

Task 1—Initial Configuration of the Branch IOS Router Step 1

Complete a write erase on the IOS Router to use a default configuration.

Step 2

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

Step 3

Assign the IOS Router the parameters as defined in the following tables and enable the interfaces: Ethernet0/0—10.3.P.1/255.255.255.0 (where P = pod number) 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: ¾®Ðø½±²º·¹÷ý ·° ®±«¬» ïðòîòÐòð îëëòîëëòîëëòð ïðòíòÐòë

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-11

(where P = pod number) Step 6

Configure the IOS Router to redistribute static routes into EIGRP: ¾®Ðø½±²º·¹÷ý ®±«¬»® »·¹®° ï ¾®Ðø½±²º·¹ó®±«¬»®÷ý ®»¼·-¬®·¾«¬» -¬¿¬·½

(where P = pod number) Step 7

Verify your routing table ensuring that the static route you entered is being redistributed into EIGRP.

Step 8

Compare your configuration to the following: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» ²± -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ÿ ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòíòïòï îëëòîëëòîëëòð ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ÿ ®±«¬»® »·¹®° ï ®»¼·-¬®·¾«¬» -¬¿¬·½ ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§

Lab 8-12 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïðòíòïòë ²± ·° ¸¬¬° -»®ª»® ÿ ´·²» ½±² 𠬮¿²-°±®¬ ·²°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ÿ ²± -½¸»¼«´»® ¿´´±½¿¬» »²¼

Task 2—Test and Verify the Configuration Step 1

Ping the following devices from the Student PC to ensure they are operational: 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)

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-13

VPN Concentrator Initial Configuration Complete the following lab exercise to configure the VPN Concentrator.

Objectives In this lab exercise, you will configure the VPN Concentrator to provide basic connectivity by completing the following tasks: Reset the VPN concentrator via CLI. Configure the VPN Concentrator via CLI. Test and verify the configuration.

Setup Before starting this lab exercise, make sure the VPN Concentrator is turned on and that your PC has console access to the VPN Concentrator.

Task 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

(where P = pod number)

Task 3—Test and Verify the Configuration Step 1

Ping the following devices from the Student PC to ensure they are operational: VPN Concentrator public interface—10.3.P.5 (where P = pod number)

Lab 8-14 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

VPN Concentrator private interface—10.2.P.1 (where P = pod number) Branch PC—10.2.P.11 (where P = pod number) Step 2

Copyright

Establish ftp and web access to the Branch PC from the Student PC.

2003, Cisco Systems, Inc.

Case Study Lab 8-15

PIX Firewall Configuration Complete the following lab exercise to configure the PIX Firewall.

Objectives In this lab exercise, you will configure the PIX Firewall to secure the corporate network by completing the following tasks: Deny outbound traffic from the Public Services Segment (PSS) network. Allow necessary Internet services to the PSS server. Implement spoofing protection. Enable logging to the management server on the internal corporate network. Assign Telnet and enable passwords. Test and verify the configuration.

Network Security Policy You will implement the following security policies in this lab exercise: Control incoming traffic: —

Allow Internet users access to PSS server and services.

—

Allow corporate users access to PSS server and services.

—

Deny Internet users access to the corporate office internal network.

—

Deny inbound traffic from the 127.0.0.0 and 10.0.P.0 networks. (where P = pod number)

—

Permit Internet Control Message Protocol (ICMP) echo replies to internal networks.

—

Permit ICMP echo request to all PIX interfaces. The outside interface should not respond to requests from untrusted networks.

Control outgoing traffic: —

Deny traffic initiated from the PSS server.

—

Allow corporate users access to the Internet.

Lab 8-16 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Apply PIX Firewall hardening and management: —

Enable logging.

—

Assign Telnet and enable passwords.

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

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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-17

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 5

Write the current configuration to Flash memory.

Step 6

Compare your configuration to the following: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ÜÓÆï -»½«®·¬§é𠲿³»·º »¬¸»®²»¬ë ÜÓÆî -»½«®·¬§èð »²¿¾´» °¿--©±®¼ èΧîǶק¬éÎÎÈËîì »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì

Lab 8-18 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ïéîòïêòïòëð ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ °¿¹»® ´·²»- îì ·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ÜÓÆï ïëð𠳬« ÜÓÆî ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðòð Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-19

º¿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆï ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆî ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëò𠲿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ïçîòïêèòïòïï ïéîòïêòïòëð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬ ¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æìéçí¿ìîîïêêëëì¼èè¾¼ïêéçí쿼çê»ìï æ »²¼ ÅÑÕÃ

Step 7

Verify the configuration by performing the following test from the VPN Client PC: Test that ICMP access does not work to the outside interface of the PIX Firewall: 192.168.P.2. (where P = pod number)

Lab 8-20 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Test FTP and web access to the PSS server: 192.168.P.11. (where P = pod number)

Task 3—Implement Spoofing Protection Complete the following steps to implement Unicast Reverse Path Forwarding (RPF) IP spoofing protection: Step 1

Enable Unicast RPF IP spoofing protection for the outside and PSS interfaces.

Step 2

Write the current configuration to Flash memory.

Task 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

Step 2

Write the current configuration to Flash memory.

Task 5—Assign Telnet and Enable Passwords Complete the following steps to assign Telnet and enable passwords: Step 1

Configure and set your password according to the following parameters: enable password—enable telnet password—cisco

Step 2

Write the current configuration to Flash memory:

Step 3

Compare your configuration to the following sample configuration from pix1: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ÜÓÆï -»½«®·¬§é𠲿³»·º »¬¸»®²»¬ë ÜÓÆî -»½«®·¬§èð

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-21

»²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ïéîòïêòïòëð ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ÜÓÆï ïëð𠳬« ÜÓÆî ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð Lab 8-22 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆï ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆî ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëò𠲿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ïçîòïêèòïòïï ïéîòïêòïòëð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-23

¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æìî»èèíð¾¾ëéëë¾íèïï¼êºï»ºîº¿ëì½êð æ »²¼ ÅÑÕÃ

Task 6—Test and Verify the Configuration Complete the following steps to test your configuration: Step 1

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

Step 2

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

Step 3

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

Step 4

Ensure that you cannot initiate a connection to any network from the PSS server.

Lab 8-24 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

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

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

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

—

Enforce password encryption to protect device passwords.

—

Disable unnecessary network services.

Log branch office router events: —

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

—

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

—

Set accurate time-stamping for log and debug messages.

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

Copyright

Control access into the router from the console and the vty lines.

2003, Cisco Systems, Inc.

Case Study Lab 8-25

—

Allow Telnet to the perimeter router only from the student system inside the branch office network.

—

Authenticate Telnet sessions with usernames and passwords entered into the perimeter 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.

Setup Before starting this lab exercise, set up your equipment so that you can do the following from the branch office equipment: Ping the branch office router’s inside and outside interfaces from the branch office PC.

Lab 8-26 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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

Task 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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-27

proxy-arp cdp enable ip redirects ip directed-broadcast Step 4

Enable logging to the Syslog server to provide a method to monitor router events including attacks: management 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.

Lab 8-28 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Caution Step 1

Do not do Task 3 in a remote lab environment.

Establish static translation between an inside local address and an outside global address and apply it to both interfaces using the following parameters: local-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: access list number—101 Allows traffic, routing updates, and logs from the ISP router (RBB) and no other routers Allows traffic from the corporate office Prevents inbound network traffic with source addresses of the branch office internal networks Implements RFC 1918 filtering for the following networks

Step 2

—

127.0.0.0

—

172.18.0.0

Create an ACL that only allows outbound traffic originating from the internal network and explicitly denies all other traffic using the following parameters: access list number—102 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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-29

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: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü¯òÙéü߯¦»Úß·ñ²²Íܱ-´ÜضڹÈð »²¿¾´» °¿--©±®¼ é ðéïÝîììÚëÝðÝðÜ ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðëïèïîïßîëìçìðïÜ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° º·²¹»® ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼°

Lab 8-30 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòíòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ÿ ®±«¬»® »·¹®° ï ®»¼·-¬®·¾«¬» -¬¿¬·½ ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïðòíòïòë ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï ¼»²§ Copyright

2003, Cisco Systems, Inc.

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹ Case Study Lab 8-31

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

²± ½¼° ®«² ÿ ¾¿²²»® »¨»½ ÂÝÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïîïßðÝðìïïðì ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

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.

Lab 8-32 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Site-to-Site VPN Configuration Complete the following exercise to implement the case study.

Objectives In this lab exercise you will configure a site-to-site VPN by completing the following tasks: Prepare the PIX Firewall for the DMZ IOS Router to Branch Office IOS Router IPSec tunnel configuration. Prepare for configuring IPSec on the Branch Office IOS Router. Configure IKE parameters on the Branch Office IOS Router. Configure IPSec parameters on the Branch Office IOS Router. Prepare for configuring IPSec pre-shared keys on the DMZ IOS Router. Configure IKE parameters on the DMZ IOS Router. Configure IPSec parameters on the DMZ IOS Router. Configure the PIX Firewall to only allow IPSec Traffic to the DMZ IOS Router. Verify the IPSec configuration.

Network Security Policy IPSec will be configured between the branch office IOS Router and the DMZ IOS Router to use pre-shared keys. Branch office users will have access to the internal corporate and the DMZ network through the VPN tunnel. Corporate users will have access to the branch office network through the VPN tunnel. There will be no Network Address Translation (NAT) used in the VPN tunnel.

Setup Before starting this lab exercise, make sure you can access the console ports of the devices used.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-33

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

Step 7

Save your configuration and compare it to the following: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò æ Í¿ª»¼ æ Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ÜÓÆï -»½«®·¬§é𠲿³»·º »¬¸»®²»¬ë ÜÓÆî -»½«®·¬§èð »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼

Lab 8-34 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¸±-¬²¿³» °·¨ï º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòîðð ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ïéîòïêòïòëð ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÜÓÆïóÑËÌ °»®³·¬ ·° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòïòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëðð Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-35

³¬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ÜÓÆï ïëð𠳬« ÜÓÆî ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆï ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆî ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëò𠲿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ïçîòïêèòïòïï ïéîòïêòïòëð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ øÜÓÆïô±«¬-·¼»÷ ïçîòïêèòïòîðð ïéîòïèòïòë ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ øÜÓÆîôÐÍÍ÷ ïðòîòïòð ïðòîòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÜÓÆïóÑËÌ ·² ·²¬»®º¿½» ÜÓÆï ¿½½»--ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ®±«¬» ÜÓÆî ïðòîòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï ®±«¬» ÜÓÆî ïðòíòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð

Lab 8-36 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬ ¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æìíçêç»êéð½ïèé缺ï½éëîçé軽½è¿»è¼ æ »²¼ ÅÑÕÃ

Task 2—Prepare for Configuring IPSec on the Branch Office IOS Router Complete the following lab exercise steps to prepare for the IPSec configuration: Step 1

Input static routes for the following networks using the translated address of the DMZ IOS Router as the next hop: Next 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)

Step 2

Determine the Internet Key Exchange (IKE) and IPSec policy. The IKE policy is to use pre-shared keys and Secure Hash Algorithm (SHA) for authentication. The IPSec policy is to use Encapsulating Security Payload (ESP) mode with Triple-Data Encryption Standard (3DES) encryption. The IPSec policy is to encrypt IP traffic between internal NT servers in each pod.

Task 3—Configure IKE Parameters on the Branch Office IOS Router Complete the following steps to configure IKE to use pre-shared keys:

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-37

Step 1

Create an IKE policy using the parameter values listed: Isakmp key—cisco1234 Policy priority number—10 Encryption algorithm—3des Hash algorithm—sha Authentication method—pre-share Diffie-Hellman group identifier—1 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: Traffic encrypted—Traffic between corporate internal networks and branch office networks Access list name—103 Protocol—Any Internet protocol

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) Access list name—101 Protocol—Any Internet protocol

Step 3

Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed: Transform name—myset ESP protocols—3des

Lab 8-38 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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 Key exchange type—isakmp Peer—192.168.P.200 (where P = pod number) Transform set—myset Match address—103

Step 5

Save your configuration and compare it to the following: Þ«·´¼·²¹ ½±²º·¹«®¿¬·±²òòò Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ ²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü¯òÙéü߯¦»Úß·ñ²²Íܱ-´ÜضڹÈð »²¿¾´» °¿--©±®¼ é ðéïÝîììÚëÝðÝðÜ ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðëïèïîïßîëìçìðïÜ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° º·²¹»® ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-39

·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ½®§°¬± ·-¿µ³° °±´·½§ ïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòïòîðð ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ÜÓÆ ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïçîòïêèòïòîðð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ³¿¬½¸ ¿¼¼®»-- ïðí ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòíòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ²± ½¼° »²¿¾´» ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ½®§°¬± ³¿° ÜÓÆ ÿ ®±«¬»® »·¹®° ï ®»¼·-¬®·¾«¬» -¬¿¬·½ ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ Lab 8-40 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð ·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïðòíòïòë ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðï ¼»²§

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ²± ½¼° ®«² ÿ ¾¿²²»® »¨»½ ÂÝÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïîïßðÝðìïïðì ´±¹·² ´±½¿´ Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-41

¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

Task 5—Prepare for Configuring IPSec Pre-Shared Keys on the DMZ IOS Router Complete the following lab exercise steps to prepare for the IPSec configuration: Step 1

Determine the Internet Key Exchange (IKE) and IPSec policy. The IKE policy is to use pre-shared keys and Secure Hash Algorithm (SHA) for authentication. The IPSec policy is to use Encapsulating Security Payload (ESP) mode with Triple-Data Encryption Standard (3DES) encryption. The IPSec policy is to encrypt IP traffic between internal NT servers in each pod.

Task 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 Policy priority number—10 Encryption algorithm—3des Hash alogorithm—sha Authentication method—pre-share Diffie-Hellman group identifier—1 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:

Lab 8-42 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Traffic encrypted—Traffic between corporate internal networks and branch office networks Peer network address—IP address of branch office network Access list name—103 Protocol—Any Internet protocol Step 2

Configure an IPSec transform set (IKE phase two parameters). Use the parameter values listed in the table. Transform name—myset ESP protocols—3des 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 Key exchange type—isakmp Peer—172.26.26.10P (where P = pod number) Transform set—myset 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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-43

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.

Lab 8-44 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Client-to-LAN VPN Configuration Complete the following lab exercise sub-section to practice what you learned in this chapter.

Objectives In this lab exercise, complete the following tasks to enable remote access via VPN: Configure the VPN Concentrator using Quick Configuration via the web interface. Configure the VPN Concentrator via the web interface. Configure the Cisco VPN Client. Configure the Branch Office IOS router. Test and verify the IPSec configuration.

Network Security Policy In this lab exercise, you will configure the perimeter router, the Cisco VPN Concentrator, and other managed devices according to the following VPN security policy: A VPN tunnel will secure communication between the Cisco VPN Client PC and the Concentrator. The VPN Client PC must be able to access the branch office internal network.

Setup Before starting this lab exercise, set up your equipment as follows: Ensure that your Concentrator is turned on. Access the branch office 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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-45

DST Support—Enable DNS Server—0.0.0.0 (which is the default) Domain Name—podP.com (where P = pod number) Default Gateway—10.3.P.1 (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.

Group Name—podP_group (where P = pod number)

Lab 8-46 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

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.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-47

Step 8

Enable split tunneling on the VPN Concentrator only allowing access to the translated address of the Student PC. Translated 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 Name—podP_group (where P = pod number) 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.

Lab 8-48 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Step 1

Configure an access-list entry in access-list number 101 to allow IKE and IPSec traffic access to the public interface of the VPN concentrator.

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

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-49

Final Configurations Compare your final configurations to the one’s shown: PIX Firewall Configuration Ð×È Ê»®-·±² êòîøï÷ ²¿³»·º »¬¸»®²»¬ð ±«¬-·¼» -»½«®·¬§ð ²¿³»·º »¬¸»®²»¬ï ·²-·¼» -»½«®·¬§ïð𠲿³»·º »¬¸»®²»¬î ÐÍÍ -»½«®·¬§ë𠲿³»·º »¬¸»®²»¬í ·²¬ºí -»½«®·¬§ïë ²¿³»·º »¬¸»®²»¬ì ÜÓÆï -»½«®·¬§é𠲿³»·º »¬¸»®²»¬ë ÜÓÆî -»½«®·¬§èð »²¿¾´» °¿--©±®¼ Ê°Û«ñÜ޷˯®òʸÙé »²½®§°¬»¼ °¿--©¼ îÕÚϲ¾Ò×¼×òîÕÇÑË »²½®§°¬»¼ ¸±-¬²¿³» °·¨ï º·¨«° °®±¬±½±´ º¬° îï º·¨«° °®±¬±½±´ ¸¬¬° èð º·¨«° °®±¬±½±´ ¸íîí ¸îîë ïéîð º·¨«° °®±¬±½±´ ¸íîí ®¿- ïéïèóïéïç º·¨«° °®±¬±½±´ ·´- íèç º·¨«° °®±¬±½±´ ®-¸ ëïì º·¨«° °®±¬±½±´ ®¬-° ëëì º·¨«° °®±¬±½±´ -³¬° îë º·¨«° °®±¬±½±´ -¯´²»¬ ïëîï º·¨«° °®±¬±½±´ -·° ëðêð º·¨«° °®±¬±½±´ -µ·²²§ îðð𠲿³»¿½½»--ó´·-¬ ÑËÌÞÑËÒÜ °»®³·¬ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïîéòðòðòð îëëòðòðòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ïðòðòïòð îëëòîëëòîëëòð ¿²§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòîðð ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ »-° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòîðð ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ «¼° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòîð𠻯 ·-¿µ³° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·° ¸±-¬ ïéîòîêòîêòïðï ¸±-¬ ïçîòïêèòïòîðð ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ ©©© ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ¬½° ¿²§ ¸±-¬ ïçîòïêèòïòïï »¯ º¬° ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ °»®³·¬ ·½³° ¿²§ ïçîòïêèòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ×ÒÞÑËÒÜ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ °»®³·¬ ·½³° ïéîòïêòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¸±-¬ ïéîòïêòïòëð ¿²§ ¿½½»--ó´·-¬ ÐÍÍóÑËÌ ¼»²§ ·° ¿²§ ¿²§ ¿½½»--ó´·-¬ ÜÓÆïóÑËÌ °»®³·¬ ·° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·½³° ¿²§ ïðòðòïòð îëëòîëëòîëëòð »½¸±ó®»°´§ Lab 8-50 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïðòðòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòîòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð ¿½½»--ó´·-¬ ÜÓÆîóÑËÌ °»®³·¬ ·° ïðòíòïòð îëëòîëëòîëëòð ïéîòïêòïòð îëëòîëëòîëëòð °¿¹»® ´·²»- îì ´±¹¹·²¹ ±² ´±¹¹·²¹ ¬®¿° ·²º±®³¿¬·±²¿´ ´±¹¹·²¹ ¸±-¬ ·²-·¼» ïðòðòïòïï ·²¬»®º¿½» »¬¸»®²»¬ð ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ï ï𺫴´ ·²¬»®º¿½» »¬¸»®²»¬î ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬í ¿«¬± -¸«¬¼±©² ·²¬»®º¿½» »¬¸»®²»¬ì ¿«¬± ·²¬»®º¿½» »¬¸»®²»¬ë ¿«¬± ·½³° ¼»²§ ¿²§ ±«¬-·¼» ³¬« ±«¬-·¼» ïëð𠳬« ·²-·¼» ïëð𠳬« ÐÍÍ ïëð𠳬« ·²¬ºí ïëð𠳬« ÜÓÆï ïëð𠳬« ÜÓÆî ïëðð ·° ¿¼¼®»-- ±«¬-·¼» ïçîòïêèòïòî îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²-·¼» ïðòðòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÐÍÍ ïéîòïêòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ·²¬ºí ïîéòðòðòï îëëòîëëòîëëòîëë ·° ¿¼¼®»-- ÜÓÆï ïéîòïèòïòï îëëòîëëòîëëòð ·° ¿¼¼®»-- ÜÓÆî ïéîòïçòïòï îëëòîëëòîëëòð ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ±«¬-·¼» ·° ª»®·º§ ®»ª»®-»ó°¿¬¸ ·²¬»®º¿½» ÐÍÍ ·° ¿«¼·¬ ·²º± ¿½¬·±² ¿´¿®³ ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ²± º¿·´±ª»® º¿·´±ª»® ¬·³»±«¬ ðæððæð𠺿·´±ª»® °±´´ ïë º¿·´±ª»® ·° ¿¼¼®»-- ±«¬-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²-·¼» ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÐÍÍ ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ·²¬ºí ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆï ðòðòðò𠺿·´±ª»® ·° ¿¼¼®»-- ÜÓÆî ðòðòðòð °¼³ ¸·-¬±®§ »²¿¾´» ¿®° ¬·³»±«¬ ïììðð ¹´±¾¿´ ø±«¬-·¼»÷ ï ïçîòïêèòïòííóïçîòïêèòïòîîî ²»¬³¿-µ îëëòîëëòîëëò𠲿¬ ø·²-·¼»÷ ï ïðòðòïòð îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÐÍÍ÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-51

-¬¿¬·½ ø·²-·¼»ôÜÓÆï÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ ø·²-·¼»ôÜÓÆî÷ ïðòðòïòð ïðòðòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð -¬¿¬·½ øÐÍÍô±«¬-·¼»÷ ïçîòïêèòïòïï ïéîòïêòïòëð ²»¬³¿-µ îëëòîëëòîëëòîëë ð ïððð -¬¿¬·½ øÜÓÆïô±«¬-·¼»÷ ïçîòïêèòïòîðð ïéîòïèòïòë ²»¬³¿-µ îëëòîëëòîëëòîëë ð ð -¬¿¬·½ øÜÓÆîôÐÍÍ÷ ïðòîòïòð ïðòîòïòð ²»¬³¿-µ îëëòîëëòîëëòð ð ð ¿½½»--ó¹®±«° ×ÒÞÑËÒÜ ·² ·²¬»®º¿½» ±«¬-·¼» ¿½½»--ó¹®±«° ÑËÌÞÑËÒÜ ·² ·²¬»®º¿½» ·²-·¼» ¿½½»--ó¹®±«° ÐÍÍóÑËÌ ·² ·²¬»®º¿½» ÐÍÍ ¿½½»--ó¹®±«° ÜÓÆïóÑËÌ ·² ·²¬»®º¿½» ÜÓÆï ¿½½»--ó¹®±«° ÜÓÆîóÑËÌ ·² ·²¬»®º¿½» ÜÓÆî ®±«¬» ±«¬-·¼» ðòðòðòð ðòðòðòð ïçîòïêèòïòï ï ®±«¬» ÜÓÆî ïðòîòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï ®±«¬» ÜÓÆî ïðòíòïòð îëëòîëëòîëëòð ïéîòïçòïòë ï ¬·³»±«¬ ¨´¿¬» íæððæðð ¬·³»±«¬ ½±²² ïæððæð𠸿´ºó½´±-»¼ ðæïðæðð «¼° ðæðîæðð ®°½ ðæïðæðð ¸íîí ðæðëæðð -· ° ðæíðæðð -·°Á³»¼·¿ ðæðîæðð ¬·³»±«¬ «¿«¬¸ ðæðëæðð ¿¾-±´«¬» ¿¿¿ó-»®ª»® ÌßÝßÝÍõ °®±¬±½±´ ¬¿½¿½-õ ¿¿¿ó-»®ª»® ÎßÜ×ËÍ °®±¬±½±´ ®¿¼·«¿¿¿ó-»®ª»® ÔÑÝßÔ °®±¬±½±´ ´±½¿´ ²± -²³°ó-»®ª»® ´±½¿¬·±² ²± -²³°ó-»®ª»® ½±²¬¿½¬ -²³°ó-»®ª»® ½±³³«²·¬§ °«¾´·½ ²± -²³°ó-»®ª»® »²¿¾´» ¬®¿°º´±±¼¹«¿®¼ »²¿¾´» ²± -§-±°¬ ®±«¬» ¼²¿¬ ¬»´²»¬ ¬·³»±«¬ ë --¸ ¬·³»±«¬ ë ¬»®³·²¿´ ©·¼¬¸ èð Ý®§°¬±½¸»½µ-«³æëðìíèºç뻽ìíºìç¼ïð¿ïëí¾»í¿ëðð æ »²¼ ÅÑÕÃ

Branch IOS Router Configuration Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ ¼¿¬»¬·³» ´±½¿´¬·³» -¸±©ó¬·³»¦±²» -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¾®ï ÿ

Lab 8-52 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

²± ´±¹¹·²¹ ½±²-±´» »²¿¾´» -»½®»¬ ë üïü¯òÙéü߯¦»Úß·ñ²²Íܱ-´ÜضڹÈð »²¿¾´» °¿--©±®¼ é ðéïÝîììÚëÝðÝðÜ ÿ «-»®²¿³» -¬«¼»²¬ °¿--©±®¼ é ðëïèïîïßîëìçìðïÜ ÿ ³»³±®§ó-·¦» ·±³»³ ïð ·° -«¾²»¬ó¦»®± ²± ·° -±«®½»ó®±«¬» ²± ·° º·²¹»® ²± ·° ¼±³¿·²ó´±±µ«° ÿ ²± ·° ¾±±¬° -»®ª»® ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¬½° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© º¬° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© «¼° ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ¸íîí ·° ·²-°»½¬ ²¿³» ¾®¿²½¸º© ®»¿´¿«¼·± ·° ¿«¼·¬ ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ·° ¿«¼·¬ ²¿³» ¾®¿²½¸·¼- ¿¬¬¿½µ ¿½¬·±² ¿´¿®³ ¼®±° ÿ ½®§°¬± ·-¿µ³° °±´·½§ ïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïçîòïêèòïòîðð ÿ ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ÜÓÆ ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïçîòïêèòïòîðð -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ³¿¬½¸ ¿¼¼®»-- ïðí ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïðòíòïòï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðî ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ·° ·²-°»½¬ ¾®¿²½¸º© ·² ·° ¿«¼·¬ ¾®¿²½¸·¼- ·² ²± ½¼° »²¿¾´» ÿ Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-53

·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòîêòîêòïðï îëëòîëëòîëëòð ·° ¿½½»--ó¹®±«° ïðï ·² ²± ·° ®»¼·®»½¬²± ·° °®±¨§ó¿®° ²± ½¼° »²¿¾´» ½®§°¬± ³¿° ÜÓÆ ÿ ®±«¬»® »·¹®° ï ®»¼·-¬®·¾«¬» -¬¿¬·½ ²»¬©±®µ ïðòðòðòð ²»¬©±®µ ïéîòîêòðòð ²± ¿«¬±ó-«³³¿®§ ²± »·¹®° ´±¹ó²»·¹¸¾±®ó½¸¿²¹»ÿ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð ·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïðòíòïòë ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïçîòïêèòïòîðð ²± ·° ¸¬¬° -»®ª»® ÿ ´±¹¹·²¹ ïðòîòïòïï ¿½½»--ó´·-¬ ï °»®³·¬ ïðòîòïòïï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ ïéîòîêòîêòïðï ¿½½»--ó´·-¬ ïðï °»®³·¬ »·¹®° ¸±-¬ ïéîòîêòîêòïë𠸱-¬ îîìòðòðòïð ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·½³° ¿²§ ¸±-¬ ïéîòîêòîêòïðï ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïçîòïêèòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ »-° ¿²§ ¸±-¬ ïðòíòïòë ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ «¼° ¿²§ ¸±-¬ ïðòíòïòë ´±¹ »¯ ·-¿µ³° ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðï °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ´±¹ ¿½½»--ó´·-¬ ïðï ¼»²§

·° ïîéòðòðòð ðòîëëòîëëòîëë ¿²§ ´±¹

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

·° ïéîòïèòðòð ðòðòîëëòîëë ¿²§ ´±¹

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

»·¹®° ¸±-¬ ïéîòîêòîêòïðï ¿²§ ´±¹

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

»·¹®° ¿²§ ¿²§ ´±¹

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

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ¿²§ ´±¹ ¿½½»--ó´·-¬ ïðî ¼»²§

·° ¿²§ ¿²§ ´±¹

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë Lab 8-54 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïðòðòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòîòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòíòïòð ðòðòðòîëë ïéîòïêòïòð ðòðòðòîëë ²± ½¼° ®«² ÿ ¾¿²²»® »¨»½ ÂÝÝÝDZ« ¿®» ²±© »¨»½«¬·²¹ ½±³³¿²¼- ±² ݱ³°¿²§ Ю±°»®¬§ÂÝ ¾¿²²»® ´±¹·² ÂÝÝÝÉ¿®²·²¹ò ß«¬¸±®·¦»¼ ݱ³°¿²§ ×Ì Ð»®-±²²»´ ÑÒÔÇÂÝ ÿ ´·²» ½±² 𠻨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïïðßïðïêïìïÜ ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ²±²» ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ¿½½»--ó½´¿-- ï ·² »¨»½ó¬·³»±«¬ ïë ð °¿--©±®¼ é ïîïßðÝðìïïðì ´±¹·² ´±½¿´ ¬®¿²-°±®¬ ·²°«¬ ¬»´²»¬ ¬®¿²-°±®¬ ±«¬°«¬ ²±²» ÿ -½¸»¼«´»® ¿´´±½¿¬» ìððð ïððð »²¼

DMZ IOS Router Configuration Ý«®®»²¬ ½±²º·¹«®¿¬·±²æ ÿ ª»®-·±² ïîòï -»®ª·½» ¬·³»-¬¿³°- ¼»¾«¹ «°¬·³» -»®ª·½» ¬·³»-¬¿³°- ´±¹ «°¬·³» ²± -»®ª·½» °¿--©±®¼ó»²½®§°¬·±² ÿ ¸±-¬²¿³» ¼®ï ÿ »²¿¾´» -»½®»¬ ë üïüÆéÆñüÝϼ¦±Ê¬-µ·»ºîµº×ÚܪÚÎï ÿ ³»³±®§ó-·¦» ·±³»³ ïë ·° -«¾²»¬ó¦»®± ÿ ·° ¿«¼·¬ ²±¬·º§ ´±¹ ·° ¿«¼·¬ °± ³¿¨ó»ª»²¬- ïðð ÿ Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-55

½®§°¬± ·-¿µ³° °±´·½§ ïð »²½® í¼»¿«¬¸»²¬·½¿¬·±² °®»ó-¸¿®» ½®§°¬± ·-¿µ³° µ»§ ½·-½±ïîíì ¿¼¼®»-- ïéîòîêòîêòïðï ÿ ½®§°¬± ·°-»½ ¬®¿²-º±®³ó-»¬ ³§-»¬ »-°óí¼»ÿ ½®§°¬± ³¿° ¾®¿²½¸ ïð ·°-»½ó·-¿µ³° -»¬ °»»® ïéîòîêòîêòïðï -»¬ ¬®¿²-º±®³ó-»¬ ³§-»¬ ³¿¬½¸ ¿¼¼®»-- ïðí ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñð ·° ¿¼¼®»-- ïéîòïçòïòë îëëòîëëòîëëòð ÿ ·²¬»®º¿½» Í»®·¿´ðñð ²± ·° ¿¼¼®»--¸«¬¼±©² ²± º¿·®ó¯«»«» ÿ ·²¬»®º¿½» Û¬¸»®²»¬ðñï ·° ¿¼¼®»-- ïéîòïèòïòë îëëòîëëòîëëòð ½®§°¬± ³¿° ¾®¿²½¸ ÿ ·° ½´¿--´»-·° ®±«¬» ïðòðòïòð îëëòîëëòîëëòð ïéîòïçòïòï ·° ®±«¬» ïðòîòïòð îëëòîëëòîëëòð ïéîòïèòïòï ·° ®±«¬» ïðòíòïòð îëëòîëëòîëëòð ïéîòïèòïòï ·° ®±«¬» ïéîòïêòïòð îëëòîëëòîëëòð ïéîòïçòïòï ·° ®±«¬» ïéîòîêòîêòð îëëòîëëòîëëòð ïéîòïèòïòï ²± ·° ¸¬¬° -»®ª»® ÿ ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïðòðòïòð ðòðòðòîëë ïðòíòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòîòïòð ðòðòðòîëë ¿½½»--ó´·-¬ ïðí °»®³·¬ ·° ïéîòïêòïòð ðòðòðòîëë ïðòíòïòð ðòðòðòîëë ÿ ´·²» ½±² 𠬮¿²-°±®¬ ·²°«¬ ²±²» ´·²» ¿«¨ ð ´·²» ª¬§ ð ì ÿ ²± -½¸»¼«´»® ¿´´±½¿¬» »²¼

Lab 8-56 Cisco SAFE Implementation 1.1

Copyright

2003, Cisco Systems, Inc.

Copyright

2003, Cisco Systems, Inc.

Case Study Lab 8-57