Contents

Introduction
Summary
Challenge: Security Issues for Service Providers
Solution: A Service Provider Security Toolset and Deployment Framework
      Service Provider Security Tools and Techniques
         Securing the Control Plane
         Securing the Management Plane
         Securing the Data Plane
      Additional Service Provider Security Techniques
         Sinkholes
         Blackhole Routing
         Remotely Triggered Black Holes
         Backscatter Traceback
         Traffic Scrubbing
Framework for Service Provider Infrastructure Security Deployment
      Six-Phase Approach to Service Provider Security
         Preparation Phase
         Identification Phase
         Classification Phase
         Traceback Phase
         Mitigation Phase
         Post-Mortem Phase
Knowing the Side Effects, Limitations, and Caveats
Conclusion
References
Acknowledgments

Introduction

As the Internet becomes more of a place for doing business and not just exchanging information, it becomes a greater target for people who aim to use it in a criminal manner. As the framework of the global network, Internet service providers are often involved in security incidents, either as a target of an attack or as one of the defenders. This white paper describes a set of techniques ISPs can use to withstand global threats by securing their networks' infrastructure.

Summary

This white paper provides a comprehensive overview of security measures and tools that Internet service providers can use to secure their network infrastructures. It also outlines a six-phase approach for deploying network security mechanisms and responding to attacks. The scope of this document does not allow for an in-depth analysis of the techniques described. Readers interested in exploring these techniques in more detail should consult the resources listed in "References" at the end of this document.

Challenge: Security Issues for Service Providers

In addition to the general security concerns that affect anyone who uses IT technology or connects to the Internet, the community of service providers has its own set of security-related issues to deal with. The most important security issues that service providers face are the following:

Denial of service (DoS) and distributed denial of service (DDoS) attacks are aimed at disabling access to various Internet services for legitimate users.
Excessive traffic and resource depletion caused by infected machines can generate problems for service providers.
Attacking Border Gateway Protocol (BGP) routing and injecting faulty BGP routes for traffic redirection is one technique that attackers are using to obtain the "interesting" traffic.
Domain Name System (DNS) information is sometimes used to redirect Internet traffic to serve the needs of people with criminal intent.
Device compromise means breaking into vital components of the infrastructure and modifying their configuration.

These threats are correlated with the following factors specific to service provider networks:

The size of the network. Service providers must be able to rapidly implement security measures against a large number of parties that may be involved in the attack, and deploy these tools and techniques on a large number of devices, usually network entry points. In the enterprise world, the number of devices to take care of is typically considerably smaller than in the service provider space. (Although some enterprises have huge networks, this is still an exception). Size is one of the significant differences between the service provider and enterprise security paradigm. The number of possible targets of and entry points for an attack is also higher in the service provider space than it is in the enterprise world, where typically a smaller number of clearly identified assets frequently enjoy the highest level of protection possible. Accordingly, service providers must be able to defend multiple targets from multiple parallel attacks.
Securing the transit paths and the infrastructure carrying them and not necessarily securing the endpoints brings its own set of challenges. Many of the standard edge-security measures that are applicable in the enterprise world are not applicable in the service provider security paradigm. A primary difference is that firewalls and intrusion detection and prevention system (IDS/IPS) devices cannot be applied on transit paths in service provider networks. Service providers cannot afford to provide granular access control — one of the main functions of a firewall — for transit traffic. Moreover, they cannot afford focused monitoring of transit traffic to detect indications of exploitation attempts in the way that IDSs/IPSs usually do. Finally, the whole set of security measures available for hardening endpoints, like host IPSs and antivirus software, is not of much interest in the service provider world.

There are two notes on the scope of this paper:

Managed security service providers (MSSPs) — a subset of service providers — manage the security components of their customers' networks. MSSPs care about security primarily from the standpoint of enterprises. MSSP operation is not within the scope of this white paper.
Service providers are also interested in the endpoint security measures with clearly identified security zones; they use these mechanisms to secure their own back-end systems and certain host-based services, like DNS infrastructure, web servers, mail servers, and CPE devices. This paper does not discuss this aspect of securing service provider networks. Instead, this paper focuses on only those aspects that are specific to service providers and their backbone networks.

Solution: A Service Provider Security Toolset and Deployment Framework

