Cisco SAFE for Small Enterprise Networks
Available Languages
Table Of Contents
Cisco SAFE for Small Enterprise Networks
Cisco SAFE Security Reference Architecture
Cisco Security Control Framework (SCF)
Cisco SAFE Architecture Principles
Small Enterprise Network Security Design
Internet Border Router Security Guidelines
Intrusion Prevention Guidelines
Network Access Security and Control
Catalyst Integrated Security Features
Cisco Unified Wireless Network (CUWN) Integrated Security Features
NAC Appliance Modes and Positioning
NAC Appliance Deployment in Small Enterprise Networks
Cisco Identity-Based Network Networking Services (IBNS)
Impacts of 802.1X on the Network
802.1X in Small Enterprise Networks
NAC 802.1X and CISF in Combination
Internet Border Router Deployment
Firewall Hardening and Monitoring
Network Address Translation (NAT)
Intrusion Prevention Deployment
Deploying IPS with the Cisco ASA
IPS Global Correlation Deployment
Basic Clean Access Switch Configuration
Basic Clean Access Out of Band Switch Configuration
Basic 802.1X Switch Configuration
Cisco SAFE for Small Enterprise Networks
Executive Summary
If there is something certain about Internet security, it is the fact that cyber crime and on-line threats affect all organizations, no matter how small or large. Internet-based organized crime and espionage, identity and data theft, botnet infections, and insider attacks are common threats affecting all types of businesses. Particularly attractive to small businesses, mobile access technologies and cloud-based services deliver great flexibility and cost-savings, but pose new challenges. Understanding the nature and diversity of the threats affecting the small business, and how they may evolve over time, is the first step towards a successful security strategy. While small businesses tend to have fewer locations and employees to protect, tighter budgets and limited resources require them to take an innovative and cost-effective approach to security. The security strategy should also help the small business achieve and maintain compliance with mandated standards and regulations.
This document explains how the proven design and implementation principles of the Cisco SAFE Reference Architecture help secure the small business by building a solid and reliable network infrastructure that is resilient to both well-known and new forms of attacks. The Cisco SAFE is a security reference architecture that provides detailed design and implementation guidelines for organizations looking to build highly-secure and reliable networks. The Cisco SAFE leverages Cisco's many years of design and deployment experience and is an architecture that is thoroughly tested and validated as part of the Cisco Validated Design (CVD) program. This document discusses the Cisco SAFE best practices and guidelines that ensure the confidentiality, integrity, and availability of data and system resources supporting key business functions. Design recommendations are based on an understanding of current and future needs and consider the technical and financial constraints often faced by small businesses.
The objective of this document is to present the Cisco SAFE best practices, designs, and configurations applicable to the small business and to provide network and security engineers with the necessary information to help them succeed in designing, implementing, and operating secure network infrastructures based on Cisco products and technologies. While the target audience is technical in nature, business decision makers, senior IT leaders, and systems architects can benefit from understanding the design principles and fundamental security concepts.
Cisco SAFE Security Reference Architecture
The Cisco SAFE consists of design blueprints based on CVDs and proven security best practices that provide the design guidelines for building secure and reliable network infrastructures. The Cisco SAFE design blueprints implement defense-in-depth by strategically positioning Cisco products and capabilities across the network and by leveraging cross-platform network intelligence and collaboration. To that end, multiple layers of security controls are implemented throughout the network, but under a common strategy and administration. The Cisco SAFE uses modular designs that accelerate deployment and that facilitate the implementation of new solutions and technologies as business needs evolve. This modularity extends the useful life of existing equipment, protecting capital investments. At the same time, the designs incorporate a set of tools to facilitate day-to-day operations, reducing overall operational expenditures.
The Cisco SAFE uses the Cisco Security Control Framework (SCF), a common framework that drives the selection of products and features that maximize visibility and control, the two most fundamental aspects driving security. Also used by Cisco's Continuous Improvement Lifecycle services, the framework facilitates the integration of Cisco's rich portfolio of security services designed to support the entire solution lifecycle.
Cisco Security Control Framework (SCF)
The Cisco SCF is a security framework aimed at ensuring network and service availability and business continuity. Security threats are an ever-moving target and the SCF is designed to address current threat vectors, as well as track new and evolving threats, through the use of best practices and comprehensive solutions. Cisco SAFE uses SCF to create network designs that ensure network and service availability and business continuity. Cisco SCF drives the selection of the security products and capabilities and guides their deployment throughout the network where they best enhance visibility and control.
SCF assumes the existence of security policies developed as a result of threat and risk assessments and in alignment to business goals and objectives. The security policies and guidelines are expected to define the acceptable and secure use of each service, device, and system in the environment. The security policies should also determine the processes and procedures needed to achieve the business goals and objectives. The collection of processes and procedures define security operations. It is crucial to business success that security policies, guidelines, and operations do not prevent, but rather empower the organization to achieve its goals and objectives.
The success of the security policies ultimately depends on the degree to which they enhance visibility and control. Simply put, security can be defined as a function of visibility and control. Without any visibility, there is no control, and without any control, there is no security. Therefore, SCF's main focus is on enhancing visibility and control. In the context of SAFE, SCF drives the selection and deployment of platforms and capabilities to achieve a desirable degree of visibility and control.
SCF defines six security actions that help enforce the security policies and improve visibility and control. Visibility is enhanced through the actions of identify, monitor, and correlate. Control is improved through the actions of harden, isolate, and enforce.
Figure 1 Cisco Security Control Framework Model
In an enterprise, there are various places in the network, such as data center, campus, and branch. The SAFE designs are derived from the application of SCF to each place in the network. The result is the identification of technologies and best practices that best satisfy each of the six key actions for visibility and control. In this way, SAFE designs incorporate a variety of technologies and capabilities throughout the network to gain visibility into network activity, enforce network policy, and address anomalous traffic. As a result, network infrastructure elements such as routers and switches are used as pervasive, proactive policy-monitoring and enforcement agents.
Cisco SAFE Architecture Principles
The Cisco SAFE design blueprints were created following these architecture principles:
•
Defense in depth—Multi-layer security embedded throughout the entire infrastructure, endpoints, and applications.
•
•
•
•
•
Underlying Network Design
The Cisco SAFE best practices, designs, and configurations presented in this document were integrated and validated using the network design best practices for small businesses and as documented in the Small Enterprise Design Profile. This CVD is a well-designed and validated network architecture that enables the small business to deliver all of the services required for an enhanced business environment. The Small Enterprise Design Profile includes a routing and switching foundation and integrates services such as WAN connectivity, Video Surveillance, Unified Communications, Digital Media Systems, and Mobility.
The Small Enterprise Design Profile consists of a main site and multiple remote sites of various sizes, all interconnected over a Metro Ethernet core. The architecture is illustrated in Figure 2. At the heart of the architecture is a robust routing and switching network. Operating on top of this network are the services used within the enterprise, which often include the majority of the most business-critical applications, such as databases, payroll, accounting, and customer relationship management (CRM) applications. The core of those services are deployed and managed at the main site, allowing the enterprise to reduce the need for separate services to be operated and maintained at the various remote locations. Centralized systems and applications are served by a main site serverfarm.
Figure 2 Small Enterprise Network Design
One of the main features of the Small Enterprise Design Profile is that it provides a loop-free topology, minimizing re-convergence times and eliminating the complexities of certain technologies, such as spanning tree. The architecture supports different designs for the access layer, including the traditional multi-tier access layer design and the more optimal routed access design. The Small Enterprise Design Profile ensures a loop-free topology for both access designs, however the routed access approach provides for up-link load balancing and virtually eliminates any issues associated with spanning tree.
Another important feature of the Small Enterprise Design Profile is that it uses a collapsed network design where the core and distribution layers at each site are collapsed into one layer, allowing the use of a single device (reducing network cost) while maintaining most of the benefits of the traditional three-tier hierarchical model (core, distribution, and access).
The Small Enterprise Design Profile accommodates different levels of redundancy. This includes the use of redundant supervisor engines with Stateful Switchover (SSO) and Non-Stop Forwarding (NSF) capabilities on Cisco Catalyst 4500 switches, Cisco's Virtual Switching Systems (VSS) technology on the Cisco Catalyst 6500 series, and stackwise technology on the Cisco Catalyst 3700 series switches. The last two features allow two or more distribution switches to be combined into a single virtual switch from a management and data forwarding perspective. Redundancy at the link levels is implemented by using EtherChannel technology, where multiple physical links are bundled into a single EtherChannel. EtherChannel significantly simplifies the network response to an individual link failure. If an individual link in EtherChannel fails, the interface does not trigger any network topology changes, thus minimizing impact to network and application performance and improving network convergence.
Small Enterprise Network Security Design
The small enterprise design presented here implements security following the guidelines of the Cisco SAFE security architecture. As a result, a series of network security technologies and products are strategically deployed throughout the network to protect employees and company assets, to guarantee the confidentiality of sensitive data, and to ensure the availability and integrity of systems and data. Safeguards were carefully chosen to mitigate well-known attacks as well as emerging threats.
Common threats to enterprise environments include:
•
•
•
•
•
As shown in Figure 2, the application of the Cisco SAFE principles to the small enterprise network design follows a defense-in-depth approach, where multiple layers of protection are built into the architecture. The different security tools are combined together for enhanced visibility and control.
The security design for the small enterprise network focuses on the following key areas:
•
–
•
–
–
–
•
–
–
•
–
–
•
–
–
–
Note
http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap9.html.
The following sections discuss the key areas of the small enterprise network security design.
Network Foundation Protection
Small enterprise networks are built with routers, switches, and other network devices that keep the applications and services running. Therefore, properly securing these network devices is critical for continued operation.
The network infrastructure of a small enterprise can be protected by implementing the Cisco SAFE best practices for the following areas:
•
–
–
–
–
–
•
–
–
–
•
–
–
–
–
•
–
–
–
–
•
–
–
•
–
–
–
–
–
–
–
–
–
•
–
–
–
–
–
–
–
For more detailed information on the NFP best practices, refer to "Chapter 2, Network Foundation Protection" of the Cisco SAFE Reference Guide at: http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap2.html.
Internet Perimeter Protection
The small enterprise network design assumes the existence of a centralized Internet connection at the headquarters or main site serving users at all locations. Common services include E-mail and Web browsing for employees, the hosting of a company's website accessible to clients and partners over the Internet, and secure remote access for mobile users and remote workers. Other services may also be provided using the same infrastructure.
The network infrastructure that provides Internet connectivity is defined as the Internet perimeter, illustrated in Figure 3.
Figure 3 Internet Perimeter
The primary functions of the Internet perimeter is to allow for safe and secure access for users residing at all locations and to provide public services without compromising the confidentiality, integrity, and availability of the company's resources and data. To that end, the Internet perimeter incorporates the following security functions:
•
•
•
•
•
•
Design guidelines for implementing the security functions are presented below.
Internet Border Router Security Guidelines
The Internet border router provides connectivity to the Internet through one or more Internet service providers. The router act as the first line-of-defense against unauthorized access, DDoS, and other external threats. Access control lists (ACLs), uRPF, and other filtering mechanisms may be implemented for anti-spoofing and to block invalid packets. NetFlow, Syslog, and SNMP may be used to gain visibility on traffic flows, network activity, and system status. In addition, the Internet border router should be secured following the practices explained in Network Foundation Protection. This includes restricting and controlling administrative access, protecting the management and control planes, and securing the dynamic exchange of routing information.
Internet Border Router Deployment provides an example of Internet edge ACL. For more information on how to configure the Internet border router, refer to "Chapter 6, Enterprise Internet Edge" of the Cisco SAFE Reference Guide at: http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap6.html.
Internet Firewall Guidelines
The Cisco ASA deployed at the Internet perimeter is responsible for:
•
•
•
To that end, the security appliance is configured to enforce access policies, keep track of connection status, and inspect packet payloads following these guidelines:
•
•
•
•
•
•
•
•
Figure 4 illustrates the protocols and ports explicitly allowed by the Cisco ASA.
Figure 4 Allowed Protocols and Ports
Note
It is also important to remember that the Cisco ASA should be hardened following the best practices in Network Foundation Protection. This includes restricting and controlling administrative access, securing the dynamic exchange of routing information with MD5 authentication, and enabling firewall network telemetry with SNMP, Syslog, and NetFlow.
In the small enterprise network design, high availability may be achieved by using redundant physical interfaces. This represents the most cost-effective solution for high availability. As an alternative, a pair of firewall appliances could be deployed in stateful failover, as discussed in Internet Firewall Deployment.
Cisco ASA Botnet Traffic Filter
The Cisco ASA Botnet Traffic Filter feature can be enabled to monitor network ports for rogue activity and to prevent infected internal endpoints from sending command and control traffic back to an external host on the Internet. The Botnet Traffic Filter on the ASA provides reputation-based control for an IP address or domain name, similar to the control that Cisco IronPort SensorBase provides for E-mail and Web servers.
The Cisco Botnet Traffic Filter is integrated into all Cisco ASA appliances and inspects traffic traversing the appliance to detect rogue traffic in the network. When internal clients are infected with malware and attempt to phone home to an external host on the Internet, the Botnet Traffic Filter alerts the system administrator through the regular logging process and can be automatically blocked. This is an effective way to combat botnets and other malware that share the same phone-home communications pattern.
The Botnet Traffic Filter monitors all ports and performs a real-time lookup in its database of known botnet IP addresses and domain names. Based on this investigation, the Botnet Traffic Filter determines whether a connection attempt is benign and should be allowed or is a risk and should be blocked.
The Cisco ASA Botnet Traffic Filter has three main components:
•
•
•
The Botnet Traffic Filter uses two databases for known addresses. Both databases can be used together or the dynamic database can be disabled and the static database can be used alone. When using the dynamic database, the Botnet Traffic Filter receives periodic updates from the Cisco update server on the Cisco IronPort SensorBase network. This database lists thousands of known bad domain names and IP addresses.
Note
The Cisco ASA uses the dynamic database as follows:
1.
2.
3.
The database files are stored in running memory rather than Flash memory. The database can be deleted by disabling and purging the database through the configuration.
Note
In addition to the dynamic database, a static database can be used by manually entering domain names or IP addresses (host or subnet) that you want to tag as bad names in a blacklist. Static blacklist entries are always designated with a Very High threat level. Domain names or IP addresses can also be entered in a whitelist.
When a domain name is added to the static database, the Cisco ASA waits one minute and then sends a DNS request for that domain name and adds the domain name/IP address pairing to the DNS host cache. This action is a background process and does not affect your ability to continue configuring the Cisco ASA. Cisco also recommends that DNS packet inspection be enabled with Botnet Traffic Filter snooping. When enabled, the Cisco ASA uses Botnet Traffic Filter snooping instead of the regular DNS lookup to resolve static blacklist domain names in the following circumstances:
•
•
If DNS snooping is used, when an infected host sends a DNS request for a name on the static database, the Cisco ASA looks inside the DNS packets for the domain name and associated IP address and adds the name and IP address to the DNS reverse lookup cache.
If Botnet Traffic Filter snooping is not enabled and one of the above circumstances occurs, that traffic is not monitored by the Botnet Traffic Filter.
Note
For more information on the Cisco ASA Botnet Traffic Filter feature, see: http://www.cisco.com/en/US/prod/vpndevc/ps6032/ps6094/ps6120/botnet_index.html.
Intrusion Prevention Guidelines
IPS is responsible for identifying and blocking anomalous traffic and packets recognized as well-known attacks. An AIP SSM module on the Cisco ASA Internet firewall or a separate IPS appliance can be implemented in the Internet perimeter for enhanced threat detection and mitigation. IPS may also be configured to help block certain Internet applications such as AOL Messenger, BitTorrent, Skype, etc.
Integrating IPS on a Cisco ASA appliance using an AIP SSM provides a cost-effective solution for small enterprise networks. The AIP SSM is supported on Cisco ASA 5510 and higher platforms. The AIP SSM runs advanced IPS software providing proactive, full-featured intrusion prevention services to stop malicious traffic before it can affect the enterprise network.
The AIP SSM may be deployed in inline or promiscuous mode:
•
•
Figure 5 IPS Inline and Promiscuous Modes
The recommended IPS deployment mode depends on the goals and policies of the enterprise. IPS inline mode is more secure because of its ability to stop malicious traffic in real-time, however it may impact traffic throughput if not properly designed or sized. Conversely, IPS promiscuous mode has less impact on traffic throughput but is less secure because there may be a delay in reacting to the malicious traffic.
Although the AIP SSM runs as a separate application within the Cisco ASA, it is integrated into the traffic flow. The AIP SSM contains no external interfaces itself, except for the management interface on the SSM itself. When traffic is identified for IPS inspection on the ASA, traffic flows through the ASA and the AIP SSM in the following sequence:
1.
2.
3.
4.
5.
6.
7.
The AIP SSM card may be configured to fail open or close when the module becomes unavailable. When configured to fail open, the ASA allows all traffic through, uninspected, if the AIP SSM becomes unavailable. Conversely, when configured to fail close, the ASA blocks all traffic in case of an AIP SSM failure.
Cisco IPS Global Correlation
If desired, the AIP SSM module on the Cisco ASA (or IPS appliance) may participate in Cisco IPS Global Correlation for further threat visibility and control. Once enabled, the participating IPS sensor receives threat updates from the Cisco SensorBase Network at regular intervals. The Cisco SensorBase Network contains detailed information about known threats on the Internet, including serial attackers, botnet harvesters, malware outbreaks, and dark nets. The IPS uses this information to filter out the worst attackers before they have a chance to attack critical assets. It then incorporates the global threat data into its system to detect and prevent malicious activity even earlier.
IPS Global Correlation is an important improvement in the basic functions of IPS because it enables the system to understand the world in which it operates: an understanding of who the attacker is and whether the attacker has a record of bad behavior. With Global Correlation, the sensor does not have to rely on just the data in the packet or connection to make a decision about the intent of the activity and determine whether the activity is malicious. Now the sensor can look at a ping sweep and know that the source of the ping sweep does not have a negative reputation, but later can look at another ping sweep and see that the source is a known malicious site with a history of Web attacks and the sensor can block access to and from that site. Global Correlation gives users greater confidence in the actions the sensor takes because these actions are applied to attackers that have shown a predisposition for malicious behavior.
Global Correlation provides a process through which security data is collected for IP addresses and a reputation score is developed for each IP address globally by Cisco. Cisco IPS 7.0 uses this reputation data in two ways: for its reputation filters and for Global Correlation inspection.
•
•
Once Global Correlation is configured the IPS works in the following manner. When a packet enters the sensor, the first check is against the preprocessor, which performs Layer 2 packet normalization and atomic signature checks. Here the packet header is processed to help ensure that the packet is an IP packet, that the header is not incorrectly formed, and that the packet does not match any atomic signatures. Next, the packet is sent through the Cisco IPS reputation filters. Packets that match are discarded immediately, assuming that the reputation filters are enabled and not in Audit mode. Packets that do not match go to the inspection engines, starting with the Layer 3 and Layer 4 normalization engine, then all the signature engines, and then anomaly detection. If any events are triggered, alerts are sent to the Global Correlation inspection processor, where the source IP address for any alert is checked for negative reputation and the risk rating is modified and actions are added as appropriate. Finally, any actions assigned to alerts are processed and acted upon, including event action overrides to add new actions and event action filters to remove actions.
Reputation Filters
Cisco IPS reputation filters use a list of hundreds of networks that can be safely blocked because they are not owned by any legitimate source. The reputation of the networks on this list can be considered to be -10. This list includes only IP networks consisting entirely of stolen, "zombie" address blocks and address blocks controlled entirely by malicious organizations. Individual IP addresses are never found on this list. Because there is no way that a legitimate IP address can go from a positive or neutral reputation and then, because of malicious activity, earn a place on the Cisco IPS reputation filter list, users can confidently block all activity to and from networks on this list.
The primary purpose of the IPS reputation filters is to provide protection from direct scanning, botnet harvesting, spamming, and distributed denial-of-service (DDoS) attacks originating from these malicious address blocks and from connections being attempted back to these networks from systems already infected.
Note
The only user configuration required for reputation filters is enabling or disabling them and specifying whether Global Correlation is set to Audit mode (a global configuration setting for the entire sensor). In Audit mode, the sensor will report potential deny actions due to reputation filters instead of actually denying the activity.
Global Correlation Inspection
The primary activity of an IPS sensor is detection of malicious behavior. After the packet goes through the IPS reputation filter process, the signature inspection occurs. This involves inspection of packets flowing through the sensor by the various engines looking for the various types of malicious behavior. Alerts that are created are passed to the Global Correlation inspection process for reputation lookups.
When an event occurs, the Global Correlation inspection process performs a local lookup of the source (attacker) IP address of the event in its reputation database. This lookup process returns a value ranging from -.1 to -10; the more negative the value, the more negative the reputation of the source IP address. This reputation score is calculated for Cisco IPS sensors using the data in Cisco SensorBase and is sent to the sensor as a reputation update. If an IP address returns no value for reputation, than it is considered to be neutral. Cisco IPS, unlike E-mail and Web security reputation applications, has no concept of positive reputation. When an event is checked for reputation, this checking occurs entirely on the sensor using data downloaded previously from Cisco SensorBase. Unlike other devices, the sensor will not send a live request for information about an IP address that it has just seen. It will look in the data that it has, and if it finds the address, it will use that data; otherwise, the sensor will assume that the address has a neutral reputation.
Global Correlation inspection has three modes of primary operation: Permissive, Standard (default), and Aggressive; you can also select Off:
•
•
•
•
If Global Correlation inspection is enabled and an event is generated by an attacker with a negative reputation, the risk rating for the event will be elevated by a certain amount that is determined by a statistical formula. The amount by which the risk rating is raised depends on the original risk rating of the event and the reputation of the attacker.
Network Participation and Correlation Updates
The IPS sensor pulls reputation information for addresses on the global Internet from Cisco SensorBase. When the sensor is configured initially, a DNS server needs to be configured for the sensor to use to connect to Cisco SensorBase or an HTTP or HTTPS proxy (that has DNS configured) needs to be configured. After the sensor has this information, the sensor will make an outbound connection to check for the latest updates from Cisco SensorBase. It will initiate an HTTPS request to Cisco SensorBase update servers and download a manifest that contains the latest versions of the files related to Global Correlation. The sensor will check Cisco SensorBase every five minutes for updates. If changes are needed, the sensor will perform a DNS lookup of the server name returned in the initial request. This lookup will return the location of the server nearest to the sensor. The sensor will then initiates an HTTP connection that will actually transfer the data. The size of a full update is about 2 MB; incremental updates average about 100 KB. If a sensor loses connection to Cisco SensorBase, Global Correlation information will begin to time out within days and sensor health will change accordingly.
The other component of Global Correlation is network participation. This feature sends data from events that the sensor fires back to Cisco SensorBase to adjust the reputation of IP addresses; this information is then packaged in future reputation data downloads from Cisco SensorBase. The sensor passes this information back to Cisco SensorBase according to the sensor configuration. The possible configuration options are Off, Partial, and Full.
•
•
•
Note
The mechanism used to update Cisco SensorBase with new attack information is fairly straightforward. The sensor takes event information, parses out the important pieces of data, and buffers this data for transmission back to Cisco SensorBase. It sends this data in the form of an HTTPS connection that it initiates on average every 10 minutes. The average size of an update is 2 to 4 KB, with weekly averages of about 0.5 to 1 MB. Some higher-volume sensors have average update sizes of about 50 KB, with weekly totals in the 45-MB range. Sensors with very high alert volumes can have average update sizes of about 850 KB, with weekly totals of up to 900 MB; these sensors, though, are at the extreme end of the range.
For more information on IPS Global Correlation including configuration information, see: http://www.cisco.com/en/US/docs/security/ips/7.0/configuration/guide/cli/cli_collaboration.html.
E-mail Security Guidelines
The small enterprise network design implements a Cisco IronPort C Series E-mail Security Appliance (ESA) at the DMZ to inspect E-mails and eliminate threats such as E-mail spam, viruses, and worms. The ESA can be described as a firewall and threat monitoring system for Simple Mail Transfer Protocol (SMTP) traffic (TCP port 25). Logically speaking, the ESA acts as a Mail Transfer Agent (MTA) within the E-mail delivery chain, as illustrated in Figure 6. Upon reception, E-mails are evaluated using a reputation score mechanism based on the SensorBase network. The SensorBase network is an extensive network that monitors global E-mail and Web traffic for anomalies, viruses, malware, and other abnormal behavior. The network is composed of Cisco IronPort appliances, Cisco ASA, and Cisco IPS appliances and modules installed in more than 100,000 organizations worldwide, providing a large and diverse sample of Internet traffic patterns. By leveraging the SensorBase Network, messages originating from domain names or servers known to be the source of spam or malware, and therefore with a low reputation score, are automatically dropped or quarantined by preconfigured reputation filters. Optionally, the enterprise may choose to implement some of the other functions offered by the ESA appliance, including anti-virus protection with virus outbreak filters and embedded anti-virus engines (Sophos and McAfee), encryption to ensure the confidentiality of messages, and data loss prevention (DLP) for E-mail to detect the inappropriate transport of sensitive information.
Note
Figure 6 E-mail Delivery Chain
Note
There are multiple deployment approaches for the security appliance depending on the number of interfaces used (see Figure 7):
•
•
For simplicity, the small enterprise network design implements the ESA appliance with a single interface. In addition, using a single interface leaves other data interfaces available for redundancy.
Figure 7 Common ESA Deployments
Figure 8 illustrates the logical location of the ESA within the E-mail flow chain.
Figure 8 Typical Data Flow for Inbound E-mail Traffic
The following steps explain what is taking place in Figure 8:
1.
2.
3.
4.
5.
6.
7.
8.
9.
The Cisco IronPort ESA appliance functions as a SMTP gateway, also known as a mail exchange (MX). Key deployment guidelines include:
•
•
•
•
•
•
A failure on the ESA appliance may cause service outage, therefore a redundant design is recommended. There are multiple ways to implement redundancy:
•
•
•
IronPort NIC pairing is the most cost-effective solution (see Figure 9), because it does not require the implementation of multiple ESA appliances and other hardware. It does not, however, provide redundancy in case of chassis failure.
Figure 9 Cisco IronPort ESA NIC pairing
Finally, the Internet firewall should be configured to accommodate traffic to and from the Cisco IronPort ESA deployed at the DMZ. The protocols and ports to be allowed vary depending on the services configured on the appliance. For details, refer to the Cisco IronPort User's Guide at: http://www.ironport.com/support/.
The following are some of the most common services required:
•
•
•
•
•
•
Also remember that if the ESA is managed in-band, appropriate firewall rules need to be configured to allow traffic such as SSH, NTP, and syslog.
For more information on how to configure the Cisco Ironport ESA, see:
•
•
Web Security Guidelines
The small enterprise network design implements a Cisco IronPort S Series Web Security Appliance (WSA) to block access to sites with non-business related content and to protect the enterprise from Web-based malware and spyware.
Cisco IronPort WSA's protection relies on two independent services:
•
•
Note
As the small enterprise network design assumes a centralized Internet connection, the WSA is implemented at the core/distribution layer of the main site network. This allows the inspection and enforcement of Web access policies to all users residing at any of the enterprise locations. Logically, the WSA sits in the path between Web users and the Internet, as shown in Figure 10.
Figure 10 Cisco IronPort WSA
There are two deployment modes for the Web Proxy service:
•
•
Explicit forward proxy mode requires the enterprise to have control over the configuration of the endpoints, which may not be always possible. For example, the enterprise may allow the use of personal laptops, smart-phones, and other devices outside the company's administration. Transparent proxy mode, on the other hand, provides a transparent integration of WSA without requiring any configuration control over the endpoints. It also eliminates the possibility of users reconfiguring their Web browsers to bypass the appliance without knowledge of the administrators. For these reasons, the small enterprise network design implements transparent proxy with WCCP. In this configuration, the Cisco ASA at the Internet perimeter is leveraged as a WCCP server while the WSA act as a WCCP Traffic Processing Entity.
The Cisco ASA uses WCCP version 2, which has a built-in failover and load balancing mechanism. Per WCCPv2 specification, multiple appliances (up to 32 entities) can be configured as part of the same service group. HTTP and HTTPS traffic is load-balanced across the active appliances based on source and destination IP addresses. The server (Cisco ASA) monitors the availability of each appliance in the group and can identify appliance failures within 30 seconds. After failure, traffic is redirected across the remaining active appliances. In the case where no appliances are active, WCCP takes the entire service group offline and subsequent requests bypass redirection. In addition, WCCPv2 supports MD5 authentication for the communications between WCCP server and WSA appliances.
Note
WCCPv2 supports Generic Route Encapsulation (GRE) and Layer 2-based redirection; however, the Cisco ASA only supports GRE. In addition, WCCP is supported only on the ingress of an interface. The only topology supported is one where both clients and WSA are reachable from the same interface and where the WSA can directly communicate with the clients without going through the Cisco ASA. For these reasons, the WSA appliance is deployed at the inside segment of the Cisco ASA.
Figure 11 illustrates the how WCCP redirection works in conjunction with Cisco ASA.
Figure 11 WCCP Redirection
The following steps describe what takes place in Figure 11:
1.
2.
3.
4.
5.
The WSA appliance may also be configured to control and block peer-to-peer file-sharing and Internet applications such as AOL Messenger, BitTorrent, Skype, Kazaa, etc. The way WSA handles these applications depends on the TCP port used for transport:
•
•
Note
The following are the guidelines for implementing a Cisco IronPort WSA appliance with WCCP on a Cisco ASA:
•
•
•
•
•
•
•
•
•
Note
The Layer 4 Traffic Monitor (L4TM) service is deployed independently from the Web Proxy functionality and its mission is to monitor network traffic for rogue activity and for any attempts to bypass port 80. L4TM works by listening to all UDP and TCP traffic and by matching domain names and IP addresses against entries in its own database tables to determine whether to allow incoming and outgoing traffic. The L4TM internal database is continuously updated with matched results for IP addresses and domain names. Additionally, the database table receives periodic updates from the IronPort update server (https://update-manifests.ironport.com).
For more information on how to configure the L4TM feature on Cisco Ironport WSA, see:
•
•
Configuration steps and examples are included in "Appendix D-Web Security Deployment" section of the document.
Serverfarm Protection
Small enterprise networks typically include a serverfarm at the main site that hosts the systems that serve business applications and store the data accessible to internal users. The infrastructure supporting it may include application servers, the storage media, routers, switches, load balancers, off-loaders, application acceleration devices, and other systems. In addition, they may also host foundational services as part of the enterprise network such as identity and security services, unified communication services, mobility services, video services, partner applications, and other services.
Depending on the size of the enterprise network, the serverfarm may be constructed following different design models. Figure 12 illustrates a collapsed design, and the less common for small enterprise networks, multi-tier design. In the collapsed design all services are hosted in a shared physical serverfarm and high availability is achieved by using redundant processors and interfaces. Large enterprises may implement a more scalable multi-tier design data center with chassis redundancy.
Figure 12 Serverfarm Designs
Independently from the design model adopted by the enterprise, the following are the primary security guidelines for the serverfarm design:
•
•
•
•
•
•
Figure 13 Service Isolation
SSL termination and inspection, Web Application Firewall (WAF), Application Control Engine (ACE), and other solutions may be leveraged to complement the guidelines described above. For a more detailed discussion of serverfarm security, refer to "Chapter 4, Intranet Data Center" of the Cisco SAFE Reference Guide at: http://www.cisco.com/en/US/docs/solutions/Enterprise/Security/SAFE_RG/chap4.html.
Network Access Security and Control
Some of the most vulnerable points of the network are the access edges where users connect to the network. With the proliferation of wireless networks, increased use of laptops and smart mobile devices, the enterprise cannot simply rely on physical controls hoping to prevent unauthorized systems from being plugged into the ports of the access switches. Protection should rather be embedded into the network infrastructure, leveraging the native security features available in switches, routers, and WLAN systems. Furthermore, the network infrastructure should also provide dynamic identity or role-based access controls for all systems attempting to gain access.
Implementing role-based access controls for users and devices helps reduce the potential loss of sensitive information by enabling enterprises to verify a user or device identity, privilege level, and security policy compliance before granting network access. Security policy compliance could consist of requiring antivirus software, OS updates, or patches. Unauthorized or noncompliant devices can be placed in a quarantine area where remediation can occur prior to gaining access to the network.
Access security and control is implemented in the small enterprise network design by leveraging the following technologies:
•
•
•
•
Catalyst Integrated Security Features
Catalyst Integrated Security Features (CISF) is a set of native security features available on Cisco Catalyst Switches and designed to protect the access infrastructure and users from spoofing, man-in-the-middle, DoS, and other network-based attacks. CISF includes features such as private VLANs, port security, DHCP snooping, IP Source Guard, secure Address Resolution Protocol (ARP) detection, and Dynamic ARP Inspection (DAI). CISF features are considered to be part of a security baseline and should be deployed on all access ports.
•
•
•
•
•
•
Cisco Unified Wireless Network (CUWN) Integrated Security Features
The Cisco Unified Wireless Network adds to the 802.11 security standards by providing additional security features. Some of these are the WLAN equivalent of CiSF features, such as Dynamic Host Configuration Protocol (DHCP) and Address Resolution Protocol (ARP) protection, peer-to-peer blocking, and access control list and firewall features. Additionally other more WLAN-specific features are provided, including Enhanced WLAN security options, wireless intrusion detection system (IDS), client exclusion, rogue AP detection, management frame protection, dynamic radio frequency management, and network IDS integration.
The Cisco Unified Wireless Network solutions are discussed in the Wireless and Network Security Integration Solution Design Guide at: http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns820/landing_sec_wireless.html.
Cisco NAC Appliance
Cisco Network Admission Control (NAC) Appliance (formerly known as Cisco Clean Access) uses the network infrastructure to enforce security policy compliance on all devices seeking to access network computing resources. With Cisco NAC Appliance, network administrators can authenticate, authorize, evaluate, and remediate wired, wireless, and remote users and their machines before network access. The NAC Appliance identifies whether networked devices such as laptops, IP phones, or game consoles are compliant with your network security policies and can repair any vulnerability before permitting access to the network.
When deployed, the Cisco NAC Appliance provides the following benefits:
•
•
•
•
The NAC solution provides the following four functions, as shown in Figure 14:
•
•
•
•
Figure 14 The Four Functions of the NAC Framework
For more details of the NAC Appliance Solution, see: http://www.cisco.com/go/nacappliance.
Cisco NAC Appliance is a network-centric integrated solution administered from the Cisco Clean Access Manager (NAC Manager) Web console and enforced through the Clean Access Server (NAC Server) and (optionally) the Clean Access Agent or Cisco NAC Web Agent. Cisco NAC Appliance checks client systems, enforces network requirements, distributes patches and antivirus software, and quarantines vulnerable or infected clients for remediation before clients access the network. Cisco NAC Appliance consists of the components shown in Figure 15.
Figure 15 NAC Appliance Components
Clean Access Manager (CAM)
The Cisco CAM (a.k.a NAC Manager) is the administration server for Clean Access deployment. The secure Web console of the Clean Access Manager is the single point of management for up to 20 Clean Access Servers in a deployment (or 40 CASs if installing a SuperCAM). For Out-of-Band (OOB) deployment, the Web admin console allows you to control switches and VLAN assignment of user ports through the use of SNMP. In the small enterprise network design the CAM would be located at the main site.
Clean Access Server (CAS)
The Cisco CAS (a.k.a NAC Server) is the enforcement server between the untrusted (managed) network and the trusted network. The CAS enforces the policies you have defined in the CAM Web admin console, including network access privileges, authentication requirements, bandwidth restrictions, and Clean Access system requirements. You can install a CAS as either a standalone appliance (like the Cisco NAC-3300 Series) or as a network module (Cisco NME-NAC-K9) in a Cisco ISR chassis and deploy it in-band (always inline with user traffic) or OOB (inline with user traffic only during authentication/posture assessment).
The CAS can also be deployed in Layer 2 mode (users are Layer 2 adjacent to the CAS) or Layer 3 mode (users are multiple Layer 3 hops away from the CAS). You can also deploy several CASs of varying size/capacity to fit the needs of varying network segments. You can install Cisco NAC-3300 Series appliances in your company headquarters core, for example, to handle thousands of users and simultaneously install one or more Cisco NAC network modules in ISR platforms to accommodate smaller groups of users at a satellite office.
In the small enterprise network design, the CAS would be located at the main site and the remote locations and it would be used to provide Layer 2 or Layer 3 OOB authentication/posture assessment.
Clean Access Agent (CAA)
CAA is an optional read-only agent that resides on Windows clients. It checks applications, files, services, or registry keys to ensure that clients meet your specified network and software requirements prior to gaining access to the network.
Note
If NAC is implemented as part of the small enterprise network design, it is recommended that the CAA be used.
Cisco NAC Web Agent
The Cisco NAC Web Agent provides temporal posture assessment for client machines. Users launch the Cisco NAC Web Agent executable, which installs the Web Agent files in a temporary directory on the client machine via ActiveX control or Java applet. When the user terminates the Web Agent session, the Web Agent logs the user off of the network and their user ID disappears from the Online Users list.
Clean Access Policy Updates
Regular updates of prepackaged policies/rules that can be used to check the up-to-date status of operating systems, antivirus (AV), antispyware (AS), and other client software. It also provides built-in support for 24 AV vendors and 17 AS vendors.
NAC Appliance Modes and Positioning
NAC Appliance allows multiple deployment options and may be placed at different points in the network. The modes of operation can be generally defined as:
•
•
•
•
Out-of-Band Modes
Out-of-Band (OOB) deployments require user traffic to traverse through the NAC Appliance only during authentication, posture assessment, and remediation. When a user is authenticated and passes all policy checks, their traffic is switched normally through the network and bypasses the appliance. See Figure 16.
Figure 16 Layer 2 OOB Topology
To deploy the NAC Appliance in this manner, the client device must be directly connected to the network via a Catalyst switch port. After the user is authenticated and passes posture assessment, the Clean Access Manager (CAM) instructs the switch to map the user port from an unauthenticated VLAN (which switches or routes user traffic to the NAC) to an authenticated (authorized) VLAN that offers full access privileges. For example, as shown Figure 16, the client PC is connected through VLAN 110 to the NAC Clean Access Server for the authentication and posture assessment and is moved to VLAN 10 once it successfully completes the authentication and authorization, scan, and evaluation phases of the NAC solution.
In-Band Modes
When the NAC Appliance is deployed in-band, all user traffic, both unauthenticated and authenticated, passes through the NAC Appliance, which may be positioned logically or physically between end users and the network(s) being protected. See in-band virtual gateway topology (Figure 17) for a logical in-band topology example and physical in-band topology (Figure 18) for a physical in-band topology example.
Figure 17 In-Band Virtual Gateway Topology
Figure 18 Physical In-Band Topology
In-Band Virtual Gateway
When the NAC Appliance is configured as a virtual gateway, it acts as a bridge between end users and the default gateway (router) for the client subnet being managed. The following two bridging options are supported by the NAC Appliance:
•
•
The VLAN mapping option is usually selected when the NAC Appliance is positioned logically in-band between clients and the networks being protected. This is the bridging option that should be used if the NAC Appliance is going to be deployed in the virtual gateway mode.
In-Band Real IP Gateway
When the NAC Appliance is configured as a "real" IP gateway, it behaves like a router and forwards packets between its interfaces. In this scenario, one or more client VLAN/subnets reside behind the untrusted interface. The NAC Appliance acts as a default gateway for all clients residing on those networks. Conversely, a single VLAN/subnet is defined on the trusted interface, which represents the path to the protected upstream network(s).
After successful client authentication and posture assessment, the NAC Appliance by default routes traffic from the untrusted networks to the trusted interface, where it is then forwarded based on the routing topology of the network.
The NAC Appliance is not currently able to support dynamic routing protocols. As such, static routes must be configured within the trusted side of the Layer 3 network for each client subnet terminating on or residing behind the untrusted interface. These static routes should reference, as a next hop, the IP address of the trusted interface of the NAC.
If one or more Layer 3 hops exist between the untrusted NAC interface and the end-client subnets, static routes to the client networks must be configured in the NAC Appliance. Likewise, a static default route (0/0) is required within the downstream Layer 3 network (referencing the IP address of the untrusted NAC interface) to facilitate default routing behavior from the client networks to the NAC Appliance.
Depending on the topology, multiple options exist to facilitate routing to and from the NAC Appliance, including static routes, VRF-Lite, MPLS VPN, and other segmentation techniques. It is beyond the scope of this document to examine all possible methods.
In-Band Versus Out-of-Band
Table 1 summarizes different characteristics of each type of deployment.
Out-of-Band Requirements
OOB implementation of Cisco NAC Appliance requires the switches and Wireless LAN Controllers to be supported by the Cisco NAC Appliance software. All the switches tested as part of the development of the Enterprise Design Profile for Small Enterprise Networks, apart from the Cisco Catalyst 2975, are supported by the Cisco NAC OOB and the Wireless LAN Controllers are also supported by the NAC Appliance software used in this document. If the Catalyst 2975 is to be used as an access switch with the Cisco NAC Appliance, the NAC solution must be an in-band solution.
Note
Out-Of-Band, Layer 2, and Layer 3
The proposed design for the small enterprise network is an OOB design, in order to get the highest possible performance and scalability for traffic that has passed through the authentication, posture assessment, and remediation stages of NAC. The small enterprise network design offers two different access layer options, a Layer 2 access layer for smaller sites and a hybrid Layer 2/Layer 3 access layer for larger sites. This means that either a Layer 2 OOB solution or a Layer 3 OOB NAC solution may be deployed.
NAC Appliance Deployment in Small Enterprise Networks
In the small enterprise network design, various components of the NAC Appliance solution are deployed throughout all locations, including the main site and each of the remote sites. More precisely, a centralized CAM is deployed at the main site, likely residing at the serverfarm, while a CAS is deployed at the main site and each remote site. Each CAS is connected directly to the core/distribution layer at each of those locations.
For simplicity, the Small Enterprise Network design uses the same design principles for all locations, providing a common NAC configuration that works regardless of whether the sites use a Layer 2 or Layer 3 access model. This common configuration consists in the use of an untrusted VLAN that extends from the access layer all the way to the untrusted interface of the CAS appliance. This requires the configuration of a trunk between the access switch and the core/distribution layer carrying a pair of VLANs. One VLAN of the trunk is the untrusted VLAN, used for authentication and posture assessment, and the second VLAN is the trusted VLAN used to carry all traffic once the client is properly authenticated and authorized. The link between the access switch and the core/distribution layer is configured as a trunk, regardless of whether the sites use a Layer 2 or Laye 3 access model.
This is illustrated in Figure 19 and Figure 20. In Figure 19, there is a simple Layer 2 NAC OOB connection where a client device upon initial connection to the network is given VLAN 264, which connects them directly to the untrusted interface of the NAS. VLAN 264 on the untrusted interface is mapped to VLAN 64 on the trusted interface within the NAC appliance, which allows the client to obtain an IP address that belongs on VLAN 64. Upon successful completion of the NAC authentication and validation functions, the access switch is instructed, via SNMP from the CAM, to change the client VLAN to VLAN 64. Even though the client has changed Layer 2 VLANs, its Layer 3 network connections are unchanged and the traffic from the client no longer passes through the NAC appliance.
Figure 19 Layer 2 OOB Topology
In Figure 20, the same processes are followed when the client is untrusted, but once the client has successfully completed its NAC functions, the access switch is instructed via SNMP to change the client VLAN to VLAN 67—a subnet local to the access switch. As the Layer 3 information for the client has changed, the switch is also instructed to "bounce" the client switch port to initiate a new DHCP request for an IP address appropriate to VLAN 67.
Figure 20 Layer 3 OOB Topology
Cisco Identity-Based Network Networking Services (IBNS)
The best and most secure solution to vulnerability at the access edge is to leverage the intelligence of the network. The Cisco Identity-Based Network Networking Services solution (IBNS) is a set of Cisco IOS software services designed to enable secure user and host access to enterprise networks powered by Cisco Catalyst switches and wireless LANs. It provides standards-based network access control at the access layer by using the 802.1X protocol to secure the physical ports where end users connect. 802.1X is an IEEE standard for media-level (Layer 2) access control, offering the capability to permit or deny network connectivity based on the identity of the end user or device. 802.1X is well-known as a way to secure wireless network access. It is equally essential in securing wired network access.
IEEE 802.1X Protocol
The IEEE 802.1X protocol allows Cisco Catalyst switches to offer network access control at the port level. Every port on the switch is individually enabled or disabled based on the identity of the user or device connecting to it. When 802.1X is first enabled on a port, the switch automatically drops all traffic received on that port. There is one exception to this rule. The only traffic a switch will accept is a request to start 802.1X authentication. Only after the 802.1X authentication has successfully completed will the switch accept any other kind of traffic on the port.
The high-level message exchange in Figure 21 illustrates how port-based access control works within an identity-based system.
Figure 21 Port-Based Access Control
The following steps describe the port-based access control flow shown in Figure 21:
1.
2.
3.
4.
5.
6.
7.
The user and device credentials are processed by an AAA server. The AAA server is able to reference user or device policy profile information either internally, using the integrated user database, or externally, using database sources such as Microsoft Active Directory, LDAP, Novell NDS, or Oracle databases. This enables the integration of the system into exiting user management structures and schemes, thereby simplifying overall deployment.
802.1X and EAP
When authenticating users for the purposes of network access control, the system must provide user and/or device identification using strong authentication technologies known to be secure and reliable. IEEE 802.1X does not by itself dictate how this is achieved. Rather, the 802.1X protocol defines an encapsulation for the transport of the Extensible Authentication Protocol (EAP) from the client to the switch. The 802.1X encapsulation is sometimes referred to as EAP over LAN (EAPoL). The switch in turn relays the EAP information to the authentication server using the RADIUS protocol (EAP over RADIUS).
EAP, which is defined by RFC 3748, is itself a framework and not a specific authentication method. EAP provides a way for the client and the authentication server to negotiate an authentication method that they both support. There are many EAP methods but the ones used more frequently for 802.1X wired authentication include EAP-TLS, EAP-PEAP, and EAP-FAST.
Impacts of 802.1X on the Network
Before enabling 802.1X in the network, it is essential to review the default security posture of a port enabled for 802.1X authentication: all traffic is dropped except 802.1X EAPoL packets. This is a fundamental change from the traditional model in which the port is enabled and all traffic is allowed from the moment that a device plugs into the port. Ports that were traditionally open will now be closed by default. This is one of the cornerstones of the strong security and network access control provided by 802.1X. However, this change in the default network access model can have a profound impact on network devices and applications. Understanding and providing for the impacts of this change will make for a smooth deployment of 802.1X network access control.
Non-802.1X-Enabled Devices
802.1X must be enabled on both the host device and on the switch to which the device connects. If a device without an 802.1X supplicant attempts to connect to a port that is enabled for 802.1X, it will be subjected to the default security policy. The default security policy says that 802.1X authentication must succeed before access to the network is granted. Therefore, by default, non-802.1X-capable devices cannot get access to an 802.1X-protected network.
Although many devices increasingly support 802.1X, there will always be devices that require network connectivity but do not and/or cannot support 802.1X. Examples of such devices include network printers, badge readers, legacy servers, and PXE boot machines. Some provision must be made for these devices.
Cisco provides two features to accommodate non-802.1X devices, MAC Authentication Bypass (MAB) and the Guest VLAN. These features provide fallback mechanisms when there is no 802.1X supplicant. After 802.1X times out on a port, the port can move to an open state if MAB succeeds or if the Guest VLAN is configured. Judicious application of either or both of these features will be required for a successful 802.1X deployment.
Note
802.1X in Small Enterprise Networks
As mentioned above, one of the requirements for 802.1X authentication is the requirement for a supplicant. This has typically been a challenge in enterprise environments with a wide range of devices and limited or no management of many of these devices. In many enterprises this is still the case and this makes a company-wide 802.1X very challenging. At the same time there are pockets of an enterprise network where 802.1X may be a good choice.
For example, 802.1X-protected ports may be a good choice for the network ports in the company's headquarters or main site, as these locations are more likely to have managed PCs.
Other locations in the enterprise network still need protection, but user network access may be better served by a NAC Appliance solution. For networks requiring role-based access control using posture assessments to ensure security compliance, Cisco NAC Appliance should be considered. In addition, network access ports in open areas such as lobbies and meeting rooms may use 802.1X or Cisco Clean Access NAC to protect these ports.
When considering the 802.1X deployment, there are four main 802.1X authentication options to consider.
•
•
•
•
For more information on the Cisco IBNS 802.1X network access solution, see: http://www.cisco.com/go/ibns.
NAC 802.1X and CISF in Combination
The three key access security features discussed above have been discussed in isolation, but can be combined. In particular, the CISF features should be considered "baseline" features that are applied on all access ports and either NAC or 802.1X maybe overlaid on top of the CISF configuration.
The Cisco Clean Access and 802.1X configuration are also compatible (although they are not often combined in wired networks), the key consideration in combining the two is how to give the appearance of a SSO for the end user. Both 802.1X and NAC require authentication, as 802.1X authenticates the client initially, a mechanism of communicating the 802.1X authentication result to the Cisco Clean Access system is required.
If the authenticating clients join an Windows Active Directory network, the Cisco Clean Access Active Directory SSO feature allows the clients to authenticate to active directory once they have performed their 802.1X authentication. The CAM, when a client is detected, checks Active Directory to see if the client has authenticated, which allows a SSO experience for client devices that are using 802.1X and NAC.
Secure Mobility
Today workers use laptops, smartphones, and other smart mobile devices to access information and applications at anytime and from anywhere there is an Internet connection. While embracing a mobile workforce clearly boosts productivity and makes the small enterprise more competitive, there are a number of challenges that arise from the use of mobile technologies. To start with, workers often use the same devices to access both business and personal information. Devices used outside the enterprise onsite controls may potentially introduce viruses, worms, spyware, and other type of malware as mobile workers connect back to the corporate network. Confidential and proprietary information may also be lost or stolen while mobile users connect outside the company premises.
On the other hand, the great variety in hardware types, operating systems, and applications represents a clear challenge to the enforcement of security controls and policies. In order to continue to foster innovation, enable productivity, and meet the needs of the mobile workforce, companies must adapt to the changing trends in mobility. A viable solution is one that enables access for mobile workers while ensuring that the corporate data, assets, and network remain secure. On the other hand, users want the flexibility of choosing how, when, and where to access both personal and professional information to be productive, without being inconvenienced by security checks.
The small enterprise network design provides persistent and secure mobile access by implementing the Cisco AnyConnect Secure Mobility solution. This solution delivers secure, persistent connectivity to all mobile employees independently from the type of mobile device used. The Cisco AnyConnect Secure Mobility solution also ensures a consistent enforcement of the network security policies to all users, no matter when, where, and how they connect to the network.
The Cisco AnyConnect Secure Mobility is a collection of features across multiple Cisco products that extends control and security into borderless networks. The products that work together to provide AnyConnect Secure Mobility are:
•
•
•
Cisco AnyConnect Secure Mobility addresses the challenges of a mobile workforce by offering the following features:
•
•
Figure 22 Cisco AnyConnect Secure Mobility Solution
Figure 22 illustrates the relationship between the various elements of the Cisco AnyConnect Secure Mobility solution. Remote and mobile users use the Cisco AnyConnect Secure VPN client to establish VPN sessions with the Cisco ASA appliance. The Cisco ASA sends Web traffic to the WSA appliance along with information identifying the user by IP address and user name. The WSA scans the traffic, enforces acceptable use policies, and protects the user from security threats. The Cisco ASA returns all traffic deemed safe and acceptable to the user.
All Internet traffic scanning is done by the WSA, not the client on the mobile device. This improves overall performance by not burdening the mobile device, some of which have limited processing power. In addition, by scanning Internet traffic on the network, the enterprise can more easily and quickly update security updates and acceptable use policies since the enterprise does not have to wait days, weeks, or even months to push the updates to the client. The WSA tracks the requests it receives and applies policies configured for remote users to traffic received from remote users.
For complete details about the Cisco AnyConnect Secure Mobility solution, refer to the documentation available at: http://www.cisco.com/en/US/netsol/ns1049/index.html.
Threats Mitigated
The success of the security tools and measures in place ultimately depends on the degree they enhance visibility and control. Simply put, security can be defined as a function of visibility and control. Without any visibility, it is difficult to enforce any control, and without any control, it is hard to achieve an adequate level of security. Therefore, the security tools selected in the enterprise network design were carefully chosen not only to mitigate certain threats, but also to increase the overall visibility and control.
Table 2 summarizes how the security tools and measures used in the small enterprise network design help mitigate certain threats and how they contribute to increasing visibility and control. Note the table is provided for illustration purposes and it is not intended to include all possible security tools and threats.
Network Security Deployment
This section of the document describes the deployment best practices for the key security platforms and features used in the small enterprise network design, including deployment and setting guidelines and configuration examples.
Internet Border Router Deployment
Whether the Internet border router is managed by the enterprise or the ISP, it must be hardened following the best practices listed in Network Foundation Protection. This includes restricting and controlling administrative access, protecting the management and control planes, and securing the dynamic exchange of routing information. In addition, the Internet border router may be leveraged as the first layer of protection against outside threats. To that end, edge ACLs, uRPF, and other filtering mechanisms may be implemented for anti-spoofing and to block invalid packets.
The following configuration snippet illustrates the structure of an edge ACL applied to the upstream interface of the Internet border router. The ACL is designed to block invalid packets and to protect the infrastructure IP addresses from the Internet. The configuration assumes the enterprise is assigned the 198.133.219.0/24 address block for its public-facing services and that the upstream link is configured in the 64.104.10.0/24 subnet.
! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- Module 1: Anti-spoofing Denies!--- These ACEs deny fragments, RFC 1918 space,!--- invalid source addresses, and spoofs of!--- internal space (space as an external source).!!--- Deny fragments.access-list 110 deny tcp any 198.133.219.0 0.0.0.255 fragmentsaccess-list 110 deny udp any 198.133.219.0 0.0.0.255 fragmentsaccess-list 110 deny icmp any 198.133.219.0 0.0.0.255 fragments!--- Deny special-use address sources.!--- See RFC 3330 for additional special-use addresses.access-list 110 deny ip host 0.0.0.0 anyaccess-list 110 deny ip 127.0.0.0 0.255.255.255 anyaccess-list 110 deny ip 192.0.2.0 0.0.0.255 anyaccess-list 110 deny ip 224.0.0.0 31.255.255.255 any!--- Filter RFC 1918 space.access-list 110 deny ip 10.0.0.0 0.255.255.255 anyaccess-list 110 deny ip 172.16.0.0 0.15.255.255 anyaccess-list 110 deny ip 192.168.0.0 0.0.255.255 any!--- Deny packets spoofing the enterprise public addressesaccess-list 110 deny ip 198.133.219.0 0.0.0.255 any!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- Module 2: Explicit Permit!--- Permit only applications/protocols whose destination!--- address is part of the infrastructure IP block.!--- The source of the traffic should be known and authorized.!!--- Permit external BGP to peer 64.104.10.113access-list 110 permit tcp host 64.104.10.114 host 64.104.10.113 eq bgpaccess-list 110 permit tcp host 64.104.10.114 eq bgp host 64.104.10.113!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- Module 3: Explicit Deny to Protect Infrastructureaccess-list 110 deny ip 64.104.10.0 0.0.0.255 any!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!--- Module 4: Explicit Permit for Traffic to Company's Public!--- Subnet.access-list 110 permit ip any 198.133.219.0 0.0.0.255!
Note
Internet Firewall Deployment
The mission of the Internet firewall is to protect the company's internal resources and data from external threats, secure the public services provided by the DMZ, and to control users' traffic to the Internet. The small enterprise network design uses a Cisco ASA appliance as illustrated in Figure 23.
Figure 23 Internet Edge Firewall
The Cisco ASA is implemented with three interface groups, each one representing a distinct security domain:
•
•
•
The Internet firewall acts as the primary gateway to the Internet; therefore, its deployment should be carefully planned. The following are key aspects to be considered when implementing the firewall:
•
•
•
•
•
•
Firewall Hardening and Monitoring
The Cisco ASA should be hardened in a similar fashion as the infrastructure routers and switches. According to the Cisco SAFE security best practices, the following is a summary of the measures to be taken:
•
•
•
•
•
•
•
•
The Cisco ASA 5510 and higher appliance models come with a dedicated management interface that should be used whenever possible. Using a dedicated management interface keeps the management plane of the firewall isolated from threats originating from the data plane. The management interface should connect to the OOB management network, if one is available.
The following is an example of the configuration of a dedicated management interface.
interface Management0/0nameif managementsecurity-level 100ip address 172.26.160.225 255.255.252.0management-only!
Note
It is recommended that a legal notification banner is presented on all interactive sessions to ensure that users are notified of the security policy being enforced and to which they are subject. The notification banner should be written in consultation with your legal advisors.
The following example displays the banner after the user logs in:
banner motd UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED.banner motd You must have explicit, authorized permission to access or configure this device.banner motd Unauthorized attempts and actions to access or use this system may result in civil and/or criminal penalties.banner motd All activities performed on this device are logged and monitored.Management access to the firewall should be restricted to SSH and HTTPS. SSH is needed for CLI access and HTTPS is needed for the firewall GUI-based management tools such as CSM and ADSM. Additionally, this access should only be permitted for users authorized to access the firewalls for management purposes.
The following ASA configuration fragment illustrates the configuration needed to generate a 768 RSA key pair and enabling SSH and HTTPS access for devices located in the management subnet.
! Generate RSA key pair with a key modulus of 768 bitscrypto key generate rsa modulus 768! Save the RSA keys to persistent flash memorywrite memory! enable HTTPShttp server enable! restrict HTTPS access to the firewall to permitted management stationshttp <CSM/ADSM-IP-address> 255.255.255.255 management! restrict SSH access to the firewall to well-known administrative systemsssh <admin-host-IP-address> 255.255.255.255 management! Configure a timeout value for SSH access to 5 minutesssh timeout 5Administrative users accessing the firewalls for management must be authenticated, authorized, and access should be logged using AAA. The following ASA configuration fragment illustrates the AAA configurations needed to authenticate, authorize, and log user access to the firewall:
aaa-server tacacs-servers protocol tacacs+reactivation-mode timedaaa-server tacacs-servers host <ACS-Server>key <secure-key>aaa authentication ssh console tacacs-servers LOCALaaa authentication serial console tacacs-servers LOCALaaa authentication enable console tacacs-servers LOCALaaa authentication http console tacacs-servers LOCALaaa authorization command tacacs-servers LOCALaaa accounting ssh console tacacs-serversaaa accounting serial console tacacs-serversaaa accounting command tacacs-serversaaa accounting enable console tacacs-serversaaa authorization exec authentication-server! define local username and password for local authentication fallbackusername admin password <secure-password> encrypted privilege 15As with the other infrastructure devices in the network, it is important to synchronize the time on the firewall protecting the management module using NTP.
The following configuration fragment illustrates the NTP configuration needed on an ASA to enable NTP to an NTP server located in the management network:
ntp authentication-key 10 md5 *ntp authenticatentp trusted-key 10ntp server <NTP-Server-address> source managementSyslog and SNMP can be used to keep track of system status, device access, and session activity. NetFlow Security Event Logging (NSEL), now supported on all Cisco ASA models, may also be used for the monitoring and reporting of session activity. The following configuration fragment illustrates the configuration of Syslog.
logging trap informationallogging host management <Syslog-Server-address>logging enableThe routing protocol running between the Internet firewall and the distribution/core should be secured. The following ASA configuration fragment illustrates the use of EIGRP MD5 authentication to authenticate the peering session between the inside firewall interface and the core/distribution switch:
interface Redundant1nameif insidesecurity-level 100ip address 10.125.33.10 255.255.255.0authentication key eigrp 100 <removed> key-id 1authentication mode eigrp 100 md5Network Address Translation (NAT)
NAT is required because the enterprise typically gets a limited number of public IP addresses. In addition, NAT helps shield the company's internal address space from reconnaissance and another malicious activity.
The following illustrates the NAT configuration:
! Static translation for servers residing at DMZstatic (dmz,outside) 198.133.219.10 10.25.34.10 netmask 255.255.255.255static (dmz,outside) 198.133.219.11 10.25.34.11 netmask 255.255.255.255static (dmz,outside) 198.133.219.12 10.25.34.12 netmask 255.255.255.255static (dmz,outside) 198.133.219.13 10.25.34.13 netmask 255.255.255.255!! Dynamic Port Address Translation (PAT) for inside hosts going to the Internetglobal (outside) 10 interfacenat (inside) 10 10.0.0.0 255.0.0.0!! Static translation for inside hosts going to the DMZ and vice-versa. The inside IP addresses are visible to the DMZ.static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0Firewall Access Policies
As previously explained, the Internet firewall should be configured to:
•
•
•
Enforcing such policies requires the configuration of the appropriate interface security levels and the deployment of ACLs governing what traffic is allowed or prevented from transiting between interfaces.
By default, the Cisco ASA appliance allows traffic from higher to lower security level interfaces (i.e., from inside to outside). However, due to the sensitivity of enterprise environments, the security administrators are recommended to override the default rules with more stringent rules indicating exactly what ports and protocols are permitted.
In our configuration example the inside, DMZ, and outside interfaces were configured with the security levels of 100, 50, and 0 respectively. With this, by default any traffic originating from the inside to the DMZ, from inside to outside, and from the DMZ to the outside interface will be allowed freely. At the same time, any traffic originating from the outside to the DMZ, from the outside to the inside, and from the DMZ to the inside interface will be blocked. While this may satisfy the basic access control requirements of the organization, it is always a good idea to reinforce the policies by enforcing granular ACLs.
Before designing the ACLs, it should also be noted that as the Cisco ASA inspects traffic it is able to recognize packets belonging to already established sessions. The stateful inspection engine of the firewall dynamically allows the returning traffic. Therefore, the firewall ACLs should be constructed to match traffic in the direction in which it is being initiated. In our sample configurations ACLs are applied in the ingress direction.
The following are the guidelines and configuration examples of ACLs controlling access and traffic flows:
•
Allow Internet access to users residing at all enterprise sites for the allowed ports and protocols. This typically includes HTTP and HTTPS access.
access-list Outbound extended permit tcp 10.0.0.0 255.0.0.0 any eq httpaccess-list Outbound extended permit tcp 10.0.0.0 255.0.0.0 any eq httpsAllow users access to DMZ services such as the company's website, E-mail, and domain name resolution (HTTP, HTTPS, SMTP, POP, IMAP, and DNS). Note that the previous entries in the ACL already permit HTTP and HTTPS traffic.
! Allow DNS queries to DNS serveraccess-list Outbound extended permit udp 10.0.0.0 255.0.0.0 host 10.25.34.13 eq domain! Allow SMTP, POP3 and IMAP access to DMZ mail serveraccess-list Outbound extended permit tcp 10.0.0.0 255.0.0.0 host 10.25.34.12 eq smtpaccess-list Outbound extended permit tcp 10.0.0.0 255.0.0.0 host 10.25.34.12 eq pop3access-list Outbound extended permit tcp 10.0.0.0 255.0.0.0 host 10.25.34.12 eq imap4! Apply ACL to inside interfaceaccess-group Outbound in interface inside•
Restrict connections initiated from DMZ only to the necessary protocols and sources. This typically includes DNS queries and zone transfer from DNS server, SMTP from E-mail server, HTTP/SSL access from the Cisco IronPort ESA for updates, Sensorbase, etc.
! Allow DNS queries and zone transfer from DNS serveraccess-list DMZ extended permit udp host 10.25.34.13 any eq domainaccess-list DMZ extended permit tcp host 10.25.34.13 any eq domain!! Allow SMTP from Cisco IronPort ESAaccess-list DMZ extended permit tcp host 10.25.34.11 any eq smtp!! Allow update and SensorBase access to Cisco IronPort ESAaccess-list DMZ extended permit tcp host 10.25.34.11 any eq httpaccess-list DMZ extended permit tcp host 10.25.34.11 any eq https!! Apply ACL to DMZ interfaceaccess-group DMZ in interface dmz•
Inbound Internet access should be restricted to the public services provided at the DMZ such as SMTP, Web, and DNS. Any connection attempts to internal resources and subnets from the Internet should be blocked. ACLs should be constructed using the servers' global IP addresses.
! Allow DNS queries and zone transfer to DNS serveraccess-list Inbound extended permit udp any host 198.133.219.13 eq domainaccess-list Inbound extended permit tcp any host 198.133.219.13 eq domain!! Allow SMTP to Cisco IronPort ESAaccess-list Inbound extended permit tcp any host 198.133.219.11 eq smtp!! Allow HTTP/HTTPS access to the company's public web portalaccess-list Inbound extended permit tcp any host 198.133.219.10 eq httpaccess-list Inbound extended permit tcp any host 198.133.219.10 eq https!! Apply ACL to outside interfaceaccess-group Inbound in interface outsideBotnet Traffic Filter
The small enterprise network design utilizes the Cisco ASA Botnet Traffic Filter on the Internet Firewall to detect malware that attempts network activity such as sending private data (passwords, credit card numbers, key strokes, or other proprietary data) when the malware starts a connection to a known bad IP address. The Botnet Traffic Filter checks incoming and outgoing connections against a dynamic database of known bad domain names and IP addresses (the blacklist) and then logs or blocks any suspicious activity.
Configuring the Botnet Traffic Filter requires the following steps:
1.
2.
3.
4.
5.
The following sections provides configuration examples for each of these steps.
Configure DNS Server
The Botnet Traffic Filter requires a DNS Server to access Cisco's dynamic database update server and to resolve entries in the static database. The following example illustrates this configuration.
! Enable DNS requests to a DNS Server out the outside interfacedns domain-lookup outside! Specify the DNS Server Group and the DNS Serversdns server-group DefaultDNSname-server 68.238.112.12name-server 68.238.96.12domain-name cisco.comEnable Use of the Dynamic Database
The Botnet Traffic Filter can receive periodic updates for the dynamic database from the Cisco update server. This database lists thousands of known bad domain names and IP addresses. The following configuration enables database updates and also enables use of the downloaded dynamic database by the adaptive security appliance.
! enable downloading of the dynamic database from the Cisco Update serverdynamic-filter updater-client enable! enable use of the dynamic databasedynamic-filter use-databaseEnable DNS Snooping
DNS Snooping enables inspection of DNS packets and enables Botnet Traffic Filter Snooping, which compares the domain name with those in the dynamic or static databases and adds the name and IP address to the DNS reverse lookup cache. This cache is then used by the Botnet Traffic Filter when connections are made to the suspicious address.
It is recommended that DNS snooping is only enabled on interfaces where external DNS requests are going. Enabling DNS snooping on all UDP DNS traffic, including that going to an internal DNS server, creates unnecessary loads on the Cisco ASA. For example, if the DNS server is on the outside interface, you should enable DNS inspection with snooping for all UDP DNS traffic on the outside interface.
The following configuration example illustrates enabling DNS Snooping on the outside interface:
! create a class map to identify the traffic you want to inspect DNSclass-map dynamic-filter-snoop-classmatch port udp eq domain! create a policy map to enable DNS inspection with Botnet Traffic Filtering snooping for the class mappolicy-map dynamic-filter-snoop-policyclass dynamic-filter-snoop-classinspect dns preset_dns_map dynamic-filter-snoop! activate the policy map on the outside interfaceservice-policy dynamic-filter-snoop-policy interface outsideEnable Traffic Classification and Actions for the Botnet Traffic Filter
The Botnet Traffic Filter compares the source and destination IP address in each initial connection packet to the IP addresses in the dynamic database, static database, DNS reverse lookup cache, and DNS host cache, and sends a syslog message or drops any matching traffic. When an address matches, the Cisco ASA sends a syslog message and can optionally be configured to drop the connection. You can enable Botnet Traffic filter on a subset of traffic or for all traffic by enabling an access list to classify traffic.
The following configuration example enables the Botnet Traffic Filter feature on all traffic and additionally enables dropping of connections going to IP addresses with a severity of moderate and higher.
! identify the traffic that you want to monitor or drop.access-list btf-filter-acl extended permit ip any any! enable Botnet Traffic Filter on the outside interface for traffic classified by the btf-filter-acl access listdynamic-filter enable interface outside classify-list btf-filter-acl! enable automatic dropping of traffic with threat level moderate or higherdynamic-filter drop blacklist interface outside action-classify-list btf-filter-acl threat-level range moderate very-highBotnet Traffic Filter Verification
To monitor and verify the operation of the Botnet Traffic Filter feature, the following commands can be used:
•
cr12-asa-1-ie# show dynamic-filter updater-clientDynamic Filter updater client is enabledUpdater server URL is https://update-manifests.ironport.comApplication name: threatcast, version: 1.0Encrypted UDI: 0bb93985f42d941e50dc8f022350d1a8a8c5097dc1d252b9cff62d26d4ec58e202883d704fc62b85bf8629 fa757fe36bLast update attempted at 15:14:11 UTC Apr 7 2010,with result: Downloaded file successfullyNext update is in 00:52:14Database file version is '1270651144' fetched at 15:14:11 UTC Apr 7 2010, size: 2097152cr12-asa-1-ie#•
cr12-asa-1-ie# show dynamic-filter dataDynamic Filter is using downloaded database version '1270651144'Fetched at 15:14:11 UTC Apr 7 2010, size: 2097152Sample contents from downloaded database:win-antimalware2.com firstlook.com red-devil-sport-club.gymdb.com mswindowsupdate.infozardoz.wizardz.com exchange.bg bisexual-photo.com lookmbox.comSample meta data from downloaded database:threat-level: very-high, category: Malware,description: "These are sources that use various exploits to deliver adware, spyware and other malware to victim computers. Some of these are associated with rogue online vendors and distributors of dialers which deceptively call premium-rate phone numbers."threat-level: high, category: Bot and Threat Networks,description: "These are rogue systems that control infected computers. They are either systems hosted on threat networks or systems that are part of the botnet itself."threat-level: moderate, category: Spyware,description: "These are sources that distribute spyware, adware, greyware, and other potentially unwanted advertising software. Some of these also run exploits to install such software."threat-level: low, category: Ads,description: "These are advertising networks that deliver banner ads, interstitials, rich media ads, pop-ups, and pop-unders for websites, spyware and adware. Some of these networks send ad-oriented HTML emails and email verification services."Total entries in Dynamic Filter database:Dynamic data: 82119 domain names , 2565 IPv4 addressesLocal data: 0 domain names , 0 IPv4 addressesActive rules in Dynamic Filter asp table:Dynamic data: 0 domain names , 2565 IPv4 addressesLocal data: 0 domain names , 0 IPv4 addressescr12-asa-1-ie#•
cr12-asa-1-ie# show dynamic-filter statistics detailEnabled on interface outside using classify-list btf-filter-aclTotal conns classified 35, ingress 0, egress 35Total whitelist classified 0, ingress 0, egress 0Total greylist classified 16, dropped 0, ingress 0, egress 16Threat-level very-high: classified 0, dropped 0, ingress 0, egress 0Threat-level high: classified 0, dropped 0, ingress 0, egress 0Threat-level moderate: classified 0, dropped 0, ingress 0, egress 0Threat-level low: classified 16, dropped 0, ingress 0, egress 16Threat-level very-low: classified 0, dropped 0, ingress 0, egress 0Total blacklist classified 19, dropped 0, ingress 0, egress 19Threat-level very-high: classified 9, dropped 0, ingress 0, egress 9Threat-level high: classified 0, dropped 0, ingress 0, egress 0Threat-level moderate: classified 0, dropped 0, ingress 0, egress 0Threat-level low: classified 10, dropped 0, ingress 0, egress 10Threat-level very-low: classified 0, dropped 0, ingress 0, egress 0cr12-asa-1-ie#
Note
Other commands that are useful for monitoring the Botnet Traffic filter include the following:
•
•
•
•
Firewall Redundancy
The Internet perimeter of the small enterprise network design uses a single Cisco ASA appliance configured with redundant interfaces. The use of redundant interfaces makes the design resilient to link level failures, representing an affordable option for high availability. In cases where chassis redundancy is desirable, the enterprise may consider deploying a pair of Cisco ASA appliances configured for stateful failover. Both active/active and active/standby failover modes are supported. While stateful failover protects against chassis failures, it requires the deployment of two identical Cisco ASA appliances and the adjustment of the topologies around the firewalls, so its deployment should be carefully planned.
This guide explains the use of redundant interfaces. For information on how to configure stateful failover, refer to the Cisco ASA 5500 Series Adaptive Security Appliances Configuration Guides at: http://www.cisco.com/en/US/products/ps6120/products_installation_and_configuration_guides_list.htm.
A Cisco ASA redundant interface is a logical interface that pairs two physical interfaces, called active and standby interfaces. Under normal operation the active interface is the only one passing traffic. The active interface uses the IP address defined at the redundant interface and the MAC address of the first physical interface associated with the redundant interface. When the active interface fails, the standby interface becomes active and starts passing traffic. The same IP address and MAC address are maintained so that traffic is not disrupted. Figure 24 illustrates the concept of redundant interface
Figure 24 Cisco ASA Redundant Interface
The configuration of a redundant interface consists of the configuration of the physical interface parameters and the logical redundant interface. Physical parameters such as media type, duplex, and speed are still configured within the physical interface. IP address, interface name, routing protocols, and security level are configured as part of the redundant interface. The following configuration example corresponds to Figure 24.
! Physical interface and Ethernet parametersinterface GigabitEthernet0/0description Connected to cr24-4507-DOno nameifno security-levelno ip address!interface GigabitEthernet0/1description backup to cr24-4507-DOno nameifno security-levelno ip address!! Defines logical redundant interface associated with physical! interfaces. Configures IP and logical interface parameters.interface Redundant1description Connected to cr24-4507-DOmember-interface GigabitEthernet0/0member-interface GigabitEthernet0/1nameif insidesecurity-level 100ip address 10.125.33.10 255.255.255.0authentication key eigrp 100 <removed> key-id 1authentication mode eigrp 100 md5!Routing
An interior gateway protocol, EIGRP in our configuration examples, is used for dynamic routing. The Internet firewall may participate in routing by learning the internal routes and by injecting a default route pointing to the Internet. The default route should be removed dynamically if the Internet connection becomes unavailable.
As part of the small enterprise network design, two different approaches were validated for the injection of the default route:
•
•
Injecting a default route with OSPF requires the configuration of an OSPF process between the Cisco ASA and the Internet border router, as illustrated in Figure 25. If the router is managed by the ISP, the configuration will require coordination with the service provider. This scenario also requires the default route to be propagated over OSPF. The actual default route may originate from the Internet border router itself or somewhere in the ISP network.
Figure 25 OSPF Default Route Injection
The following are the guidelines for using OSPF for the injection of a default route:
•
•
•
The following configuration snippet illustrates the routing configuration of the Cisco ASA appliance. The configuration includes the route redistribution from OSPF into EIGRP with the enforcement of a route-map allowing only the injection of the default route. MD5 authentication is used for OSPF, and the logging of neighbor status changes is enabled.
! Permit default onlyaccess-list Inbound-Routes standard permit host 0.0.0.0!interface GigabitEthernet0/2ospf message-digest-key 1 md5 <removed>ospf authentication message-digest!route-map Inbound-EIGRP permit 10match ip address Inbound-Routes!router eigrp 100no auto-summarynetwork 10.125.33.0 255.255.255.0passive-interface defaultno passive-interface insideredistribute ospf 200 metric 1000000 2000 255 1 1500 route-map Inbound-EIGRP!router ospf 200network 198.133.219.0 255.255.255.0 area 100area 100 authentication message-digestlog-adj-changes!
Note
The other validated alternative for the default route injection is the definition of a static default route, which then can be redistributed into the internal EIGRP process. This is shown in Figure 26. This option does not require the configuration of the Internet border router.
Figure 26 Static Default Route with Object Tracking
It is highly recommended to use object tracking so the default route is removed when the Internet connection becomes unavailable. Without object tracking, the default route will be removed only if the outside interface of the appliance goes down. So there is a possibility that the default route may remain in the routing table even if the Internet border router becomes unavailable. To avoid that problem, the static default route can be configured with object tracking. This consists in associating the default route with a monitoring target. The Cisco ASA appliance monitors the target using ICMP echo requests. If an echo reply is not received within a specified time period, the object is considered down and the associated default route is removed from the routing table.
The monitoring target needs to be carefully selected. First, pick one that can receive and respond to ICMP echo requests sent by the Cisco ASA. Second, it is better to use a persistent network object. In the configuration example below the Cisco ASA monitors the IP address of the next hop gateway, which helps identifying if the Internet gateway goes down, but it will not help if the connection is lost upstream. If available, you may want to monitor a persistent network object located somewhere in the ISP network. Static route tracking can also be configured for default routes obtained through DHCP or PPPoE.
In the following configuration the IP address of the next hop gateway (198.133.219.1) is used as the monitoring target. The static default route is then redistributed into EIGRP.
router eigrp 100no auto-summarynetwork 10.125.33.0 255.255.255.0passive-interface defaultno passive-interface insideredistribute static metric 1000000 2000 255 1 1500!route outside 0.0.0.0 0.0.0.0 198.133.219.1 1 track 10!sla monitor 1type echo protocol ipIcmpEcho 198.133.219.1 interface outsidesla monitor schedule 1 life forever start-time now!track 10 rtr 1 reachability
Note
Intrusion Prevention Deployment
The small enterprise network design implements Intrusion Prevention using an Advanced Inspection and Prevention Security Services Module (AIP SSM) on the Cisco ASA appliance deployed at the Internet perimeter. This section describes the best practices for integrating and configuring the IPS module for maximum threat control and visibility, as well as the deployment of the IPS Global Correlation feature.
Deploying IPS with the Cisco ASA
The Advanced Inspection and Prevention Security Services Module (AIP SSM) is supported on Cisco ASA 5510 and higher platforms. The AIP SSM runs advanced IPS software that provides proactive, full-featured intrusion prevention services to stop malicious traffic, including worms and network viruses, before they can affect your network.
As described in Intrusion Prevention Guidelines, the AIP SSM may be deployed in inline or promiscuous mode. In inline mode the AIP SSM is placed directly in the traffic flow, while in promiscuous mode the Cisco ASA sends a duplicate stream of traffic to the AIP SSM.
When deploying the AIP SSM in inline mode it is particularly important to determine how traffic will be treated in case of a module failure. The AIP SSM card may be configured to fail open or close when the module becomes unavailable. When configured to fail open, the Cisco ASA appliance allows all traffic through, uninspected, if the AIP SSM becomes unavailable. In contrast, when configured to fail close, the adaptive security appliance blocks all traffic in case of an AIP SSM failure.
The following example illustrates how a Cisco ASA can be configured to divert all IP traffic to the AIP SSM in inline mode and to block all IP traffic if the AIP SSM card fails for any reason:
access-list IPS permit ip any anyclass-map my-ips-classmatch access-list IPSpolicy-map my-ips-policyclass my-ips-classips inline fail-closeservice-policy my-ips-policy globalIPS Global Correlation Deployment
There are a number of aspects that need to be understood prior to the deployment of the IPS Global Correlation feature. To start with, before configuration be sure that you are using Cisco IPS Version 7.0 with the latest patch and signature updates and that Cisco IPS is configured for network connectivity in either IDS or IPS mode.
The configuration of Global Correlation can be performed using the command line interface (CLI), Cisco IDS Device Manager (IDM), Cisco IME, or the Cisco Security Manager. The figures are screen shots from Cisco IME that illustrate the basic steps in the configuration of IPS Global Correlation.
The first step in configuring the IPS sensor (module or appliance) to use Global Correlation is to add either a DNS address and/or the proxy server setup. This step, illustrated in Figure 27, enables connection to Cisco SensorBase. After you configure the DNS and proxy settings, these settings will go into effect as soon as the sensor has downloaded the latest Global Correlation updates.
Figure 27 DNS and HTTP Proxy Within the Network Setting Configuration Screen
By default, a sensor runs Global Correlation Inspection in Standard mode and enables the reputation filters, both illustrated in Figure 28. A good practice is to configure Global Correlation Inspection initially in permissive mode while monitoring the effects and later change the configuration into Standard or Aggressive mode.
Figure 28 Global Correlation Inspection Settings
By default network participation is disabled, which means the sensor does not share any event data back to the Cisco SensorBase network. The event data provided by all devices participating in the Cisco SensorBase network is a key element that provides real-time and worldwide visibility into the threat activity, accelerating the identification and mitigation of threats propagating throughout the Internet. For this reason Cisco recommends to configure the IPS sensors with partial or full network participation.
Figure 29 Network Participation Settings (Off by Default)
Event Monitoring with Global Correlation
Event monitoring with Global Correlation is similar to event monitoring with signature-only IPS. The primary difference is the potential addition of reputation scores representing the Global Correlation data. Figure 30 shows Cisco IPS events with reputation scores in Cisco IME.
Figure 30 Event Monitoring with Global Correlation in Cisco IME
Figure 30 shows several TCP SYN Port Sweep and ICMP Network Sweep attacks that were seen by the sensor. The first three events had no reputation and the event's risk ratings were 52 and 60, which did not meet the threshold for the packets to be dropped. The next three events were identical except that the attacker had a negative reputation of -1.8, which elevated the risk ratings to 70 and 75, but still did not meet the thresholds to be dropped in Standard Mode. The last events were also identical, except this time the attacker has a negative reputation if -4.3, which elevated the risk ratings to 86 and 89. This time the risk rating was high enough for the packets to be dropped.
Figure 31 illustrates a detailed view of the TCP SYN Port Sweep event coming from the attacker with a negative reputation of -4.3.
Figure 31 Detailed View of a TCP SYN Port Sweep from an Attacker with a Negative Reputation Score
Web Security Deployment
The small enterprise network design implements a Cisco IronPort WSA at the core/distribution layer of the main site, as illustrated in Figure 32. The WSA is located at the inside of the Cisco ASA acting as the Internet firewall. That ensures that clients and WSA are reachable over the same inside interface of the firewall and that the WSA can communicate with them without going through the firewall. At the same time, deploying the WSA at the core/distribution layer gives complete visibility to the WSA on the traffic before getting out to the Internet through the firewall.
Figure 32 Cisco IronPort WSA deployment
The guidelines for WSA configuration and deployment are presented below.
Initial System Setup Wizard
The WSA provides a browser-based system setup wizard that must be executed the first time the appliance is installed. The System Setup Wizard guides the user through initial system configuration, such as network and security settings. It should be noted that running the initial System Setup Wizard completely reconfigures the WSA appliance and resets the administrator password. Only use the System Setup Wizard the first time you install the appliance or if you want to completely overwrite the existing configuration.
The following are some of the default settings when running the System Setup Wizard:
•
•
All these settings can be changed any time after the initial configuration by running the WSA Web-based configuration GUI.
Interface and Network Configuration
The steps need to be completed as part of the initial setup of the WSA appliance:
1.
2.
3.
4.
5.
Configuring Network Interfaces
Independently from the model, all Cisco IronPort WSA appliances are equipped with six Ethernet interfaces as shown in Figure 33.
Figure 33 WSA Interfaces
The WSA interfaces are grouped for the following functions:
•
•
•
Figure 34 illustrates the network topology around the WSA used in the Cisco validation lab.
Figure 34 WSA Network Topology
Figure 35 illustrates the IP address and hostname configurations for the interfaces used. In this case, an out-of-band management network is used; therefore the M1 port is configured with an IP address in the management subnet. In addition, the WSA is configured to maintain a separate routing instance for the M1 management interface. This allows the definition of a default route for management traffic separate from the default route used for data traffic.
Figure 35 WSA Interface Configuration
Adding Routes
A default route is defined for management traffic pointing to the OOB management default gateway (172.26.191.1). A separate default route is defined for the data traffic pointing to the inside IP address of the firewall (10.125.33.10). As all internal networks are reachable throughout the core/distribution switch, a route to 10.0.0.0/8 is defined pointing to the switch IP address (10.125.33.9) to allow the WSA to communicate with the clients directly without having to go to the firewall first. These settings are illustrated in Figure 36.
Figure 36 WSA Route Configuration
Configuring DNS
The initial setup requires the configuration of a host name for the WSA appliance and listing the DNS servers. Figure 37 shows the DNS configuration.
Figure 37 WSA DNS Configuration
Setting Time
Time synchronization is critical for forensic analysis and troubleshooting, therefore enabling NTP is highly recommended. Figure 38 shows how the WSA is configured to synchronize its clock with an NTP server located on the OOB management network.
Figure 38 WSA NTP Configuration
Working with Upstream Proxies
If Internet access is provided by an upstream proxy, then the WSA must be configured to use the proxy for component updates and system upgrades. This is illustrated in Figure 39 and Figure 40.
Figure 39 WSA Upgrade Settings
Figure 40 WSA Component Updates
WCCP Transparent Web Proxy
The configuration of the WCCP Transparent Web Proxy involves:
1.
2.
3.
4.
5.
Defining WSA WCCP Service Group
Web Proxy settings are configured as part of an initial setup using the System Setup Wizard and can be later modified with the WSA Web-based GUI. The Web Proxy settings include:
•
•
•
Figure 41 illustrates the Web Proxy settings.
Figure 41 WSA Proxy Settings
Enabling WSA Transparent Redirection
Configuring WCCP Transparent Redirection requires the definition of a WCCP service profile in the WSA. If redirecting HTTP and HTTPS, define a dynamic service ID to be used with the Cisco ASA. Use MD5 authentication to protect the WCCP communication between the WSA and Cisco ASA. Figure 42 shows an example.
Figure 42 WSA Transparent Proxy
Enabling WCCP Redirection on Cisco ASA
The configuration of WCCP on the Cisco ASA appliance requires:
•
•
•
•
Cisco ASA WCCP configuration example:
! Group-list defining the IP addresses of all WSAsaccess-list wsa-farm extended permit ip host 10.125.33.8 any!! Redirect-list defining what ports and hosts/subnets should be redirectedaccess-list proxylist extended deny ip host 10.125.33.8 anyaccess-list proxylist extended permit tcp 10.0.0.0 255.0.0.0 any eq wwwaccess-list proxylist extended permit tcp 10.0.0.0 255.0.0.0 any eq https!! WCCP servicewccp 10 redirect-list proxylist group-list wsa-farm password cisco!! Applies WCCP on an interfacewccp interface inside 10 redirect inThe WCCP connection status and configuration can be monitored on the Cisco ASA with the show wccp command. An example is provided below:
cr26-asa5520-do# show wccpGlobal WCCP information:Router information:Router Identifier: 198.133.219.5Protocol Version: 2.0Service Identifier: 10Number of Cache Engines: 1Number of routers: 1Total Packets Redirected: 428617Redirect access-list: proxylistTotal Connections Denied Redirect: 0Total Packets Unassigned: 4Group access-list: wsa-farmTotal Messages Denied to Group: 0Total Authentication failures: 0Total Bypassed Packets Received: 0cr26-asa5520-do#Enabling WSA HTTPS Scanning
To monitor and decrypt HTTPS traffic, you must enable HTTPS scanning on the WSA. The HTTPS Proxy configuration is illustrated in Figure 43.
Figure 43 WSA HTTPS Proxy
Working with Upstream Proxies
In case Internet traffic is handled by one or more upstream proxies, follow these guidelines:
•
•
The Upstream Proxy Group lists the IP addresses or domain names of the proxies to be used for traffic sent to the Internet. When multiple proxies are available, the WSA can be configured for failover or load balancing.
The following are the options available:
•
•
•
•
•
Figure 44 illustrates the upstream proxy group configuration. Two upstream proxies are used and transactions are forwarded to the proxy servicing the fewest number of connections.
Figure 44 WSA Upstream Proxy Group
Next, a routing rule needs to be defined to indicate when and how to direct transactions to the upstream proxy group. Use the Global Routing Policy if all traffic is to be handled by the upstream proxies. If no proxies are present, leave the routing destination of the Global Routing Policy configured as Direct Connection. Figure 45 presents an example where all traffic is directed to the proxies in the Upstream-Lab_proxy group.
Figure 45 WSA Routing Policies
Web Access Policies
Access policies define how the Web Proxy handles HTTP requests and decrypted HTTPS connections for network users. By configuring access policies, the enterprise can control user acces to Internet applications (instant messaging clients, peer-to-peer file-sharing, Web browsers, Internet phone services, etc.) and URL categories. In addition, access policies can be used to block file downloads based on file characteristics, such as file size and file type.
The WSA comes with a default Global Policy that applies to all users. However, multiple policies can be defined when different policies need to be applied to different groups of users. Figure 46 shows the global policy.
Figure 46 Global Access Policy
URL categories corresponding to non-business-related content should be blocked in compliance with the company's Internet access policies. Figure 47 provides an example of how the "Adult/Sexually Explicit" category is blocked.
Figure 47 URL Categories
CISF Protected Ports
Catalyst Integrated Security Features (CISF) is a set of native security features available on Cisco Catalyst Switches that protect the network against attacks such as man-in-the-middle, spoofing, and infrastructure denial-of-services (DoS) attacks. CISF includes:
•
•
•
•
•
•
The following is a sample CISF port configuration:
! configure port security parametersswitchport port-security maximum 2switchport port-securityswitchport port-security aging time 2switchport port-security violation restrictswitchport port-security aging type inactivity! configure arp inspection rate limitingip arp inspection limit rate 100! configure dhcp snooping rate limitingip dhcp snooping limit rate 100! configure storm control parametersstorm-control broadcast level 20.00 10.00storm-control multicast level 50.00 30.00NAC Appliance Deployment
In the small enterprise network design, a NAC Appliance solution is deployed at all locations, the main site, and each of the remote offices. To that end, a centralized CAM is deployed at the main site, likely within the serverfarm. A CAS is deployed at the main site and each remote site, each of which directly connects to the core/distribution layer at each of the locations.
Deploying the NAC appliance solution requires the configuration of the CAM and CAS components. The initial CAM and CAS configuration is performed via console access (described in the Cisco NAC Appliance Hardware Installation guide). During the configuration stage, multiple steps must be followed in configuring the NAC Appliance with IP addresses, VLANs. passwords, etc. The installation guide contains worksheets that assist in gathering and preparing this information for both CAM and CAS.
After performing the initial setup through the console, the rest of the configuration of the CAM and CAS is performed using the CAM Web-based GUI. The first task on the CAM, before beginning configuration, is the installation the licenses for the solution. A license must be installed for the CAM and the CAS servers controlled by the CAM. The Cisco NAC Appliance Ordering Guide provides information on the ordering options.
Licenses can be entered via the CAM Web-based GUI, as shown in Figure 48.
Figure 48 NAC Appliance Licensing
Adding a CAS to the CAM
For a CAS server to be managed by the CAM, it must be first added to the list of managed servers on the CAM. To do this the CAM needs to know the IP address of the CAS and the Server Type (its role in the network) of the CAS. In addition, the CAS and the CAM must have the same shared secret. The shared secret is configured during the server installation. An example of adding a CAS to the CAM is shown in Figure 49.
Figure 49 Adding a new CAS to the CAM
Once the CAS has been added to the CAM, it appears in the list of servers on the CAM. From this point, it can be managed directly from the CAM for almost all tasks. An example of a list of servers is shown in Figure 50.
Figure 50 List of CAS Servers
Managing the CAS
Once the CAS is in the list of servers managed by the CAM, it can be configured for its role in the network. To manage the server, click the icon under the Manage heading in the server list, which connects you to the CAS server and shows you the summary menu shown in Figure 51.
Figure 51 CAS Management Menu
Under the CAS Network setting tab, shown in Figure 52, the basic network settings for the CAS can be viewed and altered, if needed. In this example, we are keeping the network configuration set up during the server installation. The primary dialog under the Network Tab is the IP dialog, shown in Figure 52; the other dialogs allow the DHCP options to the configured—our example uses the default of DHCP passthrough—and the DNS options where host name, domain name, and DNS server information are added, as shown in Figure 53.
Figure 52 CAS Network Settings
Figure 53 CAS DNS Settings
The next tab in CAS configuration is the Filter tab (see Figure 54). For our example, the important dialog is Roles, where network traffic filters may be applied to different user Roles. The role of interest is the default Unauthenticated Role, which by default blocks all traffic. In this example, we are allowing the Unauthenticated Role to pass Active Directory client authentication traffic to the Active Directory Sever. This allows a Windows client to join the active Directory Domain and Windows users to authenticate to the domain, although they have not been through the NAC process. This is often important to allow printer and drive mapping information to be sent to Windows users. As the user has already authenticated to the Active Directory Domain, the user authentication information may be learned from Active Directory and the user does not have to reauthenticate for the NAC server.
Note
Figure 54 CAS Filter Settings
The next tab that requires configuration is the Advanced tab, which has multiple dialogs that require configuration. The first of these is the Managed Subnet dialog, where each of the trusted VLAN subnets is added to the CAS for management. An example of this shown in Figure 55.
Figure 55 CAS Managed Subnet
The next dialog of the Advanced Tab is the VLAN Mapping dialog, which tells the CAS which trusted VLAN are mapped to an untrusted VLAN; an example of this is shown in Figure 56. In our example, VLAN Prunning and VLAN Mapping are also enabled.
Figure 56 VLAN Mapping
The next tab of interest is the Authentication Tab (see Figure 57), which has multiple dialogs for configuring different authentication options. The first dialog is the Login Page Dialog, which allows the configuration of different Web login pages depending upon the untrusted subnet being used for authenticating clients.
Figure 57 Authentication Login Page
The other Authentication dialog of interest is the Windows Auth dialog, as Windows Single Sign On (SSO) is used in this example. To perform Windows SSO, the CAS must be able to communicate with Active Directory to determine the authentication state of the Windows user. If Active Directory confirms that the user has authenticated to Active Directory, the user does not need to perform additional authentication to the CAS. An example of this configuration is shown in Figure 58. There are a number of steps required to configure Active Directory SSO, as these are described in the Cisco NAC Appliance -Clean Access Server Installation and Configuration Guide. The key components in this configuration are:
•
•
Figure 58 CAS Windows Authentication
Clean Access Roles
The unauthenticated role is common to all clients, but once the client has been authenticated, a different role may be applied based upon the identity of the client. Different roles may be assigned for admin staff, users, etc.
User roles allow you to aggregate various policies into a user role. These policies include:
•
•
Note
•
•
•
For example, the Admin and User roles could each have different traffic polices and VLANs; in addition, the User role may enforce bandwidth policies by keeping the user traffic in band.
For more information on roles, refer to the Cisco NAC Appliance - Clean Access Manager Installation and Configuration Guide at: http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/45/cam/45cam-book.html.
Layer 2 OOB Example
Figure 59 shows an example of a Layer 2 OOB deployment where a wired client connected to an access switch is originally on the untrusted VLAN 264 and is switched to a trusted VLAN 64 once it has completed the NAC functions. The first NAC function is the authentication and authorization function, which is the first design decision in implementing the NAC solution, i.e, how will authentication and authorization be achieved and what will the user experience be.
This example is focused on the virtual gateway example, as a virtual gateway provides the simplest deployment. In the virtual gateway example, the original IP addressing, interfaces, VLANs, and normal traffic flows are maintained. The only changes are the addition of the untrusted VLANs that carry client traffic during NAC Authentication and Authorization, Scanning and evaluation, remediation, and quarantine modes.
Figure 59 Layer 2 OOB Example
NAC Authentication Options
The authentication option in the NAC solution can be broadly categorized as NAC Authentication or NAC Single Sign On
•
•
Topology Considerations
The Layer 2 OOB solution relies upon there being a Layer 2 network connection available between the client devices and the Cisco CAS. In Figure 59, a trunk connects the access switch to the core/distribution switch. The Cisco CAS is connected to the core/distribution switch through two interfaces—trusted and untrusted. In such a simple network, it is relatively easy to provide a Layer 2 connection between the client and the Cisco CAS; for larger networks, Layer 3 OOB may be a better choice.
The roles of the untrusted and trusted interfaces:
•
•
Availability Considerations
The CAS and CAM are both highly involved in client network access and consideration must be given to the impact on clients if either a CAS or CAM should fail or need to be taken out of service.
The CAS is inline with client devices during the authentication, authorization, and posture assessment phases of NAC and, if "In Band NAC" is being used, it may be inline at all times. A CAS outage in an OOB deployment would not impact already-connected clients, but would prevent network access for new clients. A CAS outage for "In Line" clients prevents access for all clients.
In situations where availability of a CAS is critical, a high availability CAS solution may be implemented, where a pair of CAS servers are installed using a primary CAS and a secondary in hot standby. For more information, refer to the Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide.
The CAM is also a critical part of the authentication, authorization, and posture assessment phases of NAC. Although the CAM does not pass client traffic, the impact of its availability needs to be considered in the network design. Like the CAS, the CAM has a high availability solution that provides for a primary server and a hot standby secondary server. In addition, each CAS may be configured with a "fallback" option (as shown in Figure 60) that defines how it will manage client traffic in situations where the CAM is unavailable.
In both high availability CAM and high availability CAS, high availability licenses are used that address the high availability role of the server.
The use of the high availability features is dependent upon the company's unique requirements, but CAS fallback should always configured to ensure that critical network services are available in the event of a network outage.
Figure 60 CAS Fallback
Basic Clean Access Switch Configuration
For OOB-based Clean Access, some simple configuration must be performed on the switches implementing NAC. This configuration is primarily to enable SNMP communication between the switches and the CAM. Table 3 shows a simple SNMP v1 configuration (SNMPv2c and SNMPv3 are supported).
In addition to the switch SNMP configuration, the required trusted and untrusted VLANs must exist and be operational on the switch, as illustrated in the configuration in Table 3. If a switch has more than one IP address, the snmp-server source interface must be specified, as the CAM must be configured with the source IP address that OOB SNMP messages will originate from; alternatively, all IP addresses of interfaces on the switch can be added to the CAM. If SNMP access filtering is applied on the switch (recommended as a best practice), the CAM must be added as a trusted address.
Basic Clean Access Out of Band Switch Configuration
NAC CAS Connection
The NAC CAS connects to the core/distribution switch using two switch ports (which are not configured in EtherChannel). One is the untrusted port that serves the VLANs used by the clients prior to their authentication and authorization and the other is the trusted port that connects to the VLANs used once clients have successfully completed the NAC process. Both trusted and untrusted ports are required, even if OOB NAC is used, as the CAS requires access to the trusted VLANs during the NAC process. The following is an example of NAC CAS port configuration:
interface GigabitEthernet1/0/4description NAC Trusted Eth0switchport trunk encapsulation dot1qswitchport trunk allowed vlan 48,57,62switchport mode trunkspanning-tree portfast trunk!interface GigabitEthernet1/0/8description NAC Untrusted Eth1switchport trunk encapsulation dot1qswitchport trunk allowed vlan 61,248,257switchport mode trunkspanning-tree portfast trunkBasic 802.1X Switch Configuration
The basic 802.1X configuration controls access to an access VLAN depending upon the success or failure of the 802.1X authentication. If the 802.1X authentication is successful, there are three basic options:
•
•
•
Table 4 shows an example of an 802.1X configuration.
For more information on Cisco 3750 802.1X configuration, refer to:
•
•
Cisco Security Services
The Cisco SAFE Security Architecture is complimented by Cisco's rich portfolio of security services designed to support the entire solution lifecycle. Security is integrated everywhere and with the help of a lifecycle services approach, enterprises can deploy, operate, and optimize network platforms that defend critical business processes against attack and disruption, protect privacy, and support policy and regulatory compliance controls. Figure 61 shows how the Cisco Lifecycle Security Services support the entire lifecycle.
Figure 61 Cisco Lifecycle Security Services
Strategy and Assessments
Cisco offers a comprehensive set of assessment services based on a structured IT governance, risk management, and compliance approach to information security. These services help the customer understand the needs and gaps, recommend remediation based on industry and international best practices, and help the customer to strategically plan the evolution of an information security program, including updates to security policy, processes, and technology.
Deployment and Migration
Cisco offers deployment services to support the customer in planning, designing, and implementing Cisco security products and solutions. In addition, Cisco has services to support the customer in evolving its security policy and process-based controls to make people and the security architecture more effective.
Remote Management
Cisco Remote Management services engineers become an extension of the customer's IT staff, proactively monitoring the security technology infrastructure and providing incident, problem, change, configuration, and release management, as well as management reporting, 24 hours a day, 365 days a year.
Security Intelligence
The Cisco Security Intelligence services provide early warning intelligence, analysis, and proven mitigation techniques to help security professionals respond to the latest threats. The customer's IT staff can use the latest threat alerts, vulnerability analysis, and applied mitigation techniques developed by Cisco experts who use in-depth knowledge and sophisticated tools to verify anomalies and develop techniques that help ensure timely, accurate, and quick resolution to potential vulnerabilities and attacks.
Security Optimization
The Cisco security Optimization service is an integrated service offering designed to assess, develop, and optimize the customer's security infrastructure on an ongoing basis. Through quarterly site visits and continual analysis and tuning, the Cisco security team becomes an extension of the customer's security staff, supporting them in long-term business security and risk management, as well as near-term tactical solutions to evolving security threats.
Feedback