Table Of Contents
Out of Scope for this Document
Best Practices and Known Limitations
Security Concepts—Implementation and Configuration
Infrastructure Protection Mechanisms
Encryption Services (VPN Topology)
High Availability (Redundancy)
Redundant Multi-Threaded in a Single Site Location
Multiple Single-Threaded Site Locations of NGWAN Edge
QoS for WAN Aggregation Routers
Routing Protocol Implementation
Performance and Scalability Considerations
Hardware Crypto Acceleration is Required
VPN Topology and Routing Protocol Design
Level and Type of Logging of Security Mechanisms
Profile 1—Full Configuration for Cisco 7200VXR Crypto Aggregation Routers
Profile 1—Full Configuration for Cisco 7301 WAN Routers
Profile 1—Configuration for Cisco ASA 5540s
Profile 2—Full Configuration for Cisco 7200VXR Integrated-Crypto Aggregation and WAN Systems
Profile 2—Full Configuration for Cisco ASA 5540
Profile 3—Full Configuration for Cisco 7600 Crypto Aggregation System
Profile 3—Full Configuration for Cisco 7304 WAN Router
Profile 3—Configuration for Cisco Firewall Service Modules
Profile 4—Full Configuration for Cisco 7600 Crypto Aggregation and WAN System
Profile 4—Full Configuration for Cisco Firewall Service Module
L2 Switch Configurations for all Profiles
All Profiles—Full Configuration for Cisco Catalyst 3560 Switch (Used Mainly as L2 Switch)
Appendix A—Other Possible Topologies
Request For Comment (RFC) Papers
Infrastructure Protection and Security Service Integration Design for the Next Generation WAN Edge v2.0
Modern WAN architectures require additional network capabilities to support current higher bandwidth and mission-critical applications. Requirements for deploying voice over IP (VoIP) and video conferencing include high availability, IP multicast, and quality of service (QoS). Today, most enterprises rely on private WAN connections such as Frame Relay, ATM, or leased-line services to connect their businesses. When deploying a traditional Frame Relay or ATM-based private WAN, however, network operations must implement point-to-point or hub-and-spoke architectures that make provisioning and management of moves, adds, or changes on the network complex. Also, the operational expense for a private WAN can sometimes be higher than IP-based WAN technologies. The goal is to have reliable connectivity that is secure, can be easily updated, and can scale to meet evolving business needs.
To address these needs, Cisco provides validated, extensible network architectures that are underpinned by a comprehensive line of services aggregation routers. The portfolio of WAN solutions enables an enterprise to rapidly introduce new business applications and services from the branch office, through the campus, to the data center, while reducing operating costs and network complexity.
This design guide extends the portfolio of WAN solutions to provide a highly available, secure network design to the WAN edge. Providing the WAN architecture with security from outside attacks as well as protecting the traffic entering or exiting the WAN network is the focus of this design guide. This design guide defines the comprehensive functional components required to secure the infrastructure and data paths for an enterprise WAN edge.
Cisco Enterprise Systems Engineering (ESE) is dedicated to producing high-quality tested design guides that are intended to help deploy the system of solutions more confidently and safely. This design guide is part of an ongoing series that addresses enterprise WAN solutions using the latest advanced services technologies from Cisco and based on best practice design principles that have been tested in an enterprise systems environment.
Contents
Introduction
This design guide evaluates the securing of an enterprise WAN edge network as it pertains to the Cisco enterprise WAN and MAN architectures. These architectures are defined in detail at the following URL: http://www.cisco.com/en/US/netsol/ns817/networking_solutions_program_home.html.
The following four architectures were established to provide reliable connectivity to your global enterprise while reducing operational expenses, becoming more resilient, and enabling some of the latest network services:
•
Encrypted private connectivity—Takes advantage of existing traditional private WAN and MAN connections
•
•
•
These four architectures offer several secure alternatives to traditional private WAN connectivity that help increase network scalability and flexibility.
This design guide focuses only on the enterprise WAN edge network. The enterprise WAN edge is defined as the set of networking devices that aggregate traffic from enterprise branch offices, and pass that traffic to the enterprise campus or data center. Regardless of which enterprise WAN/MAN architecture is chosen, it is crucial to guarantee the devices and traffic residing at the WAN edge. This design guide examines two typical WAN edge speeds, OC3 (155 Mbps) and OC12 (622 Mbps), and establishes profiles for each WAN speed. These profiles are not intended to be the only recommended design architectures for the WAN edge. They are meant to show examples based on the majority of enterprise WAN edge architectures available today. Each profile provides guidelines for securing the WAN edge including infrastructure protection mechanisms, network fundamentals such as routing and high availability, and, finally, the security services needed to protect against threats to the WAN edge. The framework for this document is shown in Figure 1.
Figure 1 Enterprise WAN Edge Network Framework
This design guide begins with an overview followed by design recommendations. In addition, configuration examples are presented. Each service is described in detail and then shown in each of the various profiles to provide complete guidance on how to tackle securing a WAN edge network. You must have a basic understanding of all the following to successfully implement the concepts shown in this document:
•
•
•
•
•
•
Target Audience
This design guide is targeted for Cisco systems engineers and customer support engineers to provide guidelines and best practices for customer deployments.
Scope of Work
This version of the design guide addresses the following applications of the secure NGWAN edge solution:
•
–
–
–
–
•
–
•
–
–
–
–
•
–
–
•
Out of Scope for this Document
Cisco devices incorporate a wide variety of security services and mechanisms designed to protect the network infrastructure and attached host. This version of this document does not cover the following security-related features at this time:
•
•
•
•
•
•
Design Overview
This section provides a high-level overview of concepts to secure an enterprise WAN edge. Design and Implementation provides more detail on the design considerations, while Scalability Considerations presents primary considerations to be considered before deploying the design for scalability.
A network engineer and a security engineer are usually at odds when it comes to network security. They generally have conflicting goals. The network engineer is trying to connect users with services at the highest possible speed with as little intervention into the actual traffic as possible, while the security engineer is trying to secure the network from both network intrusions (restricting access to services) as well as providing protection to the network itself from DoS-type attacks that rob the infrastructure of valuable uptime. All network security can be summarized is a trade-off of simplicity and efficiency for a level of security and protection. The high-level goal of the security engineer is to achieve these layers of security at the lowest cost to the infrastructure (bandwidth, CPU utilization, and packet delay) as possible.
When choosing which security services and infrastructure protections are right for a customer, it is strongly recommended that customers perform a risk versus cost analysis. This leads to a monetary baseline that a service disruption (down or degraded time) would incur. A "dollar per minute unavailable" value helps in choosing the proper amount of layers and mechanisms that are appropriate for the customer. The customer should compute the amount of monies lost, computed as lost development time, possible PR fallout, legal fees, lost revenue (transactions), and so on, if a network intrusion occurred that yielded proprietary data being made public or consumed by the competition. These values of monies lost help the customer and the Cisco sales engineer decide which of the possible security features are required, explain to management the cost justifications of buying security gear, and assist in the staffing requirements for security enabling the enterprise WAN edge.
Under normal operating conditions, the legitimate end user network traffic consumes some, if not most, of the network resources (bandwidth, CPU utilization, forwarding capacity, and so on) as packets of the end user pass through the network devices. In the event of a DoS attack, a packet, or series of packets, are sent in the attempt to consume those network resources and keep the network from processing the legitimate traffic; thus, denying the legitimate user traffic the services it requires. The goals of infrastructure protection are to limit intrusions, prevent data/service theft, and to minimize the likelihood of success and mitigate the damage caused by DoS attacks. Infrastructure protection includes device hardening to secure the network devices from unauthorized access by non-solution administrators over various communication protocols, as well as mechanisms to control the use of CPU and memory resources.
This document describes some infrastructure protection features embedded in Cisco IOS and some Cisco firewalls, and also the integration of some key security services namely IPsec VPNs and firewalls. This document provides design guidance on enabling and integrating these protections and services on a single network device. It is not intended to be an exhaustive technical review of all nuances of the features, but rather how to implement them in a layered approach to provide a cohesive security solution for the NG WAN edge.
Some alternate barrier (firewall) locations and the ramification to security, performance, and connectivity are discussed in detail in Appendix A—Other Possible Topologies.
The security features described in this document are by no means an exhaustive integration of all possible security features, but rather the start of a reasonable security framework using the "security in layers" approach to implementing security. The strength of many security layers is stronger than the sum of those security components separately. Most security professionals agree that no one security mechanism is adequate alone. A layered approach of several distinct features is the preferred approach to most security challenges, and provides a more robust solution to the wide range of threats.
Assumptions
The design approach presented in this design guide makes several starting assumptions:
•
•
•
•
•
•
•
•
•
•
Design Components
The four architectures defined for Enterprise WAN and MAN networks provide an alternative solution to private WAN technologies such as Frame Relay and ATM-based networks. The design guides written around these architectures focused on support for network growth, availability, operational expenses, voice and video support, and level of complexity. Each of the architectures can be summarized into the seven basic components shown in Figure 2.
Figure 2 Enterprise WAN and MAN High-Level Architecture Basic Components
These components are the following:
•
•
•
•
•
•
•
These seven components are the basic components needed for all the enterprise WAN and MAN architectures. Not all four architectures use every one of the seven components, but an overview of all seven is shown for completeness. Also, the WAN aggregation, crypto aggregation, tunnel interface, and routing protocol functionality components can reside in a single chassis or multiple chassis, depending on the WAN and MAN architecture chosen.
In Figure 2, no mention is made of how to secure the actual devices within the WAN edge, how to block malicious traffic from entering the WAN edge, or how to guarantee the appropriate users or branch routers are allowed into the WAN edge network. This design guide focuses on providing guidance in these areas. The component overview of the enterprise WAN and MAN architectures are supplemented with additional components to secure the WAN edge. The concept of securing the NGWAN edge is to add additional layers of security and security functions to the existing encrypted VPN topology that may exist in a WAN edge. These security features add an inner and outer layer of access control as well as basic infrastructure protections of those systems. Figure 3 shows the location of these added components.
Figure 3 Securing the WAN Edge High-Level Architecture Additional Components
These added security components are the following:
•
•
•
•
•
Each of these additional components is discussed in detail throughout this document. Figure 3 can be regarded as the high-level architecture overview to secure the enterprise WAN edge. This document takes this high-level architecture overview and creates a set of profiles for each of the two typical WAN speeds: OC3 (155 Mbps) and OC12 (622 Mbps). Two profiles are created for OC3 and two for OC12 WAN speeds. This profile approach shows each of the above components in an integrated as well as separate device network architecture based on the current platform set available from Cisco for these two WAN speeds. Each profile contains the various layers of security available in the additional components shown in Figure 3.
The organization of this document is summarized in Figure 4.
Figure 4 Securing the WAN Edge Documentation Framework
In addition to the additional security components, network fundamentals such as scalability and performance, high availability, QoS, and routing protocols are discussed.
WAN Speed Profiles
There are two typical WAN speeds for a WAN Edge network: OC3 (155 Mbps) and OC12 (622 Mbps). The choice of these two network speeds determines the platform set from Cisco chosen. In addition, this design guide creates two profiles for each WAN speed. These profiles are designed to provide guidance when designing a WAN edge network regardless of which enterprise WAN and MAN architecture is selected. The profiles for each WAN speed investigate integrated versus dedicated chassis for each functionality component as highlighted in the previous section. Some customers prefer a highly integrated solution where most, if not all, of the functions described in this document reside on a single or very few chassis. Other customers prefer the granularity and scalability of these same functions separated across multiple chassis. Both solutions have their advantages and disadvantages. From these profiles, guidance and configuration examples are given for securing the WAN edge mechanisms, as discussed in Figure 4. These mechanisms are encryption services (crypto), infrastructure protection services, security services, and network fundamentals.
OC3 Profiles
Based on the high-level architecture for an enterprise WAN edge network, two profiles were chosen for a WAN edge requiring an OC3 connection from the private WAN cloud. The first profile shows a dedicated chassis solution and the second profile shows an integrated solution. The platforms chosen are also discussed in the following sections.
OC3 Profile 1—Three-Tier Solution
Figure 5 shows how the seven basic network components of high-level WAN edge architecture are organized to provide a dedicated chassis, separated by function solution.
Figure 5 Profile 1 OC3 Architecture (Three-Tier Solution)
To meet the OC3 WAN speed requirement, the following Cisco platforms were chosen to fulfill each network component:
•
•
•
OC3 Profile 2—Two-Tier Solution
Figure 6 shows how the seven basic network components of high-level WAN edge architecture are organized to provide an integrated functionality solution.
Figure 6 Profile 2 OC3 Architecture (Two-Tier Solution)
To meet the OC3 WAN speed requirement, the following Cisco platforms were chosen to fulfill each network component:
•
•
Comparison of the OC3 Profiles
Table 1 shows the advantages and disadvantages of the two OC3 profiles created.
Both profile 1 and 2 share a dedicated inner barrier firewall of a Cisco ASA 5540 (as an inner barrier firewall).
OC12 Profiles
Based on the high-level architecture for an enterprise WAN edge network, two profiles were chosen for a WAN edge requiring an OC12 connection from the private WAN cloud. The third profile shows a dedicated chassis solution and the fourth profile shows an integrated solution at OC12 speeds. The platforms chosen are also discussed in the following sections.
OC12 Profile 3—Two-Tier Solution
Figure 7 shows how the seven basic network components of high-level WAN edge architecture are organized to provide a dedicated chassis, two-tier solution.
Figure 7 Profile 3 OC12 Architecture (Two-Tier Solution)
To meet the OC12 WAN speed requirement, the following Cisco platforms were chosen to fulfill each network component:
•
•
OC12 Profile 4—Integrated Functionality Solution (One-Tier Solution)
Figure 8 shows how the seven basic network components of high-level WAN edge architecture are organized to provide an integrated functionality solution.
Figure 8 Profile 4 OC12 Architecture (One-Tier Solution)
To meet the OC12 WAN speed requirement, the following Cisco platforms were chosen to fulfill each network component:
•
Comparison of the OC12 Profiles
Table 2 shows the advantages and disadvantages of the two OC12 profiles created.
Both profile 3 and 4 share a FWSM, as the inner barrier firewall. Although integrated in the 7600 chassis, the FWSM has its own independent CPU and network processors.
Securing the NG WAN Edge
The key security components of this architecture are organized in this document into three categories: infrastructure protection services, security services, and encryption services (crypto).
Encryption Services
The crypto aggregation component provides its functionality within the WAN edge. The crypto aggregation component creates a secure and encrypted communication channel between the branch sites and the core private network, as well as from "branch-to-hub-to-other branch" connections. The encryption services involve the four IPsec-based WAN architectures and are discussed in great detail in the following design guides:
•
•
•
Design and Implementation discusses these four VPN topologies as they apply to the WAN speed profiles created. Infrastructure protection services and security services are discussed in the next two sections.
Infrastructure Protection Services
Infrastructure protection services provide proactive measures to protect devices, in this case Cisco IOS software-based routers, switches, and appliances, from direct and indirect attacks. Infrastructure protection services assist in maintaining network transport continuity and availability. Regardless of which enterprise WAN and MAN architecture or WAN edge speed profile chosen, infrastructure protection services apply to all the network components in the WAN edge. To protect these devices, the following methods are used:
•
This document uses built-in facilities such as the following:
–
–
–
–
–
–
•
–
–
•
–
•
–
–
More detailed descriptions and configurations of all these infrastructure protection mechanisms are provided in Infrastructure Protection Mechanisms.
Security Services
Security services provide the added functionality within the WAN edge network to control that the appropriate users can access the network device, the appropriate certificates are given, and that a protected and archived audit trail of security events exists. The following security services methods were used:
•
•
•
•
A more detailed description and configuration of all the previous listed security services are shown in Security Service Integration.
Network Fundamentals
Network fundamentals refer to the basic services that are required for network connectivity. These services include high availability, IP routing, and QoS. Unique to the WAN edge is the scalability and performance network fundamental. Given that the WAN edge aggregates numerous branch sites and forwards that traffic to the core "private" network, selecting a platform that can meet the branch aggregation requirements and still be able to forward traffic is fundamental to a WAN edge network. Network Fundamentals discusses this network fundamental in greater detail.
High Availability
Implementing designs that incorporate high availability require the solution administrator to identify the components that may likely fail, to provide redundancy during the failure, and then to simulate a failure and recovery to test the plan. This section shows the high-level architecture of a single site, multi-threaded architecture (box-level redundancy), and discusses the architecture of a multi-site redundant architecture (geographical site redundancy). See High Availability (Redundancy) for detailed network designs and implementation information.
Redundant Multi-Threaded in a Single-Site Location
The core concept in this redundancy model is to supply device and circuit redundancy at each major function of the topology within a single site. The number of chasses chosen to implement the solution has a major impact on how much redundancy is possible.
Figure 9 shows an example of this multi-threaded system in a single-site location.
Figure 9 Multi-Threaded System in a Single Location (Profile 1)
There are trunk links between the core and the inner firewall, and also between the inner firewall and the crypto aggregation devices. This allows cross failover of one set of functions (that is, WAN and crypto or inner firewall) without failover of the whole thread.
Table 3 lists the advantages and disadvantages of a multi-threaded single-site deployment.
If L2 switches are required for redundancy, they may be implemented as unique sets of switches at each spot in the NGWAN edge topology. Alternatively, the L2 switches may simply be different VLANs off the same two shared switches. This choice depends on the company requirements for keeping various levels of traffic separated or not on a L2 device. Opinions on this practice vary among security professionals. If you are concerned that the L2 switches could be compromised giving access into a more protected location in the network topology, multiple independent sets of switches are recommended. See Redundant Multi-Threaded in a Single Site Location for details on topology and implementation.
Multiple Single-Threaded Site Locations of NGWAN Edge
A single threaded solution has one path through the set of systems (a thread). By creating two or more site locations for each single thread, geographical redundancy is achieved. This NGWAN edge topology provides very good redundancy while still maintaining cost efficiency.
The example shown in Figure 10 does not provide for redundancy within a location but provides redundancy across two or more locations.
Figure 10 Multiple Single-Threaded Site Locations Redundancy (Profile 1)
In a multiple single-threaded site locations NGWAN edge redundancy model, some basic considerations need to be designed into the network for the redundancy to operate correctly. See Multiple Single-Threaded Site Locations of NGWAN Edge for details on topology and implementation.
Quality of Service
QoS (with the exception of scavenger class QoS) is implemented to achieve some guarantees on certain application performance across the network, such as VoIP traffic. For implementation details, see QoS for WAN Aggregation Routers.
Routing Protocols
Routing protocols (and possibly the redistribution of them) are extremely important to redundancy and the time to detect and respond to a failure event. This is described in detail in Routing Protocol Implementation.
For implementation details of these items, also see Network Fundamentals.
Best Practices and Known Limitations
The following sections contain a summary of the best practices and limitations for the design. More detailed information is provided in Design and Implementation.
Best Practices Summary
The following lists at a high-level the best practices recommendations for infrastructure protection and security service integration on the WAN edge systems:
•
•
•
•
•
Known Limitations Summary
The following summarizes the known limitations for infrastructure protection and security service integration on the WAN edge systems:
•
•
–
–
–
–
•
•
•
•
Additional detailed information on these recommendations is discussed in the sections that follow.
Design and Implementation
Which security products and features to include in the "securing" of the NGWAN edge, where those services should reside, and how to properly configure them, is the primary focus of this section.
Each function in this design may have network traffic that is used for itself (control plane) or for a higher level traffic. It is important to understand how the components of this architecture communicate with their counterparts at the branch location, and where each component of the NGWAN edge is meant to terminate.
The following describes the concept of different classes of traffic and the devices on which they terminate:
•
•
•
•
•
•
–
–
In a multi-function system such as the NGWAN edge, several types of traffic go through the system at any given time. The vast majority of the packets per second (pps) and bits per second (bps) of the traffic transiting the NGWAN edge is end-user data. A smaller proportion of the traffic is considered control plane traffic. An example of control plane traffic is the routing protocol used inside the IPsec VPN tunnel (VPN IGP) to the branches. The solution administrator may choose to use any IGP (that is, EIGRP or OSPF) as the routing protocol. This traffic is critical to the stability of the network but is not generated by the end users. It is generated and terminated by the network gear itself. Other examples of control plane traffic are ISAKMP connections for IPsec, and even the solution administrator of the system connecting to them for remote administration or device monitoring.
Figure 11 shows a comparison of control plane and data plane traffic in the NGWAN edge architecture.
Figure 11 Control Plane versus Data Plane Traffic in NGWAN Edge Architectures
Each type of connection is described in more detail as follows:
1.
2.
3.
4.
5.
a.
b.
6.
7.
Design Considerations
This section gives provides configuration summaries and more detail descriptions of the various security and other mechanisms being enabled on the NGWAN edge gear. The goal of this section is to expand on the concepts in Design Overview and provide the detail needed for the solution administrator to understand and implement each feature. This section is not a technical "deep dive" into each subject described but rather how to integrate all the various features into a comprehensive "security in layers" solution and show the difference in devices and configuration.
Most of the configuration examples in this section are based off of an "integrated WAN router" model as represented in profile 2 (OC3) or profile 4 (OC12). Full configurations for all profiles are shown in Test Bed Configuration Files.
Security Concepts—Implementation and Configuration
The key components of this infrastructure protection and security service integration are indicated by red arrows, as shown in Figure 12.
Figure 12 Implementing Security Services and Infrastructure Protections
Infrastructure Protection Mechanisms
The goals of infrastructure protection are to lessen the likelihood or amount of damage done to critical systems by a deliberate or collateral intrusion attempt or DoS-type attack on that respective system, and to prevent unauthorized access to private data or service theft of the NGWAN edge systems. The NGWAN edges are located in a campus or data center of the enterprise. The NGWAN edge solution aggregates hundreds or thousands of branch devices giving connectivity to the enterprise core network; as such, it becomes a likely target of interest to an attacker.
Device Hardening
Hardening the access options of the NGWAN edge devices and removing potentially dangerous features and services is a requirement to the securing of the NGWAN edge. A basic common sense approach to device hardening is shown in the following section.
Create a Banner
For links to both the Cisco IOS essentials (now a Cisco Press book) and the NSA document, see the following URL: http://www.thewaystation.com/techref/choke.shtml. The banner is more for establishing legal ownership and the ability to prosecute an intruder. It is similar to a "no trespassing" sign in the physical world.
Create a banner for any shell connection attempts, so that the system is clearly marked as private. Cisco recommends that you consult your legal department or group for the exact language required by your company or organization in such a banner. It is recommended not to divulge any unnecessary information in the banner (that is, device name or network administration information).
Commands for creating a banner (motd):
•
!banner motd ^CWarning this is a private system.Unauthorized access is prohibited.Violators will be prosecuted..^C!! *Note the ^C should be a character not used! in the banner itself when entered, once! enter the router will convert it to a ^C in! the configuration - this is normal.•
!banner motd Warning this is a private systembanner motd Unauthorized access is prohibited.banner motd Violators will be prosecuted.banner motd .!! *Note each line of the banner can have it's own command! in the config there is no "end of block" type character! like in IOS.Use AAA on all Devices
AAA with TACACS+ can provide an easy-to-manage source for device account administration, authorization command sets, and a repository for accounting information. These AAA commands are used in conjunction with a Cisco Secure Access Control Server (ACS) or other TACACS+ server. The following are benefits of using AAA commands with an ACS server:
•
•
•
•
•
•
Commands for Authentication, Authorization, Accounting (CLI AAA via TACACS+)
In this example, the AAA server (Cisco Secure ACS) is at 10.59.138.11 and uses a secret key between the device (NAS) and the AAA server.
•
!! Enable service password-encryption:service password-encryption!! Create a local database login! for backup if ACS is down:username cisco123 privilege 15 password 7 104D000A061843595F! Enable aaa new-model mode for AAAaaa new-model!! Configuring location of the TACACS+ Server and parameters:tacacs-server host 10.59.138.11 key 7 070C285F4D06!tacacs-server timeout 10tacacs-server directed-request!! AAA Authentication commands: (request authentication via! tacacs+ for both login and for enable level:aaa authentication login default group tacacs+ local enableaaa authentication enable default group tacacs+ enable! AAA authorization (with command set send down from tacacs+):aaa accounting exec default start-stop group tacacs+!! AAA accounting to TACACS+ for start-stop records (for! session time and also any commands entered in privilege! level 0, 1, and 15 :aaa accounting exec default start-stop group tacacs+aaa accounting commands 0 default start-stop group tacacs+aaa accounting commands 1 default start-stop group tacacs+aaa accounting commands 15 default start-stop group tacacs+aaa session-id common!! *Note - In the aaa accounting commands you need to create on! for each privilege level you wish to go to accounting.! This behavior configures differently then in ASA/FWSM code.•
!! Create a local database login! for backup if ACS is down:username cisco123 password ffIRPGpDSOJh9YLq encrypted privilege 15! Configuring location of the TACACS+ Server and parameters:aaa-server tacacs-group protocol tacacs+aaa-server tacacs-group host 10.59.138.11key ciscoaaa-server TACACS+ protocol tacacs+!! AAA Authentication commands: (request authentication via! tacacs+ for both login and for enable level:aaa authentication enable console tacacs-group LOCALaaa authentication ssh console tacacs-group LOCALaaa authentication telnet console tacacs-group LOCAL! if you are on an ASA Security Appliance you will need this additional command! which is not necessary on a FWSM:aaa authentication serial console tacacs-group LOCAL!! AAA authorization (with command set PIX SHELL send down from tacacs+):aaa authorization command tacacs-group LOCAL! AAA accounting to TACACS+ for start-stop records (for session time! in either telnet or ssh and also any commands entered for privilege! level 1 thru 15aaa accounting telnet console tacacs-groupaaa accounting ssh console tacacs-groupaaa accounting command tacacs-group!! *Note - the "aaa accounting command" is for that level and up! this example was 1 and up - which is default! This behavior is configures differently then in Cisco IOSAAA configuration and behavior is slightly different in Cisco IOS, Cisco ASA 5540, and Cisco FWSM. In general, the use of AAA is the same on all platforms: to provide a userID/password login for "privilege level 1", and to enable password login for "enable or configure" (privilege level 15) commands.
In Cisco IOS devices, the configuration of this document uses the "default" group. This uses a userID/password for the "privilege level 1" login, and depending on the account setup in the AAA (Cisco Secure ACS) server, may also require a separate "enable" level login (privilege level 15). This is true whether the solution administrator connects via SSH or via the physical console port. Both use the default of AAA. As a backup if the AAA server is unavailable, there is a "local account" configured in the device, but this is used only if the AAA server is unreachable from that specific device.
In a Cisco ASA security appliance, the commands are slightly different, there is no default, and the solution administrator must configure the AAA authentication command per communication protocol in which the AAA is to be applied. The commands differ in syntax from traditional IOS AAA commands; the term console really means command-line interface (CLI). The physical port of the console is actually named serial in the configuration, and AAA must be applied to this separately. If a solution administrator connects to the Cisco ASA via SSH or via the serial (physical console) port, AAA behavior is determined by that specific command in the configuration. The default behavior, if no AAA policy is applied to the serial, is to use the login "enable_1" for the account ID, although this is not recommended. Only the active ASA in a failover pair has the OSPF routing table that gives a dynamic network route to the AAA server if more that one hop away; thus, only the active system has access to the AAA server, super-log syslog server, and so on. Any static routes are valid on the "standby" but not any dynamically learned routes via a dynamic routing protocol (that is, OSPF in this document). This means that a serial (physical console) connection on the standby unit must use the local user account in the configuration to get either "privilege level 1 or 15" access via the physical console port.
In a Cisco FWSM, the commands are mostly similar to the Cisco ASA Security Appliance, but there is no physical serial console on the module. The solution administrator can connect via SSH or by connecting via a special command issued on the 7600 chassis where the module is installed. That command is session slot 4 processor 1, where the FWSM is installed in slot 4 of the chassis. This creates a reverse telnet from the 7600 chassis to the FWSM for administration. The FWSM always accepts this reverse telnet from the 7600, even when the Telnet protocol has been disabled and the AAA rules apply. Much like on the ASA appliances, only the active has routes via a dynamic routing protocol, so if the AAA server is more than one hop away (and no static route exists to it), you need to use the login of the local account in the configuration on the standby unit.
Restrict Shell Access to SSH instead of Telnet
Use SSH instead of Telnet for remote administration of devices in the NGWAN edge. This provides an encryption shell and adds encrypted privacy to the administrative shell session of the solution administrator to prevent snooping by unwanted parties.
When an solution administrator uses Telnet or r-shell (rsh) to access a device, the UserID and password for that shell session are sent over the network in clear text, as well as any commands they may enter or the responses to those commands. By allowing only SSH, the shell session of the solution administrator is encrypted and uses keyed endpoint authentication to keep the session private and not easily viewable. The solution administrator needs to carefully choose Cisco IOS images for their routers that support SSH (usually indicated in the image description or as a 3DES image).
Commands for only using SSH (no telnet or other protocols) for an administrative shell are as follows:
•
!! set the routers hostname and domainhostname wpoc1-r1ip domain name ese.cisco.com!! Create a key for SSH:cry key generate rsa general-keys modulus 1024!! set at SSH version 2 and parametersip ssh time-out 30ip ssh source-interface gi0/1ip ssh authentication-retries 3ip ssh logging events! ***SSH logging not available in cisco 7600 image tested.ip ssh version 2!! This allow ONLY ssh (not telnet) as an inbound! management shellline vty 0 15transport input ssh...!•
!! set the firewall's hostname and domainhostname wpoc2-asa1domain-name ese.cisco.com!! Create a key for SSH:cry key generate rsa modulus 1024!! *Note - see section below to set range of valid client IP's! before it will operate - This is required.Using ACLs to Restrict Access
An important step in hardening the devices is to use access control of any protocols that are permitted to the devices for administrative or monitoring purposes (that is, SNMP, SSH, and other protocols used to monitor the devices). A basic shell setting such as a timeout value (not infinite) is also strongly recommended.
In the ASA/FWSM, take special care when allowing SNMP on the inner barrier firewall. Cisco strongly recommends that if you wish to poll the ASA/FWSM, use the configuration similar to what is shown in the configurations below. This allows polling from a particular host, but does not configure an SNMP trap to be sent to that host. A busy firewall such as the ASA or FWSM located in the NGWAN edge with a high level of syslogging (that is, syslog level 6 or 7) can output a tremendous amount of syslog/SNMP traps, so it can easily overwhelm a normal network management system with SNMP traps. Cisco does not recommend using SNMP trap for the firewall to a network management system. If you choose to do this, trap only lower level events.
The SNMP shown in the example below is SNMPv3, and is using the authentication and encryption options of v3. Some network management stations may require a lower version of SNMP or may not support the authentication option shown here. The solution administrator should contact the network management team and see what SNMP support level is possible in the network NMS tools before implementation. For example, Cisco Works (CW), Cisco LNS, Cisco Resource Manager Essentials (RME) for the most part do not support authpriv, but do support most other common NMS systems (such as HP OpenView).
SNMPv3 is an interoperable standards-based protocol defined in RFCs 2273 to 2275. SNMPv3 provides secure access to devices by a combination of authenticating and encrypting packets over the network.
The security features provided in SNMPv3 are as follows:
•
•
•
•
Note
The following are commands for access control of device administration protocols (access control of SSH is in the following section):
•
!! Define a standard ACL of which subnets or hosts are ALLOW! access to VTY and/or SNMP!access-list 10 permit 10.0.0.0 0.255.255.255access-list 10 deny any log!!! Applies ACL 10 to control access to the VTY ports and also! set the timeout for a shell to 3 minutesline vty 0 4 </
Guest