To address the challenges described above, the service provider community, in close interaction with networking vendors, has developed a set of evolving techniques over the years. The next section, "Service Provider Security Tools and Techniques," describes these techniques.

However, tools and techniques alone are not enough to secure the network. Service providers need procedures to implement these techniques efficiently in response to attacks. The section "Framework for Service Provider Infrastructure Security Deployment" provides an operational context for deployment of the techniques outlined in this paper. The "Framework" section describes a six-phase approach to implementing service provider security processes and points to some of the specific tools and techniques that service providers can use in each phase.

Service Provider Security Tools and Techniques

This section describes the various categories of tools and techniques service providers can use to secure their networks, including the core logic of each of these mechanisms and the kinds of attacks they are designed to counter. The section "Additional Service Provider Security Techniques" describes some sophisticated techniques that can reinforce a network's security after basic security mechanisms are in place.

Traditionally, network functions are divided into three separate planes: the control plane, which incorporates elements that control the flow of actual data; the management plane, which includes various administrative and monitoring functions performed on the network; and the data plane, which constitutes the transit data itself. To secure network devices, service providers view them from the perspective of these three planes. Although the per-box and per-plane security that is achieved in this manner is not enough to handle all possible threats, it is a prerequisite for deploying additional sets of tools and techniques — network devices and the three planes must be properly secured against common threats and generally brought to a highest feasible level of robustness. Some of the techniques described below are discussed in more detail within the Cisco Network Foundation Protection framework (http://www.cisco.com/go/nfp), which provides an umbrella strategy for infrastructure protection that encompasses Cisco IOS security features.

Securing the Control Plane

The control plane covers mostly IP signaling traffic on an ISP's network. Packets that belong to the control plane do not carry any of the users' information. Instead, they contain information on how to carry the packets that constitute the customer's traffic — in other words, they carry primarily routing protocols. Besides general ISP architectural recommendations (for example, separation of Interior Gateway Protocol [IGP] and BGP, address summarization, and scalable IGP design guidelines), the following elements of BGP hardening are considered the most important in the service provider security paradigm:

Ingress filtering of BGP updates from customers. Every customer should be allowed to advertise only the known networks that have been assigned to them. Some of the default ranges that should normally be filtered out of BGP between peers are the following addresses:
- Private or special-use addresses (such as the private addresses set aside in RFC 1918). These private and special-use addresses can be considered the DSUA addresses, based on the paper posted at http://www.isi.edu/~bmanning/dsua.html.
- Unassigned addresses spaces known as bogons. Internet Assigned Numbers Authority (IANA) address allocations are documented athttp://www.iana.org/assignments/ipv4-address-space. Regularly updated templates for bogon filters are at http://www.cymru.com/Bogons/.
Intra-autonomous-system (intra-AS) BGP filtering can be implemented at positions within the network where the routes propagated by internal BGP (IBGP) can be controlled.
Baselining the routing table. It is recommended that service providers have a baseline of the routing table and monitor its contents to detect possible anomalies more efficiently.
Ingress BGP filtering from other service provider peers is usually not easy to configure because of the large number of prefixes involved. For this reason, these filters evaluate prefixes in a "deny some, allow others" fashion, where certain networks like DSUA or bogon ranges are filtered out, while any other kind of routing update from the peer is allowed.
Authenticated routing updates. Authentication of routing updates should be activated (for example, for BGP sessions). This primarily entails MD5 authentication. Although activation of MD5 authentication requires additional administrative overhead and a higher degree of synchronization with peers, it has also proven to be an effective measure in protecting the transport protocol itself — in this case, TCP. Many of the TCP-related industrywide security advisories recently published list MD5 hashing of TCP packets as one of the most efficient workaround mechanisms.
The BGP maximum prefix parameter should be used to control the maximum number of prefixes that can be received from a peer. By imposing this constraint, service providers ensure that a BGP peer cannot overwhelm the router with BGP-propagated routes.
BGP dampening should be used to reduce the effects of route flapping or DoS attacks that could be initiated via BGP.
BGP neighbor changes should be logged and tracked so that the necessary actions can be performed when a peer's flapping is noticed.
Time-to-live (TTL) enforcement for BGP packets should be configured where appropriate. This is a relatively new feature that enforces high values for the TTL field in the BGP packets, thereby preventing remote attacks against BGP sessions.
BGP policy accounting provides an efficient method for traffic accounting based on BGP communities. It is typically used on network edges to provide easy identification of attack entry points. BGP policy accounting counters can be queried via Simple Network Management Protocol (SNMP) and represented graphically.
Securing IGP and LDP. In addition to BGP, other control-plane protocols like the deployed IGP and Label Distribution Protocol (LDP) should be secured via MD5 authentication. The motivation for this is the same as for using MD5 for BGP: to authenticate the routing updates and generally increase the level of robustness of the protocol at Layer 4.
ICMP IP unreachable messages can be used to perform a DoS attack on routers. ICMP unreachables should either be turned off or rate limited to prevent the possibility of such an attack. Please note that other security techniques, such as backscatter traceback (described later), depend on the activation of this feature on network edges. ICMP unreachable messages are rate limited in the newer releases of Cisco IOS Software.

In addition to the features used to protect routing protocols and ICMP, the following features play an important role in securing the control plane of the network infrastructure:

The input-hold queue, which handles packets that are to be process switched or are destined for one of the router's IP addresses, should be increased to higher values than the default of 75. A feasible value for this parameter is usually 1500. Setting this value requires enough memory on the distributed components, such as line cards and versatile interface processors (VIPs).
Selective packet discard (SPD) should be used to make it more difficult to attack the input hold queue. On top of the hold queue, SPD provides two additional queues for critical packets to ensure that the control function remains intact even under attack conditions. SPD is turned on by default, and it is advisable to increment the headroom to 1000 (from a default of 100). SPD aggressive mode can also be turned on if needed.
Control plane policing and receive path access control lists ( ACLs) are per-box measures that provide centralized control of the traffic destined to the router, most of which normally consists of control plane packets. Using these features enables administrators to employ modular quality of service command-line interface (MQC) service policies and ACLs to secure all the traffic that is destined for router CPUs. These features help administrators provide more scalable and simpler security, especially when compared to the alternative of per-interface ACL deployment for a similar purpose.

Securing the Management Plane

Securing the management connections to the network infrastructure is important; it is just as relevant as securing root or Administrator access to hosts.

Here are some important things to bear in mind with regard to securing the management plane:

Unnecessary services should be turned off, and it is advisable to turn off Cisco Discovery Protocol at the network edges. Running any unnecessary and possibly unsecured service on network devices leaves a potential hole that can be used for a DoS attack.
Appropriate banners should be used at login and exec levels to ensure that the legal aspects of securing the network are appropriately covered.
Enable secret password should be used to protect administrative access to routers.
Exec-timeout should be used on console and vty ports to control timing out of the inactive vty sessions.
Service tcp-keepalives can be configured to disconnect and clear idle sessions running over TCP.
Vty access classes should be used for source-based access control to terminal sessions on devices. Service providers can use the logging option on these ACLs to facilitate monitoring and attack detection.
Secure Shell (SSH) Protocol is an advisable method for obtaining vty access because it provides confidentiality for the transported data. Service providers should emphasize appropriate policies for the use of usernames and passwords. Whenever possible, secure copy (SCP) should be used to copy files to and from the routers.
One-time passwords can be used when SSH is not available on the given device. This method ensures password confidentiality even over unencrypted Telnet sessions.
Authentication, authorization, and accounting (AAA) should be used for administrative access. AAA is usually based on the TACACS protocol because TACACS provides the most comprehensive support for authorization of the commands available in command-line interface (CLI) sessions.
Authentication and accounting based on RADIUS is recommended for customer access.
Local passwords, irreversibly encrypted, should be used as a last-resort backup if the TACACS server is not working or is not accessible.
Command privilege level tuning is recommended as an initial effort to help separate administrative user groups.
Role-based CLI access control can be used as an alternative to command privilege level tuning in newer releases of Cisco IOS Software.
Tracking of up-to-date router configurations needs to be ensured. As an alternative to Trivial File Transfer Protocol (TFTP), which is not completely secure, FTP can be used. For both TFTP and FTP, the loopback address should be used as a source address on a router.
Logging messages to syslog servers should be used with an informational or warning level. The source address for syslog messages should also be set to the loopback address. Logging to the console port should be turned off.
Network Time Protocol (NTP) should be used to keep the time synchronized among routers. It is also advisable to activate security mechanisms for NTP to prevent attacks against this protocol.
SNMP should not use default communities. Generally, SNMP access should be restricted to read-only privileges. Access lists should be used to restrict IP addresses from which SNMP requests can originate.
Out-of-band management access to the routers must be ensured. This kind of access can be provided either by the network of terminal servers providing console access via reverse Telnet, or by a more comprehensive network outside the user data path providing full connectivity from management ports to the network equipment.

Securing the Data Plane

Data plane security encompasses the actual packets that carry customer traffic. In contrast to the management and control plane, traffic on the data plane just goes through network devices and is not destined for any of the interfaces on the device. Administering ACLs is the most important part of handling data plane security. Deploying ACLs is important primarily on the network edges, where multiple types of traffic need to be blocked.

The following types of ACLs are important for securing the data plane:

Antispoofing ACLs provide traffic filtering of source addresses from the service provider's own address space. By filtering out packets with the source address ranges belonging to the internal IP space, a service provider provides the basis for per-service source-based ACL deployment (such as SNMP access lists or vty access classes). Antispoofing ACLs also prevent reflection attacks that rely on the reply packets destined toward the internal spoofed addresses.
Antibogon and RFC 1918 ACLs filter out traffic that is sourced from reserved, unassigned, or private IP address space. This traffic is easy to identify, and this approach provides a simple means of protection against these classes of IP addresses.
Infrastructure ACLs (iACLS) are normally deployed on the edges of a service provider's network with the goal of blocking traffic that should never be seen on the network and is destined toward the IP range belonging to the network infrastructure. The iACLs provide filtering of unwanted packets on the network edges. Deploying iACLs is an iterative task that requires identifying the traffic from the outside that needs to be filtered out and the traffic directed toward the network infrastructure that needs to be allowed in. Infrastructure ACLs complement the receive-path ACLs (rACLs) and control plane policing that are deployed throughout the network on a per-device basis.
Classification ACLs, although a part of the iACL and rACL deployment mechanisms, can also be used as an independent method for detecting the characteristics of network traffic. To use this technique, deploy ACLs that do not filter anything but instead permit all the traffic. By specifying arbitrary ACLs and issuing proper commands for checking per-access-control-entry (per-ACE) counters, you can determine which traffic is flowing over a given interface.

In addition to the ACL types listed above, there are methods that provide security within the data plane. Some of the most important ones are Unicast Reverse Path Forwarding (uRPF) verification and NetFlow monitoring.

uRPF is a network edge technique that enables efficient dropping of packets that come from unexpected interfaces. This technique has two basic modes of operation. In strict mode, the router drops all packets that do not arrive on one of the best return paths to the source of the packet, as determined by a reverse lookup in the Forwarding Information Base (FIB). In loose mode, the router drops packets with a source that does not have any corresponding destination route in the FIB, or with a next hop that is, possibly recursively, resolved to the Null0 interface. Besides providing antispoofing functions, uRPF is useful for various types of source-based drops induced via remote triggers. These are explained in more detail later in this paper. Newer versions of IOS support an additional mode of using uRPF by black listing or white listing source IP addresses in dedicated VRFs.
NetFlow was initially implemented as a packet-switching acceleration mechanism. Now, service providers use it as a leading traffic-monitoring tool in their networks. NetFlow provides information in a telephone-bill-like format about the traffic flows on the network. The flow information includes source and destination IP addresses, protocol types, and port numbers, as well as information about the amount of data that has been carried in a particular flow. Like a telephone bill, a NetFlow report does not provide any information about the content of the packets moving through the network. Instead, it provides information only on the volume of the traffic that was exchanged between the endpoints involved. Typically, NetFlow is configured on the network edges to provide insight into the traffic getting into the network. Various tools are available for the graphic representation of NetFlow-generated data. Using these visualization tools, you can collect data from many devices, establish a baseline for "normal" network behavior, and aggregate and present the data so that it is easier to interpret. In addition, NetFlow is an evolving tool with numerous interesting features that have appeared in recent Cisco IOS Software releases (Layer 2 NetFlow, Top Talkers report, and NetFlow MIB, for example).
Committed access rate (CAR) or rate limiting can also be used to handle attacks. Provided that it can be easily identified, attack traffic can be rate limited at network ingress points. By rate limiting the malicious traffic flows, service providers can greatly reduce the effects of an attack. One issue is that the standard rate-limiting mechanisms do not have any means to distinguish bad traffic from legitimate traffic, which can lead (to a certain extent) to self-induced DoS. However, by using the option for remote propagation of the "signalization" of the traffic to be rate limited, it is possible to remotely control CAR on many ingress points in a scalable fashion. QoS Policy Propagation on BGP (QPPB) provides the means for this remote propagation.

Additional Service Provider Security Techniques

This section describes additional techniques that service providers can use to strengthen the security in their networks, including sinkholes, blackhole routing, remotely triggered black holes, backscatter traceback, and traffic scrubbing.

Sinkholes

ISP security sinkholes belong to a group of techniques that take advantage of routing protocols as a security tool. A sinkhole is a part of the network that advertises (usually via BGP) certain ranges of IP addresses and attracts traffic destined for those ranges so that it can be analyzed. The IP address ranges that are forwarded to the sinkhole may belong to unused address spaces — private IP ranges or unallocated parts of the provider's address space. Used in this way, sinkholes facilitate the detection of worms and other attacks that randomly generate packets to unknown addresses. Or the sinkhole may attract traffic destined for real addresses; in these cases, the attackers do not pick up the addresses randomly but are instead determined to attack specific IP addresses.

Ramifications of implementing sinkholes include the following:

Depending on the size of the IP blocks advertised by the sinkhole, the sinkhole can attract a lot of junk traffic. For this reason, it is important to carefully choose the size of the address block that the sinkhole will accept. In addition, the network infrastructure supporting the sinkhole must be capable of handling heavy traffic loads.
By using anycast — a technique of advertising the same address space from multiple points in the network — it is possible to establish a kind of distributed sinkhole.
Sinkholes allow administrators to perform monitoring using resources that would otherwise need to be centrally deployed rather than distributed throughout the network or embedded into the network infrastructure.
After administrators have analyzed the traffic attracted by the sinkhole, it can be dropped by a router that is capable of dropping packets at a fast pace. Alternatively, it can be IP terminated by a host and used in strategies for analyzing and confusing the attacker's tactics. (However, service providers often avoid these techniques for legal reasons.)

Blackhole Routing

Blackhole routing is a popular way of discarding packets being sent to a specific destination when the destination of the traffic flow is known. An advantage of this method is that it lets the router do what it was designed to do: route packets.

Blackhole routing works as follows. Network administrators identify the host that is under attack and route traffic destined for that host to Null0 by creating a static host route. Null0 is a pseudo-interface that functions like the null device in most operating systems. This interface can never forward traffic to any other interface. When traffic is received by the Null0 interface, it is the same as dropping the packet. As this can be done in the fast traffic forwarding path, it is a very efficient way of dropping packets.

The null interface provides an alternative method of filtering traffic. You can avoid the overhead involved in using ACLs by directing undesired traffic to the null interface. Use the no icmp unreachable command to prevent unnecessary replies when traffic is passed to the Null0 interface.

Remotely Triggered Black Holes

Remote control of packets to be dropped is an important category of security techniques for ISPs. Remotely triggered black holes are based on the concept of uRPF loose checks: packets are dropped based on source address if the next hop for the source address resolves to a Null0 interface or if the route does not exist in the routing table at all.

Remotely triggered black holes work as follows. Administrators define a certain set of static routes on the routers where the packets are to be dropped. Typically, these routes are from unused private address spaces (such as the unused address block known as Test-Net, 192.0.2.0 /24 ). Administrators give these routes a next hop of the router's logical, virtual Null0 interface. Packets are then dropped if they are destined to the unused private address spaces, or if their routes point to the unused private address spaces and they recursively have a next hop of Null0 in the FIB.

To be able to drop packets based on the remotely triggered black hole, the specific router needs to run BGP and be part of the ISP's IBGP structure. Another router, usually called the trigger router, is used to generate a BGP update that contains Network Layer Reachability Information (NLRI) for the IP ranges that are sending packets that should be dropped. The NLRI for these ranges will indicate a next hop in the private addresses space (such as Test-Net). Setting the nonconnected next hop is possible in BGP using a route map for redistributed routes. On edge routers that also have uRPF loose check activated on some interfaces, packets will be dropped based on the recursive lookup that resolves the next hop for the source to the Null0 interface. Blackhole routing is illustrated at http://www.cisco.com/web/about/security/intelligence/worm-mitigation-whitepaper.html#tt_routing.

In addition to the core logic just described, the following recommendations make remotely triggered black holes safer and easier to use:

To inject appropriate routes into the BGP, on the trigger router, static routes can be tagged with certain strings that are matched on the route maps used for redistribution into BGP. This kind of tagging would prevent injecting faulty information into BGP by providing a simple means of identifying the relevant static routes.
Tagged static routes should also be marked with the BGP no-export community so that they will not propagate outside the provider's autonomous system. As an additional security measure, you can filter the advertised routes to the BGP peers (this best practice should be implemented in any case).
Both the controlled edge router and the trigger router can also be BGP route reflector clients, or they can be assigned any other IGP role that allows BGP to be configured as required.

Backscatter Traceback

Backscatter traceback is primarily useful for spoofed attacks where the attackers use source addresses from the private or bogon IP address space. The mechanism relies on a combination of sinkholes, remotely triggered destination-based black holing, and ICMP unreachable messages generated by the edge routers. The edge routers drop packets destined for the attacked IP range and send the ICMP unreachable messages back toward the spoofed sources of the malicious packets. When a sinkhole advertises parts of the private or unused addresses space, these ICMP packets will eventually get routed toward it. If you monitor for these packets in the sinkhole in order to detect the routers that are generating them, it is relatively easy to determine the egress points for the attacking data streams.

Traffic Scrubbing

Traffic scrubbing allows you to dynamically distinguish legitimate traffic from the attack traffic that comes either from malicious or naïve sources. Traffic scrubbing is usually implemented when a part of the network — for example, a customer of a service provider or a hosted server farm — is exposed to a DDoS attack.

Traffic scrubbing works like this: legitimate traffic is forwarded toward the attacked zone, while the malicious traffic is dropped in the scrubbing center. To differentiate between legitimate traffic and attack traffic, you usually need dedicated devices or modules with high-performing hardware that can support focused algorithms. The main difference between traffic scrubbing and various black holing or rate-limiting techniques is that the attacked service remains available for legitimate users, while the destination-based black holing or rate limiting is not able to distinguish between legitimate and illegitimate traffic.

Framework For Service Provider Infrastructure Security Deployment

To get the full benefit of the security tools and techniques just described and to use them efficiently, you need a well-defined approach to deploying them. This section outlines the elements of a solid deployment framework.

Six-Phase Approach to Service Provider Security

Generally, Cisco advocates a six-phase framework for deploying security systems. The six phases are:

Preparation
Detection
Classification
Traceback
Mitigation
Post-mortem

While the six-phase approach was designed primarily to counter DDoS attacks (the attacks of highest concern to service providers), this framework provides a good overall approach to securing service provider environments.

Preparation Phase

Preparation is probably the most important of the six phases. This phase includes setting up both technical and nontechnical processes, tools, and organizational structure that constitute the security system. The tasks in the preparation phase include:

Select, develop, install, and test the security tools and techniques you will use.
Define and agree upon security policy and incident response procedures.
Set up communications channels with service provider peers and customers, and establish equipment vendor incident response teams.

Identification Phase

In the identification phase, you detect unusual activity or behavior and activate appropriate measures after an alert is raised. You can use many tools and data sources to identify these issues, including NetFlow information, SNMP information about the CPU, and interface utilization data. A customer's report that service is unavailable is often an early indicator of an attack.

Classification Phase

After an attack has been detected, you'll need to collect comprehensive information about it, including the spoofed or nonspoofed source addresses, destination IP addresses, packet sizes, and Layer 4 information, such as protocol and port numbers. You can gather this data by direct sniffing, using classification ACLs, or installing a sniffer into the sinkhole and analyzing packets offline. NetFlow can also provide information about the attack based on the data elements tracked in each individual flow.

Traceback Phase

Assuming you have identified the attack vector in the preceding phase, you now need to identify the ingress points in order to mitigate the attack efficiently. The traceback phase entails tracing the attack flows from the attacked sections of the network toward the network edges. You can take a hop-by-hop approach tracking the sources upstream from the victim toward network edges, or you can directly jump on the network ingress points to check them for the presence of attack flows. You can track flows through the network in various ways: through ACLs (with or without the log-input clause), by deploying NetFlow, or by using backscatter mechanisms.

Mitigation Phase

In this phase, you mitigate the attacking flows using the various mechanisms you identified as appropriate for your network during the preparation phase. These tools and techniques can include ACLs, remotely triggered source-based and destination-based black holing, rate limiting, or traffic scrubbing. For a service provider, it is important that the techniques can be deployed quickly and on a high number of ingress points. A primary concern is deploying techniques that have minimal or no negative impact on the nonattacking traffic flows and on the performance of the network.

Post-Mortem Phase

The post-mortem phase is critical. This is where you review the whole attack-handling process, analyze the experience, and look for ways to improve either organizational or technical aspects of the response. By incorporating post-mortem conclusions into a new preparation phase, you can begin to close what is often referred to as the security wheel to help ensure that the security of the service provider network remains at a high level. The security wheel illustrates that security is a cycle in which security measures are tested and improved and policies are updated so that they reflect changing security needs and drive security enhancement. Because Internet attacks are not a temporary phenomenon and they will only become more sophisticated, it is important to continually review and refine attack-handling tools and procedures.

Knowing The Side Effects, Limitations, And Caveats

The techniques described in this paper will vary somewhat, based on the architecture of the network and the types of networking equipment on which the techniques are deployed. Just as it is important to know the technology fundamentals of the security methods that you will use, it is also important to know how the network will behave when they are deployed. The following list, although not exhaustive, provides examples of caveats or interdependencies you should know about.

The performance of the equipment under various traffic profiles is one of the most important factors in how a network will behave under attack. It is also a good indicator of how the various security techniques described in this paper will affect the manageability of devices. In this context, the term traffic profiles refers primarily to the mean packet size, a key measure of sustainable throughput values on the equipment.
The performance penalty of deployed features is another important issue to consider — it directly affects a network's ability to sustain its load under attacks. Normally, software platforms suffer a CPU utilization impact for any additional feature deployed. However, platforms with hardware acceleration, when used within the specified limitations, do not suffer a performance penalty with the addition of new features.
Hardware acceleration of features is closely related to traffic profiles and performance penalties. Normally, the robustness of the methods deployed is increased when hardware acceleration is used. Hardware acceleration helps keep the performance high, even under heavy loads.
Variations in features available in different hardware platforms or Cisco IOS Software release trains can mean that some security tools or techniques are not supported by some of the hardware or software deployed on the network. It is important to consider how the features supported in different software releases and hardware platforms, modules, and cards may affect your security implementation.
Operational impact and costs also need to be considered when choosing and implementing features. Sometimes the initial deployment of a feature is simple and technically feasible but the operational costs and/or efforts are high. Typical examples of such potentially effort-intensive tasks are maintenance of ACLs (in some cases) and monitoring of a high number of alarms generated by IDS/IPS (the latter not being typical for the ISP infrastructure security framework, as discussed above). Although there are tools or products that help reduce the overhead in most cases, it is necessary to consider deployment issues up front.

Conclusion

Service providers have their own set of security challenges as well as specific tools and techniques for network protection. These methods are often based on various routing mechanisms, thereby using the technology and experience that is already present in a typical service provider environment. There is no single solution for security issues, but there is a wide range of methods that you can use as your network's needs dictate.

Because preparing the tools and settings is not enough to protect a network, a structured process for responding to attacks and mitigating them must be in place. This white paper outlined a six-phase approach to deploying a network security system.

Finally, when you deploy any of the techniques described, it is important to be aware of the negative implications or limitations of specific tools and techniques when they are used in specific contexts. For this reason, successfully implementing and maintaining the security of service provider networks requires a good technical understanding of both the theory and practical issues involved in using security tools.

References

Cisco Network Foundation Protection White Papers
//www.cisco.com/en/US/products/ps6642/prod_white_papers_list.html

Cisco ISP Essentials (FTP link)
ftp://ftp-eng.cisco.com/cons/isp/essentials/

Protecting Your Core: Infrastructure Protection Access Control Lists
http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

NANOG Security Curriculum
http://www.nanog.org/ispsecurity.html

Acknowledgments

Dragan Parmakovic is a Network Consulting Engineer with Cisco Advanced Services, specializing in security.

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.