Cisco Network Security Little Black Book [1 ed.] 1932111654, 9781932111651

Citation preview

Cisco Network Security Little Black Book

Table of Contents Cisco Network Security Little Black Book......................................................................................1 Introduction........................................................................................................................................4 Is this Book for You?................................................................................................................4 How to Use this Book...............................................................................................................4 The Little Black Book Philosophy.............................................................................................6 Chapter 1: Securing the Infrastructure............................................................................................7 In Brief......................................................................................................................................7 Enterprise Security Problems.............................................................................................7 Types of Threats................................................................................................................8 Enterprise Security Challenges..........................................................................................8 Enterprise Security Policy..................................................................................................9 Securing the Enterprise....................................................................................................10 Immediate Solutions..............................................................................................................14 Configuring Console Security...........................................................................................14 Configuring Telnet Security..............................................................................................16 Configuring Enable Mode Security...................................................................................17 Disabling Password Recovery.........................................................................................18 Configuring Privilege Levels for Users.............................................................................20 Configuring Password Encryption....................................................................................21 Configuring Banner Messages.........................................................................................22 Configuring SNMP Security.............................................................................................24 Configuring RIP Authentication........................................................................................25 Configuring EIGRP Authentication...................................................................................27 Configuring OSPF Authentication....................................................................................31 Configuring Route Filters.................................................................................................35 Suppressing Route Advertisements.................................................................................40 Chapter 2: AAA Security Technologies.........................................................................................43 In Brief....................................................................................................................................43 Access Control Security...................................................................................................43 AAA Protocols..................................................................................................................48 Cisco Secure Access Control Server...............................................................................53 Immediate Solutions..............................................................................................................56 Configuring TACACS+ Globally.......................................................................................56 Configuring TACACS+ Individually..................................................................................58 Configuring RADIUS Globally..........................................................................................61 Configuring RADIUS Individually.....................................................................................62 Configuring Authentication...............................................................................................64 Configuring Authorization.................................................................................................72 Configuring Accounting....................................................................................................75 Installing and Configuring Cisco Secure NT....................................................................78 Chapter 3: Perimeter Router Security............................................................................................85 In Brief....................................................................................................................................85 Defining Networks............................................................................................................85 Cisco Express Forwarding...............................................................................................86 Unicast Reverse Path Forwarding...................................................................................87 TCP Intercept...................................................................................................................87 i

Table of Contents Chapter 3: Perimeter Router Security Network Address Translation...........................................................................................89 Committed Access Rate...................................................................................................90 Logging............................................................................................................................92 Immediate Solutions..............................................................................................................93 Configuring Cisco Express Forwarding............................................................................93 Configuring Unicast Reverse Path Forwarding................................................................95 Configuring TCP Intercept................................................................................................98 Configuring Network Address Translation (NAT)...........................................................103 Configuring Committed Access Rate (CAR)..................................................................116 Configuring Logging.......................................................................................................119 Chapter 4: IOS Firewall Feature Set.............................................................................................123 In Brief..................................................................................................................................123 Context−Based Access Control.....................................................................................123 Port Application Mapping...............................................................................................127 IOS Firewall Intrusion Detection.....................................................................................129 Immediate Solutions............................................................................................................131 Configuring Context−Based Access Control..................................................................131 Configuring Port Application Mapping............................................................................143 Configuring IOS Firewall Intrusion Detection.................................................................149 Chapter 5: Cisco Encryption Technology...................................................................................156 In Brief..................................................................................................................................156 Cryptography..................................................................................................................156 Benefits of Encryption....................................................................................................160 Symmetric and Asymmetric Key Encryption..................................................................160 Digital Signature Standard.............................................................................................166 Cisco Encryption Technology Overview.........................................................................167 Immediate Solutions............................................................................................................168 Configuring Cisco Encryption Technology.....................................................................168 Chapter 6: Internet Protocol Security..........................................................................................189 In Brief..................................................................................................................................189 IPSec Packet Types.......................................................................................................190 IPSec Modes of Operation.............................................................................................191 Key Management...........................................................................................................193 Encryption......................................................................................................................196 IPSec Implementations..................................................................................................197 Immediate Solutions............................................................................................................197 Configuring IPSec Using Pre−Shared Keys...................................................................198 Configuring IPSec Using Manual Keys..........................................................................214 Configuring Tunnel EndPoint Discovery........................................................................224 Chapter 7: Additional Access List Features...............................................................................231 In Brief..................................................................................................................................231 Wildcard Masks..............................................................................................................233 Standard Access Lists....................................................................................................234 Extended Access Lists...................................................................................................234 Reflexive Access Lists...................................................................................................235 ii

Table of Contents Chapter 7: Additional Access List Features Dynamic Access Lists....................................................................................................236 Additional Access List Features.....................................................................................238 Immediate Solutions............................................................................................................239 Configuring Standard IP Access Lists............................................................................239 Configuring Extended IP Access Lists...........................................................................242 Configuring Extended TCP Access Lists.......................................................................247 Configuring Named Access Lists...................................................................................250 Configuring Commented Access Lists...........................................................................252 Configuring Dynamic Access Lists.................................................................................254 Configuring Reflexive Access Lists................................................................................260 Configuring Time−Based Access Lists..........................................................................263 Appendix A: IOS Firewall IDS Signature List..............................................................................266 Appendix B: Securing Ethernet Switches...................................................................................272 Configuring Management Access........................................................................................272 Configuring Port Security.....................................................................................................273 Configuring Permit Lists.......................................................................................................275 Configuring AAA Support.....................................................................................................276 List of Figures................................................................................................................................281 List of Tables..................................................................................................................................283 List of Listings...............................................................................................................................284

iii

Cisco Network Security Little Black Book Joe Harris CORIOLIS President and CEO Roland Elgey Publisher Al Valvano Associate Publisher Katherine R. Hartlove Acquisitions Editor Katherine R. Hartlove Development Editor Jessica Choi Product Marketing Manager Jeff Johnson Project Editor Greg Balas Technical Reviewer Sheldon Barry Production Coordinator Peggy Cantrell Cover Designer Laura Wellander Cisco ™ Network Security Little Black Book Title Copyright © 2002 The Coriolis Group, LLC All rights reserved. This book may not be duplicated in any way without the express written consent of the publisher, except in the form of brief excerpts or quotations for the purposes of review. The information contained herein is for the personal use of the reader and may not be incorporated in any commercial programs, other books, databases, or any kind of software without written consent of the publisher. Making copies of this book or any portion for any purpose other than your own is a violation of United States copyright laws. Limits of Liability and Disclaimer of Warranty The author and publisher of this book have used their best efforts in preparing the book and the programs contained in it. These efforts include the development, research, and testing of the 1

theories and programs to determine their effectiveness. The author and publisher make no warranty of any kind, expressed or implied, with regard to these programs or the documentation contained in this book. The author and publisher shall not be liable in the event of incidental or consequential damages in connection with, or arising out of, the furnishing, performance, or use of the programs, associated instructions, and/or claims of productivity gains. Trademarks Trademarked names appear throughout this book. Rather than list the names and entities that own the trademarks or insert a trademark symbol with each mention of the trademarked name, the publisher states that it is using the names for editorial purposes only and to the benefit of the trademark owner, with no intention of infringing upon that trademark. The Coriolis Group, LLC 14455 North Hayden Road Suite 220 Scottsdale, Arizona 85260 (480) 483−0192 FAX (480) 483−0193 http://www.coriolis.com/ Library of Congress Cataloging−in−Publication Data Harris, Joe, 1974− Cisco network security little black book / Joe Harris p. cm. Includes index. 1−93211−165−4

1. Computer networks−−Security measures. I. Title. TK5105.59 .H367 2002 005.8−−dc21 2002019668 10 9 8 7 6 5 4 3 2 1 I dedicate this book to my wife, Krystal, to whom I fall in love with all over again every day. I love you, I always have, I always will. To my son, Cameron, I cannot begin to put into words how much I love you. You are my world—my purpose in life. To my mother, Ann, thank you for your love and support, and for always being there for me—you will always be my hero. To my father, Joe Sr., thank you for all the sacrifices you had to make, so that I wouldn't have to—they didn't go unnoticed. Also, thanks for helping to make me the man that I am today—I love you.

—Joe Harris

2

About the Author Joe Harris, CCIE# 6200, is the Principal Systems Engineer for a large financial firm based in Houston, Texas. He has more than eight years of experience with data communications and protocols. His work is focused on designing and implementing large−scale, LAN−switched, and routed networks for customers needing secure methods of communication. Joe is involved daily in the design and implementation of complex secure systems, providing comprehensive security services for the financial industry. He earned his Bachelors of Science degree in Management Information Systems from Louisiana Tech University, and holds his Cisco Security Specialization. Acknowledgments There are many people I would like to thank for contributing either directly or indirectly to this book. Being an avid reader of technology books myself, I have always taken the acknowledgments and dedication sections lightly. Having now been through the book writing process, I can assure you that this will never again be the case. Writing a book about a technology sector like security, that changes so rapidly, is a demanding process, and as such, it warrants many "thanks yous" to a number of people. First, I would like thank God for giving me the ability, gifts, strength, and privilege to be working in such an exciting, challenging, and wonderful career. As stated in the book of Philippians, Chapter 4, Verse 13: "I can do all things through Christ which strengtheneth me." I would also like to thank The Coriolis Group team, which made this book possible. You guys are a great group of people to work with, and I encourage other authors to check them out. I would like to extend a special thanks to Jessica Choi, my development editor. In addition, I would also like to thank my acquisitions editors, Charlotte Carpentier and Katherine Hartlove, and my project editor, Greg Balas. It was a pleasure to work with people who exemplify such professionalism, and to the rest of the Coriolis team— Jeff Johnson, my product marketing manager, Peggy Cantrell, my production coordinator, and Laura Wallander, my cover designer—thank you all! In addition, I would like to thank Judy Flynn for copyediting and Christine Sherk for proofreading the book, respectively, and to Emily Glossbrenner for indexing the book. A big thanks also to Sheldon Barry for serving as the tech reviewer on the book! Special thanks to my friend, Joel Cochran, for being a great friend and mentor, and for repeatedly amazing me with your uncanny ability to remember every little detail about a vast array of technologies, and for also taking me under your wing and helping me to "learn the ropes" of this industry. Also thanks to Greg Wallin for the late night discussions and your keen insights into networking, and for your unique methods of communicating them in a manner that consistently challenges me to greater professional heights. Finally, I would like to thank Jeff Lee, Steven Campbell, Raul Rodriguez, Jose Aguinagua, Kenneth Avans, Walter Hallows, Chris Dunbar, Bill Ulrich, Dodd Lede, Bruce Sebecke, Michael Nelson, James Focke, Ward Hillyer, Loi Ngo, Will Miles, Dale Booth, Clyde Dardar, Barry Meche, Bill Pinson, and all those I have missed in this listing for their insight and inspiration. And last, but certainly not least, I would like to thank my wife, Krystal, for her love, support, and patience with me during this project. To my son, Cameron, thank you for being daddy's inspiration.

3

Introduction Thanks for buying Cisco Network Security Little Black Book, the definitive guide for security configurations on Cisco routers. New business practices and opportunities are driving a multitude of changes in all areas of enterprise networks, and as such, enterprise security is becoming more and more prevalent as enterprises try to understand and manage the risks associated with the rapid development of business applications deployed over the enterprise network. This coupled with the exponential growth of the Internet has presented a daunting security problem to most enterprises: How does the enterprise implement and update security defenses and practices in an attempt to reduce its vulnerability to exposure from security breaches? In this book, I will attempt to bridge the gap between the theory and practice of network security and place much of its emphasis on securing the enterprise infrastructure, but first let me emphasize that there is no such thing as absolute security. The statement that a network is secure, is more often than not, misunderstood to mean that there is no possibility of a security breach. However, as you will see throughout this book, having a secure network means that the proper security mechanisms have been put in place in an attempt to reduce most of the risks enterprise assets are exposed to. I have tried to include enough detail on the theories and protocols for reasonable comprehension so that the networking professional can make informed choices regarding security technologies. Although the focus of this book is on the Cisco product offering, the principles apply to many other environments as well.

Is this Book for You? Cisco Network Security Little Black Book was written with the intermediate or advanced user in mind. The following topics are among those that are covered: • Internet Protocol Security (IPSec) • Network Address Translation (NAT) • Authentication, authorization, and accounting (AAA) • TCP Intercept • Unicast Reverse Path Forwarding (Unicast RPF) • Ethernet Switch Security

How to Use this Book This book is similar in format to a typical book in the Little Black Book series. Each chapter has two main sections: "In Brief," followed by "Immediate Solutions." "In Brief" introduces the subject matter of the chapter and explains the principles it is based upon. This section does not delve too deeply into details; instead it elaborates only on the points that are most important for understanding the material in "Immediate Solutions." "Immediate Solutions" presents several tasks related to the subject of the chapter and presented in "In Brief." The tasks in "Immediate Solutions" vary from simple to complex. The vast array of task levels provides a broad coverage of the subject. This book contains seven chapters. The following sections include a brief preview of each one.

4

Chapter 1: Securing the Infrastructure Chapter 1 provides insight into enterprise security problems and challenges that face many organizations today in the "Internet Age" and focuses on the configuration of networking devices to ensure restricted and confidential access to them within the enterprise infrastructure. Chapter 2: AAA Security Technologies Chapter 2 includes a detailed examination of Cisco's authentication, authorization, and accounting (AAA) architecture, and the technologies that not only use its features, but also provide them. It presents proven concepts useful for implementing AAA security solutions and discusses how to configure networking devices to support the AAA architecture. Chapter 3: Perimeter Router Security Chapter 3 describes many of the security issues that arise when connecting an enterprise network to the Internet. It also details the technologies that can be used to minimize the threat of exposure to the enterprise and its assets. The chapter covers features such as TCP Intercept, Unicast Reverse Path Forwarding (Unicast RPF), and Network Address Translation (NAT). Chapter 4: IOS Firewall Feature Set Chapter 4 discusses the add−on component to the Cisco IOS that provides routers with many of the features available to the PIX firewall, which extends to routers with similar functionality as that provided from a separate firewall device. It covers features such as ContextBased Access Control (CBAC), Port Application Mapping (PAM), and the IOS Firewall Intrusion Detection System (IDS). Chapter 5: Cisco Encryption Technology Chapter 5 presents on overview of encryption algorithms, hashing techniques, symmetric key encryption, asymmetric key encryption, and digital signatures. It discusses how to configure a router to support Cisco Encryption Technologies and presents detailed methods for testing the encryption configuration. Chapter 6: Internet Protocol Security Chapter 6 presents an overview of the framework of open standards for ensuring secure private communications over IP networks and IPSec. It discusses how to configure a router for support of the protocols used to create IPSec virtual private networks (VPNs) and details the configuration of preshared keys, manual keys, and certificate authority support. Chapter 7: Additional Access List Features Chapter details the use of access lists and the security features they provide. It discusses the use of dynamic and reflexive access lists, as well as standard and extended access lists. Appendix A: IOS Firewall IDS Signature List Appendix A provides a detailed list of the 59 intrusion−detection signatures that are included in the Cisco IOS Firewall feature set. The signatures are presented in numerical order with a detailed description of the signature number contained within the Cisco Secure IDS Network Security Database (NSD). 5

Appendix B: Securing Ethernet Switches Appendix B presents an overview of methods used to provide security for the Catalyst Ethernet model of switches. This appendix discusses how to configure VLANS, Vlan Access Lists, IP permit lists, port security, SNMP security, and support for the AAA architecture on the Catalyst line of Ethernet switches.

The Little Black Book Philosophy Written by experienced professionals, Coriolis Little Black Books are terse, easily "thumb−able" question−answerers and problem−solvers. The Little Black Book's unique two−part chapter format—brief technical overviews followed by practical immediate solutions—is structured to help you use your knowledge, solve problems, and quickly master complex technical issues to become an expert. By breaking down complex topics into easily manageable components, this format helps you quickly find what you're looking for, with the diagrams and code you need to make it happen. The author sincerely believes that this book will provide a more cost−effective and timesaving means for preparing and deploying Cisco security features and services. By using this reference, the reader can focus on the fundamentals of the material, instead of spending time deciding on acquiring numerous expensive texts that may turn out to be, on the whole, inapplicable to the desired subject matter. This book also provides the depth and coverage of the subject matter in an attempt to avoid gaps in security−related technologies that are presented in other "single" reference books. The information security material in this book is presented in an organized, professional manner, that will be a primary source of information for individuals new to the field of security, as well as for practicing security professionals. This book is mostly a practical guide for configuring security−related technologies on Cisco routers, and as such, the chapters may be read in any order. I welcome your feedback on this book. You can either email The Coriolis Group at [email protected], or email me directly at [email protected]. Errata, updates, and more are available at http://www.coriolis.com/.

6

Chapter 1: Securing the Infrastructure In Brief This chapter is made up of two parts. The first part provides insight into enterprise security problems and challenges that face many organizations today in the "Internet Age." The Internet has changed the way people live, work, and play. Even more so, it has revolutionized the way business is conducted and the methods in which businesses communicate. More and more businesses are recognizing that the Internet provides them with a relatively inexpensive medium for conducting business on a global scale. Unfortunately, the Internet is missing a lot of key components, one of which is security. The Internet possesses an unlimited number of possibilities for enterprises, but enterprises must first weigh the risk of conducting business on the Internet against the security measures necessary to protect the business they are trying to conduct. As a result of the Internet, information traffic loads within the enterprise have increased exponentially, and so, too, has the business value of the infrastructure that supports the higher traffic loads, thereby increasing the risk of vulnerability to security breaches. The second part of this chapter focuses on configuration of Cisco routers to ensure restricted and confidential access to network devices within the enterprise infrastructure. This chapter examines common features used to secure access to physical and logical interfaces and technologies used to effectively manage routing updates and control commonly exploited methods for gaining access into networking devices. It also examines what Simple Network Management Protocol (SNMP) is used for within a network and methods used to secure SNMP access to networking devices. Finally, it examines the HTTP server function that a Cisco router can perform, the security risks associated with it, and the methods used to protect the router if this function is used.

Enterprise Security Problems One of the major security problems that enterprises face today is that sophisticated and sometimes complicated security defenses are required to mitigate the newest threats posed by intruders and to provide a reduction in business vulnerabilities. Another major hurdle involves choosing whether or not a security solution is the proper fit for the business; a vast number of specialized products in the market only work in certain parts of the network and fail to provide a true end−to−end solution for the business. Security is a complicated subject in theory and in practice, and more often than not, is very difficult to implement, especially when the solution must provide end−to−end security. To provide the utmost security to your network, you must first have an idea of what it is you are trying to protect. You must then decide what type of intruders you are trying to protect yourself from. Intruders can take on many forms, including the following: • Current employees • Former employees • Employees that misuse the environment • Competitors • Thrill seekers The most common terms used today to identify an individual who uses a computer to engage in mischievous behavior are "hacker" and "cracker." A hacker is intensely interested in the innermost workings of any computer operating system. Most often, hackers are programmers. As such, they have advanced knowledge of operating systems and programming languages. They constantly seek further knowledge, freely share what they have discovered, and, almost never, intentionally 7

damage data. Hackers are sometimes referred to as white−hats. A cracker breaks into or violates the integrity of someone else's system with malicious intent. Crackers gain unauthorized access, destroy vital data, deny service to legitimate users, or basically cause problems for their targets. Crackers are sometimes referred to as black−hats.

Types of Threats The methods hackers and crackers use to gain unauthorized access into network devices are known as threats. Having a security problem is bad enough, but defying any effort to categorically group problems and define methods to protect against them, is the number, nature, and types of security threats that exist today. These defy any effort that attempts to categorically group and define methods to protect against problems. A generalized list of threats follows; the methods used to thwart these threats will be discussed later in this chapter as well as throughout this book: • Unauthorized access—A network intruder can gain unauthorized access to networking devices through a variety of means, three of which are as follows: ♦ Physical—If attackers have physical access to a machine, more often than not, they will be able to get in. The techniques used to gain access range from accessing the device via the console to physically taking apart the system. ♦ System—System access assumes that the intruder already has a user account on the system. Proper privileges should be granted to the user such that he or she is authenticated and authorized only to do that which is deemed to be a function of his or her job duties. ♦ Remote—Remote access involves intruders who attempt to penetrate the system remotely from across the Internet, through a dial−up connection, or on local or wide area network. This type of intruder usually has no account privileges. • Eavesdropping—Eavesdropping is used to capture TCP/IP or other protocol packets, thus allowing the intruder to decode the contents of the packet using a protocol analyzer. "Packet sniffing" is a more common term used to describe the act of eavesdropping. Eavesdropping leads to information theft, like stolen credit card and social security numbers. • Data manipulation—Data manipulation is simply the act of altering files on computers, vandalizing a Web site, or replacing FTP files. • Protocol weakness—The most−used protocol in circulation today is TCP/IP. This protocol was designed a long time ago. As a result, a number of its design flaws can lead to possible security problems, such as smurf attacks, IP spoofing, TCP sequence number prediction, and SYN floods. The IP protocol itself is a very trusting protocol; therefore, hackers are free to forge and change IP data. • Session replay—Intruders can eavesdrop on one or more users involved in a communication session and manipulate the data in such a manner according to the hack they are trying to perform. This list does not by any means include all of the types of security threats. Its purpose is to give you a general idea of the number and types of methods intruders have at their disposal.

Enterprise Security Challenges One the biggest challenges that IT managers face is choosing from among the vast number of security offerings and vendors in the market space. IT managers must weigh the cost of security products against things such as performance, manageability, and scalability. After sorting through each vendor, IT managers must choose the security solution that most uniquely adapts to and 8

satisfies their business environment. The solution that is chosen must not be overly restrictive and must allow the business to enable new applications, innovations, and services as needed, without unnecessary challenges. After IT managers choose a security solution that most adequately meets their specific needs, more often than not they find themselves having to develop a design that will allow them to smoothly integrate the solution into a network environment of products developed by different vendors. This usually adds to the cost of implementation and overall operation of the network. On top of that, IT managers must hire skilled security engineers or spend money from their budgets to adequately train their existing engineers to support the new technologies. After an organization's IT management has recognized the existence of security threats and has directed changes to improve its posture or information security process, they should formulate a plan to address the issue. The first step in implementing this plan is the development of a security policy.

Enterprise Security Policy Request for Comments (RFC) 2196, Site Security Handbook, states that "A security policy is a formal statement of rules by which people who are given access to an organization's technology and information must abide." A security policy should not determine how an enterprise operates; instead, the business of the enterprise should dictate how a security policy is written. Business opportunities are what drive the need for security in the first place. The main purpose of a security policy is to inform anyone that uses the enterprise's network of the requirements for protecting the enterprise's technology and information assets. The policy should specify the mechanisms through which these requirements can be met. Of all the documents an organization develops, the security policy is one of the most important. Prior to developing the security policy, you should conduct a risk assessment to determine the appropriate corporate security measures. The assessment helps to determine areas in which security needs to be addressed, how the security needs to be addressed, and the overall level of security that needs to be applied in order to implement adequate security controls. A risk assessment is a process whereby critical assets are identified and values are placed on the assets. You determine how much each asset is at risk of being compromised and how much you need to upgrade or add to it to meet your business needs. To develop a security policy that is not overly restrictive for users, that balances ease of use with a certain level of security, and that is enforceable both technically and organizationally, the policy should contain, at a minimum, some of the topics in the following list: • Acceptable use policy—Spells out what users are allowed and not allowed to do on the various components within the network; this includes the type of traffic allowed on the network. The policy should be as explicit as possible to avoid any ambiguity or misunderstanding. • Remote access policy—Spells out to users acceptable or unacceptable behavior when they have connected to the enterprise via the Internet, a dial−up connection, a virtual private network (VPN), or any other method of remote connectivity. • Incident handling policy—Addresses planning and developing procedures to handle incidents before they occur. This document also creates a centralized group to be the primary focus when an incident happens. The incident handling policy can be contained within the actual security policy, but due to corporate structure, this document often actually exists as a subdocument to the security policy. 9

• Internet access policy—Defines what the enterprise considers to be ethical, proper use of its Internet connection. • Email policy—Defines the acceptable use of the enterprise's email systems, including personal emails and Web−based email. • Physical security policy—Defines controls that pertain to physical device security and access. After you've completed the enterprise security policy, the last step is to perform regular audits. Audits not only give you a baseline by which to judge what is deemed as normal activity or network behavior, they also, in many cases, produce results that will be the first alert in the detection of a security breach. Noticing unusual events within the network can help to catch intruders before they can cause any further damage.

Securing the Enterprise The enterprise infrastructure is vulnerable to many different security threats (discussed earlier) from any number of intruders. The solution to the infrastructure security problem is to securely configure components of the network against vulnerabilities based on the network security policy. Most network security vulnerabilities are well known, and the measures used to counteract them will be examined in detail throughout this chapter. Physical and Logical Security Physical and logical security include the following: • Securing console access • Securing Telnet access • Setting privilege levels • Disabling password recovery • Configuring password encryption • Setting banner messages Securing Console Access

It's important to put the proper physical security mechanisms into place. If the proper physical security mechanisms are not in place, an intruder could potentially bypass all other logical security mechanisms and gain access to the device. If an intruder can gain access to the administrative interface of the router, he could view and change the device's configuration and gain access to other networking equipment. The first thing you should do to thwart intruders is to set a console password. If the intruder has already gained physical access to the device, he'll attempt to gain network access through the console port first. The console port supports many different methods for authenticating a user and allowing access, some of which are listed here: • Console password • Local user database • TACACS+ • RADIUS Securing Telnet Access

Telnet is a protocol that allows a user to establish a remote connection to a device. After connected to the remote device, you are presented with a screen that is identical to the screen that would be displayed if you were directly connected to the console port. Telnet ports on a router are referred to 10

as virtual terminal ports. Telnet is really no different from a console connection, and as such, the proper logical security mechanisms should be put into place to ensure that only responsible personnel are allowed Telnet access. Virtual terminal ports support many different methods for authenticating a user and allowing access. Some of the methods are included in the following list: • Vty password • Local user database • TACACS+ • RADIUS Setting Privilege Levels

Privilege levels associate router commands with each security level configured on the router. This allows for a finer granularity of control when restricting user access. There are 16 privilege levels contained within the router operating system. Level 2 to level 14 are customizable and allow you to configure multiple privilege levels and multiple passwords to enable certain users to have access to specific commands. Disabling Password Recovery

Setting passwords is the first line of defense against intruders. Sometimes passwords are forgotten and must be recovered. All Cisco password recovery procedures dictate that the user performs the password recovery process from the console port of the router or switch. There are, however, certain circumstances in which the widely available password recovery procedure should be disabled. One such circumstance is an emergency Add, Move, or Change (AMC), whereby a networking device needs to be in a location that does not have the proper mechanisms in place for physical security, thus allowing an intruder a greater chance of circumventing traditional security measures. Configuring Password Encryption

All Cisco console and Telnet passwords configured on the router are stored in plain text within the configuration of the router by default, thus making them easily readable. If someone issues the show running−config privileged mode command, the password is displayed. Another instance when the password can easily be read is if you store your configurations on a TFTP server, the intruder only needs to gain access into the TFTP machine, after which the intruder can read the configuration with a simple text editor. Password encryption stores passwords in an encrypted manner on the router. The encryption is applied to all configured passwords on the router. Setting Banner Messages

You can use banner messages to issue statements to users, indicating who is and who is not allowed access into the router. Banner messages should indicate the seriousness of an attempt to gain unauthorized access into the device and should never reflect to the user that gaining unauthorized access is acceptable. If possible, recite certain civil and federal laws that are applicable to unauthorized access and let users know what the punishment would be for accessing the device without express written permission. If possible, have certified legal experts within the company review the banner message. SNMP The Simple Network Management Protocol (SNMP) is an application−layer protocol that helps to facilitate the exchange of management information between network devices. SNMP enables 11

network administrators to manage network performance, find and solve network problems, and plan for network growth. An SNMP network consists of three key components: managed devices, agents, and network−management systems (NMSs). A managed device is a network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and make this information available to NMSs by use of the SNMP protocol. Managed devices can be routers, access servers, switches, computer hosts, or printers. An agent is a network−management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. An SNMP managed device has various access levels. These are as follows: • Read−only— Allows read access of the Management Information Base (MIB) on the managed device • Read/write—Allows read and write access of the Management Information Base on the managed device • Write−only—Allows write access of the Management Information Base on the managed device Routers can send notifications to NMS machines when a particular event occurs. The SNMP notifications can be sent as a trap or inform request. Traps are unreliable because the receiver does not send an acknowledgment that it received a trap. However, an NMS machine that receives an inform request acknowledges the message with an SNMP response. If the NMS does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more reliable. Cisco IOS software supports the following versions of SNMP: • SNMPv1 • SNMPv2c • SNMPv3 Both SNMPv1 and SNMPv2c use a community−based form of security. The group of managers able to access the agent is defined by an access list and password. SNMPv2c support includes a bulk retrieval mechanism and more detailed error−message reporting to management stations. The bulk retrieval mechanism supports the retrieval of large quantities of information, minimizing the number of polls required. The SNMPv2c improved error−handling support includes a larger number of error codes that distinguish different kinds of error conditions. Error return codes in SNMPv2c report the error type. SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level will determine which security mechanism is employed when an SNMP packet is handled. Routing Protocol Authentication Routing protocol authentication prevents the introduction of false or unauthorized routing messages from unapproved sources. With authentication configured, the router will authenticate the source of each routing protocol packet that it receives from its neighbors. Routers exchange an authentication key or a password that is configured on each router. The key or password must match between 12

neighbors. There are two types of routing protocol authentication: plain text authentication and Message Digest 5 (MD5) authentication. Plain text authentication is generally not recommended because the authentication key is sent across the network in clear text, making plain text authentication susceptible to eavesdropping attempts. MD5 authentication creates a hash value from the key; the hash value instead of the actual password is exchanged between neighbors, preventing the password from being read because the hash, not the password, is transmitted across the network. Routing Filters Route filtering enables the network administrator to keep tight control over route advertisements. Frequently, companies merge or form a partnership with other companies. This can pose a challenge because the companies need to be interconnected yet remain under separate administrative control. Because you do not have complete control over all parts of the network, the network can become vulnerable to malicious routing or misconfiguration. Route filters ensure that routers will advertise as well as accept legitimate networks. They work by regulating the flow of routes that are entered into or advertised out of the routing table. Filtering the networks that are advertised out of a routing process or accepted into the routing process helps to increase security because, if no route is advertised to a downstream or upstream neighbor, then no route apparently exists to the network. This will keep intruders from having logical connectivity to the target destination. It also increases the network stability to a certain degree. Misconfiguration is determined to be the largest contributor of network instability; however, an intruder could introduce into routing updates false information that could result in routing problems. Suppressing Routing Advertisements

To prevent routers on a local network from learning about routes that are dynamically advertised out on the interface, you can define the interface as passive. Defining an interface as passive keeps routing update messages from being sent through a router interface, preventing other systems on the interface from learning about routes dynamically from this router. You can configure a passive interface for all IP routing protocols except Border Gateway Protocol (BGP). In networks with large numbers of interfaces, you can set all interfaces to passive using the passive−interface default command. This feature allows the administrator to selectively determine over which interfaces the protocol needs to run. After the determination is made to allow the protocol to run on the interface, the administrator can disable the passive−interface feature on an interface−by−interface basis with the no passive−interface command. Note Making an interface passive for the Enhanced Interior Gateway Routing Protocol (EIGRP) disables route advertisements sent out the interface that was made passive, just as any other routing protocol; however, the interface will not listen for route advertisements either. HTTP Access Cisco IOS software on routers is equipped with a Web browser user interface that allows you to issue commands into the router via the Web interface. The Web browser user interface can be customized and tailored to your business environment. The HTTP server is disabled by default; when it's enabled, it introduces some new security vulnerabilities into your network. The HTTP server function, when it's enabled, gives all client devices with logical connectivity to the router the ability to monitor or modify the configuration of the router. All that needs to reside on the client is a software package that interprets packets on port 80. This is obviously a major security issue. 13

However, the router software allows you to change the default port that the HTTP server is running on. You can also configure an access list of specific hosts that are allowed Web access to the router and apply the access list to the HTTP server. Authentication of each user provides better security if you elect to use the router's HTTP server functions. Authentication can take place by one of four different methods: • AAA—Indicates that the AAA function is used for authentication. • Enable—Indicates that the configured enable password is used for authentication. This is the default authentication method. • Local—Indicates that the locally configured security database is used for authentication. • TACACS+—Indicates that the Terminal Access Controller Access system is used for authentication.

Immediate Solutions Configuring Console Security The console port is used to attach a terminal directly into the router. By default, no security is applied to the console port and the setup utility does not prompt you to configure security for console access. Cisco routers have many different modes of operation, one of which is user mode. When you first access the router via the console port, the router will prompt you for a password, if one has been configured. After successfully supplying the password, you are logged into user mode on the router. When a Cisco router is in user mode, the router will display its hostname followed by the greater than symbol. Here is an example of user mode access: SecureRouter>

User mode has limited functionality. Enable mode, also called privileged mode, can be accessed by typing the enable command. If passwords have been configured to access this level of the IOS, the router prompts you for the correct password. When a Cisco router is in enable mode, the router will display its hostname followed by the pound sign. Here is an example of enable mode access: SecureRouter#

Cisco passwords are case sensitive. The simplest and most direct way to connect to the network device is to use a direct connection to the console port of a router or switch. You can configure a console password to authenticate users for user mode access by entering the following commands: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#line con 0 SecureRouter(config−line)#password Coriolis SecureRouter(config−line)#login SecureRouter(config−line)#end

14

The preceding configuration sets the user mode password to Coriolis. Cisco routers also maintain a local user authentication database, which can be used to authenticate users who connect directly to the console port of a router. Here's an example of configuring the router to use the local user database for authentication of users who attempt to access the router via the console: ! username Fred privilege 15 password 0 Flintstone username Elroy privilege 12 password 0 Jetson username Captain privilege 8 password 0 Kirk ! line con 0 login local transport input none !

The preceding configuration defines three users: Fred, Elroy, and Captain. Each user has an associated privilege level defined for their respective login credentials and has a password that is associated with their username. This allows Fred to log into the router with a username of Fred and a password of Flintstone. Because Fred's privilege level defines the maximum privilege level that can be configured on the router, Fred is considered to be the super−user. Elroy has a privilege level of 12 and the password Jetson. Note Assignment of privilege levels is discussed in detail later in this chapter. By assigning Elroy a privilege of 12, the administrator can limit the functionality that Elroy may have on the router. That's also the case for Captain. When a user plugs into the console port of a router configured with local authentication, they are first prompted for their username; after successfully passing the correct username to the router, they are then prompted for the password that is associated with that username. The following example details these steps: User Access Verification Username: Fred Password: Flintstone SecureRouter#

Now, what do you think would happen if you were to attempt to log in with the username of Fred and the password that is associated with Elroy? You would suspect that the router would deny you access. This example details this attempt: User Access Verification Username: Fred Password: Jetson % Login invalid Username:

15

From this, you can see that you must supply the password that is associated with the username with which you are attempting to gain access. Warning

When using local authentication and assigning privilege levels, you must be careful to associate the correct username with the correct privilege level. Anyone who logs in with a privilege level that is equal to 2 or above is logged directly into privileged mode.

Configuring Telnet Security Directly connecting to the console of a router is generally a relatively easy method for gaining access to the device; however, this method is inconvenient and not abundantly scalable. If console access is the only method available to gain access into the device, an administrator must always walk, drive, or fly to the physical location of the router and plug into the device's console port. Fortunately, there are methods for gaining access into the router from a remote location. The most common method of remote administration for a Cisco router is to use a Telnet session. Unlike with console access, there are four configuration requirements that must be met before you can use this method of access: • An enable password must be supplied. This is discussed in the next section. • The router must have an IP address assigned to a routable interface. • The routing table of the router must contain a route for the source of the Telnet packet. • Under line configuration mode, a vty password must be supplied. The steps involved in defining Telnet security are similar to the steps used to configure console security. An example of configuring the fourth requirement (after the first three have been met) can be seen here: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#line vty 0 4 SecureRouter(config−line)#login SecureRouter(config−line)#password letmein SecureRouter(config−line)#end SecureRouter#

As mentioned in the preceding section, "Configuring Console Security," Cisco routers also maintain a local user authentication database, which can be used to authenticate users who directly connect to the console port of a router. Here is an example of configuring the router to use the local user database for authentication of users who attempt to access the router via the console: ! username Fred privilege 15 password 0 Flintstone username Elroy privilege 12 password 0 Jetson username Captain privilege 8 password 0 Kirk ! line vty 0 4 login local

The result is that, when a user telnets to the router with this configuration, they will be prompted to enter a username and password before being allowed to gain access into the router. 16

Routers can also restrict Telnet access to authorized users with the use of an access list. The access list is then applied to the virtual terminal ports of the router with the access−class command. This allows you to restrict Telnet access from a particular IP address or a subnet of IP addresses. Use the following steps to this method of security: 1. Use the access−list global configuration command to configure an access list that permits the specific hosts that are allowed Telnet access. 2. Use the access−class access−list−number {in|out} command to apply the access list to the virtual terminal ports. In the following example, the router is configured to allow only three hosts Telnet access on each of the available virtual terminal ports: Router−A#config t Enter configuration commands, one per line. End with CNTL/Z. Router−A(config)#access−list 10 permit 10.10.10.19 Router−A(config)#access−list 10 permit 10.10.11.20 Router−A(config)#access−list 10 permit 10.10.12.130 Router−A(config)#line vty 0 4 Router−A(config−line)#access−class 10 in Router−A(config−line)#end Router−A#

Note Remember, console and Telnet security is not preconfigured for you by default. One of your first configuration steps when you initially set up your router should be to configure each of these interfaces.

Configuring Enable Mode Security To configure enable mode access, you can use one of two commands: enable password or enable secret. Both commands accomplish the same thing, allowing access to enable mode. However, the enable secret command is considered to be more secure because it uses a one−way encryption scheme based on the MD5 hashing function. Only use the enable password command with older IOS images and/or boot ROMs that have no knowledge of the newer enable secret command. Note The MD5 encryption algorithm will be discussed in detail in Chapter 6. For now, just remember that this method is considered more secure. You configure an enable password by entering the enable password command in global configuration mode: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#enable password Omni−Pass01 SecureRouter(config)#end SecureRouter#

The preceding configuration sets the enable password to Omni−Pass01. The result of setting the enable password can be seen in the following output. From the user mode prompt, you must enter the enable command to gain access into privileged mode: 17

SecureRouter>enable Password: Omni−Pass01 SecureRouter#

Note

After you enter the enable command, the password you type at the password prompt will not be displayed. Be sure to type the password exactly as it is configured in the enable password command.

You configure an enable secret password by entering the following command in global configuration mode: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#enable secret Long@Horn10 SecureRouter(config)#end SecureRouter#

The preceding configuration sets the enable secret password to Long@Horn10. The result of setting the enable secret password can be seen in the following output. From the user mode prompt, you must enter the enable command to gain access into privileged mode, as follows: SecureRouter>enable Password: Long@Horn10 SecureRouter#

Note

After you enter the enable command, the password you type at the password prompt will not be displayed. Be sure to type the password exactly as it is configured in the enable password command.

Disabling Password Recovery The first line of defense against intruders is to set passwords on routers. Sometimes passwords are forgotten and must be recovered. There are, however, some instances in which the widely known password recovery procedures should be disabled. When physical security is not possible or in a network emergency, password recovery can be disabled. Note Password recovery on routers and switches is outside the scope of this book. However, if you need an index of password recovery procedures for Cisco network devices, see the following Cisco Web page: http://www.cisco.com/warp/public/474. The key to recovering a password on a Cisco router is through manipulation of the configuration registers of the router. All router passwords are stored in the startup configuration, so if the configuration registers are changed properly, the startup configuration with the passwords stored within them can be bypassed. If you have disabled the password recovery mechanisms, you will not be able to perform password recovery on the router. Disabling the password recovery procedure of a Cisco router is a decision that must be thought out ahead of time because the command used to disable password recovery also disables ROMMON.

18

Warning The command discussed in this section is not recommended for use on any production router and is explained here only for the benefit of learning within a lab environment. You can disable the Cisco password recovery procedure by issuing the no service password−recovery command in global configuration mode: SecureRouter#config t Enter configuration commands, one per line. End with CNTR/Z. SecureRouter(config)#no service password−recovery WARNING: Executing this command will disable password recovery mechanism. Do not execute this command without another plan for password recovery. Are you sure you want to continue? [yes/no]: yes

As you can see, the IOS reminds you of how serious disabling the password recovery procedures are with a warning message and a prompt allowing you to change your mind. To see the results of changing the password recovery feature, issue the show running−config command. The effects of issuing the command can be seen in the following configuration: SecureRouter#show run Building configuration... Current configuration: ! version 12.0 service password−encryption no service password−recovery ! hostname SecureRouter

After password recovery has been disabled and the configuration has been saved, the widely available password recovery procedure will not be available on the router. The following output verifies that password recovery is indeed disabled: SecureRouter#reload Proceed with reload? [confirm] 00:14:34: %SYS−5−RELOAD: Reload requested System Bootstrap, Version 11.3(2)XA4, RELEASE SOFTWARE (fc1) Copyright (c) 1999 by cisco Systems, Inc. TAC:Home:SW:IOS:Specials for info PC = 0xfff14ee8, Vector = 0x500, SP = 0x680127b0 C2600 platform with 49152 Kbytes of main memory PASSWORD RECOVERY FUNCTIONALITY IS DISABLED program load complete, entry point: 0x80008000, size: 0x928024 Self decompressing the image : #######################....

Warning

The use of the command discussed in this section is not recommended for a production router. It should be used only in extreme circumstances or in a lab environment! 19

If the no service password−recovery command has been issued on a Cisco router and the passwords have been forgotten, you must contact your Cisco Technical Support Engineer to obtain help in gaining access into the router and enabling the password recovery process again.

Configuring Privilege Levels for Users As mentioned earlier, the Cisco IOS software has two modes of operation. You can configure up to 16 levels of commands for each mode, which allows you to selectively assign authority on a per−user basis. Commands entered into the IOS can be associated with each privilege level. You configure the privilege level for a command using the global configuration command privilege level . The exact syntax of this command is as follows: privilege mode level level command | reset command

Figure 1.1 displays three users, Cindy, Marsha, and Jan, connected to a local segment. Cindy is the network engineer; she has full control over Router A. Marsha and Jan are system administrators; they need only limited functionality on Router A. Here is an example of the configuration that meets this requirement: enable secret Cindy enable secret level 3 Marsha enable secret level 2 Jan privilege exec level 3 debug privilege exec level 3 show running−config privilege exec level 3 telnet privilege exec level 2 ping privilege exec level 2 sh int ser0 privilege exec level 2 sh ip route line con 0 login

Figure 1.1: Using privilege levels to create administrative levels. This configuration provides Cindy with the default full administrative rights to the router. Marsha is given access to all features that are allowed with administrative level 3 and can perform the 20

commands that are listed with a privilege level of 3. Jan is assigned a privilege level of 2 and is given access to all features and allowed to perform the commands listed with a privilege level of 2. The key is that each user must use the enable command from the user mode prompt and log in with the password assigned for that level. An example is provided here: SecureRouter> SecureRouter>enable 3 Password: Marsha SecureRouter#

Configuring Password Encryption It's relatively simple to configure password encryption on Cisco routers. When password encryption is configured, all passwords that are configured on the router are converted to an unsophisticated reversible cipher. Although the algorithm that is used to convert the passwords is somewhat unsophisticated, it still serves a very good purpose. Intruders cannot simply view the password in plain text and know what the password is. To enable the use of password encryption, use the command service password−encryption. The following example shows a router configuration prior to enabling password encryption. An enable password, a console password, and a Telnet password is configured: SecureRouter#show running−config ! enable password Cisco ! line con 0 password Networking ! line vty 0 4 password Security !

The following example shows the command you would use to enable password encryption on the router: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#service password−encryption SecureRouter(config)#end SecureRouter#

The results of enabling password encryption can be seen in the following example. Notice that each password is now represented by a string of letters and numbers, which represents the encrypted format of the password: SecureRouter#show running−config ! enable password 7 05280F1C2243 !

21

line con 0 password 7 04750E12182E5E45001702 ! line vty 0 4 password 7 122A00140719051033 !

Warning Password encryption does not provide a very high level of security. There are widely available passwords crackers that can reverse the encryption. I do, however, recommend using the password encryption command on all routers. I also recommend that you take additional security measures to protect your passwords.

Configuring Banner Messages As mentioned in the section "In Brief" at the beginning of this chapter, you can display banner messages to users who are attempting to gain access to the router. There are four types of banner messages: • Message of the Day (MOTD)—Displayed at login. Useful for sending messages that affect all network users. • Login—Displayed after the Message of the Day banner appears and before the login prompts. • EXEC—Displayed whenever an EXEC process is initiated. • Incoming—Displayed on terminals connected to reverse Telnet lines. The process for configuring banner messages is fairly simple. Enter the following command in global configuration mode: banner {exec|motd|login|incoming} [delimited character] – [delimited character]

Here is a sample MOTD banner: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#banner motd # Enter TEXT message. End with the character '#'. ******************************************************* * WARNING...WARNING...WARNING...WARNING * * YOU HAVE ACCESSED A RESTRICTED DEVICE * * USE OF THIS DEVICE WITHOUT PRIOR AUTHORIZATION * * OR FOR PURPOSES WHICH AUTHORIZATION HAS NOT BEEN * * GRANTED IS STRICTLY PROHIBITED!!! * ******************************************************* # SecureRouter(config)#end SecureRouter#

22

The results of setting the MOTD banner message can be seen by using the show running−config command or by logging into the router. The following is an example of logging into the router from the console port: SecureRouter con0 is now available ...... Press RETURN to get started. ...... ******************************************************* * WARNING...WARNING...WARNING...WARNING * * YOU HAVE ACCESSED A RESTRICTED DEVICE * * USE OF THIS DEVICE WITHOUT PRIOR AUTHORIZATION * * OR FOR PURPOSES WHICH AUTHORIZATION HAS NOT BEEN * * GRANTED IS STRICTLY PROHIBITED!!! * ******************************************************* SecureRouter>

EXEC banner messages, as mentioned earlier, are invoked when a user attempts to gain access into privileged mode. (Accessing privileged mode was explained in "Configuring Enable Mode Security" earlier in this chapter.) Industry−standard best practices recommend configuring a MOTD banner message as well as an EXEC banner message. Working still on the same router, here's how to configure an EXEC banner to complement the MOTD banner. This can be accomplished using the following configuration: SecureRouter#config t Enter configuration commands, one per line. End with CNTL/Z. SecureRouter(config)#banner exec # Enter TEXT message. End with the character '#'. ******************************************************* * WARNING...WARNING...WARNING...WARNING * * * * THIS IS A REMINDER...THIS IS A REMINDER * * * * YOU HAVE ACCESSED A RESTRICTED DEVICE * * USE OF THIS DEVICE WITHOUT PRIOR AUTHORIZATION * * OR FOR PURPOSES WHICH AUTHORIZATION HAS NOT BEEN * * GRANTED IS STRICTLY PROHIBITED!!! * ******************************************************* # SecureRouter(config)#end SecureRouter#

The results of setting the EXEC message can be seen by using the show running−config command or by using the telnet command to remotely connect to a router with the EXEC banner enabled. The results of configuring both the MOTD banner and the EXEC banner can be seen here: R1#telnet 192.168.10.1 Trying 192.168.10.1 ... Open ******************************************************* * WARNING...WARNING...WARNING...WARNING * * YOU HAVE ACCESSED A RESTRICTED DEVICE * * USE OF THIS DEVICE WITHOUT PRIOR AUTHORIZATION * * OR FOR PURPOSES WHICH AUTHORIZATION HAS NOT BEEN * * GRANTED IS STRICTLY PROHIBITED!!! *

23

******************************************************* User Access Verification Username: Fred Password: ******************************************************* * WARNING...WARNING...WARNING...WARNING * * * * THIS IS A REMINDER...THIS IS A REMINDER * * * * YOU HAVE ACCESSED A RESTRICTED DEVICE * * USE OF THIS DEVICE WITHOUT PRIOR AUTHORIZATION * * OR FOR PURPOSES WHICH AUTHORIZATION HAS NOT BEEN * * GRANTED IS STRICTLY PROHIBITED!!! * ******************************************************* SecureRouter>en Password: SecureRouter#

Notice that the EXEC banner is displayed after the user has passed the local authentication phase on the router.

Configuring SNMP Security There is no specific command that you use to enable SNMP. To configure SNMP support, perform the tasks described in the following steps, only the first two steps are mandatory: 1. Enable the SNMP community string to define the relationship between the network management station and the agent with the following command: snmp−server community {ro|rw} {number}

The number value references an optional access−list. 2. Use this command to configure the router to send traps to an NMS host: snmp−server host host [version {1|2c}]

3. Configure the type of traps for which a notification is sent to the NMS. You do so with the following command: snmp−server enable traps [notification type] – [notification option]

4. Set the system contact, location, and serial number. You can set the systems contact with the snmp−server contact [text] command. You set the location with the snmp−server location [text] command, and you set the serial number with the snmp−server chassis−id [text] command. 5. Use the access−list command to specify a list of hosts that are allowed read−, read/write, or write−only access to the router. Figure 1.2 shows Router A, which is configured to allow SNMP read−only access and read/write access from two separate hosts. Router A is also configured to send SNMP trap information to the same two hosts. The following lines show how Router A should be configured so SNMP access 24

from both host 192.168.40.1 and 192.168.40.2 is allowed and SNMP trap information is sent to both hosts: access−list access−list snmp−server snmp−server snmp−server snmp−server snmp−server snmp−server snmp−server

12 permit 192.168.40.1 13 permit 192.168.40.2 contact Harris location Network Engineering chassis−id 100000333 community observe RO 12 community adjust RW 13 host 192.168.40.1 observe snmp host 192.168.40.2 adjust snmp

Figure 1.2: Router A configured for SNMP.

Configuring RIP Authentication There are two versions of Routing Information Protocol (RIP): version 1 and version 2. RIP version 1 does not support authentication of routing updates; however, RIP version 2 supports both plain text and MD5 authentication. Figure 1.3 shows two routers, Router A and Router B, that exchange RIP version 2 MD5 authentication updates.

Figure 1.3: Router A and Router B configured for RIP authentication. Configuring authentication of RIP version 2 updates is fairly easy and very uniform. The basic configuration includes the following steps: 25

1. Define the key chain using the command key−chain < name> in global configuration mode. This command transfers you to the key chain configuration mode. 2. Specify the key number with the key < number> command in key chain configuration mode. You can configure multiple keys. 3. For each key, identify the key string with the key−string < string> command. 4. Configure the period for which the key can be sent and received. Use the following commands: accept−lifetime {infinite|end−time|duration − seconds} send−lifetime {infinite|end−time|duration seconds}

5. Exit key chain configuration mode with the exit command. 6. Under interface configuration mode, enable the authentication of RIP updates with this command: ip rip authentication key−chain

This command is all that is needed to use plain text authentication. 7. Optionally, under interface configuration mode, enable MD5 authentication of RIP updates using the ip rip authentication mode md5 command. The listings that follow show how Router A and Router B in Figure 1.3 should be configured to authenticate updates from one another using RIP MD5 authentication. Listing 1.1 shows the configuration of Router A, and Listing 1.2 shows the configuration of Router B. Listing 1.1: Router A's configuration with MD5 authentication. key chain systems key 1 key−string router ! interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip rip authentication mode md5 ip rip authentication key−chain systems clockrate 64000 ! router rip version 2 network 10.0.0.0 network 192.168.10.0 no auto−summary

Listing 1.2: Router B's configuration with MD5 authentication. key chain cisco key 1 key−string router ! interface Loopback0 ip address 10.10.12.1 255.255.255.0 !

26

interface FastEthernet0/0 ip address 10.10.13.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ip rip authentication mode md5 ip rip authentication key−chain cisco ! router rip version 2 network 10.0.0.0 network 192.168.10.0 no auto−summary

The configuration in Listing 1.1 displays Router A's MD5 configuration. Router A is configured with a key chain value of systems, a key value of 1, and a key−string value of router. Listing 1.2 displays Router B's MD5 configuration. Router B is configured with a key chain value of cisco, a key value of 1, and a key−string value of router. Note Notice that the key−chain command of each router can have a different value; however, the key−string command must match for each key that is configured on each neighbor. You can use the command debug ip rip to examine how RIP receives the encrypted routing updates. Entering this command on Router A and Router B displays the output shown in Listing 1.3 and Listing 1.4, respectively. Listing 1.3: The output of the command debug ip rip displays how Router A receives RIP routing updates from Router B. Router−A#debug ip rip RIP protocol debugging is on Router−A# RIP: received packet with MD5 authentication RIP: received v2 update from 192.168.10.2 on Serial0/0 10.10.12.0/24 −> 0.0.0.0 in 1 hops 10.10.13.0/24 −> 0.0.0.0 in 1 hops

Listing 1.4: The output of the command debug ip rip displays how Router B receives RIP routing updates from Router A. Router−B#debug ip rip RIP protocol debugging is on Router−B# RIP: received packet with MD5 authentication RIP: received v2 update from 192.168.10.1 on Serial0/0 10.10.10.0/24 via 0.0.0.0 in 1 hops 10.10.11.0/24 via 0.0.0.0 in 1 hops

Configuring EIGRP Authentication EIGRP authentication of packets has been supported since IOS version 11.3. EIGRP route authentication is similar to RIP version 2, but EIGRP authentication supports only the MD5 version of packet encryption. 27

EIGRP's authentication support may at first seem limited, but plain text authentication should be configured only when neighboring routers do not support MD5. Because EIGRP is a proprietary routing protocol developed by Cisco, it can be spoken only between two Cisco devices, so the issue of another neighboring router not supporting the MD5 cryptographic checksum of packets should never arise. The steps for configuring authentication of EIGRP updates are similar to the steps for configuring RIP version 2 authentication: 1. Define the key chain using the command key−chain < name> in global configuration mode. This command transfers you to the key chain configuration mode. 2. Specify the key number with the key command in key chain configuration mode. You can configure multiple keys. 3. For each key, identify the key string with the key−string command. 4. Optionally, you can configure the period for which the key can be sent and received. Use the following commands: accept−lifetime {infinite|end−time|duration − seconds} send−lifetime {infinite|end−time|duration seconds}

5. Exit key chain configuration mode with the exit command. 6. Under interface configuration mode, enable the authentication of EIGRP updates with this command: ip authentication key−chain eigrp

7. Enable MD5 authentication of EIGRP updates using the following command: ip authentication mode eigrp md5

Listing 1.5 shows how Router A should be configured to authenticate updates from Router B using EIGRP MD5 authentication, and Listing 1.6 shows the configuration for Router B. Listing 1.5: Router A's configuration with MD5 authentication. key chain router−a key 1 key−string eigrp ! interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip authentication mode eigrp 2 md5 ip authentication key−chain eigrp 2 router−a clockrate 64000 ! router eigrp 2 network 10.0.0.0 network 192.168.10.0 no auto−summary eigrp log−neighbor−changes

28

Listing 1.6: Router B's configuration with MD5 authentication. key chain router−b key 1 key−string eigrp ! interface Loopback0 ip address 10.10.12.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.13.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ip authentication mode eigrp 2 md5 ip authentication key−chain eigrp 2 router−b clockrate 64000 ! router eigrp 2 network 10.0.0.0 network 192.168.10.0 no auto−summary eigrp log−neighbor−changes

Listing 1.5 configures Router A with a key chain value of router−a, a key value of 1, and a key−string value of eigrp. Listing 1.6 configures Router B with a key chain value of router−b, a key value of 1, and a key−string value of eigrp. Notice again that the key chain need not match between routers; however, the key number and the key string associated with the key value must match between routers configured to use that key value. Although debugging of encrypted EIGRP packets is somewhat limited, a few commands can be used to verify that packet encryption is taking place correctly. Two of those commands are debug eigrp packet and show ip route. The debug eigrp packet command informs you if the router has received a packet with the correct key value and key string. The output of issuing this command can be seen here: Router−A#debug eigrp packet EIGRP Packets debugging is on (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK) Router−A# EIGRP: received packet with MD5 authentication EIGRP: received packet with MD5 authentication

Router A is receiving MD5−authenticated packets from it neighbor, Router B. However, we cannot fully determine whether or not the authentication is taking place correctly without issuing the show ip route command on Router A. This allows us to look at the route table and determine that packet authentication is taking place correctly because the routes that Router B has sent to Router A are installed into the route table. Listing 1.7 displays the output of the show ip route command. Listing 1.7: Route table of Router A with correct authentication configured. Router−A#sh ip route ... C 192.168.10.0/24 is directly connected, Ethernet0/0 C 10.10.10.0 is directly connected, Loopback0

29

C 10.10.11.0 is directly connected, Ethernet0/0 D 10.10.12.0 [90/409600] via 192.168.10.2, 00:18:36, Serial0/0 D 10.10.13.0 [90/409600] via 192.168.10.2, 00:18:36, Serial0/0 Router−A#

You can change Router A's key−string value for key 1 to see what kind of an effect this will have. The following lines will change the key−string value for key 1 on Router A to ospf: Router−A#config t Enter configuration commands, one per line. End with CNTL/Z. Router−A(config)#key chain router−a Router−A(config−keychain)#key 1 Router−A(config−keychain−key)#key−string ospf Router−A(config−keychain−key)#end Router−A#

Now that Router A has a different key string associated with key 1, you would assume that packet authentication is not taking place correctly. By issuing the debug eigrp packet command, you can see that there is indeed a problem with authentication: Router−A#debug eigrp packet EIGRP Packets debugging is on (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK) Router−A# EIGRP: received packet with MD5 authentication EIGRP: ignored packet from 192.168.10.2 opcode = 5 (invalid authentication)

Taking a quick look at the route table confirms that the authentication is incorrectly configured. Now that the key strings are different, no routes from Router B are installed into the route table of Router A. Listing 1.8 displays the routing table of Router A. Listing 1.8: Route table of Router A with incorrect authentication configured. Router−A#sh ip route ... C 192.168.10.0/24 is directly connected, Ethernet0/0 10.0.0.0/24 is subnetted, 2 subnets C 10.10.10.0 is directly connected, Loopback0 C 10.10.11.0 is directly connected, Loopback1 Router−A#

Tip You can also issue the show ip eigrp neighbor command to determine if authentication is configured correctly. If authentication is correctly configured, the neighboring router will be displayed in the output of the command. If authentication is incorrectly configured, the neighbor will not be displayed in the output.

30

Configuring OSPF Authentication Open Shortest Path First (OSPF) supports two forms of authentication: plain text and MD5. Plain text authentication should be used only when neighboring devices do not support the more secure MD5 authentication. To configure plain text authentication of OSPF packets, follow these steps: 1. In interface configuration mode, use the ip ospf authentication−key command. The key that is specified is the plain text password that will be used for authentication. 2. Enter OSPF configuration mode using the router ospf command. Then use the area authentication command to configure plain text authentication of OSPF packets for an area. Referring to Figure 1.4, we will configure Router A and Router B for plain text authentication of OSPF packets. Listing 1.9 and Listing 1.10 display each router's configuration.

Figure 1.4: Router A and Router B configured for OSPF authentication. Listing 1.9: Router A configured to authenticate OSPF packets using plain text authentication. interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip ospf authentication−key security clockrate 64000 router ospf 60 area 0 authentication network 10.10.10.0 0.0.0.255 area 10 network 10.10.11.0 0.0.0.255 area 11 network 192.168.10.0 0.0.0.255 area 0

Listing 1.10: Router B configured to authenticate OSPF packets using plain text authentication. interface Loopback0 ip address 10.10.12.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.13.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ip ospf authentication−key security router ospf 50 area 0 authentication network 10.10.12.0 0.0.0.255 area 12 network 10.10.13.0 0.0.0.255 area 13 network 192.168.10.0 0.0.0.255 area 0

31

In Listing 1.9 and Listing 1.10, plain text authentication is configured to authenticate updates across area 0. By issuing the show ip ospf command, you can determine if plain text authentication is properly configured for each area. Here is an example of the output for the show ip ospf command: Router−B#show ip ospf 50 Routing Process "ospf 50" with ID 10.10.13.1 ...... Area BACKBONE(0) Number of interfaces in this area is 1 Area has simple password authentication SPF algorithm executed 7 times

To configure MD5 authentication of OSPF packets, follow the steps outlined here: 1. From interface configuration mode, enable the authentication of OSPF packets using MD5 with the following command: ip ospf message−digest−key md5

The value of the key−id allows passwords to be changed without having to disable authentication. 2. Enter OSPF configuration mode using the router ospf command. Then configure MD5 authentication of OSPF packets for an area using this command: area authentication message−digest

This time, Routers A and B will be configured to authenticate packets across the backbone using the MD5 version of authentication. Listing 1.11 shows the configuration for Router A, and Listing 1.12 shows Router B's configuration. Listing 1.11: Router A configured for MD5 authentication. interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip ospf message−digest−key 15 md5 miller clockrate 64000 router ospf 60 area 0 authentication message−digest network 10.10.10.0 0.0.0.255 area 10 network 10.10.11.0 0.0.0.255 area 11 network 192.168.10.0 0.0.0.255 area 0

Listing 1.12: Router B configured for MD5 authentication. interface Loopback0 ip address 10.10.12.1 255.255.255.0

32

! interface Ethernet0/0 ip address 10.10.13.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ip ospf message−digest−key 15 md5 miller router ospf 50 area 0 authentication message−digest network 10.10.12.0 0.0.0.255 area 12 network 10.10.13.0 0.0.0.255 area 13 network 192.168.10.0 0.0.0.255 area 0

When you use the ip ospf message−digest−key command, the key value allows the password to be changed without having to disable authentication. Note For OSPF, authentication passwords do not have to be the same throughout the area, but the key id value and the password must be the same between neighbors. Using the show ip ospf command again, you can see that it now states that MD5 authentication is being used across area 0: Router−A#sh ip ospf 60 Routing Process "ospf 60" with ID 10.10.11.1 ...... Area BACKBONE(0) Number of interfaces in this area is 1 Area has message digest authentication SPF algorithm executed 4 times

As noted earlier, the key id value and the passwords must be the same between neighbors. If you change the key id value to a number other than 15 on Router A, authentication should not take place and OSPF should get mad. Here is the changed configuration: interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip ospf message−digest−key 30 md5 miller clockrate 64000 router ospf 60 area 0 authentication message−digest network 10.10.10.0 0.0.0.255 area 10 network 10.10.11.0 0.0.0.255 area 11 network 192.168.10.0 0.0.0.255 area 0

Notice that it has been changed to a value of 30. The following lines show what OSPF has to say about this: Router−A#debug ip ospf events OSPF events debugging is on Router−A# 00:03:58: OSPF: Send with youngest Key 30

33

00:04:04: OSPF: Rcv pkt from 192.168.10.2, Ethernet0/0 : Mismatch Authentication Key − No message digest key 15 on Interface

OSPF is obviously not happy. If you change the key value back, everything should again be all right. As mentioned earlier, the key id value allows passwords to be changed without having to disable authentication. Listing 1.13 and Listing 1.14 display the configuration of Router A and Router B with multiple keys and passwords configured. Listing 1.13: Router A configured with multiple keys and passwords. interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.11.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ip ospf message−digest−key 15 md5 miller ip ospf message−digest−key 20 md5 ampaq clockrate 64000 router ospf 60 area 0 authentication message−digest network 10.10.10.0 0.0.0.255 area 10 network 10.10.11.0 0.0.0.255 area 11 network 192.168.10.0 0.0.0.255 area 0

Listing 1.14: Router B configured with multiple keys and passwords. interface Loopback0 ip address 10.10.12.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.13.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ip ospf message−digest−key 15 md5 miller ip ospf message−digest−key 20 md5 ampaq router ospf 50 area 0 authentication message−digest network 10.10.12.0 0.0.0.255 area 12 network 10.10.13.0 0.0.0.255 area 13 network 192.168.10.0 0.0.0.255 area 0

As a result of this configuration, Routers A and B will send duplicate copies of each OSPF packet out of their serial interfaces; one will be authenticated using key number 15, and the other will be authenticated using key number 20. After the routers each receive from each other OSPF packets authenticated with key 20, they will stop sending packets with the key number 15 and use only key number 20. At this point, you can delete key number 15, thus allowing you to change passwords without disabling authentication.

34

Configuring Route Filters Route filters work by regulating what networks a router will advertise out of an interface to another router or what networks a router will accept on an interface from another router. Route filtering can be used by administrators to manually assure that only certain routes are announced from a specific routing process or interface. This feature allows administrators to configure their routers to prevent malicious routing attempts by intruders. You can configure route filtering in one of two ways: • Inbound route filtering—The router can be configured to permit or deny routes advertised by a neighbor from being installed to the routing process. • Outbound route filtering—The route filter can be configured to permit or deny routes from being advertised from the local routing process, preventing neighboring routers from learning the routes. Configuring Inbound Route Filters The steps for configuring inbound route filters are as follows: 1. Use the access list global configuration command to configure an access−list that permits or denies the specific routes that are being filtered. 2. Under the routing protocol process, use the following command: distribute−list in [interface−name]

In this example, an inbound route filter will be configured on Router B to deny routes from being installed into its routing process (refer to Figure 1.5). Listing 1.15 displays Router A's configuration prior to applying the route filter, and Listing 1.16 displays Router B's.

Figure 1.5: Router B configured with an inbound route filter. Listing 1.15: Router A configuration. interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Loopback1 ip address 10.10.11.1 255.255.255.0 ! interface Ethernet0/0 ip address 10.10.12.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 clockrate 64000 !

35

router rip version 2 network 10.0.0.0 network 192.168.10.0 no auto−summary

Listing 1.16: Router B configuration. interface Loopback0 ip address 10.10.13.1 255.255.255.0 ! interface Loopback1 ip address 10.10.14.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.10.15.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ! router rip version 2 network 10.0.0.0 network 192.168.10.0 no auto−summary

Taking a look at the route table of Router B, notice that it has learned of three networks from Router A: 10.10.10.0, 10.10.11.0, and 10.10.12.0. Listing 1.17 displays Router B's route table. Listing 1.17: Router B's route table. Router−B#show ip route ...... C 10.10.13.0 is directly C 10.10.14.0 is directly C 10.10.15.0 is directly R 10.10.10.0 [120/1] via R 10.10.11.0 [120/1] via R 10.10.12.0 [120/1] via

connected, Loopback0 connected, Loopback1 connected, FastEthernet0/0 192.168.10.1, 00:00:16, Serial0/0 192.168.10.1, 00:00:16, Serial0/0 192.168.10.1, 00:00:16, Serial0/0

Router−B#

Now, a route filter will be configured on Router B to deny the 10.10.10.0 and 10.10.11.0 networks from being installed into the route table. This will allow only the 10.10.12.0 network to be installed into the route table from Router A. Use the access−list command to configure the router with a standard access list and use the distribute−list in command to apply the access list under the routing process. Listing 1.18 displays Router B's new configuration. Listing 1.18: Router B configured with an inbound route filter. ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ! router rip version 2 network 10.0.0.0

36

network 192.168.10.0 distribute−list 1 in Serial0/0 no auto−summary ! access−list 1 permit 10.10.12.0

Looking back again at Router B's route table after applying the route filter, you can see that the 10.10.12.0 network is the only network that Router B is allowing to be installed into its route table. Listing 1.19 displays Router B's route table. Note Access lists have an implicit deny any as the last configuration line that is not displayed in the output of the configuration. Therefore, there is no need to manually configure the access list to deny the .10 and .11 networks. Listing 1.19: Router B's route table with inbound route filter permitting only one network. Router−B#show ip route ...... C 10.10.13.0 is directly C 10.10.14.0 is directly C 10.10.15.0 is directly R 10.10.12.0 [120/1] via

connected, Loopback0 connected, Loopback1 connected, FastEthernet0/0 192.168.10.1, 00:00:16, Serial0/0

Router−B#

Now, suppose Router A needs to learn only the 10.10.15.0 network from Router B and not the 10.10.13.0 and 10.10.14.0 networks. You can configure an inbound router filter on Router A to permit the installation of only the 10.10.15.0 network into the route table. Listing 1.15 displays Router A's configuration prior to the configuration change. Listing 1.20 displays the route table on Router A prior to the configuration change. Listing 1.20: Route table of Router A. Router−A#show ip route ...... C 10.10.10.0 is directly C 10.10.11.0 is directly C 10.10.12.0 is directly R 10.10.13.0 [120/1] via R 10.10.14.0 [120/1] via R 10.10.15.0 [120/1] via Router−A#

connected, Loopback0 connected, Loopback1 connected, Ethernet0/0 192.168.10.2, 00:00:17, Serial0/0 192.168.10.2, 00:00:17, Serial0/0 192.168.10.2, 00:00:17, Serial0/0

Listing 1.21 displays the configuration change needed on Router A. Listing 1.21: Router A configured with an inbound route filter. interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ! router rip version 2 network 10.0.0.0 network 192.168.10.0

37

distribute−list 1 in Serial0/0 no auto−summary ! access−list 1 permit 10.10.15.0

Taking another look at Router A's route table, you can see that the only network that is permitted into the route table is the 10.10.15.0 network. Listing 1.22 displays Router A's route table after the inbound route filter had been applied. Listing 1.22: Router A's route table with inbound route filter permitting only one network. Router−A#show ip route ...... C 10.10.10.0 is directly C 10.10.11.0 is directly C 10.10.12.0 is directly R 10.10.15.0 [120/1] via Router−A#

connected, Loopback0 connected, Loopback1 connected, Ethernet0/0 192.168.10.2, 00:00:17, Serial0/0

Configuring Outbound Route Filters In the preceding section, you learned how to configure a router to accept only routes that the administrator deems necessary. However, Router A advertised the 10.10.10.0 and 10.10.11.0 networks all the way across the network only to have them dropped upon reaching Router B. Router B did the same with networks 10.10.13.0 and 10.10.14.0. The same results can be accomplished by configuring an outbound route filter. This filter will not allow the route to advertised across the network and gives the administrator finer granularity of control for advertising networks to external partners. The steps to configure outbound route filters are described here: 1. Use the access−list global configuration command to configure an access list that permits or denies the specific routes that are being filtered. 2. Under the routing protocol process, use the following command: distribute−list access−list−number out [interface−name| − routing − process|autonomous−system−number]

Continuing with the example, in the last section, you can configure Router A and Router B to accomplish the same results, using the reverse logic of inbound route filters and configure an outbound route filter. Router A, in Listing 1.22, was configured to accept only the 10.10.15.0 network into its routing process, and Router B was configured to accept only the 10.10.12.0 network into its routing process. This was accomplished by configuring an inbound route filter on each respective router. However, a kind of reverse logic will be used in this next example to achieve the exact same result. Listing 1.23 and Listing 1.24 display Router A's and Router B's configuration prior to making the necessary changes. Listing 1.23: Router A's configuration. interface Loopback0 ip address 10.10.10.1 255.255.255.0 ! interface Loopback1 ip address 10.10.11.1 255.255.255.0 ! interface Ethernet0/0

38

ip address 10.10.12.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.1 255.255.255.252 clockrate 64000 ! router eigrp 50 network 10.0.0.0 network 192.168.10.0 no auto−summary eigrp log−neighbor−changes

Listing 1.24: Router B's configuration. interface Loopback0 ip address 10.10.13.1 255.255.255.0 ! interface Loopback1 ip address 10.10.14.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.10.15.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ! router eigrp 50 network 10.0.0.0 network 192.168.10.0 no auto−summary eigrp log−neighbor−changes

Notice that both routers are now using a different routing protocol. This was done to demonstrate that route filters work with any routing protocol. First, Router A will be configured such that it will advertise only the 10.10.12.0 network to Router B. This can be accomplished using the commands in Listing 1.25. Listing 1.25: Router A configured with an outbound route filter. interface Serial0/0 ip address 192.168.10.1 255.255.255.252 ! router eigrp 50 network 10.0.0.0 network 192.168.10.0 distribute−list 3 out Serial0/0 no auto−summary ! access−list 3 permit 10.10.12.0

Router A is configured with access list 3, which permits only the 10.10.12.0 network and has an outbound distribute−list applied to the EIGRP routing process. This should achieve the necessary results. You can check to see if the results have been met by looking at the route table of Router B, which is displayed in Listing 1.26. Listing 1.26: Route table of Router B after applying an outbound route filter on Router A.

39

Router−B#show ip route ...... D 10.10.12.0 [90/409600] C 10.10.13.0 is directly C 10.10.14.0 is directly C 10.10.15.0 is directly Router−B#

via 192.168.10.1, Serial0/0 connected, Loopback0 connected, Loopback1 connected, FastEthernet0/0

Router A is only advertising the 10.10.12.0 network to Router B; thus, Router B only knows about the 10.10.12.0 network. Now Router B must be configured such that Router A only learns the 10.10.15.0 network. Listing 1.27 displays the configuration that is needed on Router B. Listing 1.27: Router B configured with an outbound route filter. interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ! router eigrp 50 network 10.0.0.0 network 192.168.10.0 distribute−list 3 out Serial0/0 no auto−summary ! access−list 4 permit 10.10.15.0

Router B is configured with access list 4, which permits only the 10.10.15.0 network and has an outbound distribute−list applied to the EIGRP routing process. The next step is to check the route table of Router A to determine if the required results have been met. Listing 1.28 displays the route table of Router A. Listing 1.28: Route table of Router A after applying an outbound route filter on Router B. Router−A#sh ip route ...... C 10.10.10.0 is directly C 10.10.11.0 is directly C 10.10.12.0 is directly D 10.10.15.0 [90/409600] Router−A#

connected, Loopback0 connected, Loopback1 connected, Ethernet0/0 via 192.168.10.2, Serial0/0

After viewing the route table of Router A, you can determine that Router B is advertising only the 10.10.15.0 network to Router A; thus, Router A only knows about the 10.10.15.0 network.

Suppressing Route Advertisements To prevent other routers on a network from learning about routes dynamically, you can prevent routing update messages from being sent out a router interface. To accomplish this, use the passive−interface routing process configuration command. This command can be used on all IP−based routing protocols except for the Exterior Gateway Protocol (EGP) and Border Gateway Protocol (BGP). When an interface is configured to be in a passive state, the router disables the passing of routing protocol advertisements out of the interface; however, the interface still listens and accepts any route advertisement that is received into the interface. Configuring this on a router essentially makes the router a silent host over the interfaces that were specified. To 40

configure an interface as passive, use the passive−interface command under routing protocol configuration mode; this command is all that is needed to make an interface no longer advertise networks. Here is an example of configuring an interface as passive: interface FastEthernet0/0 ip address 10.10.15.1 255.255.255.0 ! interface Serial0/0 ip address 192.168.10.2 255.255.255.252 ! router eigrp 50 passive−interface FastEthernet0/0 passive−interface Serial0/0 !

Configuring HTTP Access Cisco routers include an HTTP server, which makes configuration and administration easier, especially for someone who does not have a lot of experience with the command−line interface. The HTTP server function is disabled by default and must be manually enabled. Follow these steps to enable the HTTP server functionality (only the first step is mandatory): 1. To enable the HTTP server, use the ip http server global configuration command. 2. You can specify the authentication method the router should use to authenticate users who attempt a connection to the server with the following global configuration command: ip http authentication {aaa|enable|local|tacacs}

3. You can control which hosts can access the HTTP server using this global configuration command: ip http access−class {access list number|access list name}

4. By default, the HTTP server listens for connection attempts on port 80. This can be changed using the ip http port global configuration command. Figure 1.6 displays a host named Jeff at IP address 192.168.10.100 who uses his Web browser to administer the router. Jeff accesses the HTTP server on the router on port 8080 and uses the local method of authentication. The following example configuration displays the HTTP server configuration that is needed so that Jeff can access the router.

41

Figure 1.6: User Jeff needs HTTP access to the router. SecureRouter#show running−config ...... username Jeff privilege 10 password 0 NewUser ! interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.0 ! ip http server ip http port 8080 ip http access−class 20 ip http authentication local ! access−list 20 permit 192.168.10.100 !

WarningIf the HTTP server is enabled and local authentication is used, it is possible, under some circumstances, to bypass the authentication and execute any command on the device. For further information, please see the following Web page: http://www.cisco.com/warp/public/707/IOS−httplevel−pub.html.

42

Chapter 2: AAA Security Technologies In Brief Chapter 1 covered security issues that are common to the infrastructure of a network and the counter measures that are needed to mitigate the effects of these issues. This chapter addresses the issues of unauthorized access and repudiation for enterprise environments, which both create a potential for intruders to gain access to sensitive network equipment. I'll begin with a detailed examination of Cisco's authentication, authorization, and accounting (AAA) architecture and the technologies that not only use these features but also provide them. I'll discuss both of the major protocols used to provide the AAA architecture: TACACS+ and RADIUS. The focus will then shift to configuring network access servers and networking equipment to provide the security features of the AAA architectures. Then, I'll also examine the Cisco Secure Access Control Server (ACS) software. Cisco Secure Access Control Server is designed to ensure the security of networks and maintain detailed records of the people connecting to your networking devices.

Access Control Security Access control has long been an issue that has frustrated both administrators and users alike. As networks continue to evolve into a state of convergence, administrators increasingly need flexibility to determine and control access to resources under their care. Administrators are being faced with new situations pertaining to remote access combined with strong security. For example, remote users and telecommuters need to access their corporate networks; they need to be able to work in the same network environment they would be working in if they were sitting at their desks at the office. This creates a significant need for an administrator to effectively give those users flexible and seamless access, yet at the same time, the administrator must have the ability to provide security and resource accountability. Also, within most networks, different administrators have varying responsibilities that require varying levels of access privileges. There are three components to access control: • Determining who is allowed access to a network • Determining what services they are allowed to access • Providing detailed accounting records of the services that were accessed Access control is based on a modular architecture known as authentication, authorization, and accounting (AAA). The AAA network security services provide the framework through which you set up access control on your router. As mentioned earlier, AAA is based on a modular architecture; as such, each module will be discussed separately. Authentication Authentication is the process of determining whether someone or something is, in fact, who or what it is declaring to be. In private and public computer networks, authentication is commonly accomplished through the use of logon passwords. The assumption is that knowledge of the password guarantees the authenticity of the user. Each user registers initially using an assigned or self−declared password. On each subsequent use, the user must know and use the previously declared password.

43

Authentication provides a way of identifying a user, typically by having the user enter a valid username and valid password before access is granted. The process of authentication is based on each user having a unique set of criteria for gaining access. The AAA server compares a user's authentication credentials with other user credentials stored in a database. If the supplied credentials match, the user is granted access to the network. If the supplied credentials don't match, authentication fails and network access is denied. The authentication database may be configured either in a local security database, using the username password command discussed in Chapter 1, or with a remote security database, such as a Cisco Secure ACS server. Authentication Methods

There are many forms of authentication; the most common is of course the use of usernames and passwords. Username and password combinations can range from very weak to somewhat strong. Other authentication methods provide far stronger security at an increased cost financially and increased complexity from a manageability standpoint. The trade−off is that weaker methods of authentication are often much easier to administer, whereas the stronger methods of authentication involve a greater degree of difficulty to administer. The following list includes the advantages and disadvantages of some of the popular current authentication methods: • Usernames and passwords—This method has been the predominant method of authentication in the client/server environment. This is the least scalable method of authentication because usernames and passwords need to be assigned for each user and cannot be managed on a groupwide basis. Usernames and passwords may be assigned in a static manner so that they do not change unless they are changed manually by the administrator or user. Or they can be assigned so that after a certain period of time they age out and must be changed by the administrator or user. Advantages: ♦ Inexpensive and easy to implement. ♦ Can be implemented entirely within software, avoiding the need for extra hardware. ♦ Username and password carried over hashed encryption. Disadvantages: ♦ Increasingly prone to "eavesdropping" as username and password travel over the network. ♦ Subject to replay attacks. ♦ Subject to password guessing. ♦ Ineffective password management and controls. ♦ Can be captured by Trojan horses under false pretences. ♦ Susceptible to "Social Engineering." • Token Cards/Smart Cards—These are typically small credit−card−sized devices that use a hardware−based challenge−response authentication scheme in which the server challenges the user to demonstrate that he possesses a specific hardware token and knows a PIN or passphrase by combining them to generate a response that is valid. This method of authentication has become very popular in recent years. Advantages: ♦ Ease of use for users; they only need to remember a single PIN to access the token. ♦ Ease of management; there is only one token instead of multiple passwords. 44

♦ Enhanced security; the attacker requires both the PIN and the token to masquerade as the user. ♦ Better accountability. ♦ Mobility; security is not machine specific. ♦ No client−side software needed. Disadvantages: ♦ Client is required to carry a token card to use facilities. ♦ Limited life span; tokens must be replaced about every four years. ♦ Ongoing operations cost associated with keeping track of token cards. ♦ Longer time to authenticate the identity of the user because numerous steps are required to authenticate the client. • Digital Certificates—Digital certificates are electronic documents that are generally issued by a trusted third party called a Certificate Authority. The certificates contain information about the user that the Certificate Authority has verified to be true. They consist of a public key denoted by a series of characters, which reside on the user's computer. When an electronic message is sent from the mobile client to the enterprise, it is signed using the digital certificate. Digital certificates are an essential part of the public key infrastructure (PKI) because PKI manages the process of issuing and verifying the certificates used to grant people and systems access to other systems. Note Digital certificates will be discussed in detail in Chapter 6, "Internet Security Protocol (IPSec)." Advantages that Digital certificates provide are as follows: • Validation of file's creator. Recipients need to know that the sender created the file. • Nonrepudiation. • Confidentiality ensured. • Guaranteed integrity. • Personalization scalability features. • Industry momentum is growing for digital certificates. Disadvantages: • Complicated for most users to install. • Must be installed on every computer. • Not feasible where users share machines. • Extensive integration. PAP and CHAP Authentication

Remote access is an integral part of any corporate mission. Traveling salespeople, executives, and telecommuters all need to communicate by connecting to the main office local area network. To make these remote connections, remote users should have appropriate software, protocol stacks, and link−layer drivers installed on their remote access device. Point−to−point links between local area networks can provide sufficient physical connectivity in many application environments. Most corporations provide access to the Internet over point−to−point links, thus providing an efficient way to access their service provider locally. The Internet community has adopted the Point−to−Point Protocol (PPP) scheme for the transmission of IP datagrams over serial point−to−point lines. PPP is a Data Link layer protocol that provides router−to−router and host−to−network connections over synchronous and asynchronous circuits. PPP has the following three main components: • It has a method for encapsulating datagrams over serial links. 45

• Link Control Protocols (LCPs) establish, configure, authenticate, and test datalink connections. • Network Control Protocols (NCPs) establish and configure different Network−layer protocols. Link Control Protocols are used as a security measure for authentication with PPP and PPP callback. This method of authentication allows the dial−up destination to determine if the dial−up client is correctly authenticated based on a preassigned username and password combination. Point−to−Point Protocol (PPP) currently supports two authentication protocols: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). Both PAP and CHAP are specified in RFC 1334. The dial−up destination uses either PAP or CHAP to determine if the dial−up client is authenticated. PAP provides a simple method for the remote client to establish its identity using a one−way authentication handshake when communication is taking place between a host and an access server; this is detailed in Figure 2.1.

Figure 2.1: One−way PAP authentication. The PAP authentication process occurs as follows: 1. Incoming client establishes PPP negotiation on the interface configured with PPP encapsulation and informs the access server to use PPP. 2. The network access server determines which authentication method to use. In this case, the network access server tells the remote client to use PAP. 3. The client sends the username and password in cleartext PAP format to the network access server. 4. The network access server compares the values passed to it from the remote client against the values configured within its local database or queries a security server to accept or reject the remote client. When communication is taking place between two routers, PAP uses a two−way authentication handshake; a username/password pair is repeatedly sent by the peer to the authenticator until the authentication is acknowledged or the connection is terminated. For PAP, this process proves to be an insecure authentication method because the password is passed over the link in cleartext. With PAP, there is no protection from playback. With CHAP authentication, the access server sends a challenge message to the remote node after the PPP link is established. The access server checks the response against its own calculation of the expected hash value. If the values match, the authentication is accepted. This is detailed in Figure 2.2.

46

Figure 2.2: Three−way CHAP authentication. The following list explains the CHAP authentication process: 1. The incoming client establishes PPP negotiation on the interface configured with PPP encapsulation. 2. LCP negotiates CHAP and Message Digest 5 (MD5), and the network access informs the remote client to use CHAP. 3. The remote client acknowledges the request. 4. A CHAP packet is built and sent to the remote client. The CHAP packet contains the following items: ♦ Packet type identifier ♦ Sequential identification number ♦ Random number ♦ Authentication name 5. The remote client processes the CHAP challenge packet as follows: ♦ Sequential id is run through a MD5 hash generator. ♦ Random number is run through a MD5 hash generator. ♦ Authentication name is used to determine the password. ♦ Password is run through the MD5 hash generator. The result is a one−way hash CHAP challenge that will be sent back to the network access server in a CHAP response packet. 6. The CHAP response packet is received by the network access server and the following occurs: ♦ The sequential id number identifies the original challenge. ♦ The sequential id number is run through a MD5 hash generator. ♦ The original random number is run through a MD5 hash generator. ♦ The authentication name is used to look up a password. ♦ The password is run through the MD5 hash generator. ♦ The hash value that was received is then compared against the value the network access server calculated. 7. If authentication was successful, a CHAP success packet is built and sent to the remote client. Likewise, if authentication is unsuccessful, a CHAP failure packet is built and sent to the remote client. CHAP provides protection against playback attacks through the use of a variable challenge value that is unique and unpredictable. The use of repeated challenges every two minutes during any CHAP session is intended to limit the time of exposure of any single attack. The access server controls the frequency and timing of the challenges.

47

Authorization After authentication, a user must be authorized to do certain tasks. Simply put, authorization is the process of enforcing policies (or giving someone permission to do or have something)—determining what types or qualities of activities, resources, or services a user is permitted. After authenticating into a system, for instance, the user may try to issue commands. The authorization process determines whether the user has the authority to do so. Sometimes, authorization can occur within the context of authentication. After you have authenticated a user, she needs to be authorized for different types of access or activity. You configure the network device to control user access to the network so that users can perform only functions that are deemed to be within the context of their authentication credentials. When authorization takes place, a set of attributes describing what actions a user is authorized to perform is compiled. After a user attempts to gain access to a system, the network device determines and enforces the permissions of the user based on the authorization information contained within the database and the user's authentication credentials. The assembled attributes may be configured in either a local security database or a remote security database, such as a Cisco Secure ACS server. Accounting Accounting, which is the third major requirement in the AAA security system, is the process of recording what the user does in addition to what the user accesses and for how long. You can also use accounting to measure the resources users consume during their sessions. This can include the amount of system time or the amount of data a user has sent and/or received during a session. Accounting is accomplished through logging of session statistics and usage information, and it's used for authorization control, billing, trend analysis, resource utilization, and capacity planning activities, which form an audit trail when combined. All of the information that is gathered during the accounting phase can be used to provide audit documentation to customers or clients. An accounting record typically contains the following information: • Username • Network address • Service accessed • Start time, stop time, and date • Log origination date and time

AAA Protocols Many protocols require authentication verification before providing authorization and access rights to the user or device. Each of the protocols that will be discussed in detail in the following sections is an example of such protocols. TACACS+ and RADIUS are the two predominant protocols implemented with security servers and used by networking devices. A third protocol, Kerberos, is used in some enterprise environments to first verify that users and the network services they use are really who and what they claim to be before granting access privileges. These protocols forward information between the network device and the security server. TACACS+ Terminal Access Controller Access Control Plus (TACACS+) is a security server protocol that enables central control of users attempting to gain access into networking devices. TACACS+ is the 48

latest generation of the TACACS protocol, which was developed by the BBN for MILNET. At that time, TACACS was primarily a User Datagram Protocol (UDP) access−based protocol that orchestrated user access. There are three versions of TACACS: • TACACS—An industry−standard protocol that forwards usernames and passwords to a central security server. TACACS is specified in RFC 1492. The original version of TACACS combined authentication and authorization and was based on the UDP protocol. • XTACACS—An enhanced version of TACACS with extensions that Cisco added (thus, the "X" for "extension") to support advanced features. The most notable advanced feature is the added functionality for multiprotocol support and authorization of multifunction connections with syslog exporting. XTACACS separated authentication, authorization, and accounting. It has been superseded by TACACS+. • TACACS+—Supported by the Cisco family of routers and access servers beginning in Cisco IOS release 10.3. TACACS+ is the third generation of Terminal Access Control, which is a Cisco proprietary client/server protocol. TACACS+ uses TCP as its transport protocol, and the server daemon usually listens on port 49. Its use originates from the need to manage and control terminal access. Its functions are based on the classic server/client relationship, using request and response to determine, in an algorithm format, whether or not users are authenticated, authorized, and accounted for. This protocol is a completely new version of the TACACS protocol referenced by RFC 1492. TACACS+ surpasses TACACS and XTACACS, and furthermore, it's not compatible with its predecessors, which are considered end of life (EOL) by Cisco and should probably not be considered for implementation. TACACS+ Benefits

TACACS+ uses TCP as the communication protocol to communicate between the network device and the security server on reserved port number 49. TCP, as opposed to UDP, was chosen in part because of its inherent capability to reliably retransmit data packets. Using MD5, TACACS+ also encrypts the data payload of the packet. However, the 12−byte header of a TACACS+ packet is sent in cleartext. Figure 2.3 shows the header of a TACACS+ packet.

Figure 2.3: TACACS+ packet header. TACACS+ Authentication Process

The TACACS+ protocol forwards many types of username/password information. The information is encrypted over the network with the MD5 encryption algorithm. TACACS+ authentication also supports multiple challenge and response demands from the TACACS+ server. A TACACS+ server can authenticate a user based on its own internal username and password database, or it can act as a client to authenticate the user based on various other authentication systems, such as a Windows NT domain controller. The TACACS+ authentication process typically begins with the network access server sending a START message to the TACACS+ server. The START packet is always sent only as the first packet in the authentication process or following a reset. 49

Upon receipt of the START packet from the network access server, the TACACS+ server sends a REPLY packet with the value set to GET USER. This will present the client with a username prompt. The access server gets the requested information and returns it to the TACACS+ server in a CONTINUE packet. If the username is found either in the local database on the TACACS+ server or in an external database, the server sends another REPLY packet with the value set to GET PASS. This will present the client with a password prompt. The access server again gets the requested information and returns it to the TACACS+ server in a CONTINUE packet. If the password is found either in the local database on the TACACS+ server or in an external database and it creates a match with the corresponding username, the server sends another REPLY message with the value set to ACCEPT or REJECT. The authentication process is detailed in Figure 2.4.

Figure 2.4: TACACS+ authentication. Note One other TACACS+ packet can be returned to the network access server from the security server. The ERROR packet is sent in the event of an error due to a failed daemon or network congestion problem during the authentication phase. If the network access server receives an ERROR packet from the security server, it will attempt to authenticate the client using the next configured method in the method list. TACACS+ Authorization Process

Unlike the authentication process, the TACACS+ authorization process defines only two types of messages, REQUEST and RESPONSE. The authorization process begins with the network access server sending to the TACACS+ server a REQUEST packet requesting authorization. The REQUEST packet contains certain values that it sends to the TACACS+ server to distinguish the user. These values include the following: • Authentication method • Privilege level • Authentication type • Authentication service After receipt of the REQUEST packet from the network access server, the TACACS+ server 50

determines the permissions the user has and sends back a RESPONSE packet with bundled attributes to the network access server. The TACACS+ authorization process can be seen in Figure 2.5.

Figure 2.5: TACACS+ authorization. TACACS+ Accounting Process

Accounting is usually the final phase of the AAA architecture. The TACACS+ accounting phase and authorization phase are similar. The accounting process begins with the network access server sending an accounting REQUEST packet to the TACACS+ server. The REQUEST packet contains many of the same values that the authorization packet contained. After receiving the REQUEST packet, the TACACS+ server acknowledges the request with a RESPONSE packet indicating that all accounting took place correctly. RADIUS RADIUS (Remote Access Dial In User Service) is an Internet security protocol originally developed by Livingston Enterprises. It is defined in RFC 2138 and RFC 2139. RADIUS uses UDP as its transport protocol and is generally considered to be a connectionless service. RADIUS clients run on routers and send authentication requests to a central RADIUS server, which contains all the user authentication credentials. The following list includes some key aspects of RADIUS that have led to its success: • Open protocol • Based on client/server architecture • Support for many authentication mechanisms • Encrypted transactions between client and server • Centralized authentication • Interoperability with other protocols RADIUS is a fully open protocol, which means that the source code is freely available and can be modified to work with any security system on the market. This allows RADIUS to be tailored to suit the particular needs of a particular environment. RADIUS is based on a client/server model. The remote machine acts as the client, and the security RADIUS server at the other end handles authentication. RADIUS supports the AAA model just as TACACS+ does; however, RADIUS combines authentication and authorization and separates only accounting. RADIUS is able to interact with 51

other authentication protocols, such as TACACS, XTACACS, and TACACS+. RADIUS Authentication Process

RADIUS supports a variety of methods for authenticating users, in part, because it is an open protocol. A RADIUS server can authenticate a user based on its own internal username or password list, or it can act as a client to authenticate the user based on various other authentication systems, such as a Windows NT domain controller. The method used, of course, depends on a specific vendor's implementation of RADIUS. Typically, a user login is queried from the network access server to the RADIUS server and a response is sent from the RADIUS server. The user login consists of what is commonly referred to as an Access−Request, and the server response is commonly referred to as an Access−Accept or an Access−Reject. The Access−Request packet contains the username, encrypted password, IP address, and port. After the RADIUS server receives the Access−Request packet, it begins to query its database for a matching username and password pair. If it cannot find a match, the server sends an Access−Reject packet back to the network access server. If it finds a match, the server sends an Access−Accept packet back to the network access server. This is detailed in Figure 2.6.

Figure 2.6: RADIUS authentication process. Note There is a third response a RADIUS server can use: Access−Challenge. A challenge packet sent from the RADIUS server simply asks the network access server to gather additional data from the client. Challenge packets are typically sent during an established session. RADIUS Authorization Process

As mentioned earlier, RADIUS combines authentication and authorization. But to a small degree, they are separate. The RADIUS authentication process must be complete before the authorization process can begin. After the RADIUS server has found within its database a matching pair for the credentials that were supplied to it from the network access server during the authentication phase, the RADIUS server returns an Access−Accept response to the network access server. It is at this point that the RADIUS server bundles within the Access−Accept packet a list of attribute−value pairs that determine the parameters to be used for this session. (Refer to Figure 2.6 earlier in this chapter.) 52

RADIUS Accounting Process

The network access server and RADIUS server communicate accounting information between one another on UDP port 1646. It is the network access server's responsibility to send accounting information to the RADIUS server after initial authentication and authorization is complete, and it does so by sending an Accounting−Request packet to the server. This is considered the Accounting−Start packet. Because RADIUS implements services using the UDP protocol (which is connectionless oriented), the RADIUS server has the responsibility of acknowledging the Accounting−Request packet with an Accounting−Response packet. When the session is complete, the network access server sends another Accounting−Request packet to the RADIUS security server, detailing the delivered service. This is considered the Accounting−Stop packet. Finally, the RADIUS security server sends an Accounting−Response packet back to the network access server, acknowledging the receipt of the stop packet. This is detailed in Figure 2.7.

Figure 2.7: RADIUS accounting process.

Cisco Secure Access Control Server Cisco Secure Access Control Server (ACS) is a scalable, centralized user access control software package for both Unix and Windows NT. Cisco Secure ACS offers centralized command and control of all user authentication, authorization, and accounting services via a Web−based, graphical interface. With Cisco Secure ACS, an enterprise can quickly administer accounts and globally change levels of security for entire groups of users. The Cisco Secure security server is designed to ensure the security of your network by providing authentication and authorization services and to track the activity of the people who connect to the network by providing feature−rich accounting services. The Cisco Secure security server software supports these features by using either the TACACS+ or RADIUS protocols. As mentioned, the Cisco Secure ACS software can run on either a Windows NT server or a Unix server; I'll discuss the Windows NT version. Cisco Secure ACS for Windows Cisco Secure ACS supports any network access servers that can be configured with the TACACS+ or RADIUS protocol. Cisco Secure ACS helps to centralize access control and accounting for dial−up access servers and firewalls and makes it easier to manage access to routers and switches. Cisco Secure ACS uses the TACACS+ and RADIUS protocols to provide AAA services to ensure a 53

secure environment. Cisco Secure ACS can authenticate users against any of the following user databases: • Windows NT • Windows 2000 Active Directory • Cisco Secure ACS • Novell NetWare Directory Services (NDS), version 4.6 or greater • Generic Lightweight Directory Access Protocol (LDAP) • Microsoft Commercial Internet System (MCIS) • Relational databases fully compliant with Microsoft Open Database Connectivity (ODBC) Cisco Secure ACS Requirements

To install Cisco Secure ACS, you must ensure that the system on which you are installing the software package meets the minimum system requirements, which are as follows: • Pentium II, 300MHz processor or faster • Windows NT Server 4 (with service pack 6a) or Windows 2000 Server • 128MB RAM; recommended 256MB • At least 250MB of free disk space; more if you're using the Cisco Secure local database • Minimum resolution of 256 colors for 800×600 • Microsoft Internet Explorer 4.x or higher or Netscape Communicator 4.x or higher • JavaScript enabled • Microsoft Internet Information Server for User Changeable Passwords utility (optional) Cisco Secure ACS Architecture

Cisco Secure ACS is designed to be both flexible and modular. Within the context of Cisco Secure ACS, modular refers to the seven modules that make up the architecture of the AAA server. These modules are installed as services within Windows NT and can be stopped and started by using the settings accessed by clicking the Services icon within Control Panel in Windows NT Server. The modules are described in the following list: • CSAdmin—Cisco Secure is equipped with its own internal Web server and, as such, does not require the presence of a third−party Web server. CSAdmin is the service that controls the operation of the internal Web server, allowing users to remotely manage the server via the Web interface. • CSAuth—CSAuth is the database manager that acts as the authentication and authorization service. The primary purpose of the CSAuth service is to authenticate and authorize requests to permit or deny access to users. CSAuth determines if access should be granted and, if access is granted, defines the privileges for a particular user. • CSTacacs and CSRadius—The CSTacacs and CSRadius services communicate with the CSAuth module and the network access device that is requesting authentication and authorization services. CSTacacs is used to communicate with TACACS+ devices and CSRadius is used to communicate with RADIUS devices. The CSTacacs and CSRadius services can run at the same time. When only one protocol is used, only the corresponding service needs to be running; however, the other service will not interfere with normal operation and does not need to be disabled. • CSLog—CSLog is the service used to capture logging information. It gathers data from the TACACS+ or RADIUS packet and the CSAuth service and then manipulates the data to be placed into the comma−separated value (CSV) files for exporting.

54

• CSMon—CSMon is a service that provides monitoring, recording, notification, and response for both TACACS+ and RADIUS protocols. The monitoring function monitors the general health of the machine the application is running on, as well as the application and the resources that Cisco Secure ACS is using on the server. Recording records all exception events within the server logs. Notification can be configured to send an email in the event of an error state on the server, and Response responds to the error by logging the event, sending notifications, and, if the event is a failure, carrying out a pre−defined or user−configured response. • CSDBSync—CSDBSync is the service used to synchronize the Cisco Secure ACS database with third−party relational database management system (RDBMS) system. Cisco Secure ACS Database

You can configure the Cisco Secure ACS server to use a user−defined database that is local to the server or you can configure an external user database, such as a Windows NT Server. There are advantages and disadvantages to each. When the Cisco Secure ACS server is configured to use the local database for authentication of usernames and passwords and it receives a request from the network access server, it searches its local database for the credentials that were supplied in the REPLY packet of the GETUSER packet. If it finds a match for the GETUSER packet, it compares the values that it receives from the REPLY packet of the GETPASS packet to the locally configured password for the account. The Cisco Secure ACS server then returns a pass or fail response to the network access server. After the user has been authenticated, the Cisco Secure ACS server sends the attributes of authorization to the network access server. The advantage to using the locally configured database is ease of administration and speed. The disadvantage is that manual configuration is needed to populate the database. You can also configure the Cisco Secure ACS server to authenticate usernames and passwords credentials against those already defined within a Windows NT or 2000 user database. If the Cisco Secure ACS server receives a request from the network access server, it searches its local database to find a match. If it does not find a match and the server is configured to forward requests to an external user database, the username and password are forwarded to the external database for authentication. The external database forwards back to the Cisco Secure ACS server a pass or fail response. If a match is confirmed, the username is stored in the Cisco Secure user database for future authentication requests; however, the password is not stored. This allows the user to authenticate much faster for subsequent requests. In enterprises that have a substantial Windows NT network already installed, Cisco Secure ACS can leverage the work already invested in building the database without any additional input. This eliminates the need for separate databases. An added benefit of using an external user database is that the username and password used for authentication are also used to log into the network. This allows you to configure the Cisco Secure ACS so that users need to enter their usernames and passwords only once, thus providing a single login. One of the major disadvantages of using an external database for authentication is that the Cisco Secure server cannot store any third−party passwords such as PAP and CHAP passwords. Also, in the event of a network issue that prevents the Cisco Secure ACS server from receiving a response from the external database for an authentication request, you could potentially lock yourself out of the network access server because the user never gets authenticated.

55

Immediate Solutions Configuring TACACS+ Globally The process for configuring a Cisco router to support the TACACS+ protocol is fairly uniform. The basic configuration to enable the TACACS+ protocol always includes the following steps; however, the steps can be accomplished using two different methods. The first method configures TACACS+ globally on the network access server. This method is generally used in environments that use only one TACACS+ server or in environments in which all TACACS+ servers within the network are configured to use the same security values. This configuration method is outlined in the following steps: 1. Use the aaa new−model global configuration command to enable AAA. This command establishes a new AAA configuration. The command must be configured if you plan to support the TACACS+ protocol. 2. Use the tacacs−server host command to specify the IP address of one or more TACACS+ servers. 3. Set the global TACACS+ authentication key and encryption key using the tacacs−server key command. The key string configured on the network access server must match the key string configured on the TACACS+ server or all communication between the devices will fail. The preceding steps include the basic configuration commands needed to enable TACACS+ globally on the network access server. Figure 2.8 illustrates how to configure the network access server named Seminole to provide TACACS+ services for user James. James is an administrator who must access the network access server Seminole remotely and perform administrative functions. The access server Seminole is configured to communicate with the Cisco Secure ACS server at IP address 192.168.10.4.

Figure 2.8: Single TACACS+ server. The following configuration commands are needed to configure the router based on the requirements: Seminole#config t Enter configuration commands, one per line. End with CNTL/Z. Seminole(config)#aaa new−model Seminole(config)#tacacs−server host 192.168.10.4 Seminole(config)#tacacs−server key 1Cisco9

56

In this configuration, the key 1Cisco9 is the encryption key that is shared between router Seminole and the Cisco Secure server at IP address 192.168.10.4. The encryption key should be kept secret for privacy reasons because it is encrypted only after it is sent across the network to the Cisco Secure server but it's not stored in encrypted format on the local device. Issuing the show running−config command allows you see the results of the preceding configuration: Seminole#show running−config ! hostname Seminole ! aaa new−model tacacs−server host 192.168.10.4 tacacs−server key 1Cisco9 !

Issuing the show running−config command allows you to review the configuration changes that were made to the local device; however, a few more commands are needed to verify that the network access server and TACACS+ server are communicating properly. After you verify that the configuration changes are correct, the next command you should issue is the show tacacs command. The output of this command verifies that the network access server and the TACACS+ server are communicating properly. Issuing the show tacacs command will verify that network access server Seminole in Figure 2.8 is communicating with the TACACS+ server. Seminole#sh tacacs Server: 192.168.10.4/49: opens=215 closes=214 aborts=79 errors=4 packets in=1637 packets out=1930 expected replies=0 connection 62524500 state=ESTAB

The output of the show tacacs command first lists the TACACS+ server's IP address and the port number that the router and the TACACS+ server are communicating on; port 49 is the default port number. The port number may be changed in instances in which the TACACS+ server has been configured to communicate on a different port number. The values for opens and closes are the number of times the router opened or closed a session with the TACACS+ server. The most important output that is displayed by the show tacacs command is the state of the connection. In the preceding example, the state equals Established. If, for instance, the router and TACACS+ server could not communicate, the following output listed would be seen: Server: 192.168.10.4/49: opens=0 closes=0 aborts=0 errors=227 packets in=0 packets out=0 expected replies=0 no connection

Notice the high number of errors. The number is high because there is no connection between the router and the TACACS+ server after a determination has been made that the router and the TACACS+ server are communicating. The command debug tacacs events is needed to make sure the session communication is functioning properly. The debug tacacs events command displays the opening and closing of TCP connections to the TACACS+ server and also displays the bytes written and read during the connection. This output can be seen in Listing 2.1. Listing 2.1: Debugging TACACS+ events output. Seminole#debug tacacs events TACACS+ events debugging is on Seminole#

57

: TAC+: Opening TCP/IP to 192.168.10.4/49 timeout=5 : TAC+: Opened TCP/IP handle 0x47B76A to 192.168.10.4/49 : TAC+: req=6257CD64 Qd id=3392702625 ver=192 handle=0x0 – : TAC+: (NONE) expire=4 AUTHEN/START/LOGIN/ASCII processed : TAC+: periodic timer stopped (queue empty) : TAC+: periodic timer started : TAC+: 192.168.10.4 req=6257CD64 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE) expire=5 AUTHEN/START/LOGIN/ASCII queued : TAC+: 192.168.10.4 ESTAB id=3392702625 wrote 37 of 37 bytes : TAC+: 192.168.10.4 req=6257CD64 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE)expire=4 AUTHEN/START/LOGIN/ASCII sent : TAC+: 192.168.10.4 ESTAB read=12 wanted=12 alloc=55 got=12 : TAC+: 192.168.10.4 ESTAB read=28 wanted=28 alloc=55 got=16 : TAC+: 192.168.10.4 received 28 byte reply for 6257CD64 – : TAC+: id=3392702625 : TAC+: req=6257CD64 Tx id=3392702625 ver=192 handle=0x0 – : TAC+: (NONE) expire=4 AUTHEN/START/LOGIN/ASCII processed : TAC+: periodic timer stopped (queue empty) : TAC+: periodic timer started : TAC+: 192.168.10.4 req=6252CD78 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE)expire=5AUTHEN/CONT queued : TAC+: 192.168.10.4 ESTAB id=3392702625 wrote 24 of 24 bytes : TAC+: 192.168.10.4 req=6252CD78 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE)expire=4 AUTHEN/CONT sent : TAC+: 192.168.10.4 ESTAB read=12 wanted=12 alloc=55 got=12 : TAC+: 192.168.10.4 ESTAB read=28 wanted=28 alloc=55 got=16 : TAC+: 192.168.10.4 received 28 byte reply for 6252CD78 – : TAC+: id=3392702625 : TAC+: req=6252CD78 Tx id=3392702625 ver=192 handle=0x0 – : TAC+: (NONE) expire=4 AUTHEN/CONT processed : TAC+: periodic timer stopped (queue empty) : TAC+: periodic timer started : TAC+: 192.168.10.4 req=6257CD64 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE)expire=5 AUTHEN/CONT queued : TAC+: 192.168.10.4 ESTAB id=3392702625 wrote 27 of 27 bytes : TAC+: 192.168.10.4 req=6257CD64 Qd id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE)expire=4 AUTHEN/CONT sent : TAC+: 192.168.10.4 ESTAB read=12 wanted=12 alloc=55 got=12 : TAC+: 192.168.10.4 ESTAB read=18 wanted=18 alloc=55 got=6 : TAC+: 192.168.10.4 received 18 byte reply for 6257CD64 – : TAC+: id=3392702625 : TAC+: req=6257CD64 Tx id=3392702625 ver=192 – : TAC+: handle=0x0 (NONE) expire=3 AUTHEN/CONT processed : TAC+: periodic timer stopped (queue empty)

Configuring TACACS+ Individually The second method used to enable TACACS+ allows a finer granularity of control in specifying features on a per−security−server basis. This method is generally used in environments that use multiple TACACS+ servers, and each server is configured to use separate values. Use the following steps to enable this method of TACACS+ configuration: 58

1. Use the aaa new−model global configuration command to enable AAA. This command establishes a new AAA configuration. The command must be configured if you plan to support the TACACS+ protocol. 2. Use the following command to specify the IP address of one or more TACACS+ servers: tacacs−server host hostname

95

A deny statement configures the router to drop the packet and a permit statement allows the packet to forward out the egress interface toward its destination. Figure 3.3 displays a network in which Unicast RPF is enabled on both interfaces of Router 1.

Figure 3.3: Unicast RPF. The objective is to use Unicast RPF for filtering traffic at the ingress interfaces of Router 1 to provide protection from malformed packets arriving from the Internet or from the internal network. The following commands configure Router 1 for Unicast RPF: Router−1 ! ip cef distributed ! interface Serial1/0 ip verify unicast reverse−path ! interface Ethernet0/0 ip verify unicast reverse−path !

The preceding configuration is all that is needed to have Unicast RPF running on the router. It is very important to remember that CEF must be enabled on the router prior to configuring Unicast RPF. In fact, the router will not allow Unicast RPF to be configured until CEF is enabled, as shown in the following display: Router−1(config−if)#ip verify unicast reverse−path % CEF not enabled. Enable first

As you can see, the router will display a prompt that demands that you enable CEF on the router prior to configuring Unicast RPF. To verify that Unicast is operational, use the show cef interface command. The output should verify that Unicast RPF is in fact operational. Listing 3.3 displays the output. Listing 3.3: An example of the show cef interface command. Router−1#sh cef interface serial1/0 detail Serial1/0 is up (if_number 3) Internet address is 172.16.10.1/24 ICMP redirects are always sent Per packet loadbalancing is disabled IP unicast RPF check is enabled Inbound access list is not set Outbound access list is not set IP policy routing is disabled Hardware idb is serial1/0 Fast switching type 1, interface type 18 IP CEF switching enabled IP CEF Feature Fast switching turbo vector Input fast flags 0x4000, Output fast flags 0x0 ifindex 2(2) Slot 1 Slot unit 0 VC −1

96

Transmit limit accumulator 0x0 (0x0) IP MTU 1500 Router−1#

Unicast RPF also allows for the configuration of an optional access list to control the exact behavior when the received packet fails the source IP address check. The access list can be defined as a standard access list or as an extended access list. If an access list is defined, then after a packet fails a Unicast RPF check, the access list is checked to see if the packet should be dropped or forwarded. Unicast RPF events can also be logged by specifying the logging option for the access list entries used by Unicast RPF. The following example configures Router 1 in Figure 3.3 to use access lists and logging with Unicast RPF. In the example in Listing 3.4, the extended access list 114 contains entries that should permit or deny network traffic for specific address ranges received on interface serial1/0. Unicast RPF is configured on interface serial1/0 to check packets arriving at that interface. Listing 3.4: An example Unicast RPF logging configuration. ip cef distributed ! int serial1/0 ip verify unicast reverse−path 114 ! int ethernet0/0 ip verify unicast reverse−path ! access−list 114 deny ip 192.168.10.0 0.0.0.255 any log−input access−list 114 deny ip 192.168.20.0 0.0.0.255 any log−input access−list 114 deny ip 192.168.30.0 0.0.0.255 any log−input access−list 114 permit ip 192.168.9.0 0.0.0.255 any log−input

The configuration in Listing 3.4 denies packets with a source address of 192.168.10.0, 192.168.20.0, or 192.168.30.0 from arriving at interface serial1/0 because of the deny statement in access list 114. The access lists also logs any packet that is matched by the access list. Packets with a source address within the 192.168.9.0 subnet arriving at interface serial1/0 are forwarded if the source cannot be verified against interface serial1/0 because of the permit statement in access list 114. To verify that logging of the access list entries are taking place, use the show access−lists command: Router−1# show access−lists Extended IP access list 114\ deny ip 192.168.10.0 0.0.0.255 any log−input (87 match) deny ip 192.168.20.0 0.0.0.255 any log−input (32 match) deny ip 192.168.30.0 0.0.0.255 any log−input (76 match) permit ip 192.168.9.0 0.0.0.255 any log−input (63 match)

Each time a packet is dropped at an interface, information is not only logging globally on the router but also at each interface configured for Unicast RPF. Global statistics about packets that have been dropped provide information about potential attacks. To view the global drop statistics, use the show ip traffic command. Here is the output: Router−1#show ip traffic IP statistics: Rcvd: 1290449399 total, 75488293 local destination 0 format errors, 183 checksum errors, 8684 bad hop count

97

62 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 1147 with options ..... Drop:

1468583 encap failed, 325 unresolved, 0 no adjacency 7805049 no route, 41 unicast RPF, 1428682 forced drop Router−1#

Interface statistics help to provide information about which interface is the source of the attack. Statistics for each interface can be viewed using the show ip interface command. Interface statistics display two separate types of RPF drops: Unicast RPF drops and Unicast RPF suppressed drops. The display for Unicast RPF drops shows the number of drops at the interface, and the display for Unicast suppressed drops shows the number of packets that failed the Unicast RPF reverse lookup check but were forwarded because of a permit statement configured within the access list that is applied to Unicast RPF. The following output is from the show ip interface command: Router−1#show ip interface serial1/0 ... Unicast RPF ACL 114 37 unicast RPF drops 12 unicast RPF suppressed drops Router−1#

Configuring TCP Intercept The configuration of TCP Intercept is based on access lists, which are bound within TCP Intercept commands. Thus, access lists bound within TCP Intercept are not bound to an interface, as in most access list configurations. Use the following steps to configure TCP Intercept (Steps 4, 5 and 6 are optional): 1. Use the following global configuration command to define an extended IP access list: access−list access−list number [deny|permit] tcp any =

The access list can be configured to intercept either all TCP requests or only those coming from specific networks or destined for specific servers. The access list should define the source as any and define specific destination networks or servers; do not attempt to filter on the source addresses because you may not know which source address to intercept packets from. Identify the destination to protect destination servers. 2. Use the following command to enable TCP Intercept: ip tcp intercept list access−list number

3. Use this command to configure the mode in which TCP Intercept should operate: ip tcp intercept mode

4. If Intercept is configured to run in watch mode, configure the amount of time it will wait for a watched connection to an established state before terminating the connection. Use this command to do so:

98

ip tcp intercept watch−timeout

5. Configure the mode that Intercept should use to drop connections when under attack and running in aggressive mode by using this command: ip tcp intercept drop−mode

6. Configure the amount of time that a connection will be managed by Intercept by using the following command: ip tcp intercept connection−timeout

TCP Intercept has a number of other command arguments, which will be discussed in detail throughout this section. It should be noted that only the first three steps in the preceding list are required to take advantage of the features that TCP Intercept provides. The other steps, as well as the commands that will be discussed later, are considered commands that are used to fine−tune the operation of TCP Intercept. Note

Do not configure TCP Intercept on the perimeter router if the router is configured for Context−Based Access Control (CBAC).

In Figure 3.4, Router B is the perimeter router for the enterprise and is configured for TCP Intercept. Router B has been configured to intercept requests to a Web server that has an IP address of 192.168.20.20 and to intercept requests to an FTP server with an IP address of 192.168.20.21.

Figure 3.4: An example TCP Intercept network. Listing 3.5 details the configuration commands needed to configure Router B to intercept requests to the Web server and FTP server. Router B is configured for TCP Intercept in watch mode. Listing 3.5: TCP Intercept configuration of Router B. #config t #access−list 100 permit tcp any host 192.168.20.20 #access−list 100 permit tcp any host 192.168.20.21 #ip tcp intercept list 100 #ip tcp intercept mode intercept #end #

The configuration in Listing 3.5 defines access list 100 and permits any TCP traffic with a destination of 192.168.20.20 and 192.168.20.21 to be intercepted by Router B. TCP Intercept is configured on Router B and access list 100 is bound to the TCP Intercept configuration and the mode is configured for watch mode. TCP Intercept has a limited number of verification and debugging tools. One of the most useful verification commands is the show tcp intercept statistics command. Listing 3.6 lists the output of this command. 99

Listing 3.6: The output of show tcp intercept statistics. Router−B#show tcp intercept statistics Intercepting new connections using access−list 100 148 incomplete, 851 established connections (total 999) 1 minute connection request rate 49 requests/sec Router−B#

The output of the show tcp intercept statistics command demonstrates that TCP Intercept is using access list 100 to compare against all new connections. The output of the command displays the number of incomplete connections and established connections. The connection requests for each server can be monitored in realtime using the sh tcp intercept connections command. Issuing the command on Router B displays the output shown in Listing 3.7. Listing 3.7: Example of show TCP intercept connections output. Router−B# show tcp intercept connections Incomplete: Client Server State 208.19.121.12:58190 192.168.20.20:80 SYNRCVD 208.19.121.12:57934 192.168.20.20:80 SYNRCVD 168.41.18.4:59274 192.168.20.21:23 SYNRCVD 168.41.18.4:56196 192.168.20.21:23 SYNRCVD ... Established: Client Server State 17.96.23.23:1045 192.168.20.20:80 ESTAB ...

Create 00:00:06 00:00:06 00:00:06 00:00:06

Timeout 00:00:02 00:00:02 00:00:02 00:00:02

M I I I I

Create Timeout M 00:01:10 23:58:52 I

Note The "M" in the 3rd and 10th lines in Listing 3.7 represents the word "Mode." In Listing 3.7, the Incomplete section displays information related to connections that are not yet established. The Client field displays the source IP address of the client requesting service from the server and also lists the randomly generated source port number the source is using to communicate on. The Server field displays the destination server IP address and port number that is being protected by TCP Intercept. As discussed earlier, TCP Intercept will intercept each incoming connection request from the source and respond to the source on behalf of the server. After the source responds back to the router, the router will send the original SYN request packet to the server and merge the connections. The state of each of the connection requests is listed in the State field. The State field can contain one of three values: • SYNRCVD—When the connection is in this state, the router is attempting to establish a connection with the source of the connection request. It is during this phase that the router sends a SYN−ACK to the source and is awaiting an ACK from the source. • SYNSENT—When the connection is in this state, the router is attempting to establish a connection with the destination of the connection request. It is during this phase that the router has received an ACK from the source and is sending the original SYN request to the server in an attempt to perform the three−way handshake. • ESTAB—In order for the connection to reach this state, the two separate connections have been joined and communication between the source and destination is established. The Create field details the amount of time since the connection was created. The Timeout field lists the amount of time remaining until the retransmission timeout is reached. The Mode field displays 100

the mode under which TCP Intercept is running; the values can be either I (for intercept mode) or W (for watch mode). The Established section displays information related to connections that have become established. All fields in the Established section maintain the same values they have in the Incomplete section with the exception of the Timeout field, which displays the time remaining until the connection timeout is reached and the connection is dropped. In Listing 3.5, Router B was configured to operate in intercept mode in the earlier configuration; however, this can be changed using the ip tcp intercept mode command. Below, Router B is configured to operate in watch mode, and the ip tcp intercept watch−timeout command is used to lower the watch timeout from the default 30 seconds to a value of 16 seconds. Changing the watch timeout will define how long Intercept will wait for a watched TCP connection to reach an established state before it sends a reset to the server. The following configuration reflects the changes: #config t #ip tcp intercept mode watch #ip tcp intercept watch−timeout 16\ #end

The default timeout value for an established session with no activity is 24 hours, or one day. Notice in Listing 3.7 that there is one established session between the client and server. The timeout value for the connection still has 23 hours, 58 minutes, and 52 seconds left before it times out. This means the connection will still be managed by the router for that amount of time, even if there is no activity between the client and server. In some environments, such as those with a large amount of connection requests, the default connection timeout value should be lowered so that the router does not have to use resources managing connections that are not being used. The connection timeout value can be changed using the ip tcp intercept connection−timeout command. Router B will now be configured to lower the default connection timeout value to 6 hours: #config t #ip tcp intercept connection−timeout 21600 #end

The connection−timeout command accepts the timeout value in seconds. The timeout value can be configured as low as 1 second and as high as 2147483 seconds. Another method of viewing TCP Intercept statistics is to use the debug ip tcp intercept command. Using the debug command allows administrators to view a connections request in realtime. Using Listing 3.7 as a reference, the debug ip tcp intercept command was issued to monitor each connection request. Listing 3.8 details the output of the debug command; only the first and second connection requests are recorded in the output. Listing 3.8: Example output from debug ip tcp intercept. !1st connection attempt\ : new connection (208.19.121.12:58190) => (192.168.20.20:80) : (208.19.121.12:58190) (192.168.20.21:23) : (168.41.18.4:59274) (192.168.20.21:23) SYNSENT !Server responds and the connection is established : 2nd half of conn established : (168.41.18.4:59274)=>(192.168.20.21:23) : (168.41.18.4:59274) ACK −> (192.168.20.21:23) !The router tries to establish a connection to the 1st client, !then times the connection out and sends a reset to the server. : retransmit 16 (208.19.121.12:58190)>−(192.168.20.20:80) : SYNRCVD : retransmit expire : (208.19.121.12:58190)=>(192.168.20.20:80) SYNRCVD : (208.19.121.12:58190) speed auto ! interface Serial0/0 ip address 192.168.12.2 255.255.255.0 no ip directed−broadcast no fair−queue! ip classless no ip http server ! ip route 0.0.0.0 0.0.0.0 serial0/0 ! line con 0 session−timeout 30 exec−timeout 30 0 login local transport input none line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local ! end

Both routers in Listing 5.1 and Listing 5.2 provide access to the Internet and act as the single entry and exit point from the local network to the outside world, which is why they each have a static default route pointing out their serial interface. Prior to configuring CET on your routers, you must ensure that each router that needs to perform encryption can communicate with each peer. For CET to function properly and for encryption to take place, Layer 3 communication must be established between each peer. In Listing 5.3 and Listing 5.4, the ping command will be used to verify Layer 3 connectivity between Router A and Router B. Listing 5.3: Layer 3 connectivity verified on Router A. Router−A#ping 192.168.12.2 Type escape sequence to abort. Sending 5, 100−byte ICMP Echos to 192.168.12.2, timeout − is 2 seconds: !!!!! Success rate is 100 percent (5/5), round−trip − min/avg/max = 1/2/4 ms

173

Router−A#

Listing 5.4: Layer 3 communication verified on Router B. Router−B#ping 192.168.12.1 Type escape sequence to abort. Sending 5, 100−byte ICMP Echos to 192.168.12.1, timeout − is 2 seconds: !!!!! Success rate is 100 percent (5/5), round−trip − min/avg/max = 1/2/4 ms Router−B#

The output in Listing 5.3 and Listing 5.4 confirms that communication between each peer is working properly because each peer can ping the serial interface of the other router. The first task that must be performed to configure CET is to generate each peer router's public and private key and save them to NVRAM. Listing 5.5 displays an example of generating Router A's public and private keys. Listing 5.6 displays an example of generating Router B's public and private keys. Listing 5.5: Generating Router A's key. Router−A(config)#crypto key generate dss routera Generating DSS keys .... [OK]

Listing 5.6: Generating Router B's key. Router−B(config)#crypto key generat dss routerb Generating DSS keys .... [OK]

After each router's key pair is generated, the keys need to be saved into a private portion of NVRAM on the routers. To save the each router's key to NVRAM on the routers, the copy running−config startup−config command is used. Listing 5.7, shows Router A saving its private key to NVRAM. Listing 5.8 shows Router B saving its private key to NVRAM. Listing 5.7: Router A saving private key to NVRAM. Router−A#copy running−config startup−config Destination filename [startup−config]? Building configuration... [OK] Router−A#

Listing 5.8: Router B saving private key to NVRAM. Router−B#copy running−config startup−config Destination filename [startup−config]?

174

Building configuration... [OK] Router−B#

As mentioned previously, the command used in Listing 5.5 and Listing 5.6 generate a public key and a private key. The private keys that generated on each router are saved into NVRAM and are inaccessible for viewing because if anyone were to gain access to the private key, she could masquerade as the owner of the private key and all data secured using the private key could be compromised. Cisco routers have been designed so that the private keys that are generated and saved to NVRAM cannot be accessed or tampered with. The public key can be viewed, however, because it is shared with its encryption peers. To view the public keys that were generated as a result of issuing the crypto key generate dss command, issue the show crypto key mypubkey dss command. Listing 5.9 shows an example of issuing the show crypto key mypubkey dss command on Router A. Listing 5.10 displays an example of issuing the show crypto key mypubkey dss command on Router B. Listing 5.9: Viewing Router A's public key. Router−A#show crypto key mypubkey dss Key name: routera Serial number: 6B86ECF4 Usage: Signature Key Key Data: CC0438CE 125C2C5E DAE47A2C B47B44EE 4737C1D9 9FDF3164 69CAACA7 82D25416 8CA218AC 644BE782 36966277 BBF437DF 1347FFAA F2E3C04E 94CE60E5 5485C539 Router−A#

Listing 5.10: Viewing Router B's public key. Router−B#sh crypto key mypubkey dss Key name: routerb Serial number: 0615EC60 Usage: Signature Key Key Data: 4B013A5D DB942F8F 556B6F67 13110723 A05F17F9 D7BA15BF 74B1C17B D2E5C4A5 ABC0A7DE D1188289 A54C80EC 5BB3B9AE F4366FB1 D5DBB125 C44F904A 62209467 Router−B#

Now each router must exchange its public keys. According to Figure 5.5, Router B has been determined to be the passive router and Router A has been determined to be the active router. Router B must now be configured to initiate a key exchange connection; to do so, use the crypto key exchange dss passive command. Listing 5.11 displays an example of configuring Router B to be passive. Listing 5.11: Router B enabling DSS key exchange. Router−B(config)#crypto key exchange dss passive Enter escape character to abort if connection does not complete. Wait for connection from peer[confirm] Waiting ....

175

Router B is now waiting for a connection from the active router, Router A. In order for the public keys to be exchanged, Router A must now be configured to initiate a key exchange connection; this is done by using the cypto key exchange dss command. Listing 5.12 displays an example of configuring Router A to be active and send its public DSS keys to Router B. Listing 5.12: Router A enabling DSS key exchange. Router−A(config)#crypto key exchange dss 192.168.12.2 routera Public key for routera: Serial Number 6B86ECF4 Fingerprint 6974 475B 3FB7 F64B B40A Wait for peer to send a key[confirm] Waiting ....

In Listing 5.12, Router A defines the IP address of Router B as the peer with which it would like to exchange public keys. After configuring the crypto key exchange dss command, Router A displays the public key that it intends to send to Router B and sends its public key to Router B. Notice that after sending its public key to Router B, Router A transitions to a state of waiting. It is now waiting for a public key in return from Router B. When Router B receives the key, it displays the output in Listing 5.13. Listing 5.13: Router B asking to accept Router A's public key. Public key for routera: Serial Number 6B86ECF4 Fingerprint 6974 475B 3FB7 F64B B40A Add this public key to the configuration? [yes/no]: yes

The public key that Router B receives from Router A in Listing 5.13 includes the serial number for the key and the fingerprint of the key. The serial number and the fingerprint of the key Router B receives should be verbally compared against the key that Router A generated and displayed in Listing 5.5 and 5.9 and displayed in Listing 5.12 as the key that it was to send to Router B. Router B at this point must send Router A its public key, and Router B prompts you to send Router A its public key. In the next line of code (following the last line in Listing 5.13), Router B asks to send to Router A its public key. This can be seen in Listing 5.14 Listing 5.14: Router B asks to send Router A its public key. Send peer a key in return[confirm] Which one? routerb? [yes]: Public key for routerb: Serial Number 0615EC60 Fingerprint 9C98 0488 7058 AF43 D4FC

Router B now sends Router A it public key. Router A should receive the key and prompt you to accept it. This can be seen in Listing 5.15. Listing 5.15: Router A receives Router B's public key. 176

Public key for routerb: Serial Number 0615EC60 Fingerprint 9C98 0488 7058 AF43 D4FC Add this public key to the configuration? [yes/no]: yes

The public key that Router A receives from Router B in Listing 5.15 includes the serial number for the key and the fingerprint of the key. The serial number and the fingerprint of the key Router A receives should be verbally compared against the key that Router B generated and displayed in Listings 5.6 and 5.10 and displayed in Listing 5.14 as the key that it was to send to Router B. At this point, the key exchange process is complete. To view the key that each peer receives, issue the show crypto key pubkey−chain dss command. Listing 5.16 displays an example of viewing Router B's public key from Router A. Compare the output of Listing 5.16 on Router A with the output of Listing 5.10 on Router B. The value of the serial number and data fields should be equal. Listing 5.16: Router A viewing Router B's public key. Router−A#sh crypto key pubkey−chain dss serial 0615EC60 Key name: Serial number: 0615EC60 Usage: Signature Key Source: Manually entered Data: 4B013A5D DB942F8F 556B6F67 13110723 A05F17F9 D7BA15BF 74B1C17B D2E5C4A5 ABC0A7DE D1188289 A54C80EC 5BB3B9AE F4366FB1 D5DBB125 C44F904A 62209467 Router−A#

Listing 5.17 displays an example of viewing Router A's public key from Router B. Compare the output of Listing 5.17 on Router B with the output of Listing 5.9 on Router A. The value of the serial number and data fields should be equal. Listing 5.17: Router B viewing Router A's public key. Router−B#sh crypto key pubkey−chain dss serial 6B86ECF4 Key name: Serial number: 6B86ECF4 Usage: Signature Key Source: Manually entered Data: CC0438CE 125C2C5E DAE47A2C B47B44EE 4737C1D9 9FDF3164 69CAACA7 82D25416 8CA218AC 644BE782 36966277 BBF437DF 1347FFAA F2E3C04E 94CE60E5 5485C539 Router−B#

To summarize what has happened up to this point, each router has generated a public and a private key and successfully exchanged its public key with its encrypting peer router. Listing 5.18 displays a partial output of Router A's configuration after generating and exchanging keys. Listing 5.19 displays a partial output of Router B's configuration after generating and exchanging keys. Listing 5.18: Router A's configuration after exchanging keys.

177

Building configuration... ! version 12.1 service timestamps debug uptime service timestamps log uptime no service password−encryption ! hostname Router−A ! username routera privilege 15 password 0 routera ! memory−size iomem 10 ip subnet−zero no ip finger ip tcp synwait−time 10 no ip domain−lookup ! crypto key pubkey−chain dss named−key routerb signature serial−number 0615EC60 key−string 4B013A5D DB942F8F 556B6F67 13110723 A05F17F9 D7BA15BF − 74B1C17B D2E5C4A5 ABC0A7DE D1188289 A54C80EC 5BB3B9AE − F4366FB1 D5DBB125 C44F904A 62209467 quit !

Listing 5.19: Router B's configuration after exchanging keys. Building configuration... ! version 12.1 service timestamps debug uptime service timestamps log uptime no service password−encryption ! hostname Router−B ! username routerb privilege 15 password 0 routerb ! memory−size iomem 10 ip subnet−zero no ip finger ip tcp synwait−time 10 no ip domain−lookup ! crypto key pubkey−chain dss named−key routera signature serial−number 6B86ECF4 key−string CC0438CE 125C2C5E DAE47A2C B47B44EE 4737C1D9 9FDF3164 69CAACA7 − 82D25416 8CA218AC 644BE782 36966277 BBF437DF 1347FFAA F2E3C04E 94CE60E5 − 5485C539 quit !

178

Now that each router has generated a private and a public key pair and exchanged its public key with its peer router, the next step is to configure and enable a global encryption algorithm for use in encrypting traffic between each peer. Cisco Encryption Technology makes use of the DES algorithm for encrypted communication between peers. All encryption algorithms that your router will use during an encrypted session must be enabled globally on the router. To have an encrypted session, each peer router must have at least one DES algorithm enabled that is the same as the algorithm used by the peer router. Cisco routers support the following four types of DES encryption algorithms: • 56−bit DES with 8−bit cipher feedback • 56−bit DES with 64−bit cipher feedback • 40−bit DES with 8−bit cipher feedback • 40−bit DES with 64−bit cipher feedback Listing 5.20 displays an example of configuring a global encryption policy on Router A, and Listing 5.21 displays an example of configuring a global encryption policy on Router B. Listing 5.20: Configuring a global encryption policy on Router A. Router−A#config t Router−A(config)#crypto cisco algorithm des cfb−8 Router−A(config)#crypto cisco algorithm des cfb−64 Router−A(config)#crypto cisco algorithm 40−bit−des cfb−64 Router−A(config)#end

Listing 5.21: Configuring a global encryption policy on Router B. Router−B#config t Router−B(config)#crypto cisco algorithm des cfb−64 Router−B(config)#crypto cisco algorithm des cfb−8 Router−B(config)#crypto cisco algorithm 40−bit−des cfb−8 Router−B(config)#end

Notice in the configurations in Listing 5.20 and Listing 5.21 that each router encryption policy is configured to use the 56−bit DES algorithm with both cipher feedback 64 and 8. However, the third encryption policy on each router is configured differently. Router A is configured to use the 40−bit DES encryption algorithm using cipher feedback 64, and Router B is configured to use the 40−bit DES encryption algorithm using cipher feedback 8. Because the third encryption policy on each router is different, it will not be used to provide encryption services between each of these peer routers; however, it could be used with another router that has a similar encryption policy. To display and verify the global encryption algorithms currently in use on each router, issue the show crypto cisco algorithms command. Listing 5.22 displays an example of issuing the show crypto cisco algorithms command on Router A, and Listing 5.23 displays an example of issuing the same command on Router B. Listing 5.22: Viewing encryption algorithms in use on Router A. Router−A#show crypto cisco algorithms des cfb−64 des cfb−8 40−bit−des cfb−64 Router−A#

179

Listing 5.23: Viewing encryption algorithms in use on Router B. Router−B#show crypto cisco algorithms des cfb−64 des cfb−8 40−bit−des cfb−8 Router−B#

The next task to configuring Cisco Encryption Technology is to configure access lists to define which packets are to be protected by encryption and which packets should not be. Access lists that are used for encryption function a little differently than normal access lists used for packet filtering. When an access list is defined for encryption and the rule specifies a permit statement, if a packet matches the permit rule, the router performs encryption on the packet. If a packet matches a deny statement within an access list, the packet is not encrypted and is forwarded as normal via the routing process. IP extended access lists are used to define which packets are encrypted. Listing 5.24 displays an example of configuring Router A to provide encryption on packets with a source address within the range of 192.168.10.0 and a destination address of 192.168.11.0. Listing 5.25 displays an example of configuring Router B to provide encryption on packets with a source address within the range of 192.168.11.0 and a destination address of 192.168.10.0. It is recommended that each encrypting peer router maintain mirror copies of each other's access lists. Listing 5.24: Encryption access list configuration on Router A. Router−A#config t access−list 100 permit ip 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 permit icmp 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 deny ip 192.168.10.0 0.0.0.255 any !

Listing 5.25: Encryption access list configuration on Router B. Router−B#config t access−list 100 permit ip 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 100 permit icmp 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 100 deny ip 192.168.11.0 0.0.0.255 any !

The configurations in Listing 5.24 and Listing 5.25 define on each router an access list in which the rules state that any IP or ICMP traffic between the router with a source address local to the router and a destination address of behind the peer encrypting router should be protected by encryption. The third match rule of each access list is a deny statement, and it can be interpreted as any packet with a source address local to the router that as a destination address of any address, does not provide encryption for the packet and forward the packet as usual. At first, the access list rules might not seem correct because a packet with a source address local to the router and with any destination could be a packet that is local to the router with a destination address that is local to the peer encrypting router. However, access list rules are read in sequential order by the router, and once a packet matches a rule within the access list, the router breaks out of the access list comparison. A packet that matches one of the first two configured rules on Router A or Router B will 180

never be compared against the third rule of the access list and will always be encrypted. To display the access list configuration of each router, issue the show access−list command. The result of issuing the show access−lists command on Router can be seen in Listing 5.26, and in Listing 5.27 shows the result of issuing it on Router B. Listing 5.26: Access list configuration of Router A. Router−A#show access−lists Extended IP access list 100 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255 permit icmp 192.168.10.0 0.0.0.255 192.168.11.0 0.0.0.255 deny ip 192.168.10.0 0.0.0.255 any Router−A#

Listing 5.27: Access list configuration of Router B. Router−B#show access−lists Extended IP access list 101 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 permit icmp 192.168.11.0 0.0.0.255 192.168.10.0 0.0.0.255 deny ip 192.168.11.0 0.0.0.255 any Router−B#

The next major step in the configuration of Cisco Encryption Technology is to define crypto maps on each router. Crypto maps define a control policy for Cisco Encryption Technology by linking the traffic selection criteria of the access lists, defines the peer routers and defines the DES algorithm to use. To define a crypto map on Router A and Router B, you must use the crypto map command and define a name and a sequence number. After the crypto map is defined, the Cisco IOS command parser will move you into crypto map configuration mode. In crypto map configuration mode, you will need to define the peer router that encryption is to take place between, define the access list that will be used for determining which packets are to be encrypted, and define the encryption algorithm to use. Listing 5.28 shows an example of defining a crypto map and the parameters of the crypto map on Router A, and Listing 5.29 shows an example for Router B. Listing 5.28: Crypto map configuration of Router A. Router−A#config t Router−A(config)#crypto map routeramap 10 cisco % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured. Router−A(config−crypto−map)#set peer routerb Router−A(config−crypto−map)#match address 100 Router−A(config−crypto−map)#set algorithm des Router−A(config−crypto−map)#end Router−A#

Listing 5.29: Crypto map configuration of Router B. Router−B#config t Router−B(config)#crypto map routerbmap 10 cisco % NOTE: This new crypto map will remain disabled until a peer and a valid access list have been configured.

181

Router−B(config−crypto−map)#set peer routera Router−B(config−crypto−map)#match address 101 Router−B(config−crypto−map)#set algorithm des Router−B(config−crypto−map)#end Router−B#

After configuring each router's crypto map, use the show crypto map command to view the parameters of the crypto map. Verifying the crypto map configuration on each router is crucial to the operation of encryption because no encryption session can be established between peer routers if the encryption policy that is configured on each router is different from the other peer. Listing 5.30 displays the output of issuing the show crypto map command on Router A. Listing 5.31 shows the output on Router B. Listing 5.30: Viewing the crypto map configuration of Router A. Router−A#sh crypto map Crypto Map "routeramap" 10 cisco Peer = routerb PE = 192.168.10.0 UPE = 192.168.11.0 Extended IP access list 100 access−list 100 permit ip 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 permit icmp 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 deny ip 192.168.10.0 0.0.0.255 any Connection Id = UNSET (0 established, 0 failed) Interfaces using crypto map routeramap: Router−A#

Listing 5.31: Viewing the crypto map configuration of Router B. Router−B#sh crypto map Crypto Map "routerbmap" 10 cisco Peer = routera PE = 192.168.11.0 UPE = 192.168.10.0 Extended IP access list 101 access−list 101 permit ip 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 101 permit icmp 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 101 deny ip 192.168.11.0 0.0.0.255 any Connection Id = UNSET (0 established, 0 failed) Interfaces using crypto map routerbmap: Router−B#

After configuring the crypto map and verifying that the parameters of the crypto map are correct between each peer, the final step in the configuration of Cisco Encryption Technology is to apply the crypto map to an encryption−terminating interface. To do so, use the crypto map command in interface configuration mode. Only one crypto map set can be applied to an interface. If multiple crypto map entries have the same crypto map name but have different sequence numbers, they are considered part of the same crypto set and each one is sequentially assigned to the interface.

182

Listing 5.32 displays an example of applying the defined crypto map on Router A to its serial interface. Listing 5.33 displays an example of applying the defined crypto map on Router B to its serial interface. Listing 5.32: Applying the crypto map to Router A. Router−A#config t Enter configuration commands, one per line. End with CNTL/Z. Router−A(config)#int serial0/0 Router−A(config−if)#crypto map routeramap Router−A(config−if)#end Router−A#

Listing 5.33: Applying the crypto map to Router B. Router−B#config t Enter configuration commands, one per line. End with CNTL/Z. Router−B(config)#int serial0/0 Router−B(config−if)#crypto map routerbmap Router−B(config−if)#end Router−B#

To test the configurations of Router A and Router B, an extended ping will be used on Router A to ping local Ethernet interface of Router B. An extended ping is used so that the source address of the IP packet can be specified. In this case the source of the packet will be Router A's local Ethernet interface. Although the ping command is running, the debug crypto sessmgmt command is issued to display the connection setup messages. Listing 5.34 displays the output of the ping command. Listing 5.34: The ping command issued on Router A. Router−A#debug crypto sessmgmt Crypto Session Management debugging is on Router−A# Router−A#ping ip Target IP address: 192.168.11.1 Repeat count [5]: 30 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.10.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 30, 100−byte ICMP Echos to 192.168.11.1, timeout is 2 − seconds:

After the ping has started, the output listed in Listing 5.35 is displayed on the console of Router A. Listing 5.35: DEBUG output from the ping command on Router A.

183

CRYPTO−SDU: get_pet: PET node created CRYPTO−SDU:Adding new CIB for ACL: 100 CRYPTO−SDU: get_cot: New COT node allocated CRYPTO: Pending connection = −1 CRYPTO: Dequeued a message: Inititate_Connection CRYPTO: Allocated conn_id 1 slot 0, swidb 0x0, CRYPTO: Next connection id = 1 CRYPTO: DH gen phase 1 status for conn_id 1 slot 0:OK CRYPTO: Sign done. Status=OK CRYPTO_SM: sending CET message to FastEthernet0/0:192.168.11.1 CRYPTO: ICMP message sent: s=192.168.10.1, d=192.168.11.1 CRYPTO−SDU: send_nnc_req: NNC Echo Request sent CRYPTO: Sign done. Status=OK CRYPTO: Retransmitting a connection message CRYPTO: ICMP message sent: s=192.168.10.1, d=192.168.11.1 CRYPTO: Dequeued a message: CRM CRYPTO: CRM from 192.168.10.0 to 192.168.11.0 CRYPTO: Peer has serial number: 0615EC60 CRYPTO: DH gen phase 2 status for conn_id 1 slot 0:OK CRYPTO: Syndrome gen status for conn_id 1 slot 0:OK CRYPTO: Verify done. Status=OK CRYPTO: Sign done. Status=OK CRYPTO: ICMP message sent: s=192.168.12.1, d=192.168.12.2 CRYPTO−SDU: recv_nnc_rpy: NNC Echo Confirm sent. CRYPTO: Create encryption key for conn_id 1 slot 0:OK CRYPTO: Replacing −1 in crypto maps with 1 (slot 0) CRYPTO:old_conn_id=−1, new_conn_id=1, orig_conn_id=1 CRYPTO: Crypto Engine clear dh conn_id 1 slot 0: OK

Notice the final highlighted line in the output of Listing 5.35. This line states that the encryption keys are being created because each of the other highlighted lines returned a status message of OK. At this point, the status of the connections can be viewed on Router A by using the commands show crypto cisco connections and show crypto engine connections active. Listing 5.36 displays the output of the show commands. Listing 5.36: Output of show commands on Router A. Router−A#show crypto engine connections active ID Interface IP−Address State Algorithm Encrypt Decrypt 1 Serial0/0 192.168.12.1 set DES_56_CFB64 358 312 ! Router−A#show crypto cisco connections Connection Table PE UPE Conn_id New_id Algorithm 192.168.10.0 192.168.11.0 1 0 DES_56_CFB64 flags: TIME_KEYS ACL: 100 Router−A#

The show crypto engine connections active command is used to view the current active encrypted session connections for all crypto engines. The ID field identifies a connection by using a connection ID value, which is 1 in Listing 5.36. The interface field identifies the interface involved in the encrypted session connection, and the IP address field identifies the IP address of the interface. The state field is the most important field in the output of the show crypto engine connections active command in Listing 5.36; it specifies the current state of the connection, and a set state indicates an established session. The algorithm field indicates the DES algorithm that is used to 184

encrypt and decrypt packets. The final two fields display the number of packets that have been encrypted and decrypted by connection ID number 1. The show crypto cisco connections command displays the connection ID value that is assigned by the Cisco IOS when a new connection is initiated. In Listing 5.36, the connection ID is 1. The PE field represents a protected entity and displays a source IP address as specified in the crypto map's encryption access list, which is access list 100. The UPE field represents an unprotected entity and displays a destination IP address as specified in the crypto map's encryption access list, which again is access list 100. The flag field can display one of five different status messages. Table 5.1 includes each of the flag messages and provides a description of each.

Table 5.1: Flag field messages. Flag

Explanation

PEND_CONN

Indicates a pending connection

XCHG_KEYS

Indicates that a connection has timed out and the router must first exchange Diffie−Hellman numbers and generate a new session (DES) key before encrypted communication can take place again

TIME_KEYS

Indicates a session that is in progress and is counting down to key timeout

BAD_CONN

Indicates that no existing or pending connection exists for this entry

UNK_STATUS

Indicates an error condition

Because the flag field in Listing 5.36 displays TIME_KEYS, you can assume that the session is established. The ACL field in Listing 5.36 indicates that the session is using access list 100 for the duration of the connection in order to determine what should and should not be encrypted. The final configurations for Router A and Router B can be seen by issuing the show running−config command; they are displayed in Listings 5.37 and Listing 5.38. Listing 5.37: Final CET configuration of Router A. Router−A#show running−config Building configuration... ! version 12.1 service timestamps debug uptime service timestamps log uptime no service password−encryption ! hostname Router−A ! username routera privilege 15 password 0 routera !

185

memory−size iomem 10 ip subnet−zero no ip finger ip tcp synwait−time 10 no ip domain−lookup ! ! crypto cisco algorithm des crypto cisco algorithm des cfb−8 crypto cisco algorithm 40−bit−des ! ! crypto key pubkey−chain dss named−key routerb signature serial−number 0615EC60 key−string 4B013A5D DB942F8F 556B6F67 13110723 A05F17F9 D7BA15BF − 74B1C17B D2E5C4A5 ABC0A7DE D1188289 A54C80EC 5BB3B9AE − F4366FB1 D5DBB125 C44F904A 62209467 quit ! crypto map routeramap 10 cisco set peer routerb set algorithm des match address 100 ! interface Ethernet1/1 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ! interface Serial0/0 ip address 192.168.12.1 255.255.255.0 crypto map routeramap ! ip classless ip route 0.0.0.0 0.0.0.0 Serial0/0 no ip http server ! access−list 100 permit ip 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 permit icmp 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.0.255 access−list 100 deny ip 192.168.10.0 0.0.0.255 any ! line con 0 session−timeout 30 exec−timeout 30 0 login local transport input none line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local ! no scheduler allocate end

Listing 5.38: Final CET configuration of Router B. Router−B#show running−config Building configuration...

186

! version 12.1 service timestamps debug uptime service timestamps log uptime no service password−encryption ! hostname Router−B ! username routerb privilege 15 password 0 routerb ! memory−size iomem 10 ip subnet−zero no ip finger ip tcp synwait−time 10 no ip domain−lookup ! crypto cisco algorithm des crypto cisco algorithm des cfb−8 crypto cisco algorithm 40−bit−des cfb−8 ! ! crypto key pubkey−chain dss named−key routera signature serial−number 6B86ECF4 key−string CC0438CE 125C2C5E DAE47A2C B47B44EE 4737C1D9 9FDF3164 − 69CAACA7 82D25416 8CA218AC 644BE782 36966277 BBF437DF − 1347FFAA F2E3C04E 94CE60E5 5485C539 quit ! ! crypto map routerbmap 10 cisco set peer routera set algorithm des match address 101 ! ! ! ! ! ! interface Ethernet0/1 ip address 192.168.11.1 255.255.255.0 no ip directed−broadcast ! interface Serial0/0 ip address 192.168.12.2 255.255.255.0 crypto map routerbmap ! ip classless ip route 0.0.0.0 0.0.0.0 Serial0/0 no ip http server ! access−list 101 permit ip 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 101 permit icmp 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.0.255 access−list 101 deny ip 192.168.11.0 0.0.0.255 any ! ! line con 0 session−timeout 30 exec−timeout 30 0 login local

187

transport input none line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local ! end

188

Chapter 6: Internet Protocol Security In Brief Internet Protocol Security (IPSec) is a framework of open standards for ensuring secure private communications over IP networks. Based on standards developed by the Internet Engineering Task Force (IETF), IPSec ensures confidentiality, integrity, and authenticity of data communications across a public IP network. IPSec provides a necessary component for a standards−based, flexible solution for deploying a networkwide security policy. The IPSec initiative proposed to offer a standard way of establishing authentication and encryption services between end points. This means not only standard algorithms and transforms, but also standard key negotiation and management mechanisms to promote interoperability between devices by allowing for the negotiation of services between them. IPSec provides Network layer encryption, and the standards provide several new packet formats. Authentication Header (AH) provides data integrity, and Encapsulating Security Payload (ESP) provides data integrity and confidentiality. The Diffie−Hellman protocol is used to create a shared secret key between two IPSec peers, and Internet Key Exchange (IKE), based on Internet Security Association Key Management Protocol (ISAKMP)/Oakley, is the protocol used to manage the generation and handling of keys. It is also the protocol by which potential peer devices form security associations. A security association (SA) is a negotiated policy or agreed−upon way of handling the data that will be exchanged between two peer devices; the transform used to encrypt data is an example of a policy item. The active SA parameters are stored in the Security Association Database (SAD). SAs for both IKE and IPSec are negotiated by IKE over various phases and modes. During Phase 1, IKE negotiates IPSec security associations. Two modes can be used for Phase 1: • Main mode, which is used the majority of the time. • Aggressive mode, which is used under rare circumstances. The user cannot control which mode is chosen because the router automatically chooses a mode. The mode chosen depends on the configuration parameters used between each peer. During Phase 2, IKE negotiates IPSec security associations. The only Phase 2 exchange is quick mode: • Phase 1—During Phase 1, IKE negotiates IPSec security associations. Two modes can be used for Phase 1: 1. Main mode, which is used the majority of the time. 2. Aggressive mode, which is used under rare circumstances. The user cannot control which mode is chosen, because the router automatically chooses a mode. The mode chosen depends on the configuration parameters used between each peer: • Phase 2—During Phase 2, IKE negotiates IPSec security associations and the only Phase 2 exchange is quick mode. IPSec SAs terminate through deletion or by timing out. When the SAs terminate, the keys are also 189

discarded. When subsequent IPSec SAs are needed for a flow, IKE performs a new Phase 2 and, if necessary, a new Phase 1 negotiation. A successful negotiation results in new SAs and new keys. New SAs can be established before the existing SAs expire so that a given flow can continue uninterrupted. Security associations are unidirectional, meaning that for each pair of communicating systems there are at least two security connections. The security association is uniquely identified by a randomly chosen unique number called the security parameter index (SPI) and the destination IP address of the IPSec peer. When a system sends a packet that requires IPSec protection, it looks up the security association in its database, applies the specified processing, and then inserts the SPI from the security association into the IPSec header. When the IPSec peer receives the packet, it looks up the security association in its database by destination address and SPI and then processes the packet as required. In summary, the security association is simply a statement of the negotiated security policy between two devices.

IPSec Packet Types IPSec defines a set of headers that are added to IP packets. These new headers are placed after the IP header and before the Layer 4 protocol. They provide information for securing the payload of the IP packet. The security services are provided by the Authentication Header (AH) and the Encapsulating Security Payload (ESP) protocols. AH and ESP can be used independently or together, although for most applications, just one of them is sufficient. For both of these protocols, IPSec does not define the specific security algorithms to use; instead it provides an open framework for implementing industry−standard algorithms. Authentication Header Authentication Header (AH), described in RFC 2402, ensures the integrity and authenticity of the data, including the invariant fields in the outer IP header. It does not provide confidentiality protection, meaning it does not provide encryption. When an AH mode header is added to an IP packet, it provides authentication for as much of the IP header as possible, as well as for all the upper−layer protocols of an IP packet. However, some of the IP header fields may change in transit, and the value of these fields, when the packet arrives at the receiver, may not be predictable by the sender. These fields are known as mutable fields, and their values cannot be protected by AH. Predictable fields are also known as immutable fields. AH provides authentication and integrity to packets by performing an integrity check, which is a keyed hash using a shared secret value that creates a message digest, when used together they are known as the integrity check value (ICV). The ICV is computed on the following: • IP header fields that are either immutable in transit or predictable in value upon arrival at the end point for the Authentication Header security association. • The Authenticated Header, payload length, reserved fields, SPI, sequence number, authentication data, and padding bytes. • The upper−layer protocol data. The result of the integrity check value helps the remote peer to determine if the packet has changed in transit. Upon receipt of the packet, the remote peer performs the same integrity check on the packet and compares the integrity check value that it has computed against the value of the integrity check value that the sender provided. The following are immutable fields and are included in the Authentication Header integrity check value computation:

190

• Version • Internet header length • Total length • Identification • Protocol • Source address • Destination address AH cannot include in the integrity check any mutable field of the packet that might be modified by other routers within the transmission path of the packet from the source to the destination. The following are mutable fields and are not included in the computation of the AH ICV: • Type of Service (ToS) • Flags • Fragment offset Encapsulating Security Payload Encapsulating Security Payload (ESP), described in RFC 2406, ensures the confidentiality, integrity, and optional authenticity of the data, yet ESP does not use the invariant fields in the IP header to validate data integrity. ESP has an optional field used for authentication. It contains an ICV that is computed over the remaining part of the ESP, minus the authentication field. The length of the optional field varies depending on the authentication algorithm that is chosen. If authentication is not chosen, the ICV is omitted. Authentication is always calculated after the encryption is done. ESP performs encryption at the IP packet layer. It supports a variety of symmetric encryption algorithms. The default algorithm for IPSec is the 56−bit Data Encryption Standard using the cipher block chaining mode transform (DES−CBC). This cipher must be implemented to guarantee interoperability with other IPSec products. The services that are provided by ESP depend on the options that are configured during the IPSec implementation and after an IPSec SA is established.

IPSec Modes of Operation The format of the AH and ESP headers and the values contained within each packet vary according to the mode in which each is used. IPSec operates in either tunnel or transport mode. Transport Mode Transport mode is used when both peers are hosts. It may also be used when one peer is a host and the other is a gateway if that gateway is acting as a host. Transport mode has an advantage of adding only a few bytes to the header of each packet. When transport mode is used, the original header is not protected. This setup allows the true source and destination addresses to be viewed by intermediate devices implemented based on the contents of the IP header. One advantage of not changing the original header is that Quality of Service (QoS), can be processed from the information in the IP header. One disadvantage is that it is possible to do traffic analysis on the packets. Transport mode can be used only if the two end devices are the ones providing IPSec protection. Transport mode cannot be used if an intermediate device, such as a router or firewall, is providing the IPSec protection. Figure 6.1 displays an example of a normal IP packet.

191

Figure 6.1: IP packet. When Authentication Header (AH) is used in transport mode, the AH services protect the external IP header along with the data payload. It protects all the fields in the header that do not change in transport. The AH header goes after the IP header and, if present before the ESP header, if present, and other higher−layer protocols, like TCP. Figure 6.2 shows an example of using AH in transport mode.

Figure 6.2: AH in transport mode. When ESP is used in transport mode, the IP payload is encrypted; however, the original headders are not encrypted. The ESP header is inserted after the IP header and before the upper−layer protocol header, like TCP. The upper−layer protocols are encrypted and authenticated along with the ESP header. ESP does not authenticate the IP header or the higher−layer information, such as TCP port numbers in the Layer 4 header. Figure 6.3 shows an example of using ESP in transport mode.

Figure 6.3: ESP in transport mode. Tunnel Mode Tunnel mode is used between two gateway devices, such as two PIX firewalls, or between a host and a gateway. In tunnel mode, the entire original IP packet is encrypted and becomes the payload of a new IP packet. The new IP header has the destination address of its IPSec peer. This allows for tunneling of IP packets from a protected host through a router or firewall usually to another router or firewall, which can both be acting as security gateways. One of the advantages of tunnel mode is that intermediate devices, such as routers, can do encryption without any modification to the end system. All the information from the original packet, including the headers, is protected. Tunnel mode protects against traffic analysis because, although the IPSec tunnel end points can be determined, the true source and destination end points cannot be determined because the information in the original IP header has been encrypted. When Authentication Header (AH) is used in tunnel mode, the original header is authenticated and the new IP header is protected in exactly the same manner it was protected when used in transport mode. Figure 6.4 shows an example of using AH in tunnel mode.

192

Figure 6.4: AH in tunnel mode. When ESP is used in tunnel mode, the original IP header is protected because the entire original IP packet is encrypted. When both authentication and encryption are configured, encryption is performed first, before authentication. The reason for this process to take place in this order is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving node. Prior to decrypting the packet, the receiver can detect the problem and potentially reduce the impact of an attack. Figure 6.5 shows an example of using ESP in tunnel mode.

Figure 6.5: ESP in tunnel mode. When you want to make sure that certain data from a known and trusted source gets transferred with integrity and the data does not need confidentiality, use the AH protocol. AH protects the upper−layer protocols and the IP header fields that do not change in transit, such as the source and destination addresses. AH cannot protect those fields that change in transit, such as the Type of Service (TOS) field. When the fields are protected, the values cannot be changed without detection, so the IPSec node will reject any altered IP packet. In summary, AH does not protect against someone sniffing the wire and seeing the headers and data. However, because headers and data cannot be changed without the change being detected, changed packets would get rejected. If data confidentiality is needed, use ESP. ESP will encrypt the upper−layer protocols in transport mode and the entire original IP packet in tunnel mode so that neither is readable. ESP can also provide authentication for the packets. However, when you use ESP in transport mode, the outer IP original header is not protected; in tunnel mode, the new IP header is not protected. You will probably implement tunnel mode more than transport mode during initial IPSec usage. This mode allows a network device, such as a router to act as an IPSec proxy.

Key Management I'll now discuss Internet Security Association Key Management. Internet Key Exchange Internet Key Exchange (IKE) is the facilitator and manager of IPSec−based conversations and is a derivative of Internet Security Association Key Management Protocol/Oakley (ISAKMP/Oakley), specifically for IPSec. IPSec uses the services of IKE to authenticate peers, manage the generation and handling of the keys used by the encryption algorithm, as well as the hashing algorithms between peers. It also negotiates IPSec security associations. IKE provides three modes for exchanging key information and setting up IKE SAs. The first two modes are Phase 1 exchanges, which are used to set up the initial secure channel; the other mode is the Phase 2 exchange, which negotiates IPSec SAs. The two modes in Phase 1 are main mode and aggressive mode, and the Phase 2 mode is called quick mode. An IKE SA is used to provide a 193

protected pipe for subsequent protected IKE exchanges between the IKE peers and then use Phase 2 quick mode with the IKE SA to negotiate the IPSec SAs. Main mode has three two−way exchanges between the initiator and receiver. In the first exchange, the algorithms and hashes are agreed upon. The second exchange uses Diffie−Hellman to agree on a shared secret and to pass nonces. (Nonces are random numbers sent to the other party and signed and returned to prove their identity. The third exchange verifies the identity of the other peer. In aggressive mode, fewer exchanges are done using fewer packets than with main mode. On the first exchange, almost everything is squeezed in—the proposed SA. The receiver sends back everything that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange. The disadvantage of using the aggressive mode is that both sides have exchanged information before there is a secure channel. Therefore, it is possible to snoop the wire and discover who formed the new SA. However, aggressive mode is faster than main mode. Quick mode occurs after IKE has established the secure tunnel. Every packet is encrypted using quick mode. Both negotiation of the IPSec SA and derivation of the key material needed by IPSec are accomplished in quick mode. Before IKE will proceed, the potential parties are required to agree upon a way to authenticate themselves to each other. This authentication method is negotiated during the IKE Phase 1 main mode exchange. Before any traffic can be passed using IPSec, each router/firewall/ host must be able to verify the identity of its peer. This is accomplished by authenticating each peer, and IKE supports multiple authentication methods as part of the Phase 1 exchange. The two entities must agree on a common authentication protocol through a negotiation process. IPSec supports the following negotiation processes: • Pre−shared keys • Public key cryptography (nonces) • Digital signatures When pre−shared keys are used, identical keys are configured on each host. IKE peers authenticate each other by computing and sending a keyed hash of data that includes the pre−shared key. If the receiving peer is able to create the same hash using its pre−shared key, then it knows that both parties share the same secret key, thus authenticating the other party. Pre−shared keys do not scale well because each IPSec peer must be configured with the key of every other peer with which the router needs to establish a session. When using public key cryptography, each party generates a pseudo−random number (a nonce) and encrypts it in the other party's public key. The ability for each party to compute a keyed hash containing the other peer's nonce, decrypted with the local private key as well as other publicly and privately available information, authenticates the parties to each other. This system provides for deniable transactions. That is, either side of the exchange can plausibly deny that it took part in the exchange. Currently, only the RSA public key algorithm is supported. When digital signatures are used, each device digitally signs a set of data and sends it to the other party. This method is similar to public key cryptography, except that it provides nonrepudiation. Sharing keys does not scale well for a large network. One method that does scale is encapsulation of the public key in a digital certificate authenticated by a Certificate Authority (CA). A CA is a trusted third party who can bind a public key to an identity. In this case, that includes the identity of devices, especially router and firewall devices. 194

In summary, when the IKE negotiation begins, IKE looks for an IKE policy that is the same on both peers. The peer that initiates the negotiation will send all its configured policies to the remote peer, and the remote peer will try to find a match. The remote peer looks for a match by comparing its own highest priority policy against the other peer's received policies. The remote peer checks each of its configured policies in the order of its highest priority first until a match is found. A match is made when both policies from the two peers contain the same encryption, hash, authentication, and Diffie−Hellman parameter values and when the remote peer's policy specifies a lifetime less than or equal to the lifetime in the policy being compared. If no acceptable match is found, IKE refuses negotiation and IPSec will not be established. If a match is found, IKE will complete negotiation and IPSec security associations will be created Diffie−Hellman Key Agreement Diffie−Hellman provides a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. Diffie−Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining your private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material. Each peer generates a public key and private key pair. The private key that is generated by each peer is never shared; the public key is calculated from the private key by each peer and the result is exchanged with the other peer. Each peer combines the other peer's public key with its own private key and each peer computes the same shared secret number. The shared secret number is then converted into a shared secret key, which is used for encrypting data using the encryption algorithm specified during the security association setup. The Diffie−Hellman key agreement has two system parameters, p and g. They are both public and may be used by all the users in a system. Parameter p is a prime number and parameter g (usually called a generator) is an integer less than p with the following properties: for every number n between 1 and p‘ inclusive, there is a power k, of g k such that n = g k modulus p. The Diffie−Hellman key agreement can be explained further using the following example: 1. The Diffie−Hellman process begins with each host creating a prime number, p (which is larger than 2) and a base number, g, an integer that is smaller than p. 2. Next, the hosts each secretly generate a private number called x, which is less than p 1. 3. The hosts next generate the public keys, y. They are created with the following function: y = gx % p

4. The two hosts now exchange the public keys (y) and the exchanged numbers are converted into a secret key, z: z = yx % p

5. The value z can now be used as the key for the IPSec encryption method used to transfer information between the two hosts. Mathematically, the two hosts should have generated the same value for z. 6. This yields the following: z = (gx % p)x' % p = (gx' % p)x % p

On Cisco devices, Diffie−Hellman can be configured to support one of two different group modes on a per−IKE−policy basis: 768−bit groups or 1024−bit groups. The 1024−bit groups are more challenging to break, but they come with the added expense of being more CPU intensive. 195

Encryption I'll now discuss encryption. Data Encryption Standard IPSec can use either the 56−bit Data Encryption Standard (DES) algorithm or the 168−bit 3DES algorithm for encryption. After two IPSec peers obtain their shared secret key, they can use the key to communicate with each other using the DES encryption algorithm. The 56−bit DES system consists of an algorithm and a key. The key has a length of 64 bits, of which 56 are used as the key. The remaining 8 bits are parity bits used in checking for errors. Even with just 56 bits, there are more than 70 quadrillion possible keys (simply, 2 56). The digits in the key must be independently determined to take full advantage of 70 quadrillion possible keys. The mechanics of DES are relatively simple. DES enciphers data in blocks of 64 bits of binary data. Given a message that needs to be encrypted, one must first pick a 64−bit key and then convert the plaintext into binary form. It takes a string of only 5 bits to describe our alphabet, because 2Ø5 32 and the alphabet is 26 letters long. This is relatively easy to do. Now within the blocks or strings of 64 bits, order is very important. The leftmost bit is known as the 1st bit or is in the first position. The rightmost bit is the 64th bit. The first step in the DES procedure is to change the order within each block. For example, the 52nd bit in the original string becomes the 1st bit in this new block. Bit 40 becomes bit 2 and so forth, as specified by a table. This step is called the initial permutation. Permutation is used in the strict mathematical sense that only order is changed. The results of this initial permutation are broken down into two halves. The first 32 bits become L0. The last 32 bits are called R0. Now the data is subjected to the following transformation 16 times: Ln = Rn−1 where R0 occurs at n=1 Rn = Ln−1 ( ((Rn−1, Kn) where L0 occurs at n=1

After the first iteration, we are presented with the following: Ln+1 = Rn in essence Ln+1 = Ln−1 ( ((Rn, K0) Rn+1 = Ln ( ((Rn, K0) in essence Rn+1 = Rn−1 ( ((Rn, K0)

Cisco's encryption algorithm incorporates cipher feedback (CFB), which further guarantees the integrity of the data received by using feedback. This is the essence of DES. The key and the message become interwoven and inseparable, which makes it difficult to break apart the cipher text into its constituent parts. This procedure is performed 16 times. The expression Rn = Ln‘ (((Rn+1, Kn) is simply saying, "Add L, bit by bit in modulo 2, from one iteration ago to the term ((Rn‘, Kn)." This function is determined by R, one iteration ago and Kn, which is based on the key. Kn is, in turn, given by another formula, Kn= KS(n, KEY). Because this algorithm goes through 16 iterations, Kn will be of length 48. The calculation of Kn is another operation in which DES looks in a table. The calculation of the function ((Rn+1,Kn) is likewise simple. First, however, notice that R is of 32−bit length and K is 48 bits long. R is expanded to 48 bits using another table. The resulting R is added to K (using bit−by−bit addition in mod base 2). The result of this addition is broken into eight 6−bit strings. One enters into another table that gives the primitive function Sn. There is one S function for each 6−bit block. The result of entering into these S functions is a 32−bit string. After 16 iterations, the result should be, L16 and R16. These two strings are united where R forms the first 32 bits and L forms the last 32. The 64−bit result is entered into the inverse of the initial permutation function. The result of this last step is cipher text. Decoding is accomplished by simply running the process backwards. 196

Triple DES When the encryption services provided by the 56−bit DES algorithm are not deemed as being strong enough from a mathematical standpoint for encryption of data, the Triple DES (3DES) symmetrical encryption algorithm can be used. Cisco products support the use of the 168−bit 3DES encryption algorithm with IPSec implementations. 3DES has been standardized by the National Institute of Standards and Technology (NIST) and is a variant of 56−bit DES. 3DES takes data and breaks it into 64−bit blocks just as DES does, yet 3DES processes each block three times. Each time 3DES uses an independent 56−bit key, the encryption strength over 56−bit DES is tripled. MD5 Message Digest The MD5 algorithm, an extension to the MD4 message digest, can be used to ensure that a message has not been altered. The MD5 algorithm takes as input a message of arbitrary length—for example, a username and password—and after running the message through the algorithm, MD5 produces as output a 128−bit message digest of the input. It is considered computationally infeasible to produce two messages having the same message digest or to produce a message that has a predefined message digest.

IPSec Implementations Generally, there are two accepted schemes for implementing IPSec. The first is for each end station to perform IPSec directly. This provides the advantage of not having an impact on the network design, topology, or any routing decisions. The disadvantage is that each end station usually must possess special software or needs an upgrade in addition to the added configuration. Complicating the issue is that the user must be aware of when encryption is required. Because users make the decisions, they potentially must make a change to the configuration. When using this scheme, encryption is not transparent to the end user. The second is for the network devices to provide the service of IPSec. An advantage to this scheme is that the end stations and users are not directly involved. Another consideration is that, when you design a network to use encryption and the end stations won't be doing the encryption, the enrypting end points impose a very simple constraint. All traffic that has security services applied to it must go through the two peering crypto end points. This setup places some limits on asymmetric traffic paths. After a packet is processed by one enrypting end point (one end of the SA), the packets may take any route between the two encrypting end points; however, the route must bring the packet back to the peer encrypting end point for processing. This requirement means that there are single points in a network where IPSec traffic must traverse. For enterprises with multiple access points onto the Internet, care must be taken in how network addresses are advertised to enforce the symmetric relationship between IPSec peers. The security associations are unique between the two peering encrypting end points and are not shared with other possible encrypting devices. When applying security, make sure that it is indeed secure; that is, make sure that the "state" of any particular data flow in the SAD is restricted to the two peers.

Immediate Solutions

197

Configuring IPSec Using Pre−Shared Keys This section details how to configure IPSec on Cisco routers using pre−shared keys. Configuring IPSec encryption can be difficult and complicated. However, with a well−thought−out plan, the challenges associated with configuring IPSec can be overcome. Because IPSec can be configured without IKE (manual key configuration) or with IKE (pre−shared keys, public keys, or digital certificates), and the configuration of each is different, I will begin by configuring IPSec using IKE with pre−shared keys for authentication of IPSec sessions. To configure IKE, perform the tasks in the following list. The first two tasks are required; the remaining tasks are optional: 1. The first step is to use the crypto isakmp enable command to enable IKE globally for the router. If you do not want IKE to be used with your IPSec implementation, use the no crypto isakmp enable command. IKE is enabled by default globally on the router and does not need to be enabled on a per−inter−faces basis. 2. The next step is to define a suite of IKE policies on the router. The IKE policies define the parameters to be used during IKE negotiation. Use the crypto isakmp policy command to uniquely identify and define the policy. The priority parameter assigns a priority to the policy and can accept any integer from 1 to 10,000, with 1 being the highest priority and 10,000 being the lowest priority. Multiple IKE policies can be configured for each peer participating in IPSec. Use of this command takes you into IKE policy configuration command mode (config−isakmp). 3. In IKE policy configuration command mode, use the encryption command to define the encryption algorithm to be used for encryption of packets between IPSec peers. If this command is not defined within the IKE policy, the encryption algorithm defaults to 56−bit DES. 4. In IKE policy configuration command mode, use the hash command to define the hash algorithm used within the IKE policy. If this command is not defined within the IKE policy, the hash algorithm defaults to SHA1. 5. To specify the authentication method used in the IKE policy, use this command in IKE policy configuration command mode: authentication

If this command is not defined within the IKE policy, the authentication method defaults to RSA signatures. 6. To specify the Diffie−Hellman identifier used for the IKE policy, use the group command in IKE policy configuration command mode. The group 1 command specifies that the policy should use the 768−bit Diffie−Hellman group. The group 2 command specifies that the policy should use the 1024−bit Diffie−Hellman group. If this command is not defined within the IKE policy, the 768−bit Diffie−Hellman group will be used. 7. To specify how long the IKE established security association should exist before expiring, use the lifetime command in IKE policy configuration mode. If this command is not defined within the IKE policy, the security associations expire after 86,400 seconds or 1 day. The default values for configured policies do not show up in the configuration when you issue a show running command. To view the default IKE values within the configured policies, use the show crypto isakmp policy command. The configuration commands in the preceding list are all that are needed to enable and define the IKE policy. Next, you should define the ISAKMP identity for each peer that uses pre−shared keys in Note

198

an IKE policy. When two peers use IKE to establish IPSec security associations, each peer sends its identity to the remote peer. To configure the ISAKMP identity mode used between peers, use the commands in the following steps: 1. Use this command to define the identity used by the router: crypto isakmp identity

The address parameter is used when there is only one interface and only one IP address that is used by the peer for IKE negotiations and the IP address is known. The hostname parameter is used if there is more than one interface that might be used for IKE negotiations or if the IP address is unknown. If this command is not specified, the identity parameter will be used by the router. 2. If the crypto identity was configured to use the hostname of the remote peer, the hostname of the remote peer must be defined using the ip host command to define a static hostname−to−address mapping in the host cache. After configuring the ISAKMP identity used between peers, you must specify the pre−shared keys to use between each peer. The keys must be configured anytime pre−shared authentication is specified in an IKE policy. The same pre−shared key must be configured on each pair of IPSec peers when you're using pre−shared keys for IKE authentication. Configuration of the pre−shared key can be accomplished by two separate commands and is dependant upon the identity configured in the previous command. Configure the pre−shared key using the following commands. To configure a pre−shared authentication key, use this command: crypto isamkmp key key−string address −

This command is used if the ISAKMP identity was configured to use the address parameter or if the identity was not configured, because the default is to use the peer routers address. If the ISAKMP identity was configured to use the hostname parameter, then use this command: crypto isakmp key key−string hostname

The next task that needs to be performed is to configure the router for IPSec. The first step in configuring IPSec is to define the transform set the router should use. A transform set is an acceptable combination of security protocols, algorithms, and other settings to apply to IPSec−protected traffic. The transform set is agreed upon between peers during the IPSec security association negotiation. It tells the router how to protect data within a particular data flow. During IPSec security association negotiations with IKE, the peers search for a transform set that is the same at both peers. When such a transform set is found, it is selected and will be applied to the protected traffic as part of both peers' IPSec security associations. To define a transform set, use the following commands starting in global configuration mode (only the first command is required): 1. Define the transform set using the following command:

199

crypto ipsec transform−set transform−set−name −

Rules exist that define an acceptable combination of security protocols and algorithms that can be used as transforms. Table 6.1 defines the acceptable combinations.

Table 6.1: Transform combinations. Type

Transform

AH Authentication Transform

ah−md5−hmac Authentication Header with Message Digest 5 authentication

ESP Encryption Transform

ESP Authentication Transform

Description

ah−sha−hmac

Authentication Header with SHA1 authentication

esp−des

ESP with 56−bit DES encryption

esp−3des

ESP with 168−bit DES encryption

esp−null

Null encryption

esp−md5−hmac ESP with Message Digest 5 authentication

esp−sha−hmac ESP with SHA1 authentication 2. To change the mode associated with the transform set, use the mode command in crypto transport configuration mode. If this command is omitted, the mode will default to tunnel mode. Note The IOS command parser will deny you from entering invalid combinations. There is one other possible transform, comp−lzs; however, it will not be discussed within this book. After defining the transform set that IPSec should use, you must configure an access list. Access lists defined for IPSec are different than regular access lists, which permit or deny traffic from entering into or exiting out of an interface. Access lists are used with IPSec to define which IP traffic will be protected by encryption and which will not. To create access lists that define which traffic should be encrypted, use the following command in global configuration mode. To determine which IP packets will be encrypted by IPSec, use this command: access−list access−list−number {deny | permit} −

200

Cisco recommends that the access list keyword any be avoided when specifying the source address or destination address within the access list. It is not recommended because it causes the router to encrypt all outbound or all inbound traffic. Try to be as precise as possible when defining which packets to protect with an access list. It is also recommended that mirrored copies of the access list be configured between each host that is to perform IPSec. After configuration of the access list(s), you must define IPSec crypto maps to allow the setup of security associations for traffic flows to be encrypted. Crypto map entries contain information for IPSec. When IKE is used to establish security associations, the IPSec peers can negotiate the settings they will use for the new security associations. This allows you to specify the parameters of the crypto map on a per−peer basis. To configure the crypto maps and define the appropriate parameters, use the commands in the following steps (only the first four steps are required): 1. To create the crypto map entry and enter the crypto map configuration mode, use this command: crypto map map−name seq−num ipsec−isakmp

The map−name parameter defines the name that identifies the crypto map set. The seq−num parameter is the number that is assigned to this crypto map; it should not be chosen arbitrarily because this number is used to rank multiple crypto map entries within a crypto map set, and a crypto map entry with a lower seq−num is evaluated before a map entry with a higher seq−num. Use of this command moves you into crypto map configuration mode. The ipsec−isakmp parameter specifies that IKE will be used to establish the security associations for protecting the traffic matched by this crypto map entry. 2. In crypto map configuration mode, use this command to specify an extended access list for a crypto map entry that matches packets that should be protected by encryption: match address

3. To specify an IPSec peer, use the following command in crypto map configuration mode: set peer

You can specify the remote IPSec peer by its hostname if the hostname is mapped to the peer's IP address in a domain name server (DNS) or if you manually map the hostname to the IP address with the ip host command that was discussed earlier. When using IKE to set up security associations, you can specify multiple peers per crypto map. 4. To specify which transform sets can be used with the crypto map entry, use this command: set transform set

List multiple transform sets in order of priority with the highest−priority transform set listed first. When using IKE to set up security associations, you can specify multiple transform sets per crypto map. 201

5. Use the set pfs command to specify that IPSec should ask for perfect forward secrecy when requesting a new sa or should demand PFS in requests received from the IPSec peer. 6. To specify that separate IPSec security associations should be requested for each source/destination host pair, use the set security−association level per−host command. This command should be omitted if one security association should be requested for each crypto map access list permit entry. 7. To override the global lifetime value on a per−crypto−map−list basis, which is used when negotiating IPSec security associations, use this command: set security−association lifetime

After configuring the router for IPSec, the last step in IPSec configuration is to apply the configured crypto map to an interface. As soon as the crypto map is applied to an interface, the security associations are set up in the Security Association Database (SAD). Only one crypto map can be applied to an interface, and multiple crypto map entries with the same crypto name and different sequence numbers are permitted. To apply a previously defined crypto map set to an interface, use the commands in these steps: 1. To apply a previously defined crypto map to an interface, use the following command to move into interface configuration mode: interface

2. To apply a previously defined crypto map set to an interface, use the crypto map map−name command. A crypto map set must be applied to an interface before that interface can provide IPSec services. I'll begin with the network shown in Figure 6.6. This network contains two routers, which must communicate with one another via the use of IPSec. Router A is the corporate gateway router and Router B is the branch office router for the remote location. Remote users communicate with the corporate office via the wide area network (WAN), and when users at the branch office communicate with the corporate office, their traffic should be protected with IPSec. This configuration will use all the security services provided by both IKE and IPSec, and Router A and Router B will be configured to exchange pre−shared keys.

Figure 6.6: Basic network using IPSec. Listing 6.1 displays the configuration of Router A, and Listing 6.2 displays the configuration of Router B. Listing 6.1: IPSec configuration of Router A. hostname Router−A ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10

202

ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 11 hash md5 encryption des group 2 authentication pre−share ! crypto isakmp key ouripseckey address 10.0.30.201 ! crypto ipsec transform−set remote esp−des esp−md5−hmac ! crypto map encrypt 11 ipsec−isakmp set peer 10.0.30.201 set transform−set remote match address 120 ! interface Ethernet0/0 description Internet Connection ip address 10.0.30.200 255.255.255.0 no ip directed−broadcast ip nat outside no ip route−cache no ip mroute−cache crypto map encrypt ! interface Ethernet0/1 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ip nat inside ! ip nat pool pat 10.0.30.203 10.0.30.203 network 255.255.255.0 ip nat inside source route−map donotnat pool pat overload ! ip classless ip route 0.0.0.0 0.0.0.0 Ethernet0/0 ! access−list 120 permit ip 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.255.255 access−list 130 deny ip 192.168.10.0 0.0.0.255 − 192.168.11.0 0.0.255.255 access−list 130 permit ip 192.168.10.0 0.0.0.255 any ! route−map donotnat permit 10 match ip address 130 !

Listing 6.2: IPSec configuration of Router B. hostname Router−B ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 10 hash md5 encryption des group 2

203

authentication pre−share ! crypto isakmp key ouripseckey address 10.0.30.200 ! crypto ipsec transform−set remote esp−des esp−md5−hmac ! crypto map encrypt 10 ipsec−isakmp set peer 10.0.30.200 set transform−set remote match address 120 ! interface Ethernet1/0 description Internet Connection ip address 10.0.30.201 255.255.255.0 no ip directed−broadcast ip nat outside crypto map encrypt ! interface Ethernet0/1 ip address 192.168.11.1 255.255.255.0 no ip directed−broadcast ip nat inside ! ip nat pool pat 10.0.30.204 10.0.30.204 network 255.255.255.0 ip nat inside source route−map donotnat pool pat overload ! ip classless ip route 0.0.0.0 0.0.0.0 Ethernet1/0 ! access−list 120 permit ip 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.255.255 access−list 130 deny ip 192.168.11.0 0.0.0.255 − 192.168.10.0 0.0.255.255 access−list 130 permit ip 192.168.11.0 0.0.0.255 any ! route−map donotnat permit 10 match ip address 130 !

The configurations in Listing 6.1 and Listing 6.2 configure each router to use the benefits of IPSec, but the configurations utilize the services of PAT. PAT (NAT could have been configured in place of PAT) makes use of a route map within this configuration. The route map is needed to discriminate between packets that have a destination address that matches an address within the enterprise's IP address space or packets that could be destined to the Internet. Each router has been configured with an IKE policy using the crypto isakmp policy command. Within each IKE policy, the encryption algorithm is set at the default 56−bit DES. Note Default commands used for configuring IPSec and IKE are not displayed in the configuration output of the show running command. The default commands used to configure IPSec and IKE are listed in this chapter for completeness. Each router's Diffie−Hellman group has been changed from the default 768−bit group 1 to the stronger 1024−bit group 2, and the IKE authentication method has been defined to use pre−shared keys. Each router is then configured with the pre−shared key used for authentication; the pre−shared key is specified by using the crypto isakmp key command. In Listing 6.1 and Listing 6.2, the key is defined as ouripeckey. This concludes the configuration of IKE on Router A and Router B. 204

Next, IPSec support must be configured on Router A and Router B. The first step used in Listing 6.1 and Listing 6.2 to configure IPSec support is to define a transform set that defines the security protocols and algorithms used between the two peers; this was done using the crypto ipsec transform−set command, which is named remote. A crypto map is then defined that indicates that IKE will be used to establish the IPSec security associations for protecting the traffic specified by this crypto map entry, using the ipsec−isakmp parameter. The IPSec peer is identified and the transform set is defined for communication between the peers. An access list is defined, which specifies whether or not IPSec should provide encryption services for packets that are matched by access list entry. To begin testing the configurations of Router A and Router B, an extended Ping will be issued with the packet sourced from the Ethernet0/1 interface of Router B; the packet's destination is the Ethernet0/1 interface of Router A. On Router B, I have issued the debug crypto ipsec, debug crypto isakmp, and debug crypto engine commands. Each of these commands can be used to view event messages for IPSec and IKE. The packets from the Ping request will match the access list entry and require the encryption services of IPSec. Listing 6.3 displays the Ping request and the debug commands. Listing 6.3: Enabling the debug commands and the Ping request. #debug crypto ipsec Crypto IPSEC debugging is on #debug crypto isakmp Crypto ISAKMP debugging is on #debug crypto engine Crypto Engine debugging is on #ping ip Target IP address: 192.168.10.1 Repeat count [5]: 100 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.11.1 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 100, 100−byte ICMP Echos to 192.168.10.1, − timeout is 2 seconds:

After the Ping request sends the first packet, Router B determines that the packet matches the access list—in this case, access list 120, configured under the IPSec crypto map—and begins the security association setup by offering to Router A all of its configured transform sets. This can be verified by displaying the output of the debug crypto ipsec command. Listing 6.4 shows the security association request. Listing 6.4: Security association request. : IPSEC(sa_request): , (key eng. msg.) src= 10.0.30.201, dest= 10.0.30.200, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4),

205

protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 120s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4004

The debug output in Listing 6.4 shows that, upon security association setup, Router B offers to Router A all of its configured transform sets. It is at this point that the final verification of the IKE security association takes place. The IKE security association verification messages can be seen by displaying the output of the debug crypto isakmp command. Listing 6.5 shows the IKE verification process. Listing 6.5: IKE verification process. ! : : : : : : : : : : : : : : : : : : : : :

: : : : : : !

ISAKMP ISAKMP ISAKMP ISAKMP ISAKMP

(6): (6): (6): (6): (6):

beginning Main Mode exchange sending packet to 10.0.30.200 (I) MM_NO_STATE received packet from 10.0.30.200 (I) MM_NO_STATE processing SA payload. message ID = 0 Checking ISAKMP transform 1 against priority 10 − policy ISAKMP: encryption DES−CBC ISAKMP: hash MD5 ISAKMP: default group 2 ISAKMP: auth pre−share ISAKMP: Open ISAKMP: life duration (basic) of 120 ISAKMP (6): atts are acceptable. Next payload is 0 ISAKMP (6): SA is doing pre−shared key authentication using id type ID_IPV4_ADDR ISAKMP (6): sending packet to 10.0.30.200 (I) MM_SA_SETUP ISAKMP (6): received packet from 10.0.30.200 (I) MM_SA_SETUP ISAKMP (6): processing KE payload. message ID = 0 ISAKMP (6): processing NONCE payload. message ID = 0 ISAKMP (6): SKEYID state generated ISAKMP (6): processing vendor id payload ISAKMP (6): speaking to another IOS box! ISAKMP (6): ID payload next−payload : 8 type : 1 protocol : 17 port : 500 length : 8 ISAKMP (6): Total payload length: 12 ISAKMP (6): sending packet to 10.0.30.200 (I) MM_KEY_EXCH ISAKMP (6): received packet from 10.0.30.200 (I) MM_KEY_EXCH ISAKMP (6): processing ID payload. message ID = 0 ISAKMP (6): processing HASH payload. message ID = 0 ISAKMP (6): SA has been authenticated with 10.0.30.200

After the security associations are set up, IKE begins IPSec negotiation. You can see the process of IKE negotiation of IPSec by again viewing the output of the debug crypto ipsec and debug crypto isakmp commands. Listing 6.6 displays the IKE negotiation. Listing 6.6: IKE negotiation. ! : IPSEC(key_engine): got a queue event...

206

: IPSEC(spi_response): getting spi 559422693 for SA from 10.0.30.200 to 10.0.30.201 for prot 3 ! : ISAKMP (6): beginning Quick Mode exchange, M−ID of 121737022 : ISAKMP (6): sending packet to 10.0.30.200 (I) QM_IDLE : ISAKMP (6): received packet from 10.0.30.200 (I) QM_IDLE : ISAKMP (6): processing SA payload. message ID = 121737022 : ISAKMP (6): Checking IPSec proposal 1 : ISAKMP: transform 1, ESP_DES : ISAKMP: attributes in transform: : ISAKMP: encaps is 1 : ISAKMP: SA life type in seconds : ISAKMP: SA life duration (basic) of 120 : ISAKMP: SA life type in kilobytes : ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 : ISAKMP: authenticator is HMAC−MD5 : ISAKMP (6): atts are acceptable. !

The final display shows the security association completing the setup process. When the security association setup process is complete, traffic can begin to flow from source to destination using the security services of IPSec. Listing 6.7 displays the completion of the security association setup process. Listing 6.7: Completion of security association setup process. : IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 10.0.30.200, src= 10.0.30.201, dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 : IPSEC(key_engine): got a queue event... : IPSEC(initialize_sas): , (key eng. msg.) dest= 10.0.30.201, src= 10.0.30.200, dest_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), src_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 120s and 4608000kb, spi= 0x21581CE5(559422693), conn_id= 2, keysize= 0, − flags= 0x4 : IPSEC(initialize_sas): , (key eng. msg.) src= 10.0.30.201, dest= 10.0.30.200, : ISAKMP (6): processing NONCE payload. message ID = 121737022 : ISAKMP (6): processing ID payload. message ID = 121737022 : ISAKMP (6): unknown error extracting ID : ISAKMP (6): processing ID payload. message ID = 121737022 : ISAKMP (6): unknown error extracting ID : ISAKMP (6): Creating IPSec SAs : inbound SA from 10.0.30.200 to 10.0.30.201 − (proxy 192.168.10.0 to 192.168.11.0) : has spi 331813658 and conn_id 7 and flags 4 : lifetime of 120 seconds : lifetime of 4608000 kilobytes : outbound SA from 10.0.30.201 to 10.0.30.200 − (proxy 192.168.11.0 to 192.168.10.0) : has spi 306250407 and conn_id 8 and flags 4 : lifetime of 120 seconds : lifetime of 4608000 kilobytes

207

: ISAKMP (6): sending packet to 10.0.30.200 (I) QM_IDLE : src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 120s and 4608000kb, spi= 0x1472092E(343017774), conn_id= 3, keysize= 0, − flags= 0x4 : IPSEC(create_sa): sa created, (sa) sa_dest= 10.0.30.201, sa_prot= 50, sa_spi= 0x21581CE5(559422693), sa_trans= esp−des esp−md5−hmac, sa_conn_id= 2 : IPSEC(create_sa): sa created, (sa) sa_dest= 10.0.30.200, sa_prot= 50, sa_spi= 0x1472092E(343017774), sa_trans= esp−des esp−md5−hmac , sa_conn_id= 3

After the security association is set up and complete, you can view the settings of each security association within the database (SAD) by issuing the show crypto ipsec sa command. Listing 6.8 displays the output of the security association database of Router B. Listing 6.8: Security association database on Router B. Router−B#sh crypto ipsec sa interface: Ethernet0/0 Crypto map tag: encrypt, local addr. 10.0.30.201 local ident (addr/mask/prot/port): − (192.168.11.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): − (192.168.10.0/255.255.255.0/0/0) current_peer: 10.0.30.200 PERMIT, flags={origin_is_acl,} #pkts encaps: 5, #pkts encrypt: 5, #pkts digest 5 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #send errors 5, #recv errors 0 local crypto endpt.: 10.0.30.201, remote crypto endpt.: − 10.0.30.200 path mtu 1500, media mtu 1500 current outbound spi: 20DB2311 ! inbound esp sas: spi: 0x22900598(579863960) transform: esp−des esp−md5−hmac, in use settings ={Tunnel, } slot: 0, conn id: 2, crypto map: encrypt sa timing: remaining key lifetime (k/sec): (4607999/71) IV size: 8 bytes replay detection support: Y ! inbound ah sas: ! outbound esp sas: spi: 0x20DB2311(551232273) transform: esp−des esp−md5−hmac, in use settings ={Tunnel, } slot: 0, conn id: 3, crypto map: encrypt sa timing: remaining key lifetime (k/sec): (4607999/71) IV size: 8 bytes replay detection support: Y ! outbound ah sas:

208

Router−B#

It appears that Router B has two security associations; however, in "In Brief" earlier in this chapter, it was mentioned that security associations are unidirectional. This causes Router B to set up two security associations, one for inbound ESP packets and one for outbound ESP packets. The Security Association Database (SAD) for IKE can be viewed as well by issuing the show crypto isakmp sa command. Issuing the command on Router B displays the output seen in Listing 6.9. Listing 6.9: IKE security association database. #show crypto isakmp sa dst src 10.0.30.200 10.0.30.201 !

state QM_IDLE

conn−id 16

slot 0

The connection state of an IKE security association, displayed in state field, can vary depending on which Phase and mode the security association was negotiated over. All security association states for each entry contained within the database are listed in Table 6.2.

Table 6.2: Security association states. Phase

Mode

State

Description

Phase 1

Main

MM_NO_STATE

The IKE SA has been created, yet nothing else has happened.

MM_SA_SETUP

Parameters of the IKE SA have been agreed upon by each peer.

MM_KEY_EXCH

Each peer has exchanged Diffie−Hellman public keys and have generated a shared secret.

MM_KEY_AUTH

The IKE SA has been authenticated. If this router initiated the exchange, the state transitions immediately to QM_IDLE and a quick mode exchange begins.

AG_NO_STATE

The IKE SA has been created, yet nothing else has happened.

AG_INIT_EXCH

Peers have completed first aggressive mode exchange.

Aggressive

AG_AUTH 209

The IKE SA has been authenticated. If this router initiated the exchange, the state transitions immediately to QM_IDLE and a quick mode exchange begins. Phase 2

Quick

QM_IDLE

The IKE SA is in a quiescent state; it will remain authenticated with its peer and may be used for subsequent quick mode exchanges.

The entire security association setup can take up to a minute or longer to complete, which caused the Ping request in Listing 6.3 fail. After the security associations are complete, the Ping, or any traffic that matched an entry in the access list, would flow as normal. The network in Figure 6.7 displays three routers connected to each other using a WAN connection. The layer 2 media of exchange is configured as a full mesh, allowing full communication between each host within each network. Hosts in the 192.168.10.0 network behind Router A are configured to communicate with the hosts in both the 192.168.11.0 network behind Router B and the 192.168.12.0 network behind Router C. Hosts within the 192.168.11.0 and 192.168.12.0 networks are configured in the same manner. The company that owns these routers has determined that all traffic between hosts that is exchanged via the WAN is to be protected by the services of IKE and IPSec. To meet the requirements of the company, a creative configuration of IPSec must be used.

Figure 6.7: Full mesh IPSec network Both IPSec and IKE permit the configuration of multiple crypto policies and maps. This is accomplished through the effective use of the sequence−number parameter. Listing 6.10 through Listing 6.12 display the configuration of each router to the requirements outlined earlier. Listing 6.10: IPSec configuration of Router A. hostname Router−A ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10

210

no ip domain−lookup ! crypto isakmp policy 10 hash md5 encryption des groups 2 authentication pre−share ! crypto isakmp key AandBkey address 10.0.30.201 crypto isakmp key AandCkey address 10.0.30.202 ! crypto ipsec transform−set routerb esp−des esp−md5−hmac crypto ipsec transform−set routerc esp−des esp−md5−hmac ! crypto map mesh 10 ipsec−isakmp set peer 10.0.30.201 set transform−set routerb match address 100 ! crypto map mesh 11 ipsec−isakmp set peer 10.0.30.202 set transform−set routerc match address 101 ! interface Ethernet0/1 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ip nat inside ! interface Serial0 ip address 10.0.30.200 255.255.255.0 no ip directed−broadcast ip nat outside no ip mroute−cache no fair−queue crypto map mesh ! ip nat inside source route−map donotnat interface Serial0 − overload ip classless ip route 192.168.11.0 255.255.255.0 10.0.30.201 ip route 192.168.12.0 255.255.255.0 10.0.30.202 no ip http server ! access−list 100 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 101 permit ip 192.168.10.0 0.0.0.255 192.168.12.0 − 0.0.0.255 access−list 102 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 102 deny ip 192.168.10.0 0.0.0.255 192.168.12.0 − 0.0.0.255 access−list 102 permit ip 192.168.10.0 0.0.0.255 any ! route−map donotnat permit 10 match ip address 102

Listing 6.11: IPSec configuration of Router B. hostname Router−B ! username ipsec privilege 15 password 0 ipsec ip subnet−zero

211

ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 11 hash md5 encryption des groups 2 authentication pre−share ! crypto isakmp key AandBkey address 10.0.30.200 crypto isakmp key BandCkey address 10.0.30.202 ! crypto ipsec transform−set routera esp−des esp−md5−hmac crypto ipsec transform−set routerc esp−des esp−md5−hmac ! crypto map mesh 11 ipsec−isakmp set peer 10.0.30.200 set transform−set routera match address 100 ! crypto map mesh 12 ipsec−isakmp set peer 10.0.30.202 set transform−set routerc match address 101 ! interface Ethernet0/1 ip address 192.168.11.1 255.255.255.0 no ip directed−broadcast ip nat inside ! interface Serial0/0 ip address 10.0.30.201 255.255.255.0 no ip directed−broadcast ip nat outside no ip mroute−cache no fair−queue crypto map mesh ! ip nat inside source route−map donotnat interface Serial0/0 – overload ip classless ip route 192.168.10.0 255.255.255.0 10.0.30.200 ip route 192.168.12.0 255.255.255.0 10.0.30.202 no ip http server ! access−list 100 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 – 0.0.0.255 access−list 101 permit ip 192.168.11.0 0.0.0.255 192.168.12.0 – 0.0.0.255 access−list 102 deny ip 192.168.11.0 0.0.0.255 192.168.10.0 – 0.0.0.255 access−list 102 deny ip 192.168.11.0 0.0.0.255 192.168.12.0 – 0.0.0.255 access−list 102 permit ip 192.168.11.0 0.0.0.255 any ! route−map donotnat permit 11 match ip address 102

Listing 6.12: IPSec configuration of Router C. hostname Router−C !

212

username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 12 hash md5 encryption des groups 2 authentication pre−share ! crypto isakmp key BandCkey address 10.0.30.201 crypto isakmp key AandCkey address 10.0.30.200 ! crypto ipsec transform−set routera esp−des esp−md5−hmac crypto ipsec transform−set routerb esp−des esp−md5−hmac ! crypto map mesh 12 ipsec−isakmp set peer 10.0.30.200 set transform−set routera match address 110 ! crypto map mesh 13 ipsec−isakmp set peer 10.0.30.201 set transform−set routerb match address 111 ! interface Ethernet1 ip address 192.168.12.1 255.255.255.0 no ip directed−broadcast ip nat inside ! interface Serial1/0 ip address 10.0.30.202 255.255.255.0 no ip directed−broadcast ip nat outside no ip mroute−cache no fair−queue crypto map mesh ! ip nat inside source route−map donotnat interface Serial1/0 – overload ip classless ip route 192.168.10.0 255.255.255.0 10.0.30.200 ip route 192.168.11.0 255.255.255.0 10.0.30.201 no ip http server ! access−list 110 permit ip 192.168.12.0 0.0.0.255 192.168.10.0 − 0.0.0.255 access−list 111 permit ip 192.168.12.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 112 deny ip 192.168.12.0 0.0.0.255 192.168.10.0 − 0.0.0.255 access−list 112 deny ip 192.168.12.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 112 permit ip 192.168.12.0 0.0.0.255 any ! route−map donotnat permit 12 match ip address 112

These configurations define multiple crypto maps with different sequence numbers defined for each 213

crypto map. This allows each router to configure IPSec parameters accordingly on a per−host basis. To view the security associations that IKE has set up for each router, issue the show crypto isakmp sa command on each router. Issuing the command on Router B displays the following output. #show crypto isakmp sa dst src 10.0.30.200 10.0.30.201 10.0.30.202 10.0.30.201 !

state QM_IDLE QM_IDLE

conn−id 16 17

slot 0 0

Found on page: 138

Related solution: Configuring Network Address Translation (NAT)

Configuring IPSec Using Manual Keys The use of IKE enhances IPSec by providing additional features, flexibility, and ease of configuration for IPSec standards. Some network equipment may not support IKE, and in these instances, IPSec can be configured without IKE. If IKE is not used for establishing the security associations, there is no negotiation of security associations, so the configuration information in both systems must be the same in order for traffic to be processed successfully by IPSec. IKE provides for the dynamic creation of SAs and is the preferred method to use with IPSec. This section covers manual configuration. Manual keying involves a direct exchange of keys between IPSec peers, and this method of key exchange is not a very scalable solution for IPSec. A benefit of manual keying is that it allows Cisco networking equipment to work with other vendors’ networking equipment when the services of IPSec are needed and IKE cannot be used. The process of configuring manual IPSec involves the configuration of remote keys during the initial IPSec configuration of the routers. Each crypto map requires multiple keys. For AH authentication, there is a key for both the outbound and inbound sessions. For ESP, there is a cipher and authentication key for both the outbound and inbound sessions. To configure manual IPSec keys between IPSec peers, follow these steps: 1. To create the crypto map entry and enter the crypto map configuration mode, use the following command: crypto map map−name seq−num ipsec−manual

The map−name defines the name that identifies the crypto map set. The seq−num parameter is the number that is assigned to this crypto map; it should not be chosen arbitrarily because this number is used to rank multiple crypto map entries within a crypto map set, and a crypto map entry with a lower seq−num is evaluated before a map entry with a higher seq−num. The ipsec−manual parameter specifies that IKE will not be used to establish the security associations for traffic that is matched by this crypto map and the security associations will be created by a manual process. Use of this command moves you into crypto map configuration mode. 2. In crypto map configuration mode, use the following command to specify an extended access list for a crypto map entry that matches packets for which encryption should be 214

performed: match address

3. To specify an IPSec peer, use this command in crypto map configuration mode: set peer

You can specify the remote IPSec peer by its hostname if the hostname is mapped to the peer’s IP address in a domain name server (DNS) or you manually map the hostname to the IP address with the ip host command that was discussed earlier. When configuring manual IPSec to set up security associations, you can specify only one peer per crypto map. 4. To specify which transform sets can be used with the crypto map entry, use the following command: set transform set −

List multiple transform sets in order of priority with the highest−priority transform set listed first. When configuring manual IPSec to set up security associations, you can specify one transform set per crypto map. 5. Use one of the following commands to manually specify the session keys for AH or ESP. The ah parameter sets the session key for the Authentication Header protocol: set session−key ah

The esp parameter sets the session key for the Encapsulating Security Protocol: set session−key esp cipher − authenticator

When defining the session key for either the AH protocol or the ESP protocol, both an inbound and outbound key must be configured for each peer. Figure 6.8 displays a network with two routers separated by a WAN that must protect data via the use of IPSec. The routers will be configured to use IPSec with manual keys. Because the configuration of manual IPSec is different when using the Authentication Header protocol as opposed to the Encapsulating Security Payload within a transform set, each configuration will be discussed separately. Listing 6.13 and Listing 6.14 display the manual IPSec configurations of Router 1 and Router 2 in Figure 6.8 using AH transform sets. Listing 6.13: Manual AH configuration of Router 1. hostname Router−1 ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup

215

! crypto ipsec transform−set manual ah−sha−hmac ! crypto map toR2 10 ipsec−manual set peer 192.168.200.2 set transform−set manual match address 110 set session−key inbound ah 3073 − CCCC1234567890CCCC1234567890CCCC1234567890CCCC set session−key outbound ah 3072 − DDDD1234567890DDDD1234567890DDDD1234567890DDD1 ! interface Ethernet1 ip address 192.168.10.1 255.255.255.128 no ip directed−broadcast ! interface Serial1/0 ip address 192.168.200.1 255.255.255.0 no ip directed−broadcast no ip mroute−cache no fair−queue crypto map mesh ! ip classless ! access−list 110 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 – 0.0.0.255 !

Listing 6.14: Manual AH configuration of Router 2. hostname Router−2 ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto ipsec transform−set manual ah−sha−hmac ! crypto map toR1 10 ipsec−manual set peer 192.168.200.1 set transform−set manual match address 101 set session−key inbound ah 3072 − DDDD1234567890DDDD1234567890DDDD1234567890DDD1 set session−key outbound ah 3073 − CCCC1234567890CCCC1234567890CCCC1234567890CCCC ! interface Ethernet1/0 ip address 192.168.11.1 255.255.255.128 no ip directed−broadcast ! interface Serial0/0 ip address 192.168.200.2 255.255.255.0 no ip directed−broadcast no ip mroute−cache no fair−queue

216

crypto map mesh ! ip classless ! access−list 101 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 − 0.0.0.255 !

Figure 6.8: Network using manual IPSec Keys Note The configurations in Listing 6.13 and Listing 6.14 are not recommended for a production environment because each configuration provides authentication services only for the IP packet. Access lists are read in sequential order by a router; as such, any packet in Listing 6.14 that has a source IP address that is within the 192.168.11.0 subnet with a destination IP address within the 192.168.10.0 subnet will match access list 101 (which is defined under crypto map toR1) and create a match rule for IPSec, thus allowing IPSec to provide authentication services on the packet. Any other packet that does not match the permit statement within access list 101 will not be protected by IPSec because of the implicit deny any at the end of the access list. Security associations established via the use of manual IPSec do not expire (whereas security associations established via IKE do), and an inbound session key configured on one IPSec peer must match the outbound session key configured on the remote IPSec peer. To view the manual security associations established on each router, you must issue the show crypto ipsec sa command. Issuing the show crypto ipsec sa command on Router 2 displays the output in Listing 6.15. Listing 6.15: Manual security associations on Router 2. Router−2#sh crypto ipsec sa interface: Serial0/0 Crypto map tag: toR1, local addr. 192.168.200.2 ! local ident: (192.168.11.0/255.255.255.0/0/0) remote ident: (192.168.10.0/255.255.255.0/0/0) current_peer: 192.168.200.1 PERMIT, flags={origin_is_acl,} pkts encaps: 117, pkts encrypt: 49, pkts digest 117 pkts decaps: 116, pkts decrypt: 48, pkts verify 116 pkts compressed: 0, pkts decompressed: 0 pkts not compressed: 0, pkts compr. failed: 0, − pkts decompress failed: 0 send errors 1, recv errors 0 ! local crypto endpt.: 192.168.200.2, −

217

remote crypto endpt.: 192.168.200.1 path mtu 1500, media mtu 1500 current outbound spi: C01 ! inbound esp sas: ! inbound ah sas: spi: 0xC00(3072) transform: ah−sha−hmac , in use settings ={Tunnel,} slot: 0, conn id: 2001, flow_id: 1, crypto map: toR1 no sa timing replay detection support: Y ! inbound pcp sas: ! outbound esp sas: ! outbound ah sas: spi: 0xC01(3073) transform: ah−sha−hmac, in use settings ={Tunnel,} slot: 0, conn id: 2000, flow_id: 2, crypto map: toR1 no sa timing replay detection support: Y ! outbound pcp sas: ! Router−2# !

Notice the highlighted lines in Listing 6.15; each of these lines state that the security association for inbound and outbound traffic do not timeout, unlike security associations created using IKE. During the configuration of Router 2 in Listing 6.14, the debug crypto ipsec, debug crypto engine, and debug crypto key−exchange commands were used to verify that both routers were configured correctly. The output from those commands can be seen in Listing 6.16. Listing 6.16: Security association process on Router 2. Router−2#debug crypto ipsec Crypto IPSEC debugging is on Router−2#debug crypto engine Crypto Engine debugging is on Router−2#debug crypto key−exchange Crypto Key Exchange debugging is on ! : IPSEC(sa_request): , (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= AH, transform= ah−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0x173715C3(389486019), conn_id= 0, keysize= 0, flags= 0x4004 : IPSEC(key_engine): got a queue event... : IPSEC(initialize_sas):, (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= AH, transform= ah−sha−hmac,

218

lifedur= 3600s and 4608000kb, spi= 0xC01(3073), conn_id= 2000, keysize= 0, flags= 0x4 : IPSEC(initialize_sas):, (key eng. msg.) dest= 192.168.200.2, src= 192.168.200.1, dest_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), src_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= AH, transform= ah−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0xC00(3072), conn_id= 2001, keysize= 0, flags= 0x4 : IPSEC(create_sa): sa created, (sa) sa_dest= 192.168.200.1, sa_prot= 51, sa_spi= 0xC01(3073), sa_trans= ah−sha−hmac, sa_conn_id= 2000 : IPSEC(create_sa): sa created, (sa) sa_dest= 192.168.200.2, sa_prot= 51, sa_spi= 0xC00(3072), sa_trans= ah−sha−hmac, sa_conn_id= 2001

The manual IPSec configurations of Router 1 and Router 2 in Listings 6.13 and 6.14, which used AH only to provide authentication services, do not provide the strongest form of encryption services. In fact, the configurations did not provide any encryption services; they provided only authentication. To provide the encryption services, the use of ESP is needed. Router 1 and Router 2 in Figure 6.8 will be configured to provide the security services of both AH and ESP. The crypto map that is defined for each router will make use of a transform set that includes an ESP encryption protocol, and as such, each router will define IPSec keys for ESP encryption for both inbound and outbound traffic. The transform set will also include an ESP authentication protocol, so an IPSec key for ESP authentication for inbound and outbound traffic must be defined as well. The configuration of the AH protocol will remain the same as they are in Listing 6.13 and 6.14. The manual AH and ESP configuration of Router 1 and Router 2 are displayed in Listing 6.17 and Listing 6.18. Listing 6.17: Manual AH and ESP configuration of Router 1. hostname Router−1 ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto ipsec transform−set manual ah−sha−hmac esp−des − esp−sha−hmac ! crypto map toR2 10 ipsec−manual set peer 192.168.200.2 set transform−set manual match address 110 set session−key inbound esp 4096 cipher − BBBB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator − 1234567890BBBB1234567890BBBB1234567890BBBB1234 set session−key outbound esp 4098 cipher − AAAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator − 1234567890AAAA1234567890AAAA1234567890AAAA1234 set session−key inbound ah 3073 − CCCC1234567890CCCC1234567890CCCC1234567890CCCC

219

set session−key outbound ah 3072 − DDDD1234567890DDDD1234567890DDDD1234567890DDD1 ! interface Ethernet1 ip address 192.168.10.1 255.255.255.128 no ip directed−broadcast ip nat inside ! interface Serial1/0 ip address 192.168.200.1 255.255.255.0 no ip directed−broadcast ip nat outside no ip mroute−cache no fair−queue crypto map mesh ! ip nat inside source route−map donotnat interface Serial1/0 − overload ip classless ! access−list 110 permit ip 192.168.10.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 112 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 112 permit ip 192.168.10.0 0.0.0.255 any ! route−map donotnat permit 10 match ip address 112

Listing 6.18: Manual AH and ESP configuration of Router 2. hostname Router−2 ! username ipsec privilege 15 password 0 ipsec memory−size iomem 10 ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto ipsec transform−set manual ah−sha−hmac esp−des esp−sha−hma ! crypto map toR1 10 ipsec−manual set peer 192.168.200.1 set transform−set manual match address 101 set session−key inbound esp 4098 cipher − AAAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator − 1234567890AAAA1234567890AAAA1234567890AAAA1234 set session−key outbound esp 4096 cipher − BB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator − 1234567890BBBB1234567890BBBB1234567890BBBB1234 set session−key inbound ah 3072 − DDDD1234567890DDDD1234567890DDDD1234567890DDD1 set session−key outbound ah 3073 − CCCC1234567890CCCC1234567890CCCC1234567890CCCC ! interface Ethernet1/0 ip address 192.168.11.1 255.255.255.128 no ip directed−broadcast ip nat inside !

220

interface Serial0/0 ip address 192.168.200.2 255.255.255.0 no ip directed−broadcast ip nat outside no ip mroute−cache no fair−queue crypto map mesh ! ip nat inside source route−map donotnat interface Serial0/0 − overload ip classless ! access−list 101 permit ip 192.168.11.0 0.0.0.255 192.168.10.0 − 0.0.0.255 access−list 102 deny ip 192.168.10.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 102 permit ip 192.168.10.0 0.0.0.255 any ! route−map donotnat permit 10 match ip address 102

Again, security associations established via the use of manual IPSec do not expire (whereas security associations established via IKE do) and an inbound session key configured on one IPSec peer must match the outbound session key configured on the remote IPSec peer. To view the manual security associations established on each router, you must issue the show crypto ipsec sa command. Issuing the show crypto ipsec sa command on Router 1 displays the output in Listing 6.19. Listing 6.19: Manual security associations on Router 1. Router−1#sh crypto ipsec sa interface: Ethernet0/0 Crypto map tag: toR2, local addr. 192.168.200.1 local ident: (192.168.10.0/255.255.255.0/0/0) remote ident: (192.168.11.0/255.255.255.0/0/0) current_peer: 192.168.200.2 PERMIT, flags={origin_is_acl,} pkts encaps: 705, pkts encrypt: 705, pkts digest 705 pkts decaps: 699, pkts decrypt: 699, pkts verify 699 pkts compressed: 0, pkts decompressed: 0 pkts not compressed: 0, pkts compr. failed: 0, pkts decompress failed: 0 send errors 0, #recv errors 0 ! local crypto endpt.: 192.168.200.1, remote crypto endpt.: 192.168.200.2 path mtu 1500, media mtu 1500 current outbound spi: 1002 ! inbound esp sas: spi: 0x1000(4096) transform: esp−des esp−sha−hmac, in use settings ={Tunnel,} slot: 0, conn id: 2003, flow_id: 1, crypto map: toR2 no sa timing IV size: 8 bytes replay detection support: Y ! inbound ah sas:

221

spi: 0xC01(3073) transform: ah−sha−hmac, in use settings ={Tunnel,} slot: 0, conn id: 2002, flow_id: 1, crypto map: toR2 no sa timing replay detection support: Y inbound pcp sas: ! outbound esp sas: spi: 0x1002(4098) transform: esp−des esp−sha−hmac, in use settings ={Tunnel,} slot: 0, conn id: 2001, flow_id: 2, crypto map: toR2 no sa timing IV size: 8 bytes replay detection support: Y ! outbound ah sas: spi: 0xC00(3072) transform: ah−sha−hmac, in use settings ={Tunnel,} slot: 0, conn id: 2000, flow_id: 2, crypto map: toR2 no sa timing replay detection support: Y ! outbound pcp sas: Router−1#

One other useful command that can be used to verify that all security associations are configured properly and that each one is active is the show crypto engine connection active command. This command will display the current active encrypted session connections. Issuing the command on Router 2 displays the following output: Router−2#sh crypto en conn ac ! ID Interface IP−Address 2000 Serial0/0 192.168.200.2 2001 Serial0/0 192.168.200.2 2002 Serial0/0 192.168.200.2 2003 Serial0/0 192.168.200.2

State set set set set

Algorithm Enc Dec HMAC_SHA 612 0 HMAC_SHA+DES_56_CB 612 0 HMAC_SHA 0 612 MAC_SHA+DES_56_CB 0 612

The ID field is the connection ID number, and each active encrypted session connection is identified by an ID number. The Interface field identifies the interface that is involved in the encrypted session connection. The IP−Address field identifies the IP address of the interface involved in the encrypted session. The State field identifies the state of the connection. The Algorithm field identifies the algorithm that is used to encrypt or to decrypt the packets. The Enc field displays the total number of outbound encrypted packets, and the Dec field displays the total number of inbound encrypted packets. Although manual IPSec configurations allow a security administrator to have strict control over the implementation of IPSec VPNs, as well provide interoperability with any device that does not support the IPSec utility services of IKE, these advantages come with an added cost. The overhead associated with maintaining strict control over the IPSec VPNs can become burdensome as the number of VPNs the company has begins to grow. Security administrators should always be aware that when configuring manual IPSec, each router should contain a mirror copy IPSec configuration of its peer router. One of the problems associated with manual IPSec configurations is incorrectly configured keys between peers. 222

For instance, changing the keys on Router 2 in Listing 6.18 will result in encryption not taking place and error messages being displayed on Router 2. Listing 6.20 displays the new, incorrectly configured keys on Router 2. Listing 6.20: Changing keys on Router 2. crypto map toR1 10 ipsec−manual no set session−key inbound esp 4098 cipher − AAA1234567890AAAA1234567890AAAA1234567890AAA0 authenticator − 1234567890AAAA1234567890AAAA1234567890AAAA1234 no set session−key outbound esp 4096 cipher − BBBB1234567890BBBB1234567890BBBB1234567890BBB0 authenticator − 1234567890BBBB1234567890BBBB1234567890BBBB1234 no set session−key inbound ah 3072 − DDD1234567890DDDD1234567890DDDD1234567890DDD1 no set session−key outbound ah 3073− CCCC1234567890CCCC1234567890CCCC1234567890CCCC ! set session−key inbound esp 4098 cipher − 11111111111111111111111111111111111111111111111 authenticator − 1111111111111111111111111111111111111111111111 set session−key outbound esp 4096 cipher − 2222222222222222222222222222222222222222222222 authenticator − 2222222222222222222222222222222222222222222222 set session−key inbound ah 3072 − 3333333333333333333333333333333333333333333333 set session−key outbound ah 3073 − 4444444444444444444444444444444444444444444444

First, the original keys were deleted using the no form the set session−key command, and then the new keys were added into the configuration. As the keys are being changed, Router 2 begins to delete each security association it had configured. This can be seen in Listing 6.21 by issuing the debug crypto ipsec and debug crypto engine commands. Listing 6.21: Router 2 deleting security associations. : IPSEC(delete_sa): deleting SA, (sa) sa_dest= 192.168.200.1, sa_prot= 51, sa_spi= 0xC01(3073), sa_trans= ah−sha−hmac, sa_conn_id= 2000 : IPSEC(delete_sa): deleting SA, (sa) sa_dest= 192.168.200.1, sa_prot= 50, sa_spi= 0x1000(4096), sa_trans= esp−des esp−sha−hmac, sa_conn_id= 2001 : IPSEC(delete_sa): deleting SA, (sa) sa_dest= 192.168.200.2, sa_prot= 51, sa_spi= 0xC00(3072), sa_trans= ah−sha−hmac , sa_conn_id= 2002 : IPSEC(delete_sa): deleting SA, (sa) sa_dest= 192.168.200.2, sa_prot= 50, sa_spi= 0x1002(4098), sa_trans=esp−des esp−sha−hmac, sa_conn_id=2003

Router 2 at this point has deleted each of the existing security associations it had configured for its peer IPSec router. After the new keys (which are incorrect) are configured on Router 2 under the crypto map and a packet that matches the encryption access list is received on the router, Router 2 should attempt to set a security association with Router 1. However, the security association 223

attempt should fail because of incorrectly configured keys between the routers. This process can be seen in the output in Listing 6.22. Listing 6.22: Router 2’s failed attempt to set a security association. : IPSEC(sa_request): , (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= AH, transform= ah−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0x1028254B(271066443), conn_id= 0, keysize= 0, flags= 0x4004 : IPSEC(sa_request):, (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0x2360B83(37096323), conn_id= 0, keysize= 0, flags= 0x4004 : IPSEC(manual_key_stuffing): keys missing for − addr 192.168.200.2/prot 50/spi 0. : IPSEC(sa_request):, (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= AH, transform= ah−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0xB2C0887(187435143), conn_id= 0, keysize= 0, flags= 0x4004 : IPSEC(sa_request):, (key eng. msg.) src= 192.168.200.2, dest= 192.168.200.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−sha−hmac, lifedur= 3600s and 4608000kb, spi= 0x4AD1EE4(78454500), conn_id= 0, keysize= 0, flags= 0x4004 : IPSEC(manual_key_stuffing): keys missing for − addr 192.168.200.2/prot 50/spi 0.

Configuring Tunnel EndPoint Discovery The ability to automate as much of the configuration and maintenance of IPSec VPNs as possible is important for administrators who are challenged to minimize their administrative and operations costs and at the same time layer sophisticated IP services, such as IPSec. One IPSec enhancement that helps simplify VPN configuration is Tunnel EndPoint Discovery (TED), which was available beginning in Cisco IOS software version 12.0(5)T. Tunnel EndPoint Discovery allows IPSec to scale to large networks by reducing multiple encryption schemes, reducing the setup time, and allowing for simple configurations on participating peer routers. Each IPSec−enabled router has a simple configuration that defines the local network that the router is protecting and the IPSec transforms that are required. Tunnel EndPoint Discovery is recommended for use with networks in which the IPSec peers are not always predetermined.

224

To understand how Tunnel EndPoint Discovery works, I will use Figure 6.9 as an example for the rest of this discussion. In Figure 6.9, Host A behind Router A attempts to establish a session with Host B behind Router B. If Router A has not initiated encryption services before with Router B (meaning no security association is set up), it compares the IP address of the destination host, Host B in this case, to an access list that defines a range of IP addresses that determine which network devices are members of the IPSec VPN group. This is accomplished via the use of a permit statement within the access list. Upon receipt of the packet from Host A that is destined to Host B, Router A drops the packet and then sends a TED probe packet to Router B. Upon receipt, Router B drops the TED packet and sends a TED reply packet to Router A with its own IP address in the payload of the packet. When Router A receives the TED reply packet, it initiates dynamic Internet Key Exchange (IKE), which enables Router A to establish a secure network session.

Figure 6.9: Tunnel EndPoint Discovery To configure Tunnel EndPoint Discovery, use the following commands: 1. Configure the IKE process as explained in "Configuring IPSec using Pre−Shared Keys" earlier in this chapter. 2. Use the following command to create a dynamic crypto map entry: crypto dynamic−map

Use of this command places you in dynamic crypto map configuration command mode. 3. To specify which transform sets can be used with the dynamic crypto map entry, use the following command: set transform set −

List multiple transform sets in order of priority with the highest−priority transform set listed first. 4. In dynamic crypto map configuration mode, use this command to specify an extended access list for a crypto map entry that matches packets that should be protected by encryption: match address

5. Use the following command to add one or more dynamic crypto map sets into a crypto map set via crypto map entries that reference the dynamic crypto map sets: crypto map ipsec−isakmp − dynamic discover

225

The discover parameter defined on the dynamic crypto map enables peer discovery. 6. Apply the crypto map to an interface using the crypto map command. The map name specified with this command is the name of the crypto map that was created in Step 5. Listing 6.23 and Listing 6.24 display the configuration needed to enable TED on both Router A and Router B (use Figure 6.9 as a reference). Listing 6.23: Tunnel EndPoint Discovery configuration of Router A. hostname Router−A ! username ipsec privilege 15 password 0 ipsec ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 10 authentication pre−share group 2 hash sha ! crypto isakmp key aandbkey address 0.0.0.0 ! crypto ipsec transform−set discovery esp−des esp−md5−hmac ! crypto dynamic−map discovery−map 10 set transform−set ted−transforms match address 100 ! crypto map tunnelend 10 ipsec−isakmp dynamic discovery−map − discover ! interface Ethernet1 ip address 192.168.11.1 255.255.255.0 no ip directed−broadcast ! interface Serial0/0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast crypto map tunnelend ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.2 no ip http server ! access−list 100 permit ip 192.168.11.0 0.0.0.255 192.168.12.0 − 0.0.0.255 access−list 100 permit icmp 192.168.11.0 0.0.0.255 192.168.12.0 − 0.0.0.255 ! line con 0 login local transport input none line aux 0 line vty 0 4 login local

Listing 6.24: Tunnel EndPoint Discovery configuration of Router B. hostname Router−B

226

! username ipsec privilege 15 password 0 ipsec ip subnet−zero ip tcp synwait−time 10 no ip domain−lookup ! crypto isakmp policy 10 authentication pre−share group 2 hash sha ! crypto isakmp key aandbkey address 0.0.0.0 ! crypto ipsec transform−set discovery esp−des esp−md5−hmac ! crypto dynamic−map discovery−map 10 set transform−set discovery match address 110 ! crypto map tunnelend 10 ipsec−isakmp dynamic discovery−map − discover ! interface Ethernet1/0 ip address 192.168.12.1 255.255.255.0 no ip directed−broadcast ! interface Serial0/0 ip address 192.168.10.2 255.255.255.0 no ip directed−broadcast crypto map tunnelend ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.10.1 no ip http server ! access−list 100 permit ip 192.168.12.0 0.0.0.255 192.168.11.0 − 0.0.0.255 access−list 100 permit icmp 192.168.12.0 0.0.0.255 192.168.11.0 – 0.0.0.255 ! line con 0 login local transport input none line aux 0 line vty 0 4 login local

After Host A behind Router A attempts to initiate a connection to Host B behind Router B, dynamic IPSec security association takes place. Because Router A has not initiated encryption services before with Router B (meaning no security association is set up), Router A compares the IP address of the destination host, Host B in this case, against access list 100, which defines a range of IP addresses that determine which network devices are members of the IPSec VPN group. Upon receipt of the packet from Host A that is destined to Host B, Router A drops the packet and then sends a TED probe packet to Router B. Upon receipt, Router B drops the TED packet and sends a TED reply packet to Router A with its own IP address in the payload of the packet. When Router A receives the TED reply packet, it initiates dynamic Internet Key Exchange (IKE), which enables Router A to establish a secure network session. You can verify that a secure session has been set up by issuing the debug crypto ipsec, debug crypto isakmp, and debug crypto engine commands on Router A and having Host A attempt to connect Host B. Listing 6.25 displays the complete output of the Tunnel EndPoint Discovery process. 227

Listing 6.25: Complete Tunnel EndPoint process for Router A. : IPSEC(tunnel discover request):, (key eng. msg.) src= 192.168.11.1, dest= 192.168.12.1, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.10.1/255.255.255.255/0/0 (type=1), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 3600s and 4608000kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4004 dest=Ethernet0/0:192.168.10.2 : ISAKMP: received ke message (1/1) : ISAKMP: GOT A PEER DISCOVERY MESSAGE FROM THE SA MANAGER!!! : src = 192.168.11.1 to 192.168.12.1, protocol 3, transform 2, hmac 1 : proxy source is 192.168.11.0/255.255.255.0 and my address (not used now) is 192.168.10.1 : ISAKMP: local port 500, remote port 500 : ISAKMP (2): ID payload next−payload : 5 type : 1 protocol : 17 port : 500 length : 8 : ISAKMP (2): Total payload length: 12 : 1st ID is 192.168.10.1 : 2nd ID is 192.168.11.0 /255.255.255.0 : ISAKMP (0:2): beginning peer discovery exchange : ISAKMP (2): sending packet to 192.168.12.1 (I) PEER_DISCOVERY via Ethernet0/0:192.168.10.2 : ISAKMP (2): received packet from 192.168.10.2(I)PEER_DISCOVERY : ISAKMP (0:2): processing vendor id payload : ISAKMP (0:2): speaking to another IOS box! : ISAKMP (0:2): processing ID payload. message ID = 0 : ISAKMP (0:2): processing ID payload. message ID = −1594735024 : ISAKMP (2): ID_IPV4_ADDR_SUBNET dst 192.168.12.0/255.255.255.0 prot 0 port 0 : ISAKMP (2): received response to my peer discovery probe! : ISAKMP: initiating IKE to 192.168.10.2 in response to probe. : ISAKMP: local port 500, remote port 500 : ISAKMP (0:2): created new SA after peer−discovery with 192.168.10.2 : ISAKMP (3): sending packet to 192.168.10.2 (I) MM_NO_STATE : ISAKMP (0:2): deleting SA reason "delete_me flag/throw" state (I) PEER_DISCOVERY (peer 192.168.12.1) input queue 0 : ISAKMP (3): received packet from 192.168.10.2 (I) MM_NO_STATE : ISAKMP (0:3): processing SA payload. message ID = 0 : ISAKMP (0:3): Checking ISAKMP transform 1 against priority 10 policy : ISAKMP: encryption DES−CBC : ISAKMP: hash SHA : ISAKMP: default group 2 : ISAKMP: auth pre−share : ISAKMP (0:3): atts are acceptable. Next payload is 0 : CryptoEngine0: generate alg parameter : CRYPTO_ENGINE: Dh Phase 1 status: 0 : CRYPTO_ENGINE: Dh Phase 1 status: 0 : ISAKMP (0:3): SA is doing pre−shared key authentication : ISAKMP (3): SA is doing pre−shared key authentication using id type ID_IPV4_ADDR : ISAKMP (3): sending packet to 192.168.10.2 (I) MM_SA_SETUP : ISAKMP (3): received packet from 192.168.10.2 (I) MM_SA_SETUP : ISAKMP (0:3): processing KE payload. message ID = 0 : CryptoEngine0: generate alg parameter

228

: : : : : :

: : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :

: : : : : : : : : : :

ISAKMP (0:3): processing NONCE payload. message ID = 0 CryptoEngine0: create ISAKMP SKEYID for conn id 3 ISAKMP (0:3): SKEYID state generated ISAKMP (0:3): processing vendor id payload ISAKMP (0:3): speaking to another IOS box! ISAKMP (3): ID payload next−payload : 8 type : 1 protocol : 17 port : 500 length : 8 ISAKMP (3): Total payload length: 12 CryptoEngine0: generate hmac context for conn id 3 ISAKMP (3): sending packet to 192.168.10.2 (I) MM_KEY_EXCH ISAKMP (0:2): purging SA. CryptoEngine0: delete connection 2 ISAKMP (3): received packet from 192.168.10.2 (I) MM_KEY_EXCH ISAKMP (0:3): processing ID payload. message ID = 0 ISAKMP (0:3): processing HASH payload. message ID = 0 CryptoEngine0: generate hmac context for conn id 3 ISAKMP (0:3): SA has been authenticated with 192.168.10.2 ISAKMP (0:3): beginning Quick Mode exchange, M−ID of 699308944 ISAKMP (0:3): asking for 1 spis from ipsec ISAKMP (0:3): had to get SPI's from ipsec. CryptoEngine0: clear dh number for conn id 1 IPSEC(key_engine): got a queue event... IPSEC(spi_response): getting spi 560995998 for SA from 192.168.10.2 to 192.168.10.1 for prot 3 ISAKMP: received ke message (2/1) CryptoEngine0: generate hmac context for conn id 3 ISAKMP (3): sending packet to 192.168.10.2 (I) QM_IDLE ISAKMP (3): received packet from 192.168.10.2 (I) QM_IDLE CryptoEngine0: generate hmac context for conn id 3 ISAKMP (0:3): processing SA payload. message ID = 699308944 ISAKMP (0:3): Checking IPSec proposal 1 ISAKMP: transform 1, ESP_DES ISAKMP: attributes in transform: ISAKMP: encaps is 1 ISAKMP: SA life type in seconds ISAKMP: SA life duration (basic) of 3600 ISAKMP: SA life type in kilobytes ISAKMP: SA life duration (VPI) of 0x0 0x46 0x50 0x0 ISAKMP: authenticator is HMAC−MD5 : validate proposal 0 ISAKMP (0:3): atts are acceptable. IPSEC(validate_proposal_request): proposal part #1, (key eng. msg.) dest= 192.168.10.2, src= 192.168.10.1, dest_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4), src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 0s and 0kb, spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4 validate proposal request 0 ISAKMP (0:3): processing NONCE payload. message ID = 699308944 ISAKMP (0:3): processing ID payload. message ID = 699308944 ISAKMP (0:3): processing ID payload. message ID = 699308944 CryptoEngine0: generate hmac context for conn id 3 ipsec allocate flow 0 ipsec allocate flow 0 ISAKMP (0:3): Creating IPSec SAs inbound SA from 192.168.10.2 to 192.168.10.1 (proxy 192.168.12.0 to 192.168.11.0) has spi 560995998 and conn_id 2000 and flags 4 lifetime of 3600 seconds

229

: :

lifetime of 4608000 kilobytes outbound SA from 192.168.10.1 to 192.168.10.2 (proxy 192.168.11.0 to 192.168.12.0) : has spi 104538836 and conn_id 2001 and flags 4 : lifetime of 3600 seconds : lifetime of 4608000 kilobytes : ISAKMP (3): sending packet to 192.168.10.2 (I) QM_IDLE : ISAKMP (0:3): deleting node 699308944 error FALSE reason "" : IPSEC(key_engine): got a queue event... : IPSEC(initialize_sas):, (key eng. msg.) dest= 192.168.10.1, src= 192.168.10.2, dest_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), src_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 3600s and 4608000kb, spi= 0x21701E9E(560995998), conn_id= 2000, keysize= 0, flags= 0x4 : IPSEC(initialize_sas):, (key eng. msg.) src= 192.168.10.1, dest= 192.168.10.2, src_proxy= 192.168.11.0/255.255.255.0/0/0 (type=4), dest_proxy= 192.168.12.0/255.255.255.0/0/0 (type=4), protocol= ESP, transform= esp−des esp−md5−hmac, lifedur= 3600s and 4608000kb, spi= 0x63B22D4(104538836), conn_id= 2001, keysize= 0, flags= 0x4 : IPSEC(create_sa): sa created, (sa) sa_dest= 192.168.10.1, sa_prot= 50, sa_spi= 0x21701E9E(560995998), sa_trans= esp−des esp−md5−hmac, sa_conn_id= 2000 : IPSEC(create_sa): sa created, (sa) sa_dest= 192.168.10.2, sa_prot= 50, sa_spi= 0x63B22D4(104538836), sa_trans= esp−des esp−md5−hmac, sa_conn_id= 2001 Router−A#

230

Chapter 7: Additional Access List Features In Brief In this chapter, I'll discuss IP access list security features. Two are slight deviations of the commonly used numbered access lists and will be discussed in detail: session filtering using reflexive access lists and lock and key security using dynamic access lists. I'll also address enhancements to access list configurations using named access lists, access list comments, and time−based access lists. An access list is a sequential series of filters. Each filter is made up of some sort of matching criteria and action. The action within the filter is always either a permit or a deny. The criteria by which the access list matches upon can be as simple as a source address or as complex as a source address, a destination address, a protocol, a port, and flags. When access lists are configured, a packet is compared against the filter rules contained within the access list. At the first filter rule, a matching criteria is applied. If a match occurs at this rule, the packet is permitted or denied based on the configured action of the filter rule. If a match does not occur, the packet is compared against the second rule configured within the filter and the matching process is again applied. If a packet is compared against all the rules configured within the filter and a match does not occur, the router must have some default action method of determining what should happen to the packet. The configured default action for the Cisco implementation of access lists is to deny any packet that is subjected to each filter rule contained within an access list and does not match any of them. This filter rule does not display in any configured access list and is the default action for an access list. This is referred to as an implicit deny any. Note

Routers compare addresses against the access list conditions one by one. The order of the conditions is critical for proper operation of the access list because the first match in an access list is used. If the router does not find a match, the packet is denied because of the implicit deny any at the end of each access list.

The two primary uses of access lists in security−related implementations are for packet filtering and traffic selection. Packet filtering helps to control a packet or flow of packets through an internetwork. This allows the router to limit network traffic, thus providing a finer granularity of control for restricting network access. Traffic selection is used to determine what traffic the router should consider "interesting" in order to invoke a certain feature or security operation. Access list types may be identified by either a number or a name. Table 7.1 shows the access list types and the number range available for each.

Table 7.1: Access list type and numbers. Access List Type

Range

Standard IP access list, Standard Vines

1–99

Extended IP access list, Extended Vines

100–199

231

Ethernet Type Code, Transparent Bridging Protocol Type, Source Route Bridging Protocol Type, Simple Vines

200–299

DECnet and Extended DECnet

300–399

XNS

400–499

Extended XNS

500–599

AppleTalk

600–699

Transparent Bridging Vendor Code, Source Route Bridging Vendor Code, Ethernet Address

700–799

Standard IPX

800–899

Extended IPX

900–999

IPX SAP

1000–1099

Extended Transparent Bridging

1100–1199

NLSP Route Summary

1200–1299

When determining whether or not to configure access lists on a production router, take the following rules into consideration prior to applying the configuration change to the router: • Organization—Organization of your access lists should be such that the more specific access entries are configured first and the more general entries are listed toward the bottom of the list. • Precedence—Configure your access list such that the more frequently matched conditions are placed before less frequently matched conditions. This alleviates load on the router's CPU. • Implicit action—If the purpose of your access list is to deny a few devices and permit all others, you must remember to add the permit any statement because the access list has at the end an implicit deny any that will not appear in the configuration. • Additions—New access list entries are always added to the end of the existing access list. When you're using numbered access, it is best to copy the access list configuration to a text editor, make the necessary changes to the access list, and then reapply the access list to the router. Access list entries cannot be selectively deleted with numbered access lists; however, they can be selectively deleted with named access lists.

232

Wildcard Masks To fully understand access lists, you must first understand inverse masks, known more commonly as wildcard masks. A wildcard mask specifies which bits in an IP address should be ignored when that address is compared with another IP address. Normal IP masks that are used for subnetting use a Boolean AND operation to derive a network mask or a subnet address. To perform the Boolean AND operation, you AND a value of 0 to another value of 0 or 1, and the result is a value of 0. Only a value of 1 ANDed with another value of 1 will result in a value of 1, resulting in a value of 1 if and only if both bits are 1. A Boolean OR operation, which is used for wildcard masks, is the exact opposite of the AND operation. To perform a Boolean OR operation, you OR a value of 1 to another value of 1 or 0 and the result is a value of 1. Only a 0 ORed with another 0 value will result in a 0 value, resulting in a value of 0 if and only if both bits are 0. Wildcard masks set a 0 for each bit of the address that should be matched exactly and a 1 for each bit where anything will match; the 1 bits are frequently referred to as don't care bits and the 0 bits are referred to as do care bits. In order to define the difference between the Boolean AND operation and the Boolean OR operation, we will create a truth table. Figure 7.1 displays a truth table for the Boolean AND operation and the Boolean OR operation. Boolean AND (used for subnet masks) 192.168.10.10 = 11000000101010000000101000001010 255.255.255.0 = 11111111111111111111111100000000 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 192.168.10.0 = 11000000101010000000101000000000 Boolean OR (used for wildcard masks) 192.168.10.10 = 11000000101010000000101000001010 0.0.0.255 = 00000000000000000000000011111111 −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− 192.168.10.255 = 11000000101010000000101011111111

Figure 7.1: Truth table for Boolean operations. Subnet masks make use of the Boolean AND operation to derive a network or subnet. Access lists make use of the Boolean OR operation, which is the inverse of the AND operation, to come to the same conclusion. The AND operation derives a network or subnet address from the host address and mask. A 1 is set in the mask to correspond to each bit of the network address, and a 0 is set for each bit of the host address. The Boolean AND operation is performed on each bit, and the result is the network or subnet number. The OR operation derives a network from the host address and inverse mask. A 0 is set in the mask to correspond to each bit of the network address, and a 1 is set for each bit of the host address. The Boolean OR operation is performed on each bit, and the result is the network or subnet number. In IP terms, the result of using the inverse mask is that all hosts within the 192.168.10.0 subnet are matched. Any address within the range of 192.168.10.1 through 192.168.10.254 will match that particular wildcard mask combination.

233

Standard Access Lists An access list defined with a number ranging from 1 to 99 is a standard access list. A standard access list is used to permit or deny packets based solely on the source IP address. The source address is the number of the network or host from which the packet is being sent. The source address is followed by a wildcard mask, which is used to specify the bit positions that must match. Standard access lists can be used as either an inbound or outbound filter, or as both. When a standard access list is used as an inbound filter, the router checks the source address of the packet and compares that address with each entry within the access list. If the access list is configured with a permit statement for that source IP address, the router breaks out of the access list and processes the packet accordingly. If the access list is configured with a deny statement or does not match any other filter rule defined within the access list, the packet is dropped. When a standard access list is used as an outbound packet filter, the packet is received by the router and switched to the proper outbound interface. At this point the router will compare the source address against the filter rules contained within the access list. If the access list permits that packet, the router forwards the packet out to the interface toward its final destination, and if the packet matches a deny statement or does not match any other filter rule defined within the access list, the packet is dropped. Standard access lists also support a feature known as implicit masks. Implicit masks can be used by not issuing a wildcard mask after the IP address specified within the access list. Implicit masks use a mask of 0.0.0.0, and as mentioned earlier in the section "Wildcard Masks," a mask of all 0s instructs the router to match all bits within the address in order to permit or deny the packet. One more thing you should know about standard access lists is that they should be placed as close to the intended destination as possible.

Extended Access Lists Extended access lists provide more flexibility in the specification of what is to be filtered. An access list defined with a number ranging from 100 to 199 is an extended IP access list. An extended access list can be configured to be static or dynamic; the default is static. An extended access list is used to permit or deny packets based on multiple factors such as protocol, source IP address, destination IP address, precedence, Type−of−Service (TOS), and port. An extended access list also supports the use of logging, which creates an informational logging message about any packet that matches a filter rule within the list. Extended access lists can filter according to protocol and protocol features. When configuring an extended access list for different protocols, you will notice the command syntax for the extended access list for each protocol is different; these changes must be taken into consideration prior to configuring the access list or you could inadvertently open a security hole. Different IP protocol configurations will be discussed in "Immediate Solutions" later in this chapter. Protocols that can be matched upon when configuring extended access lists are listed in Table 7.2.

Table 7.2: Protocols available with extended access lists. Name

Description

0–255

Any IP protocol number 234

ahp

Authentication Header Protocol

eigrp

Cisco Systems Enhanced Interior Gateway Routing Protocol

esp

Encapsulated Security Payload

gre

Cisco Systems Generic Route Encapsulation Tunneling

icmp

Internet Control Message Protocol

igmp

Internet Gateway Message Protocol

igrp

Cisco Systems Interior Gateway Routing Protocol

ip

Any Internet Protocol

ipinip

IP in IP Tunneling

nos

KA9Q NOS Compatible IP over IP Tunneling

ospf

Open Shortest Path First Routing Protocol

pcp

Payload Compression Protocol

pim

Protocol Independent Multicast

tcp

Transmission Control Protocol

udp

User Datagram Protocol

Extended access lists should be placed as close to the source as possible, in part because of their capability to filter packets using a finer granularity of controls. This also prevents wasting unnecessary bandwidth and processing power on packets that are to be dropped anyway.

Reflexive Access Lists For another form of security, you can use reflexive access lists. Based on session parameters, they permit IP packets for sessions that originate from within a network but deny packets that originate from outside your network. Using reflexive access lists is commonly referred to as session filtering. Reflexive access lists are 235

most often configured on routers, which border between two different networks. They provide a certain level of security against spoofing and denial−of−service (DoS) attacks. You would typically implement reflexive access lists on a customer edge Internet router or firewall router. Reflexive access lists share many of the features that normal access lists possess. Rules are created and evaluated in a sequential order until a match occurs, at which time no further entry evaluation takes place. There are also some differences between a reflexive access list and a normal access list. Reflexive access lists use a feature referred to as "nesting," meaning you can place them within another named extended access list. Reflexive access lists do not have an implicit deny any statement at the end of the list configuration, and the access list entries are created on a temporary basis. Fundamentals of Reflexive Access Lists Reflexive access lists are triggered when an IP packet is sent from within the inside secure network to an external destination network. If this packet is the first in the session, a temporary access list entry is created. This entry will permit or deny traffic to enter back into the network if the traffic received on the interface is deemed to be part of the original session created from within the inside network; it will deny all other traffic that is not part of the original session. Figure 7.2 details the operation of reflexive access lists.

Figure 7.2: Example of traffic initiated on an internal network with reflexive access lists configured. After the session has completed, the temporary access list entry is removed. If the session was opened with a TCP packet, two methods are used to tear it down. The first method will tear down the session 5 seconds after two set FIN bits are detected within the packet or the detection of a RST bit being set within the packet. The second method tears down the session if no packets for that session have been detected within a configurable timeout period. Because UDP is a connectionless−oriented protocol that does not maintain session services, if the session was opened with a UDP packet or other protocols with similar characteristics, the session is torn down when no packets for the session have been detected within a configurable timeout period. Reflexive access lists can be configured on internal interfaces or external interfaces.

Dynamic Access Lists Dynamic access lists, commonly referred to as Lock and Key security, are a form of traffic filtering that can dynamically allow external users IP traffic that would normally be blocked by a router, to gain temporary access through the router such that it can reach its final destination. In order for this to happen, a user must first telnet to the router. The dynamic access list will then attempt to authenticate the user. If the credentials the user supplies during the authentication phase are 236

correct, the user will be disconnected from her Telnet session and the access list will dynamically reconfigure the existing access list on the interface such that the user is allowed temporary access through the router. After a specified timeout period—either an idle timeout period or an absolute timeout period—the access list reconfigures the interface such that it returns to its original state. Note

After the user passes the authentication phase, the dynamic access list creates a temporary opening in the router by reconfiguring the interface to allow access through the router. This can potentially allow a user to spoof the source address of the legitimate user and gain unauthorized access into the internal network. IPSec termination at the router performing Lock and Key security is recommended.

Typically, you would configure dynamic access lists when you want a specific remote host or a subset of remote hosts to be allowed access to a host or a subset of hosts within your network. This can take place via the Internet or through dedicated circuits between your network and the remote network. Dynamic access lists are also configured when you want a host or a subset of hosts within your network to gain access to a remote host or subset of remote hosts protected with a firewall. As mentioned earlier, in order for the user to gain access through the router, she first must pass the authentication phase. Authentication can take many forms, but the most commonly used are maintaining a local user database within the router or performing authentication from a central security server such as a TACACS+ or RADIUS server. The central security server method of authentication is recommended. Dynamic access lists make use of the autocommand and the access−enable commands; these commands allow the creation of the temporary access list. There are some caveats to configuring dynamic access lists: • You can configure only one dynamic access list for each access list. • You cannot associate a dynamic access list to more than one access list. • An idle timeout or an absolute timeout must be configured. The idle timeout is defined within the autocommand command, and the absolute timeout is configured within the access−list command. If neither is configured, the temporary access entry will remain indefinitely and must be cleared manually. The idle timeout value must be less than the absolute timeout value. Fundamentals of Lock and Key Security Figure 7.3 details the steps involved when a host on an outside network would like to gain authorized access to a host behind a router configured with Lock and Key security. Host B would like to access Host A behind the perimeter router, Router A, but first must be authenticated using Lock and Key Security. The steps are as follows:

237

Figure 7.3: Example of Host B accessing Host A through Router A configured with dynamic access lists. 1. Host B opens a Telnet session to the virtual terminal port of Router A. 2. Router A receives the Telnet request and opens a Telnet session with Host B. 3. Depending on the authentication method Router A is configured to perform, Router A asks Host B to provide the proper authentication credentials (configured on a security access server or within the local authentication database). 4. After Host B passes the authentication phase, Router A logs Host B out of the Telnet session. At this time Router A creates a temporary access list entry within the dynamic access list. 5. Host B now has a dynamic access list entry within Router A, allowing access to Host A. 6. Finally, Router A will delete the temporary access entry after the configured idle timeout period or absolute timeout period is reached.

Additional Access List Features Prior to Cisco IOS 11.2 code, IP access list configuration was somewhat limited. However, many enhancements have since been added within the IOS. Named access lists, time−based access lists, and access lists comments are just a few. Named Access Lists Typical numbered access lists have a finite number of lists that can be created. As of Cisco IOS 11.2 you can identify IP access lists with an alphanumeric string rather than a number. When you use named access lists, you can configure more IP access lists in a router than you could if you were to use numbered access lists. Another advantage to using a named access list is that descriptive names can make large numbers of access lists more manageable. If you identify your access list with a name rather than a number, the mode and command syntax is slightly different. Keep a few things in mind when configuring named access lists: Not all access lists that accept a number will accept a name, and a standard access list and an extended access list cannot have the same name. Time−Based Access Lists Cisco IOS 12.0(1) introduced timed−based access lists, which are implemented based on the time range specified within the list configuration. Prior to the introduction of this feature, access lists that were defined were in effect for an infinite period of time or until they were deleted by the administrator. With time−based access list configured, administrators can control traffic according to service provider rates (which might vary during certain times of the day) and have finer granularity of control when permitting or denying certain traffic within their network. Note

The time−based access list feature is dependant on a reliable clock source. It is therefore recommended that the router be configured to utilize the features of the Network Time Protocol (NTP).

Commented Access Lists Commented access lists give security administrators the opportunity to configure a remark within the access list. This feature allows for ease of identification when defining an access list. The commented access list feature is configurable within both named and numbered access lists. Commented remarks within the access list are limited to 100 characters. 238

Immediate Solutions Configuring Standard IP Access Lists Standard IP access lists provide selection of packets only according to the source IP address contained within the header of the IP packet. To configure a standard IP access list to filter user traffic, use the following steps: 1. Use the following command to define the subnets or host addresses that should either be permitted or denied: access−list log

The parameter is the identification number of the access list; the number for a standard IP access list can be any number from 1 to 99. The identifies the source IP address of the packet. The is an optional parameter that indicates the wildcard bits that should be applied to the source; if this parameter is omitted, a mask of 0.0.0.0 is assumed. The parameter any can be used as an abbreviation for the source, which represents 0.0.0.0 255.255.255.255 in dotted decimal notation. The optional log parameter will generate an informational syslog message about a packet that matches the filter rule. 2. Use this command to select the input interface under which the access list will be applied: interface

3. Use the following command to apply the access list to the interface: ip access−group

When the in parameter is defined and the router receives a packet, the router checks the source address of the packet against the access list. If the access list permits the address, the router will continue to process the packet. If the access list rejects the address, the router discards the packet and returns an "ICMP host unreachable" message. When the access list is using the out parameter, after receiving and routing a packet to a controlled interface, the router checks the source address of the packet against the access list. If the access list permits the address, the router forwards the packet out the interface to its final destination. If the access list rejects the address, the router discards the packet and returns an "ICMP host unreachable" message. Note Any access list defined under an interface without a matching access list entry is interpreted by the router as a permit. This is sometimes called an undefined access list. Figure 7.4 displays a network with two routers, Router Raul and Router Chris. The routers will be configured to provide packet filtering using standard access lists. Router Raul should be configured to permit only traffic from the 192.168.20.0 network and deny traffic from all other networks. Router Chris will be configured to permit traffic only from 192.168.40.0 and deny traffic from all other networks.

239

Figure 7.4: Standard access list network. An inbound access list filter will be applied to the FastEthernet interfaces of each router that permit packets from only the networks mentioned in the preceding paragraph and deny all other packets. The configuration of each router is shown in the following listings: Router Raul's configuration is shown in Listing 7.1 followed by Router Chris's configuration in Listing 7.2. Listing 7.1: Raul's numbered access list configuration. hostname Raul ! interface FastEthernet1/0 ip address 192.168.10.2 255.255.255.0 no ip directed−broadcast ip access−group 20 in ! interface FastEthernet2/0 ip address 192.168.40.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet3/0 ip address 192.168.50.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.20.0 255.255.255.0 192.168.10.1 ip route 192.168.30.0 255.255.255.0 192.168.10.1 ! access−list 20 permit 192.168.20.0 0.0.0.255

Listing 7.2: Chris's numbered access list configuration. hostname Chris ! interface FastEthernet0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ip access−group 40 in ! interface Ethernet1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet1 ip address 192.168.30.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.40.0 255.255.255.0 192.168.10.2 ip route 192.168.50.0 255.255.255.0 192.168.10.2 !

240

access−list 40 permit 192.168.40.0 0.0.0.255

To test the configuration, you can issue the ping IP global command. Raul is configured to accept only inbound packets with a source address within the 192.168.20.0 subnet, and Chris is configured to accept only inbound packets with a source address of 192.168.40.1. From Raul you can issue the ping IP command to test the configuration. First, the configuration will be tested by using an extended ping to verify connectivity to Chris's FastEthernet1 interface. The packet will be sourced on Raul from its FastEthernet2/0 interface. Because Chris is configured to accept packets from Raul's 192.168.40.0 network, one would think that configuration would work. To verify this, the debug IP packet command has been issued to display the results of each packet. The output from the ping is shown in Listing 7.3. Listing 7.3: Issuing the ping command on Raul. Raul#debug ip packet ip packet debugging is on Raul#ping ip Target ip address: 192.168.30.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.40.1 Type of service [0]: Set DF bit in ip header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5,100−byte ICMP Echo to 192.168.30.1, − timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

The output in Listing 7.3 shows that the ping command was not successful. To see why, you can examine the results that are returned by the debug IP packet command. Listing 7.4 displays the results of the command for the ping attempt in Listing 7.3. Listing 7.4: Results of the debug IP packet command. ip: ip: ip: ! ip: ip: ip: ! ip: ip: ip:

s=192.168.40.1, d=192.168.30.1, len 100, sending s=192.168.30.1, d=192.168.40.1, len 100, access denied s=192.168.10.2, d=192.168.30.1, len 56, sending. s=192.168.40.1, d=192.168.30.1, len 100, sending s=192.168.30.1, d=192.168.40.1, len 100, access denied s=192.168.10.2, d=192.168.30.1, len 56, sending. s=192.168.40.1, d=192.168.30.1, len 100, sending s=192.168.30.1, d=192.168.40.1, len 100, access denied s=192.168.10.2, d=192.168.30.1, len 56, sending.

In the first line of the output, the packet is sourced from IP address 192.168.40.1, and its destination is 192.168.30.1; the router tells you that it is sending the packet. The second line of the output 241

displays the problem. The return packet is sourced from 192.168.30.1 and its destination is to IP address 192.168.40.1, but the router denies the packet. If you look back at Raul's configuration in Listing 7.1. you'll see that its access list only allows packets from the 192.168.20.0 subnet and not the 192.168.30.0 subnet. If you were to try the ping command again and time source the packet from the 192.168.40.1 interface with a destination of Chris's 192.168.20.1 interface, everything should work. Listing 7.5 displays the output of issuing the ping command again on router Raul. Listing 7.5: Issuing the ping command again on Raul. Raul#ping ip Target ip address: 192.168.20.1 Repeat count [5]: Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.40.1 Type of service [0]: Set DF bit in ip header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5,100−byte ICMP Echo to 192.168.20.1, − timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5)

This time the ping worked. Listing 7.6 displays the results of the debug IP packet command on Raul. Listing 7.6: Results of the debug IP packet command on Raul. ip: ip: ! ip: ip: ! ip: ip:

s=192.168.40.1, d=192.168.20.1, len 100, sending s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4 s=192.168.40.1, d=192.168.20.1, len 100, sending s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4 s=192.168.40.1, d=192.168.20.1, len 100, sending s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4

Just as expected, the router sourced the ping packet from the 192.168.40.1 interface (which is the IP address that Chris is configured to accept), and the return traffic was sourced from the 192.168.20.1 interface on Chris.

Configuring Extended IP Access Lists Extended IP access lists match a packet according to the source and destination addresses, and optional protocol type information for finer granularity of control as opposed to standard access lists, which are only matched by the source IP address. This allows for greater flexibility in terms of packet−matching characteristics for deciding whether or not to forward a packet. 242

Except for configuring the packet−matching features of the access list, the process used to configure an extended IP access list is the same process used to configure a standard IP access list. To configure an extended access list, follow these steps: 1. Use the following command to define the extended access list: access−list protocol − − −

2. Use this command to select the input interface under which the access list will be applied: interface

3. Use the following command to apply the access list to the interface: ip access−group

When applied inbound or outbound, the access list functions the same as it does in a standard access list configuration (see Step 3 in the section "Configuring Standard IP Access Lists"). Note Any access list defined under an interface without a matching access list entry is interpreted by the router as a permit. This is sometimes called an undefined access list. In Step 1, the access−list number parameter is the identification number of the access list; the number range for an extended IP access list can be any number from 100 to 199. The protocol specifies either the name or number of an IP protocol that is passed in the header of the packet. The values that can be used for this field are listed in Table 7.2. The source and destination fields specify the number of the network or host in a 32−bit format. The keywords any and host may be used to simplify the configuration. The source−wildcard and the destination−wildcard fields specify the number of wildcard bits that should be applied to the source or destination. The wildcard field can be populated by specifying a 32−bit value, where the value of 1 is not counted. If the keyword any is used for specification of the source or destination, a wildcard mask of all 1s is assumed. If the keyword host is used for specification of the source or destination, a wildcard mask of all 0s is assumed. Specification of the precedence value is optional and allows for filtering based on the configured precedence value of the packet. The precedence−value field may be populated by either a name or a number. The values that can be used to specify the precedence are listed in Table 7.3.

Table 7.3: Precedence values for extended access lists. Name

Number

routine

0

priority

1

immediate

2 243

flash

3

flash−override

4

critical

5

internet

6

network

7

Specification of the type−of−service (tos) value configures the router to filter packets based on the type−of−service level configured. The tos−value field may be populated by either a name or number as well, and each of the values may be used in combination. The values that can be used to specify the type−of−service are listed in Table 7.4.

Table 7.4: Type−of−service values for extended access lists. Name

Number

normal

0

min−monetary−cost

1

max−reliability

2

max−throughput

4

min−delay

8

The optional log parameter will generate an informational syslog message about a packet that matches the filter. Figure 7.5 displays a network in which packet filtering using extended access lists may be used. Raul should be configured to allow only connection requests to 192.168.50.50 from 192.168.30.30 and to allow only connection request from 192.168.20.21 to 192.168.40.41. Listing 7.7 shows the configuration for Raul, and Listing 7.8 shows the configuration for Chris.

244

Figure 7.5: Two routers configured for extended access lists. Listing 7.7: Extended access list configuration of Raul. ! interface FastEthernet1/0 ip address 192.168.10.2 255.255.255.0 no ip directed−broadcast ip access−group 101 in ! interface FastEthernet2/0 ip address 192.168.40.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet3/0 ip address 192.168.50.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.20.0 255.255.255.0 192.168.10.1 ip route 192.168.30.0 255.255.255.0 192.168.10.1 ! access−list 101 permit ip host 192.168.30.30 host 192.168.50.50 − log access−list 101 permit ip host 192.168.20.21 host 192.168.40.41 − log !

Listing 7.8: Extended access list configuration of Chris. hostname Chris ! interface FastEthernet0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ! interface Ethernet1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet1 ip address 192.168.30.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.40.0 255.255.255.0 192.168.10.2 ip route 192.168.50.0 255.255.255.0 192.168.10.2 !

The configuration of Raul in Listing 7.7 makes use of the keyword host in the access list 245

configuration. When the host parameter is used, there is no need to specify a wildcard mask because an all 0s mask is assumed by the router. To make sure the configuration is correct and that Raul is allowing only the connections the access list is configured for, you must do some testing. Using the debug IP packet command on Raul will help you to determine the effects of the access list. If you try to ping host 192.168.50.50 from the workstation with the IP address 192.168.30.31, the ping should fail. Listing 7.9 shows an attempt to ping from 192.168.30.31 to 192.168.50.50. Listing 7.9: Ping attempt to 192.168.50.50 from 192.168.30.31. C:\>ping 192.168.50.50 Pinging 192.168.50.50 with 32 bytes of data: Reply Reply Reply Reply

from from from from

192.168.10.2: 192.168.10.2: 192.168.10.2: 192.168.10.2:

Destination Destination Destination Destination

net net net net

unreachable unreachable unreachable unreachable

When you look at Raul, which has the debug IP packet command running, you will note that it is denying the ping packet request. In the output in Listing 7.10. you can see the ping packet being denied. Listing 7.10: Output of the debug IP packet command on Raul. ip: ip: ! ip: ip: ! ip: ip: ! ip: ip:

s=192.168.10.2, d=192.168.30.31, len 56, sending s=192.168.30.31, d=192.168.50.50, len 100, access denied s=192.168.10.2, d=192.168.30.31, len 56, sending s=192.168.30.31, d=192.168.50.50, len 100, access denied s=192.168.10.2, d=192.168.30.31, len 56, sending s=192.168.30.31, d=192.168.50.50, len 100, access denied s=192.168.10.2, d=192.168.30.31, len 56, sending s=192.168.30.31, d=192.168.50.50, len 100, access denied

The connection request to 192.168.50.50 was denied at Raul because the source of the packet was not configured with a permit statement in the access list. However, if you try to access 192.168.50.50 from 192.168.30.30 using the ping command, everything should work. Listing 7.11 displays the output of the ping command issued on 192.168.30.30. Listing 7.11: Ping attempt to 192.168.50.50 from 192.168.30.30. C:\>ping 192.168.50.50 Pinging 192.168.50.50 with 32 bytes of data: Reply Reply Reply Reply

from from from from

192.168.50.50: 192.168.50.50: 192.168.50.50: 192.168.50.50:

bytes=32 bytes=32 bytes=32 bytes=32

time=126ms time=117ms time=117ms time=116ms

TTL=233 TTL=233 TTL=233 TTL=233

The ping request worked, so now you can look again at the debug output on Raul, as displayed in Listing 7.12. 246

Listing 7.12: Output of the debug IP packet command on Raul. ip: ip: ! ip: ip: ! ip: ip: ! ip: ip:

s=192.168.30.30, d=192.168.50.50, len 100, rcvd 4 s=192.168.50.50, d=192.168.30.30, len 100, sending s=192.168.30.30, d=192.168.50.50, len 100, rcvd 4 s=192.168.50.50, d=192.168.30.30, len 100, sending s=192.168.30.30, d=192.168.50.50, len 100, rcvd 4 s=192.168.50.50, d=192.168.30.30, len 100, sending s=192.168.30.30, d=192.168.50.50, len 100, rcvd 4 s=192.168.50.50, d=192.168.30.30, len 100, sending

Another troubleshooting command to issue is the show IP access−lists command, which will display each access list configured on the router; if the optional log parameter is specified in the configuration of the access list, the show IP access−lists command will display the number of matches the access list has encountered. Issuing the show IP access−lists command on Raul displays the number of packets that have matched access list 101: Raul#sh access−lists Extended ip access list 101 permit ip host 192.168.30.0 host 192.168.50.0 log (13222 matches) permit ip host 192.168.20.0 host 192.168.40.0 log

Configuring Extended TCP Access Lists In the preceding section, you learned how to configure IP−specific access lists. The Cisco IOS also gives security administrators the ability to configure extended access lists using more specific protocol−dependent options for filtering packets; for example, you can configure TCP access lists. The steps for configuring extended TCP access lists are the same as the steps for configuring extended IP access lists with the exception of the additional parameters that TCP extended access lists permit: 1. Use the following command to define the extended TCP access list: access−list tcp − −

2. Use this command to select the input interface under which the access list will be applied: interface

3. Use the following command to apply the access list to the interface: ip access−group

In the command in Step 1, the operator parameter specifies a condition of qualifications for packets that match the source and destination of the access list. The possible values for the operator include less than (lt), greater than (gt), equal (eq), not equal (nq), and an inclusive range (range). The port parameter specifies a number from 0 to 65535 or a name that represents a TCP port number. The established parameter is TCP−specific and indicates an established session if the TCP packet has the ACK or RST bit set. The established option should be used if you have implemented an inbound access list to prevent TCP sessions from being established into your 247

network, but you must ensure that the access list will allow legitimate response packets back to your inside hosts from hosts with which the inside network users have attempted to establish a session. The simple network that is shown in Figure 7.6 will be used in this example. Router C should be configured to deny all inbound connection requests to the 192.168.10.0 network. However, it should also be configured to allow responses to connection requests that were initiated from the inside network to pass through the access list. Listing 7.13 shows the configuration of Router C to accomplish this.

Figure 7.6: TCP access list for Router C. Listing 7.13: TCP established configuration of Router C. hostname Router−C ! interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ! interface Serial/0 ip address 172.16.200.1 255.255.255.0 ip access−group 101 in no ip directed−broadcast ! ip route 0.0.0.0 0.0.0.0 172.116.200.2 ! access−list 101 permit tcp any 192.168.10.0 0.0.0.255 − established log access−list 101 deny ip any any log

In Listing 7.13. Router C is configured to permit packets regardless of the source address if the packets' destination is in the 192.168.40.0 subnet and the ACK or RST bit is set within the packet. The next line of the configuration is not needed due to the implicit deny any, but it is included so that any packet that fails to meet the requirements of the first access list statement can be logged. Of note also is that the access list is bounded to the external Serial interface of Router C for packets that are incoming on that interface. To test the configuration, you can establish a Telnet session from a host on the 192.168.10.0 network to a host on the external network of Router C. On Router C, use the debug IP packet detail command to monitor packets that are coming into or leaving Router C. Here is the Telnet request from 192.168.10.212: C:\>telnet 172.16.146.73 Connecting to 172.16.146.73...open

248

Examining the debug output on Router C, you can see that the request is considered valid because the flag fields the access list is configured to look for are set. Listing 7.14 shows the output of the debug command on Router C. Listing 7.14: Established TCP connection output. Router−C#debug ip packet detail ip packet debugging is on (detailed) ..... ip: s=192.168.10.212, d=172.16.146.73, TCP src=11001, dst=23, seq=1697250670, IP: s=172.16.146.73, d=192.168.10.212, TCP src=23, dst=11001, seq=1724867633, win=4128 ACK SYN ! ip: s=192.168.10.212, d=172.16.146.73, TCP src=11001, dst=23, seq=1697250671, win=4128 ACK ! ip: s=192.168.10.212, d=172.16.146.73, TCP src=11001, dst=23, seq=1697250671, win=4128 ACK PSH ! ip: s=192.168.10.212, d=172.16.146.73, TCP src=11001, dst=23, seq=1697250683, win=4128 ACK ! IP: s=172.16.146.73, d=192.168.10.212, TCP src=23, dst=11001, seq=1724867634, win=4128 ACK PSH ! ip: s=192.168.10.212, d=172.16.146.73, TCP src=11001, dst=23, seq=1697250683, win=4116 ACK PSH !

len 44, sending ack=0, win=4128 SYN len 44, rcvd 4 ack=1697250671, −

len 40, sending ack=1724867634, −

len 52, sending ack=1724867634, −

len 40, sending ack=1724867634, −

len 52, rcvd 4 ack=1697250671, −

len 43, sending ack=1724867646, −

Because of the format limitations of this book, some lines of the code in Listing 7.14 have been broken with a hyphen. The highlighted lines display that the ACK or RST bit is set on the packets from 172.16.146.73 to 192.168.10.212. The initial TCP access list configuration defined the log parameter to the end of the access list. The following example shows the output from the log parameter, which generates an informational log message regarding any packet that matches the parameters of the extended TCP access list. Notice that the response packets from 172.16.146.73 match all parameters of access list 101, and is therefore, permitted: Note

%SEC−6−IPACCESSLOGP: list 101 permitted tcp 172.16.146.73(23)−> − 192.168.10.212(11001), 1 packet ! %SEC−6−IPACCESSLOGP: list 101 permitted tcp 172.16.146.73(23)−> − 192.168.10.212(11001), 24 packets

Note Because of the format limitations of this book, some lines of code listed above have been broken with a hyphen. The show IP access−lists command is another troubleshooting command you can issue. It will display each access list configured on the router, and because the optional log parameter was specified in the configuration of the access list, the command will display the number of matches that the access list has encountered. Issuing the show IP access−lists command on Router C 249

displays the number of packets that have matched access list 101: Router−C#show access−lists Extended ip access list 101 permit tcp any 192.168.10.0 0.0.0.255 established log(427 − matches) deny ip any any log(11924 matches) Router−C#

Configuring Named Access Lists Because of the numeric limitations of numbered standard and extended access lists, in IOS release 11.2, Cisco included a feature known as named access lists, which extend the numeric limit of numbered access lists. To configure a named access list, follow these steps: 1. Use the following configuration command to define a named access list: ip access−list name

The standard command option configures a standard access list and the extended command option configures an extended access list. The name parameter defines the name of the access list. The name of the access list cannot contain a space and must begin with a letter, not a number. 2. Use this command to define the filter rules for a standard named access list: source source−wildcard

Use this command to define the filter rules for an extended access list: − − log

3. Use the following command to select the input interface under which the access list will be applied: interface

4. Use this command to bind the access list to the interface and to apply the filter to packets entering into or exiting the interface: ip access−group name {in | out}

In the beginning of "Immediate Solutions," I began with a basic standard access list configuration. In Listing 7.1 and Listing 7.2. Routers Raul and Chris were configured to provide packet filtering using standard numbered access lists. You can also configure routers to use named access lists to provide packet filtering. In Listing 7.15, Raul is configured to permit traffic from only the 192.168.20.0 network and deny traffic from all other networks. Router Chris will be configured in Listing 7.16 to permit traffic from only 192.168.40.0 and deny traffic from all other networks. Instead of using a standard numbered access list, this time I will use a standard named access list. Refer back to Figure 7.4 for a description of the network that will be used to configure the routers. Listing 7.15: Named access list configuration of Raul. hostname Raul !

250

interface FastEthernet1/0 ip address 192.168.10.2 255.255.255.0 no ip directed−broadcast ip access−group permit−20 in ! interface FastEthernet2/0 ip address 192.168.40.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet3/0 ip address 192.168.50.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.20.0 255.255.255.0 192.168.10.1 ip route 192.168.30.0 255.255.255.0 192.168.10.1 ! ip access−list standard permit−20 permit 192.168.20.0 0.0.0.255 deny any

Listing 7.16: Named access list configuration of Chris. hostname Chris ! interface FastEthernet0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ip access−group permit−40 in ! interface Ethernet1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet1 ip address 192.168.30.1 255.255.255.0 no ip directed−broadcast ! ip route 192.168.40.0 255.255.255.0 192.168.10.2 ip route 192.168.50.0 255.255.255.0 192.168.10.2 ! ip access−list standard permit−40 permit 192.168.40.0 0.0.0.255 deny any

You can issue the show access−lists command on Chris to verify the proper configuration of the access list: Chris#show access−lists Standard ip access list permit−40 permit 192.168.40.0, wildcard bits 0.0.0.255 deny any

You can also use the show IP interface command to verify the access list. Issuing this command displays any and all access lists that are configured on an interface. Issuing the command on Chris displays the output listed in Listing 7.17. Listing 7.17: Output of the show IP interface command on Chris. Chris#sh ip int e0/0

251

FastEthernet0 is up, line protocol is up Internet address is 192.168.10.1/24 Broadcast address is 255.255.255.255 Address determined by non−volatile memory MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Outgoing access list is not set Inbound access list is permit−40 Proxy ARP is enabled

Configuring Commented Access Lists When you use named access lists, you are able to provide a small description of the access list within the name, as shown in Listing 7.15 and Listing 7.16. Sometimes, though, the name of an access list does not provide enough information about what the access list does or what function each line within the access list provides. In 12.0.2 code, Cisco released a feature known as commented access lists. In Listings 7.1 and Listing 7.15, Raul has an access list configured that permits the 192.168.20.0 network and denies all others. In Listing 7.15, a name was used to define the access list instead of a number; I attempted to give the access list a name that was relevant to the function that it provided. In Listing 7.1, a standard numbered access list was used to define the same access lists; however, no descriptive information about the access list could be made with the numbered access list. You can add a comment to standard and extended access lists as well as to numbered and named access lists. Follow these steps to configure comments within a name−based access list: 1. Use the following configuration command to define a named access list: ip access−list name

2. Use the remark command to define the comment on an access list basis or on a per−filter−rule basis. The remark parameter is limited to 100 characters, including spaces. 3. Use this command to select the input interface under which the access list will be applied: interface

4. Use the following command to bind the access list to the interface and to apply the filter to packets entering into or exiting the interface: ip access−group name {in | out}

Follow these steps to configure comments within a numbered access: 1. Use the following configuration command to define the numbered access list and to define the comment on an access list basis: access−list access−list−number remark remark

2. Use this command to select the input interface under which the access list will be applied: interface

3. Use this command to bind the access list to the interface and to apply the filter to packets entering into or exiting the interface: ip access−group access list number {in | out}

252

Figure 7.7 displays a router with two networks directly attached to it. The router, Router C, has a large access list configuration defined, and if remarks weren't used, the access list would be fairly complicated to fully understand. To add clarity to the access list, remarks have been defined within the list. Router C will be configured with a name−based access list and the appropriate remarks will be added within the access list. Listing 7.18 displays the configuration of Router C.

Figure 7.7: Router C permitting and denying traffic. Listing 7.18: Commented named access list on Router C. hostname Router−C ! interface FastEthernet0/0 ip address 172.16.15.1 255.255.255.0 no ip directed−broadcast ! interface Serial1/0 ip address 10.10.10.1 255.255.255.0 ip access−group Commented in no ip directed−broadcast ! ip access−list extended Commented remark Deny any inbound request unless initiated from inside permit tcp any 172.16.0.0 0.0.255.255 established remark Permit mail traffic to this host permit tcp any host 172.16.15.83 eq smtp remark Permit telnet from XYZ company to our company permit tcp 10.10.10.0 0.0.0.255 172.16.0.0 0.0.255.255 − eq telnet remark Permit FTP from XYZ company to our company permit tcp 10.10.10.0 0.0.0.255 172.16.0.0 0.0.255.255 eq ftp remark Allow DNS traffic to the internal DNS server permit udp any host 172.16.15.84 eq domain remark Deny all other traffic deny ip any any

Router C has been configured with an extended name−based access list. Within the access list remarks provide clarity on the function of each filter rule statement. As mentioned earlier, comments can also be listed for numbered access lists. Using the same requirements that were listed with Listing 7.18, Router C can now be configured with a numbered access list that contains remarks for each filter rule. An extended numbered access list is used to accomplish the same thing Listing 7.18 accomplishes. Listing 7.19 displays the configuration of Router C using numbered access lists. Listing 7.19: Commented numbered access list on Router C. hostname Router−C ! interface FastEthernet0/0 ip address 172.16.15.1 255.255.255.0 no ip directed−broadcast

253

! interface Serial1/0 ip address 10.10.10.1 255.255.255.0 ip access−group 121 in no ip directed−broadcast ! access−list 121 remark Deny any inbound request access−list 121 permit tcp any 172.16.0.0 0.0.255.255 − established access−list 121 remark Permit mail traffic to this host access−list 121 permit tcp any host 172.16.15.83 eq smtp access−list 121 remark Permit telnet from XYZ company access−list 121 permit tcp 10.10.10.0 0.0.0.255 − 172.16.0.0 0.0.255.255 eq telnet access−list 121 remark Permit FTP from XYZ company to our − company access−list 121 permit tcp 10.10.10.0 0.0.0.255 − 172.16.0.0 0.0.255.255 eq ftp access−list 121 Allow DNS traffic to the internal DNS server access−list 121 permit udp any host 172.16.15.84 eq domain access−list 121 remark Deny all other traffic access−list 121 deny ip any any

Note Because of the format limitations of this book, some lines of code listed above have been broken with a hyphen.

Configuring Dynamic Access Lists Dynamic access lists permit or deny traffic based on user credentials that are passed to the Lock and Key router for user authentication. To be permitted access to a host behind a router configured for Lock and Key security, a user must first telnet to the router and pass an authentication phase. If authentication is successful, a temporary access list is created; it will enable the user to connect to the intended destination. To configure a router to provide Lock and Key security services for hosts, follow these steps: 1. Use the following global configuration command to define a dynamic access list: access−list − telnet − −

2. Optionally, use the access−list dynamic−extend command to extend the absolute timer of the dynamic ACL by six minutes when another Telnet session is opened into the router. 3. Use this command to configure user authentication: username name password secret

4. Use the following command to select the input interface under which the access list will be applied: interface

5. Use the following command to bind the access list to the interface and to apply the dynamic filter to packets entering into the interface: ip access−group name

6. Use this command to define one or more virtual terminal (vty) ports: line vty

254

7. Use the login local command to specify that user authentication should use the locally configured security database. 8. Use the following command in line configuration mode to enable the creation of temporary access list entries: autocommand access−enable host [timeout minutes]

The network displayed in Figure 7.8 will demonstrate dynamic access list security. Router 1 and Router 2 are each configured with two loopback interfaces. When Router 2 attempts to connect to one of the loopback interfaces on Router 1, it must first telnet to Router 1 and will be asked to authenticate via the local security database. If authentication takes place correctly, Router 2 will be disconnected from Router 1 and then will be allowed to communicate with the host on the loopback interface. The configuration of Router 1 is shown in Listing 7.20, and the configuration of Router 2 is shown in Listing 7.21.

Figure 7.8: Dynamic access list security. Listing 7.20: Configuration of Router 1 for dynamic access lists. hostname Router−1 ! username R2 password 0 R2 ! interface Loopback0 ip address 192.168.40.1 255.255.255.0 no ip directed−broadcast ! interface Loopback1 ip address 192.168.50.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet0/0 ip address 192.168.10.2 255.255.255.0 ip access−group 101 in no ip directed−broadcast ! ip classless ip route 192.168.20.0 255.255.255.0 192.168.10.1 ip route 192.168.30.0 255.255.255.0 192.168.10.1 no ip http server ! access−list 101 permit tcp any host 192.168.10.2 eq telnet access−list 101 dynamic PermitR2 permit tcp − host 192.168.20.1 host 192.168.40.1 access−list 101 dynamic PermitR2 permit tcp − host 192.168.20.1 host 192.168.50.1 ! line con 0 session−timeout 30

255

exec−timeout 30 0 login local transport input none line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local autocommand access−enable timeout 5 !

Listing 7.21: Configuration of Router 2 for dynamic access lists. hostname Router−2 ! username R1 password 0 R1 ip telnet source−interface Loopback1 ! interface Loopback1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface Loopback2 ip address 192.168.30.1 255.255.255.0 no ip directed−broadcast ! interface Ethernet0/0 ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast ! ip classless ip route 192.168.40.0 255.255.255.0 192.168.10.2 ip route 192.168.50.0 255.255.255.0 192.168.10.2 ! line con 0 session−timeout 30 exec−timeout 30 0 login local transport input none line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local !

Note Because of the format limitations of this book, some lines of code listed above have been broken with a hyphen. As you can probably tell, there is nothing special about Router 2's configuration. It is Router 1's configuration that matters. The only special command configured on Router 2 is the IP telnet source−interface command, which is used to have Router 2 source the Telnet packet from the specified loopback interface because, by default, the router will source the packet with the output interface's IP address as the source of the packet. You can first try to establish a Telnet connection to the 192.168.40.1 loopback interface of Router 1 from Router 2 to verify that the access list is not allowing access. The following code displays the output of a Telnet connection request from Router 2 to the loopback interface of Router 1. To verify that the access list is denying access, Router 1 is configured to debug packets using the debug IP 256

packet detail command and is configured to log all events to the internal buffer using the logging buffered command. Router−2#telnet 192.168.40.1 Trying 192.168.40.1 ... % Destination unreachable; gateway or host down Router−2#

As you can see, Router 1 has denied Router 2 access to the 192.168.40.1 interface. Looking back at the log information on Router 1 will in fact show that the packet request was made for access to 192.168.40.1 but was denied. The following output can be seen by issuing the show logging command on Router 1: Router−1#show logging Syslog logging: enabled(1 messages dropped, 0 flushes, − 0 overruns) Console logging: level debugging, 81 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 9 messages logged Trap logging: level informational, 24 message lines logged Log Buffer (2000000 bytes): IP: s=192.168.20.1, d=192.168.40.1, len 44, access denied TCP src=11007, dst=23, seq=3683728902, ack=0, win=4128 SYN ip: s=192.168.10.2, d=192.168.20.1, len 56, sending ICMP type=3, code=13 Router−1#

Router 1 has in fact denied the connection request. Now I'll go back to Router 2 and attempt a Telnet connection to the 192.168.10.2, Fast Ethernet0/0 interface of Router 1. The Telnet connection request from Router 2 to Router 1 can be seen in the following output. Router 1 is still configured with the debug IP packet detail command so that the connection request can be verified: Router−2#telnet 192.168.10.2 Trying 192.168.10.2 ... Open User Access Verification Username: R2 Password: R2 [Connection to 192.168.10.2 closed by foreign host] Router−2#

After Router 2 makes the connection request to Router 1 and is authenticated via the local security database, Router 1 disconnects the Telnet session with Router 2 and creates the temporary access list entries in access list 101, permitting traffic from 192.168.20.1 to 192.168.40.1. The output in Listing 7.22 displays the creation of the temporary access lists on Router 1. To display the information, issue the show IP access−lists command. Listing 7.22: Temporary access list entries on Router 1. Router−1#show ip access−lists Extended ip access list 101 permit tcp any host 192.168.10.2 eq telnet log (38 matches) Dynamic PermitR2 permit tcp host 192.168.20.1 host 192.168.40.1 − log permit tcp host 192.168.20.1 host 192.168.40.1 log −

257

(time left 293) Dynamic PermitR2 permit tcp host 192.168.20.1 host 192.168.50.1 − log permit tcp host 192.168.20.1 host 192.168.40.1 log − (time left 293) Router−1#

It should also be helpful to take a look at the logging information. The output in Listing 7.23 displays the output from the show logging command. Listing 7.23: Show logging on Router 1. Router−1#show logging Syslog log: enabled (1 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 679 messages logged Monitor logging: level debugging, 0 messages logged Buffer logging: level debugging, 607 messages logged Trap logging: level informational, 27 message lines logged Log Buffer (2000000 bytes): %SEC−6−IPACCESSLOGP: list 101 permitted tcp 192.168.20.1 − (11010) −> 192.168.10.2(23), 1 packet ip: s=192.168.20.1, d=192.168.10.2, len 44, rcvd 3 TCP src=11010, dst=23, seq=1082833484, ack=0, win=4128 SYN ip: s=192.168.10.2, d=192.168.20.1, len 44, sending TCP src=23,dst=11010,seq=2196401629,ack=1082833485,win=4128 ACK SYN ip: s=192.168.20.1, d=192.168.10.2, len 40, rcvd 3 TCP src=11010,dst=23,seq=1082833485,ack=2196401630,win=4128 ACK ip: s=192.168.20.1, d=192.168.10.2, len 52, rcvd 3 TCP src=11010, dst=23, seq=1082833485, ack=2196401630, win=4128 ACK PSH

At this point, I have been authenticated and Router 1 has created the temporary access list entries to allow connectivity to Router 2. I should now be able to connect to the loopback interface of Router 1 because the temporary access list entry has been created to allow for the connectivity from 192.168.20.1 to 192.168.40.1. The following output details the connection request to Router 1's loopback interface: Router−2#telnet 192.168.40.1 Trying 192.168.40.1 ... Open User Access Verification Username: R2 Password: Router−1#

After the connection request is made to Router 1, you can look again at the access list configuration and see that packets have matched the temporary access lists. The following output displays the information from the show IP access−lists command: Router−1#show ip access−lists Extended ip access list 101 permit tcp any host 192.168.10.2 eq telnet (40 matches) Dynamic PermitR2 permit tcp host 192.168.20.1 host 192.168.40.1 permit tcp host 192.168.20.1 host 192.168.40.1 (38 matches) −

258

(time left 275) Dynamic PermitR2 permit tcp host 192.168.20.1 host 192.168.50.1 permit tcp host 192.168.20.1 host 192.168.40.1 (38 matches) − (time left 275) Router−1#

Note Because of the format limitations of this book, some lines of code listed above have been broken with a hyphen. Of particular note in the preceding output is the time left 275 field; this field displays the amount of idle time remaining before the timeout period is reached and the router tears down the temporary access list entry. In Listing 7.20, the timeout period was configured to three minutes using the autocommand access−enable command. This configured all dynamic access lists' idle timeout period to five minutes. If the idle timeout value is reached and the dynamic entry is deleted, any user that authenticated to Router 1 using the username R2 will have to reauthenticate before gaining access again. Sometimes security administrators need a finer granularity of control on a per−user basis. One user may need to have a longer idle timeout value than another user; however, with the preceding configuration, all users have the same idle timeout value. Router 1's configuration in Listing 7.20 can be altered to provide different timeout values on the basis of local database users. Listing 7.24 displays Router 1's new configuration, which has defined multiple local security database entries and configured a specific idle timeout value for each local database entry. Listing 7.24: New configuration of Router 1. hostname Router−1 ! username R2 password 0 R2 uername R2 autocommand access−enable timeout 3 username Cisco password 0 Cisco username Cisco autocommand access−enable timeout 5 username Systems password 0 Systems username Systems autocommand access−enable timeout 7 ! interface Loopback0 ip address 192.168.40.1 255.255.255.0 no ip directed−broadcast ! interface Loopback1 ip address 192.168.50.1 255.255.255.0 no ip directed−broadcast ! interface FastEthernet0/0 ip address 192.168.10.2 255.255.255.0 ip access−group 101 in no ip directed−broadcast ! ip classless ip route 192.168.20.0 255.255.255.0 192.168.10.1 ip route 192.168.30.0 255.255.255.0 192.168.10.1 no ip http server ! access−list 101 permit tcp any host 192.168.10.2 eq telnet log access−list 101 dynamic PermitR2 permit tcp − host 192.168.20.1 host 192.168.40.1 log access−list 101 dynamic PermitR2 permit tcp − host 192.168.20.1 host 192.168.50.1 log ! line con 0 session−timeout 30 exec−timeout 30 0 login local transport input none

259

line aux 0 line vty 0 4 session−timeout 30 exec−timeout 30 0 login local

Configuring Reflexive Access Lists To define a reflexive access list, you must create an entry in an extended named IP access list. This entry must use the reflect keyword and is nested inside of another access list. To define reflexive access lists, follow these steps: 1. Use this command to define an extended named access list: ip access−list extended name

If the reflexive access list is configured for an external interface, the extended named IP access list should be one that is applied to outbound traffic, and if the reflexive access list is configured for an internal interface, the extended named IP access list should be one that is applied to inbound traffic. This command moves you into access list configuration mode. 2. In access list configuration mode, use this configuration command to define the reflexive access list: permit protocol any any reflect name

The protocol parameter should be specified for each upper−layer protocol that should be permitted. 3. Use the IP access−list extended name command to define another extended named access list. The name of this access list must be different from the name that was used to create the access list in Step 1. If the access list that was created in Step 1 was for inbound packets, then the access list that is created during this step is created for outbound packets. This command moves you into access list configuration mode. 4. Use permit statements to permit any traffic that should not be subjected to the reflexive access list, and then use the evaluate name command to create an entry that references the reflect statement that was created in Step 2. The name parameter defined in this step should match the name parameter that was created in Step 2 with the reflectname parameter. 5. Apply the extended named IP access list to the interface, using this command: ip access−group name {in | out}

When previous access lists were configured, this command was somewhat simple, but when applying reflexive access lists, each in or out option must be used. This will be further explained in the following paragraphs. 6. Optionally, use this command to change the default idle timeout for each temporary access list entry (the default idle timeout period is 300 seconds): ip reflexive−list timeout seconds

A brief discussion is needed in order to provide clarity to the preceding configuration steps. Reflexive access lists are normally configured on external interfaces, which will prevent IP traffic from entering the router and the internal network unless the traffic is part of a session already established from within the internal network. If the reflexive access list is not configured on the 260

external interface and more than two interfaces are in use, then more than likely it will be configured on the internal interface, which prevents IP traffic from entering your internal network unless the traffic is part of a session already established from within the internal network. If reflexive access lists are being configured and applied to an external interface, the extended named IP access list should be applied to outbound traffic. If reflexive access lists are being configured and applied to an internal interface, the extended named IP access list should be applied to inbound traffic. After the reflexive access list has been defined (Step 1), the access list must be "nested" within the second access list that is created in Step 4. If reflexive access lists are being configured and applied to an external interface, nest the reflexive access list within an extended named IP access list applied to inbound traffic. If reflexive access lists are being configured and applied to an internal interface, nest the reflexive access list within an extended named IP access list applied to outbound traffic. Figure 7.9 displays a network in which reflexive access lists may be used. In this example, reflexive access lists are configured on the Ethernet0/0 interface of Router 2 for outbound traffic that is originated from the internal networks. The reflexive access list configuration of Router 2 is shown in Listing 7.25.

Figure 7.9: Reflexive access list network. Listing 7.25: Reflexive access list configuration of Router 2. hostname Router−2 ! ip reflexive−list timeout 100 ! interface Ethernet1/1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface Ethernet1/0 ip address 192.168.30.1 255.255.255.0 no ip directed−broadcast ! interface Ethernet0/0 ip address 192.168.10.1 255.255.255.0 ip access−group in−filter in ip access−group out−filter out no ip directed−broadcast ! ip classless ip route 192.168.40.0 255.255.255.0 192.168.10.2 ip route 192.168.50.0 255.255.255.0 192.168.10.2 ! ! ip access−list extended out−filter permit icmp any any

261

evaluate protect ip access−list extended in−filter permit icmp any any permit tcp any any reflect protect permit udp any any reflect protect !

The configuration in Listing 7.26 defines two access lists and each is applied to the Ethernet0/0 interface. The reflexive access list has been named "protect," and before there is any packet movement through the router, you can view the access list by using the show IP access−lists command. Using this command on Router 2 prior to any packet movement through the router displays the output listed in Listing 7.27. Listing 7.26: Display of the access lists defined on Router 2. Router−2#show access−lists Extended ip access list out−filter permit icmp any any (40008 matches) permit tcp any any reflect protect permit udp any any reflect protect Extended ip access list in−filter permit icmp any any evaluate protect Router−2#

Notice that no information regarding the reflexive access list is displayed in the output in Listing 7.27; no traffic has triggered the access list yet. There is, however, ping traffic moving through the router, but ping traffic is not subjected to the reflexive access list filters. To trigger the reflexive access list, initiate a Telnet session from Router 2 to Router 1. After the Telnet session has started, you can issue the show access−lists command again to view the reflexive access list. Issuing the command on Router 2 displays the output in Listing 7.28. Listing 7.27: Displaying the reflexive access list on Router 2. Router−2#sh access−lists Extended ip access list out−filter permit icmp any any (70006 matches) permit tcp any any reflect protect permit udp any any reflect protect ! Extended ip access list in−filter permit icmp any any evaluate protect ! Reflexive ip access list protect permit tcp host 192.168.20.1 eq 11003 host 192.168.50.1 eq telnet − (49 matches) (time left 95) permit tcp host 192.168.30.1 eq 11002 host 192.168.40.1 − eq telnet − (49 matches) (time left 62) permit tcp host 192.168.30.2 eq 11001 host 192.168.40.1 − eq telnet − (69 matches) (time left 18) Router−2#

262

The configuration that has been examined in this section so far has been for reflexive access lists on an internal interface basis. Configuring reflexive access lists on an external interface basis is just the opposite of the configuration in Listing 7.26. Figure 7.10 displays a network in Router 2 should be configured for a reflexive access list that should be placed on an external interface. Listing 7.28 displays Router 2's configuration.

Figure 7.10: External reflexive access list. Listing 7.28: External reflexive access list on Router 2. hostname Router−2 ! ip reflexive−list timeout 100 ! interface Ethernet1 ip address 192.168.20.1 255.255.255.0 no ip directed−broadcast ! interface Serial0 ip address 192.168.10.1 255.255.255.0 ip access−group in−filter in ip access−group out−filter out no ip directed−broadcast ! ip classless ip route 0.0.0.0 0.0.0.0 serial0 ! ip access−list extended in−filter permit icmp any any evaluate protect ip access−list extended out−filter permit icmp any any permit tcp any any reflect protect permit udp any any reflect protect !

Configuring Time−Based Access Lists To configure time−based access lists, perform the following steps: 1. Use the time−range name command to define the name of the timed access list. Issuing this command moves you into time−range configuration mode. 2. Use either of the following commands to specify when the timed access list should be in effect: absolute periodic hh:mm to hh:mm

When using the periodic parameter, you may define multiple ranges. When using the absolute parameter, only one range may be defined. The day(s)−of−the−week parameter can be specified as any day of the week or a combination of days using the Monday, 263

Tuesday, Wednesday, Thursday, Friday, Saturday, or Sunday keyword. There are also three other options that may be used: The daily keyword represents Monday through Sunday. The weekend keyword specifies Saturday and Sunday, and the weekday keyword specifies Monday through Friday. 3. Define an extended numbered access list as described earlier using the command and bind the time range to the access list: access−list protocol − − −

4. Use this command to apply the access list to the interface: ip access−group

In the first example, I will configure time−based access lists using only periodic statements with extended numbered access lists. In this configuration, I would like to permit FTP traffic only on the weekdays from 7:00 A.M. to 6:00 P.M., deny all HTTP traffic on the weekend, permit TFTP traffic only on the weekend from noon to 8:00 P.M., and permit Telnet traffic only on Saturday from noon to 8:00 P.M. Listing 7.29 displays the configuration needed to meet these requirements. Listing 7.29: Timed access list using numbered access list. time−range permit−ftp periodic weekdays 07:00 to 18:00 ! time−range deny−http periodic weekend 00:00 to 23:59 ! time−range permit−tftp periodic weekend 12:00 to 20:00 ! time−range permit−telnet periodic saturday 12:00 to 20:00 ! access−list 120 permit tcp any any eq 21 time−range permit−ftp access−list 120 deny tcp any any eq 80 time−range deny−http access−list 120 permit udp any any eq 69 time−range permit−tftp access−list 120 permit tcp any any eq 23 time−range − permit−telnet ! interface fast0/0 ip access−group 120 in

To monitor the access list, issue the show access−lists command. This will display results that tell you whether the access list is active or inactive. An active state means the access list is currently in use, and an inactive state means the access list is currently not in use. Here are the results of issuing this command to monitor the access list configured in Listing 7.30: ACL−Router#sh access−lists Extended ip access list 120 permit tcp any any eq 21 time−range permit−ftp (inactive) deny tcp any any eq 80 time−range deny−http (inactive) permit udp any any eq 69 time−range permit−tftp (inactive) permit tcp any any eq 23 time−range permit−telnet (inactive) ACL−Router#

264

Time−based access lists can also be configured using the absolute argument with extended numbered access lists or with extended named access lists. The next example shows how to configure a time−based access list using the absolute argument and binding the time range to an extended named access list. This access list should deny HTTP traffic during a preplanned Web−server outage within the year, and it should permit FTP traffic to a different server for the entire year of 2004. It should also permit TFTP traffic from the time the access list applied until the 11th of February 2004 and permit Telnet traffic until the end of the year 2004. Listing 7.30 displays the configuration needed to meet these requirements. Listing 7.30: Timed access list using named access list. time−range permit−ftp absolute start 06:00 1 January 2004 end 23:59 31 December 2004 ! time−range deny−http absolute start 00:00 24 November 2004 end 06:00 26 November 2004 ! time−range permit−tftp absolute end 17:50 11 February 2004 ! time−range permit−telnet absolute end 23:59 31 December 2004 ! ip access−list extended absolute−list permit tcp any host 192.168.10.234 eq 21 time−range permit−ftp deny tcp any host 192.168.10.233 eq 80 time−range deny−http permit udp any any eq 69 time−range permit−tftp permit tcp any any eq 23 time−range permit−telnet ! interface fast0/0 ip access−group absolute−list in

As with the numbered access list, you can monitor the time−based named access list by issuing the show access−lists command. This will display results that tell you whether the access list is active or inactive. An active state means the access list is currently in use, and an inactive state means the access list is currently not in use. Here are the results of issuing this command to monitor the access list defined in Listing 7.30 : ACL−Router#show access−lists ..... Extended ip access list absolute−list deny tcp any host 192.168.10.233 eq 80 time−range − deny−http (inactive) permit udp any any eq 69 time−range permit−tftp (active) permit tcp any any eq 23 time−range permit−telnet (active) permit tcp any host 192.168.10.234 eq 21 time−range − permit−ftp (inactive) ACL−Router#

Note Because of the format limitations of this book, some lines of code listed above have been broken with a hyphen.

265

Appendix A: IOS Firewall IDS Signature List This appendix includes a complete list of Cisco IOS Firewall IDS signatures. A signature detects patterns of misuse in network traffic. The 59 intrusion−detection signatures included in the Cisco IOS Firewall software represent the most common network attacks and information−gathering scans that should be considered intrusive activity in an operational network. The signatures in Table A.1 are listed in numerical order by their signature number in the Cisco Secure IDS Network Security Database (NSD).

Table A.1: IOS Firewall Network Security Database signatures. NSD Number 1000 IP options−Bad Option List

Description Type Signature is triggered by receipt of an IP datagram in which Info, Atomic the list of IP options in the IP datagram header is incomplete.

1001 IP Signature is triggered by receipt of an IP datagram with the options−Record Packet Record Packet Route chosen or option 7. Route

Info, Atomic

1002 IP options−Timestamp

Signature is triggered by receipt of an IP datagram with the timestamp option chosen.

Info, Atomic

1003 IP options−Provide s,c,h,tcc

Signature is triggered by receipt of an IP datagram in which the IP option list for the datagram includes security options.

Info, Atomic

1004 IP options−Loose Signature is triggered by receipt of an IP datagram where the Info, Atomic Source Route IP option list for the datagram includes Loose Source Route. 1005 IP options−SATNET ID

Signature is triggered by receipt of an IP datagram where the Info, Atomic IP option

1005 IP options−SATNET ID (continued)

list for the datagram includes SATNET stream identifier.

Info, Atomic

1006 IP options−Strict Source Route

Signature is triggered by receipt of an IP datagram in which the IP option list for the datagram includes Strict Source Route.

Info, Atomic

1100 IP Fragment Attack

Signature is triggered when any IP datagram is received with Attack, the "more fragments" flag set to 1 or if there is an offset Atomic indicated in the offset field. 266

1101 Unknown IP Protocol

Signature is triggered when an IP datagram is received with the protocol field set to 101 or greater, which are undefined or reserved protocol types.

Attack, Atomic

1102 Impossible IP Packet

Signature is triggered when an IP packet arrives with the source address equal to the destination address.

Attack, Atomic

2000 ICMP Echo Reply Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 0 (Echo Reply).

Info, Atomic

2001 ICMP Host Unreachable

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 3 (Host Unreachable).

Info, Atomic

2002 ICMP Source Quench

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 4 (Source Quench).

Info, Atomic

2003 ICMP Redirect

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 5 (Redirect).

Info, Atomic

2004 ICMP Echo Request

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 8 (Echo Request).

Info, Atomic

2005 ICMP Time Exceeded for a Datagram

Signature is triggered when an IP datagram is received with Info, Atomic the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 11 (Time Exceeded for a Datagram).

2006 ICMP Parameter Problem on Datagram

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 12 (Parameter Problem on Datagram).

Info, Atomic

2007 ICMP Timestamp Signature is triggered when an IP datagram is received with Request the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 13 (Timestamp Request).

Info, Atomic

2008 ICMP Timestamp Signature is triggered when an IP datagram is received with Reply the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 14 (Timestamp Reply).

Info, Atomic

267

2009 ICMP Information Signature is triggered when an IP datagram is received with Request the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 15 (Information Request).

Info, Atomic

2010 ICMP Information Signature is triggered when an IP datagram is received with Reply the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 16 (Information Reply).

Info, Atomic

2011 ICMP Address Mask Request

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 17 (Address Mask Request).

Info, Atomic

2012 ICMP Address Mask Reply

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the type field in the ICMP header set to 18 (Address Mask Reply).

Info, Atomic

2150 Fragmented ICMP Signature is triggered when an IP datagram is received with Info, Atomic Traffic the "protocol" field in the IP header set to 1 (ICMP) and either the More Fragments Flag set to 1 (ICMP) or an offset indicated in the offset field. 2151 Large ICMP Traffic

Signature is triggered when an IP datagram is received with the "protocol" field in the IP header set to 1 (ICMP) and the IP length greater than 1024.

Info, Atomic

2154 Ping of Death Attack

Signature is triggered when an IP datagram is received with Attack, Atomic the protocol field in the IP header set to 1 (ICMP), the Last Fragment bit is set, and (IP offset * 8 ) + (IP data length) > 65535. Where the IP offset (which represents the starting position of this fragment in the original packet, and which is in 8−byte units) plus the rest of the packet is greater than the maximum size for an IP packet.

3040 TCP−no bits set in Signature is triggered when a TCP packet is received with no Attack, flags bits set in the flags field. Atomic 3041 TCP−SYN and FIN bits set

Signature is triggered when a TCP packet is received with both the SYN and FIN bits set in the flag field.

Attack, Atomic

3042 TCP−FIN bit with Signature is triggered when a TCP packet is received with no ACK bit in flags the FIN bit set but with no ACK bit set in the flags field.

Attack, Atomic

268

3050 Half−open SYN Attack/ SYN Flood

Signature is triggered when multiple TCP sessions have been improperly initiated on any of several well−known service ports. Detection of this signature is currently limited to FTP, Telnet, HTTP, and email servers.

Attack, Compound

3100 Smail Attack

Signature is triggered on the "smail" attack against SMTP−compliant email servers.

Attack, Compound

3101 Sendmail Invalid Recipient

Signature is triggered on any mail message with a pipe symbol (|) in the recipient field.

Attack, Compound

3102 Sendmail Invalid Sender

Signature is triggered on any mail message with a pipe symbol (|) in the "From:" field.

Attack, Compound

3103 Sendmail Reconnaissance

Signature is triggered when expn or vrfy commands are issued to the SMTP port.

Attack, Compound

3104 Archaic Sendmail Signature is triggered when wiz or debug commands are Attacks issued to the SMTP port.

Attack, Compound

3105 Sendmail Decode Signature is triggered on any mail message with ": decode@" Attack, Alias in the header. Compound 3106 Mail Spam

Signature counts number of Rcpt to: lines in a single mail message and sends an alarm after a user−definable maximum has been exceeded (default is 250).

3107 Majordomo Execute Attack

Signature when a bug in the Majordomo program allows Attack, remote users to execute arbitrary commands at the privilege Compound level of the server.

3150 FTP Remote Command Execution

Signature is triggered when someone tries to execute the FTP SITE command.

Attack, Compound

3151 FTP SYST Command Attempt

Signature is triggered when someone tries to execute the FTP SYST command.

Attack, Compound

3152 FTP CWD (enable) set enablepass Enter old password: Enter new password: Retype new password: Password changed. Cat−6509> (enable)

272

The Native IOS mode code that runs on many newer switches is a blend of Layer 2 code and Layer 3 code all rolled up into one version. The Native IOS mode code creates an environment in which Catalyst switches can be configured and managed through the familiar IOS user interface that runs on most routers. To configure a password on a Catalyst switch that is using Native IOS use the commands in the following steps: 1. Use this command to enter into line configuration mode: line line−number

2. Use the password command to define the password for each line on the router. 3. To configure enable mode access you can use one of two commands, enable password or enable secret level . Both commands accomplish the same thing; they allow access to enable mode. However, the enable secret password is considered to be more secure because it uses a one−way encryption scheme based on the MD5 hashing function. The following listing displays an example of configuring the line password and enable passwords on a Catalyst switch using Native IOS: Cat−6509#config t Cat−6509(config)#enable secret Secret@Password Cat−6509(config)#line con 0 Cat−6509(config−line)#login Cat−6509(config−line)#password thisissecure

Configuring Port Security Port security is used to block input to an Ethernet, FastEthernet, or Gigabit Ethernet port when the MAC address of the station attempting to access the port is different from any of the MAC addresses specified for that port. When a packet is received on a port with port security enabled, the source MAC address of the packet is compared with the secure MAC address configured for the port. If the MAC address of the device attached to the port differs from the secure MAC address configured for the port, a security violation occurs and the port can be configured to go into shutdown mode or restrictive mode. If the security violation is configured to transition the port into shutdown mode, the port is permanently disabled or disabled for only a specified time. The default action of shutdown mode is for the port to shut down permanently. If the security violation is configured to transition the port into restrictive mode, the port will remain enabled during the security violation and only drop packets that are coming in from insecure hosts. Warning If you configure a port in restrictive mode and the MAC address on a device that is connected to the port is already configured as a secure MAC address on another port on the switch, the port in restrictive mode shuts down instead of restricting traffic from that device. The secure MAC address of the port can be configured statically, or the port can be configured to dynamically learn the MAC address of the device connected to the switch via the port. There are a few restrictions to configuring port security. Certain rules exist that pertain to configuring port security on a Cisco Catalyst switch:

273

• Port security cannot be enabled on a port that is performing trunking. • Port security cannot be enabled on a destination Switched Port Analyzer (SPAN) port. • Content−Addressable Memory (CAM) entries cannot be configured for a port on which port security is enabled. Use the set cam command to enter CAM entries into the switch. To configure port security for a switch using CatOS code, use the following commands: 1. Use this command to enable dynamic port security on the specified port: set port security enable

2. Use this command to statically define the MAC address of the device connected via the secure port: set port security mod_num/port_num enable

3. Use this command to define the length of time a dynamically learned address on the port specified within the command is secured: set port security age

4. Use this command to define the action a port should take when a security violation occurs: set port security violation

The shutdown parameter disables the port permanently or for a specified period time that is configured with the next command. The restrict parameter drops all packets from an insecure source but the port remains enabled. 5. Use this command to define the amount of time a port remains disabled as a result of a security violation: set port security shutdown

If this command is not configured, the default time is set to permanent and the port must be manually reenabled. Here is an example of configuring port security on a switch that is using CatOS code: Cat−6509 Cat−6509 Cat−6509 Cat−6509 Cat−6509 Cat−6509

(enable) (enable) (enable) (enable) (enable) (enable)

set set set set set set

port port port port port port

security security security security security security

4/48 enable 5/3 enable 00−d0−b7−53−40−bb 4/48 age 360 4/48 violation restrict 5/3 violation shutdown 5/3 shutdown 360

The commands used to enable port security for Catalyst switches that are using Native IOS code are not as robust as the commands available via the CatOS code. To configure port security for a switch that is using Native IOS code, use the following commands: 1. Use this command to select the interface on which port security should be configured: interface

2. Use this command to define the action the port should take in the event of a violation condition: port security action

274

The shutdown parameter will disable the port in the event of a security violation. The trap parameter will send an SNMP trap message in the event of a security violation. 3. Use this command to define the maximum MAC address count for the port: port security max−mac−count

The following code is an example of configuring port security on a switch that is using Native IOS code: Cat−6509#config t Cat−6509(config)#interface fast0/42 Cat−6509(config−if)#port security action shutdown Cat−6509(config−if)#port security max−mac−count 1 Cat−6509(config−if)#end

Configuring Permit Lists The IP permit list is a feature of the CatOS that permits authorized Telnet and SNMP access to the switch only from authorized source IP addresses. IP permit lists do not affect traffic that is transiting the switch or that is locally originated by the switch. IP permit lists only affect inbound Telnet and SNMP traffic with a destination address as that of the management address of the switch. Each IP permit entry consists of an IP address and subnet mask pair that is permitted Telnet or SNMP access. If a mask for an IP permit list entry is not specified, or if a hostname is entered instead of an IP address, the mask has an implicit value equal to all 1s, which effectively means match according to host address. There is a limit on the number of permit entries that can be configured on the switch; the maximum is 100 entries. To configure IP permit lists on a switch running CatOS code, use the following commands: 1. Use this command to enable the IP permit list for Telnet, SNMP, or SSH access: set ip permit enable

2. Use this command to specify the IP addresses that are added to the permit list: set ip permit

Figure B.1 displays a small network that has devices, which need network management access to the switch. Telnet access into the switch should be allowed from any machine within the network. The following code is an example of configuring an IP permit list for the Catalyst switch in Figure B.1 using CatOS code: set set set set set set set

ip ip ip ip ip ip ip

permit permit permit permit permit permit permit

enable telnet enable snmp 192.168.0.0 255.255.0.0 telnet 192.168.24.12 snmp 192.168.24.15 snmp 192.168.24.16 snmp 192.168.40.250 snmp

275

Figure B.1: Catalyst switch using IP permit lists.

Configuring AAA Support Cisco Catalyst switches support the use of the AAA architecture that was discussed in Chapter 2. Catalyst switches allow for the configuration of any combination of these authentication methods to control access to the switch: • Local authentication—Uses the locally configured login and enable passwords to authenticate login attempts. • RADIUS authentication—Uses the AAA server to authenticate login attempts using the RADIUS protocol. • TACACS+ authentication—Uses the AAA server to authenticate login attempts using the TACACS+ protocol. • Kerberos authentication—Uses a trusted Kerberos server to authenticate login attempts. Note All configurations in this section are related to switches that use the CatOS software. To configure for AAA support a Catalyst that uses Native IOS software, please refer to Chapter 2. Use the following commands to enable authorization for the Catalyst switch (local login and enable authentication are enabled for both console and Telnet connections by default): set authentication login tacacs disable console set authentication login tacacs enable telnet primary set set set set set set set set set set

authentication authentication authentication authentication authentication authentication authentication authentication authentication authentication

login tacacs enable http primary enable tacacs disable console enable tacacs enable telnet primary enable tacacs disable http login local enable console login local enable telnet login local enable http enable local enable console enable local enable telnet enable local enable http

276

To view the results of enabling authorization on the switch, issue the show authentication command. The following output is an example of issuing the show authentication command: Cat−6509> (enable) sh authentication Login : Console Telnet −−−−−−− −−−−−−− −−−−−− tacacs disabled enabled(primary) radius disabled disabled kerberos disabled disabled local enabled(primary) enabled

Http −−−− enabled(primary) disabled disabled enabled

Enable: −−−−−−− tacacs radius kerberos local

Http −−−− disabled disabled disabled enabled(primary)

Console −−−−−−− disabled disabled disabled enabled(primary)

Telnet −−−−−− enabled(primary) disabled disabled enabled

Authorization is also supported in the Catalyst model switches. It controls the functions that are permitted by an authenticated user on the switch. Authorization is supported on the Catalyst Ethernet switches for the following: • Commands—User must supply username and password that is verified by the AAA server to EXECute certain commands. Authorization for all commands can be enabled only for enable mode commands. • EXEC mode—User must supply a valid username and password that is verified by the AAA server to gain access to EXEC mode. • Enable mode—User must supply a valid username and password that is verified by the AAA server to gain access to enable mode. Authentication is supported for three different connections attempts; however, authorization is supported for only two, Console and Telnet: • Console—Authorization is performed for all console sessions. • Telnet—Authorization is performed for all Telnet sessions. Just as with routers, switches can be configured to support the use of methods to provide authorization services. The methods are sometimes referred to as options, and the option configured is known as the primary option. Any option configured after the primary option is known as a fallback option. Fallback options are used only in the event of an error condition or failure of the primary option. The Catalyst switches support the use the following options: • TACACS+—Uses a defined TACACS+ server to provide authorization services. • If−Authenticated—If authentication has already taken place for a session, authorization succeeds. • Deny—If the authentication server fails to respond to a request for authorization, the authentication request fails. • None—If the authentication server fails to respond, authentication succeeds. Use the following commands to enable authorization for the Catalyst switch: 1. Use this command to enable authorization for EXEC mode access: set authorization exec enable

277

2. Use this command to enable authorization for privileged mode access to the switch: set authorization enable enable

3. Use this command to enable authorization of configuration commands: set authorization commands enable

The following output displays an example of enabling authorization on the Catalyst switch: set authorization exec disable console set authorization exec enable tacacs+ if−authenticated telnet set authorization enable disable console set authorization enable disable telnet set authorization commands disable console set authorization commands enable config tacacs+ if−authenticated telnet

To view the results of enabling authorization on the switch, issue the show authorization command. The following output displays an example of issuing the show authorization command: Cat−6509> (enable) sh authorization Telnet: −−−−−−−

exec: enable: commands: config: all:

Primary −−−−−−− tacacs+ −

Fallback −−−−−−−− if−authenticated −

tacacs+ −

if−authenticated −

Primary −−−−−−− − −

Fallback −−−−−−−− − −

− −

− −

Console: −−−−−−−−

exec: enable: commands: config: all:

Accounting allows you to track user activity to a specified host, suspicious connection attempts in the network, and unauthorized changes. The accounting information is sent to the accounting server where it is saved in the form of a record. Accounting information typically consists of the user's action and the duration for which the action lasted. You can use the accounting feature for security, billing, and resource allocation purposes. Accounting on the Catalyst switches can be configured for the following types of events: • EXEC mode—Accounting information about EXEC mode sessions on the switch is recorded when this mode of accounting is configured. • Connect—All outbound connection requests made from the switch are accounted for when this mode of accounting is performed. • System—Accounting information on system events that are not user related is recorded. This information includes system reset, system boot, and user configuration of accounting. 278

• Command—Accounting information for each command entered into the switch by a user is recorded when this mode of accounting is configured. After the switch is configured for accounting of services on the switch, accounting records are created. There are two types of accounting records: start records and stop records. Start records include information that pertains to the beginning of an event and stop records include the complete information of the event. To configure the switch for accounting, perform the following steps: 1. Use this command to enable accounting for connection events: set accounting connect enable

2. Use this command to enable accounting for EXEC mode events: set accounting exec enable

3. Use this command to enable accounting for system events: set accounting system enable

4. Use this command to enable accounting of all configuration commands: set accounting commands enable

5. Use this command to enable suppression of unknown user events: set accounting suppress null−username enable

It is best to use the following command to disable this command so that information about unknown user events is accounted for: set accounting suppress null−username disable

An example of configuring a Catalyst switch for accounting service is shown here: set set set set set

accounting accounting accounting accounting accounting

exec enable stop−only tacacs+ connect disable system enable stop−only tacacs+ commands enable config stop−only tacacs+ suppress null−username disable

To view the results of enabling authorization on the switch, issue the show accounting command. The following output is an example of issuing the show accounting command: GC05−6509A> (enable) Event Method −−−−− −−−−−− exec: tacacs+ connect: − system: tacacs+ commands: config: tacacs+ all: −

sh accounting Mode −−−− stop−only − stop−only stop−only −

TACACS+ Suppress for no username: disabled Update Frequency: new−info

279

Accounting information: −−−−−−−−−−−−−−−−−−−−−−− Active Accounted actions on tty0, User (null) Priv 0 Active Accounted actions on tty−2106106732, − User testuser Priv 15 Task ID 807, exec Accounting record, 0,00:00:44 Elapsed task_id=807 start_time=1011372975 timezone=CST service=shell Overall Accounting Traffic: Starts Stops Active −−−−−− −−−−− −−−−−− Exec 0 489 1 Connect 0 0 0 Command 0 0 0 System 0 43 0

280

List of Figures Chapter 1: Securing the Infrastructure Figure 1.1: Using privilege levels to create administrative levels. Figure 1.2: Router A configured for SNMP. Figure 1.3: Router A and Router B configured for RIP authentication. Figure 1.4: Router A and Router B configured for OSPF authentication. Figure 1.5: Router B configured with an inbound route filter. Figure 1.6: User Jeff needs HTTP access to the router. Chapter 2: AAA Security Technologies Figure 2.1: One−way PAP authentication. Figure 2.2: Three−way CHAP authentication. Figure 2.3: TACACS+ packet header. Figure 2.4: TACACS+ authentication. Figure 2.5: TACACS+ authorization. Figure 2.6: RADIUS authentication process. Figure 2.7: RADIUS accounting process. Figure 2.8: Single TACACS+ server. Figure 2.9: Multiple TACACS+ servers. Figure 2.10: Remote client PPP connection. Figure 2.11: Cisco Secure ACS server interface Figure 2.12: Console of the Cisco Secure ACS server Chapter 3: Perimeter Router Security Figure 3.1: ICP three−way handshake. Figure 3.2: Example of CEF network. Figure 3.3: Unicast RPF. Figure 3.4: An example TCP Intercept network. Figure 3.5: Static NAT. Figure 3.6: Example static NAT and route map network. Figure 3.7: Dynamic NAT network example. Figure 3.8: Router 1 Dynamic NAT with route map. Figure 3.9: Rate−limiting Denial of Service. Figure 3.10: A network design with logging defined. Chapter 4: IOS Firewall Feature Set Figure 4.1: Basic operation of CBAC. Figure 4.2: Sample CBAC network. Figure 4.3: Network configured for Java blocking. Figure 4.4: Router 3 configured for CBAC with three interfaces. Figure 4.5: CBAC and NAT network design. Figure 4.6: Network layout for PAM. Figure 4.7: Host that needs PAM configuration. Figure 4.8: Simple firewall IDS network design. Chapter 5: Cisco Encryption Technology

281

Figure 5.1: An Example of the Scytale cipher. Figure 5.2: Example of symmetric key encryption. Figure 5.3: Example of asymmetric key encryption. Figure 5.4: Verbal authentication process. Figure 5.5: CET network topology. Chapter 6: Internet Protocol Security Figure 6.1: IP packet. Figure 6.2: AH in transport mode. Figure 6.3: ESP in transport mode. Figure 6.4: AH in tunnel mode. Figure 6.5: ESP in tunnel mode. Figure 6.6: Basic network using IPSec. Figure 6.7: Full mesh IPSec network Figure 6.8: Network using manual IPSec Keys Figure 6.9: Tunnel EndPoint Discovery Chapter 7: Additional Access List Features Figure 7.1: Truth table for Boolean operations. Figure 7.2: Example of traffic initiated on an internal network with reflexive access lists configured. Figure 7.3: Example of Host B accessing Host A through Router A configured with dynamic access lists. Figure 7.4: Standard access list network. Figure 7.5: Two routers configured for extended access lists. Figure 7.6: TCP access list for Router C. Figure 7.7: Router C permitting and denying traffic. Figure 7.8: Dynamic access list security. Figure 7.9: Reflexive access list network. Figure 7.10: External reflexive access list. Appendix B: Securing Ethernet Switches Figure B.1: Catalyst switch using IP permit lists.

282

List of Tables Chapter 2: AAA Security Technologies Table 2.1: Authorization command parameters. Table 2.2: Accounting command parameters. Chapter 3: Perimeter Router Security Table 3.1: Logging messages and severity level. Chapter 4: IOS Firewall Feature Set Table 4.1: System−defined port application services. Chapter 5: Cisco Encryption Technology Table 5.1: Flag field messages. Chapter 6: Internet Protocol Security Table 6.1: Transform combinations. Table 6.2: Security association states. Chapter 7: Additional Access List Features Table 7.1: Access list type and numbers. Table 7.2: Protocols available with extended access lists. Table 7.3: Precedence values for extended access lists. Table 7.4: Type−of−service values for extended access lists. Appendix A: IOS Firewall IDS Signature List Table A.1: IOS Firewall Network Security Database signatures.

283

List of Listings Chapter 1: Securing the Infrastructure Listing 1.1: Router A's configuration with MD5 authentication. Listing 1.2: Router B's configuration with MD5 authentication. Listing 1.3: The output of the command debug ip rip displays how Router A receives RIP routing updates from Router B. Listing 1.4: The output of the command debug ip rip displays how Router B receives RIP routing updates from Router A. Listing 1.5: Router A's configuration with MD5 authentication. Listing 1.6: Router B's configuration with MD5 authentication. Listing 1.7: Route table of Router A with correct authentication configured. Listing 1.8: Route table of Router A with incorrect authentication configured. Listing 1.9: Router A configured to authenticate OSPF packets using plain text authentication. Listing 1.10: Router B configured to authenticate OSPF packets using plain text authentication. Listing 1.11: Router A configured for MD5 authentication. Listing 1.12: Router B configured for MD5 authentication. Listing 1.13: Router A configured with multiple keys and passwords. Listing 1.14: Router B configured with multiple keys and passwords. Listing 1.15: Router A configuration. Listing 1.16: Router B configuration. Listing 1.17: Router B's route table. Listing 1.18: Router B configured with an inbound route filter. Listing 1.19: Router B's route table with inbound route filter permitting only one network. Listing 1.20: Route table of Router A. Listing 1.21: Router A configured with an inbound route filter. Listing 1.22: Router A's route table with inbound route filter permitting only one network. Listing 1.23: Router A's configuration. Listing 1.24: Router B's configuration. Listing 1.25: Router A configured with an outbound route filter. Listing 1.26: Route table of Router B after applying an outbound route filter on Router A. Listing 1.27: Router B configured with an outbound route filter. Listing 1.28: Route table of Router A after applying an outbound route filter on Router B. Chapter 2: AAA Security Technologies Listing 2.1: Debugging TACACS+ events output. Listing 2.2: Router Seminole authentication configuration. Listing 2.3: Successful login authentication output. Listing 2.4: Failed login authentication output. Listing 2.5: Authentication debug output. Listing 2.6: PPP network access server. Listing 2.7: Remote authentication using TACACS+. Listing 2.8: Authorization configuration. Listing 2.9: Authorization process. Listing 2.10: Accounting configuration. Listing 2.11: Accounting process. Listing 2.12: Output of the Users.txt file. Listing 2.13: Output of the dump.txt file. 284

Chapter 3: Perimeter Router Security Listing 3.1: The adjacency table of Router B. Listing 3.2: An example CEF table for Router B. Listing 3.3: An example of the show cef interface command. Listing 3.4: An example Unicast RPF logging configuration. Listing 3.5: TCP Intercept configuration of Router B. Listing 3.6: The output of show tcp intercept statistics. Listing 3.7: Example of show TCP intercept connections output. Listing 3.8: Example output from debug ip tcp intercept. Listing 3.9: Example Intercept aggressive mode configuration. Listing 3.10: Final TCP Intercept configuration. Listing 3.11: Static NAT configuration. Listing 3.12: Router 1 static NAT with route map configuration. Listing 3.13: Dynamic NAT configuration. Listing 3.14: Display of NAT translations. Listing 3.15: Display of NAT statistics. Listing 3.16: Router 1 Dynamic NAT with route map configuration. Listing 3.17: PAT configuration example. Listing 3.18: Router A configured for rate−limiting. Listing 3.19: Rate limit configuration of Router A. Listing 3.20: Verifying the operation of CAR. Listing 3.21: Router B configuration. Listing 3.22: Multiple rate−limiting policies configuration. Listing 3.23: Router B's logging configuration. Listing 3.24: Show logging output. Listing 3.25: Show logging history output. Listing 3.26: Show logging history. Chapter 4: IOS Firewall Feature Set Listing 4.1: Example configuration of Router 3 for CBAC. Listing 4.2: Output of the show ip inspect command. Listing 4.3: Audit trail messages on Router 3. Listing 4.4: Updated output from the show ip inspect command. Listing 4.5: Configuring Router 3 for Java blocking. Listing 4.6: Debug output of Java blocking. Listing 4.7: CBAC configuration of Router 3 with three interfaces. Listing 4.8: Router 3 configured for CBAC and NAT. Listing 4.9: PAM configuration for Router 3. Listing 4.10: Port mapping table on Router 3. Listing 4.11: Default PAM table of Router 3. Listing 4.12: Attempt to map over a system−defined entry. Listing 4.13: Creating host−defined entries on Router 3. Listing 4.14: Display of the host−defined PAM table entries. Listing 4.15: Subnet−defined PAM configuration. Listing 4.16: Output of the PAM table on Router 3. Listing 4.17: Router 3 configured to override system−defined entries. Listing 4.18: Display of PAM table on Router 3. Listing 4.19: Configuration of mapping different hosts to the same port. Listing 4.20: Final configuration of Router 3. Listing 4.21: Complete PAM table for Router 3. 285

Listing 4.22: IDS configuration of Router 3. Listing 4.23: Output of the show ip audit statistics command. Listing 4.24: Router 3 audit configuration. Listing 4.25: Denying devices from inspection. Listing 4.26: Access list configuration. Listing 4.27: Verification of disabled attack signatures. Listing 4.28: Disabling attack signatures on a per−host basis. Listing 4.29: Complete intrusion detection configuration. Chapter 5: Cisco Encryption Technology Listing 5.1: Initial configuration of Router A. Listing 5.2: Initial configuration of Router B. Listing 5.3: Layer 3 connectivity verified on Router A. Listing 5.4: Layer 3 communication verified on Router B. Listing 5.5: Generating Router A's key. Listing 5.6: Generating Router B's key. Listing 5.7: Router A saving private key to NVRAM. Listing 5.8: Router B saving private key to NVRAM. Listing 5.9: Viewing Router A's public key. Listing 5.10: Viewing Router B's public key. Listing 5.11: Router B enabling DSS key exchange. Listing 5.12: Router A enabling DSS key exchange. Listing 5.13: Router B asking to accept Router A's public key. Listing 5.14: Router B asks to send Router A its public key. Listing 5.15: Router A receives Router B's public key. Listing 5.16: Router A viewing Router B's public key. Listing 5.17: Router B viewing Router A's public key. Listing 5.18: Router A's configuration after exchanging keys. Listing 5.19: Router B's configuration after exchanging keys. Listing 5.20: Configuring a global encryption policy on Router A. Listing 5.21: Configuring a global encryption policy on Router B. Listing 5.22: Viewing encryption algorithms in use on Router A. Listing 5.23: Viewing encryption algorithms in use on Router B. Listing 5.24: Encryption access list configuration on Router A. Listing 5.25: Encryption access list configuration on Router B. Listing 5.26: Access list configuration of Router A. Listing 5.27: Access list configuration of Router B. Listing 5.28: Crypto map configuration of Router A. Listing 5.29: Crypto map configuration of Router B. Listing 5.30: Viewing the crypto map configuration of Router A. Listing 5.31: Viewing the crypto map configuration of Router B. Listing 5.32: Applying the crypto map to Router A. Listing 5.33: Applying the crypto map to Router B. Listing 5.34: The ping command issued on Router A. Listing 5.35: DEBUG output from the ping command on Router A. Listing 5.36: Output of show commands on Router A. Listing 5.37: Final CET configuration of Router A. Listing 5.38: Final CET configuration of Router B. Chapter 6: Internet Protocol Security

286

Listing 6.1: IPSec configuration of Router A. Listing 6.2: IPSec configuration of Router B. Listing 6.3: Enabling the debug commands and the Ping request. Listing 6.4: Security association request. Listing 6.5: IKE verification process. Listing 6.6: IKE negotiation. Listing 6.7: Completion of security association setup process. Listing 6.8: Security association database on Router B. Listing 6.9: IKE security association database. Listing 6.10: IPSec configuration of Router A. Listing 6.11: IPSec configuration of Router B. Listing 6.12: IPSec configuration of Router C. Listing 6.13: Manual AH configuration of Router 1. Listing 6.14: Manual AH configuration of Router 2. Listing 6.15: Manual security associations on Router 2. Listing 6.16: Security association process on Router 2. Listing 6.17: Manual AH and ESP configuration of Router 1. Listing 6.18: Manual AH and ESP configuration of Router 2. Listing 6.19: Manual security associations on Router 1. Listing 6.20: Changing keys on Router 2. Listing 6.21: Router 2 deleting security associations. Listing 6.22: Router 2’s failed attempt to set a security association. Listing 6.23: Tunnel EndPoint Discovery configuration of Router A. Listing 6.24: Tunnel EndPoint Discovery configuration of Router B. Listing 6.25: Complete Tunnel EndPoint process for Router A. Chapter 7: Additional Access List Features Listing 7.1: Raul's numbered access list configuration. Listing 7.2: Chris's numbered access list configuration. Listing 7.3: Issuing the ping command on Raul. Listing 7.4: Results of the debug IP packet command. Listing 7.5: Issuing the ping command again on Raul. Listing 7.6: Results of the debug IP packet command on Raul. Listing 7.7: Extended access list configuration of Raul. Listing 7.8: Extended access list configuration of Chris. Listing 7.9: Ping attempt to 192.168.50.50 from 192.168.30.31. Listing 7.10: Output of the debug IP packet command on Raul. Listing 7.11: Ping attempt to 192.168.50.50 from 192.168.30.30. Listing 7.12: Output of the debug IP packet command on Raul. Listing 7.13: TCP established configuration of Router C. Listing 7.14: Established TCP connection output. Listing 7.15: Named access list configuration of Raul. Listing 7.16: Named access list configuration of Chris. Listing 7.17: Output of the show IP interface command on Chris. Listing 7.18: Commented named access list on Router C. Listing 7.19: Commented numbered access list on Router C. Listing 7.20: Configuration of Router 1 for dynamic access lists. Listing 7.21: Configuration of Router 2 for dynamic access lists. Listing 7.22: Temporary access list entries on Router 1. Listing 7.23: Show logging on Router 1. Listing 7.24: New configuration of Router 1. 287

Listing 7.25: Reflexive access list configuration of Router 2. Listing 7.26: Display of the access lists defined on Router 2. Listing 7.27: Displaying the reflexive access list on Router 2. Listing 7.28: External reflexive access list on Router 2. Listing 7.29: Timed access list using numbered access list. Listing 7.30: Timed access list using named access list.

288