Issues for Enterprises to Resolve When Connecting at Layer 3 to Provider Networks


This section reviews some security mechanisms that are considered recommended practices when connecting at Layer 3 to any third-party network.

Note

Many references are listed at the end of this chapter to complement the overview provided in this section, because this topic is vast. The best places to start your research are http://www.ispbook.com and http://www.nanog.org/ispsecurity.html.


History of IP Network Attacks

It's worth looking at the history of the most visible attacks on IP networks because it helps you understand the types of attacks that have existed in the past, and the direction that attacks are taking now, so that focus is applied to the current areas of concern.

DoS attacks can be considered as starting in 1999. The first major public awareness of this type of attack occurred with the February 2000 distributed DoS (DDoS) attack that denied service from Amazon, eBay, CNN, and E-Trade. The DDoS attack marked a new era in attacks, because it made feasible DoS attacks on major Internet locations by the generation of large amounts of traffic. In January 2001, attacks migrated from generating traffic to attacking routers. The most visible example was Microsoft websites being taken down by attacks on the routers that connected them to the Internet. This form of attack reached its most significant effects in January 2002, when the European service provider Cloud 9 went out of business because of persistent and successful DoS attacks on its infrastructure.

DoS attacks continue to gain in sophistication with the latest trends, such as the e-mail worm viruses that generate large amounts of traffic. These are not explicitly DoS attacks themselves, but they have a similar effect on the network. As these changes in attack types have occurred, their impact has changed from a local to global nature as the attacks have moved from attacking specific computers to network elements and finally to affecting the entire Internet, as we see with e-mail worms.

The number of attacks launched through the Internet is continually growing. The Internet provides much information about how routers work. Even conferences such as Blackhat (http://www.blackhat.com), Defcon (http://www.defcon.org), and Hivercon (http://www.hivercon.com) provide details of router construction and routing protocol operations that some attackers find useful.

This section contains general references to types of attacks that have been seen, either on a widespread or limited basis, but precise details of the attacks are not given for obvious reasons. However, protection from different classes of attacks is defined. Initially, most of these techniques were viewed just as provider techniques. However, they are now just as relevant to large enterprise IP cores that now have Layer 3 connectivity to external networks. Enterprise network managers must be aware of the protection mechanisms identified here and ask prospective providers about what type of security protection mechanisms they implement. Enterprise network managers must also assess how secure their network is likely to be and what additional enterprise-based security measures are necessary to keep their network safe. Additionally, it is reasonable to assume that any technique to protect a P router is required because the router is exposed to Internet traffic. This must also be applied to enterprise routers that are similarly exposed to the Internet.

In this section, techniques such as tracing the source of DoS attacks used to be relevant to provider networks only. This is because enterprise networks typically had only one or two peering points to external networks, whereas provider networks had dozens, so it was more challenging to locate the source of attacks. However, with enterprises now having connectivity to multiple provider networks, extranet and external network-based data services, which are the sources of DoS attacks in an enterprise infrastructure, are increasing. This proliferation of external connections makes identifying the source of a DoS attack that appears on an enterprise network similar to the problem providers face by trying to identify the source of attacks.

Strong Password Protection

The most common and simple attack on infrastructure routers is via an insecure password. Attackers use tools that search for open Telnet ports and then send standard passwords through them to gain network access. From the enterprise's perspective, it is interesting to know if a provider implements some sort of central and secure password-management system, such as TACACS+. This increases the likelihood of secure passwords being used and reduces the possibility of operator error in setting secure passwords. In the world of hackers, identifying a weak password for a BGP-speaking router on the Internet is worth cash these days, because this could provide the launchpad for extensive DoS attacks.

Preparing for an Attack

The first step to prepare for an attack is to have one or more persons responsible for network security. In an enterprise, maybe not all the issues raised here need to be addressed directly; however, knowledge of what your provider can do for you during an attack and what needs to be done to complement that within the enterprise is an essential starting point. Too often, no security plans, procedures, or specific training or tools are in place, and learning tends to come on the job after an attack occurs. The person(s) responsible for security should follow these initial steps:

Step 1.

Have a security contact for each network you peer with.

Step 2.

Have contacts for security issues with the vendors.

Step 3.

Document procedures for who is responsible for what during an attack.

Here are the primary phases to consider when creating a security policy:

Step 1.

Prepare in terms of knowing your network and its normal traffic flows. Know the tools you have to identify, classify, and react to attacks. Participate in security groups. Additionally, use the security forums to keep up to date with new tools, techniques, and attack profiles.

Step 2.

Know how to identify attacks by building baseline network activity logs and defining a procedure to detect anomalies.

Step 3.

Know what you will do to classify the attack.

Step 4.

Have a plan for tracing the source of the attack.

Step 5.

Be prepared to react in multiple ways, depending on the nature of the attack, possibly rate-limiting, dropping, or capturing traffic for later analysis.

Step 6.

Close the feedback loop by instigating a post mortem to learn from the attack and to see how your internal procedures can be optimized to deal with the attack.

Note

You might be interested in joining these primary forums to learn about security issues:

  • Operator meetings Your local one can be found at http://www.nanog.org/orgs.html and http://www.first.org.

  • Security collection data Go to http://www.dshield.org and submit firewall logs.


Identifying an Attack

In preparing for an attack, the most important knowledge to have is to know how to identify attacks. NetFlow is the most valuable tool to use when you try to identify an attack that's in progresswhere it's coming from, what it is targeting, and its nature. However, during an attack that generates significant amounts of traffic, analyzing all the NetFlow data can be infeasible for a human. You should use a type of NetFlow Collector, which sorts through the reams of NetFlow data, reports what is anomalous, and provides some intelligent sorting of that data for a security expert to digest and take action on.

The partner Cisco Systems works with on providing such a system is Arbor Networks. (Detailed information on Arbor productsPeakflow X for enterprises and Peakflow SP for providerscan be found at http://www.arbor.net.) When run properly, this system learns what is normal traffic for the network and reports anomalies for the security staff to investigate. What is most valuable from this system during times of attack is that the Peakflow system immediately identifies what is anomalous and what that anomalous traffic consists of in terms of source, destination, packet type, protocol, port range, packet size, and so on. All these things are essential to know to successfully block the attack.

Initial Precautions

The first line of defense against a network attack is a well-structured access control list (ACL) policy at the edge of the network and within the router. This section looks at ACLs applied to traffic that is destined for the router itself (either from a router that has an adjacency for exchange of routing information or management traffic) as well as transit traffic. These protection mechanisms need to be applied to all Internet-accessible routers, within both the provider and enterprise domain.

Simple ACLS are limited, though. For example, they were useless against the Code Red and Nimda viruses. For attacks like these, Network-Based Application Recognition and other higher-level filters must be applied.

Receiving ACLs

The first issue considered here is how you can protect the route processor of a router that is accessible from the public Internet. In today's hardware-based forwarding routers that form the backbone of provider networks, the linecards that are responsible for forwarding traffic can do so at the interface's line rate without difficulty. The only software part of the router that has constrained performance is the route processor, which is responsible for controlling traffic.

The primary means of protecting these route processors is to use receive ACLs. The basic concept is that a router receives two broad categories of traffic:

  • Traffic that transits the router on its way to another destination (which constitutes the majority of traffic)

  • Traffic such as Telnet, SNMP, or route information that is destined for the router itself and needs to be processed by the route processor on the router

In addition to these control packets, transit packets that the linecards cannot deal with directly are also sent to the route processor for special processing. Packets with certain options configured in the header or packets alerting the router to certain conditions on the network fall into this category.

A simple option for protecting the route processor is to limit the amount of traffic that a linecard allows into the router if the destination is the route processor itself. However, given that many routing adjacencies send updates to multicast addresses, this becomes cumbersome. Typically, this is implemented by an ACL with the destination address being the route processor IP address. This is a simplistic approach, because no differentiation between higher-priority routing protocol traffic and other lower-priority access-related traffic, such as Telnet, is possible. Receive ACLs provide this additional differentiation for traffic that enters a linecard and is destined for the route processor. The key implementation point is that the receive ACL itself is pushed to each linecard and is executed against traffic the linecard receives that is destined for the route processor, from what are termed receive adjacencies (basically peers exchanging route information) rather than being applied to the traffic that is transiting the router.

Figure 7-7 shows the location of these receive ACLs in a routing infrastructure.

Figure 7-7. Receive ACL Location of Operation


Infrastructure ACLs

The more traditional ACL protection falls under the category of infrastructure ACLs. Infrastructure ACLs are implemented to protect routers from receiving and processing packets that are not valid transit packets that need to be forwarded to customer hosts. Each infrastructure ACL is applied to protect the router from a specific type of packet. These protections need to be applied both to P routers and to enterprise routers connecting to the provider networkor, in fact, any third-party network.

Note

This section only introduces this topic; it covers the most basic issues. You can find more detailed information by visiting the URLs listed in the "References" section.


The first action of the infrastructure ACL is to ensure that no packets can enter the network from prefixes that should not be on the network. Things such as private addresses, like the 10.0.0.0 network and multicast addresses, clearly should not appear as source addresses of packets on the public Internet. Internet providers deny packets with these source addresses from entering their networks. Enterprises should also take the same precautions to deny packets with these source addresses from entering their network via Internet connections. The source for identifying these "banned" source addresses is the bogon list maintained by Team Cymru (http://www.cymru.com/). These source addresses are harmful because they are commonly the source addresses crafted into packets injected into the network for the purpose of a DoS attack.

Identifying the list of bogons (addresses considered bogus and not to be allowed) starts with the Internet Assigned Numbers Authority (IANA) allocation at http://www.iana.org/assignments/ipv4-address-space, which identifies all addresses not allocated to a valid user. If all the unallocated addresses are denied as either routes that can be injected into the network or as source addresses of packets, these bogon addresses are of no use to attackers. Of course, the issue arises of IANA allocating these address prefixes to valid users. For this, Team Cymru regularly updates the bogon list and provides a template for configuring IOS in a secure fashion, along with a secure BGP configuration. The following URLs provide preconfigured bogon lists and explanations of all the recommended configurations for border routers:

  • http://www.cymru.com/Documents/secure-ios-template.html

  • http://www.cymru.com/Documents/secure-bgp-template.html

One issue that is often not addressed when trying to protect either edge or core routers by using ACLs is the treatment of fragmented packets. The templates given in these URLs address denying ICMP fragments. This section explains why this is so important for ICMP and other protocols.

This issue with fragments is documented in RFC 1858 (http://www.ietf.org/rfc/rfc1858.txt). The bottom line is that unfragmented packets have Layer 3 and Layer 4 information in the header, which allows for identification and classification. Initial fragments have Layer 4 information, but subsequent fragments do not; they just have the destination IP address in their header. The issue then becomes how the router handles these noninitial fragments given that they have no Layer 4 data for application classification purposes.

The answer for Cisco equipment depends on what the ACL consists of and what type of packet is presented to the ACL for processing. The operation has changed for IOS starting with 12.1(2) and 12.0(11) onward.

These releases have six different types of ACL lines, and each has a specific processing action, depending on whether a packet does or does not match the ACL entry. When there is both Layer 3 and Layer 4 information in the ACL line and the fragments keyword is present, the ACL action for both permit and deny actions is defined as conservative. The definition of conservative for the permit case means it is assumed that the Layer 4 information in the packet, if available, matches the Layer 4 information in the ACL line. In the deny case, a noninitial fragment is not denied; instead, the next ACL entry is processed.

Specific examples of each of the possible cases are described at http://www.cisco.com/warp/public/105/acl_wp.html. However, just one example is useful here to illustrate the concept. In the following example, access list 100 illustrates the commands to invoke fragment processing. Clearly, denying all fragments to the router may break some operations. However, most uses of control traffic, such as ICMP and Telnet, do not have to send packets that cause MTUs to be exceeded, so fragment processing for these protocols may be turned on, as in the secure IOS template from Team Cymru:

access-list 100 deny ip any host 172.16.10.1 fragments access-list 100 permit tcp any host 172.16.10.1 eq 80 access-list 100 deny ip any any


Access list 100 does not allow noninitial fragments through to the 172.16.10.1 address because of the first line. A noninitial fragment to the server is denied when it encounters the first ACL line because the Layer 3 information in the packet matches the Layer 3 information in the ACL line.

Initial or nonfragments to port 80 of packets destined for 172.16.10.1 also match the first line of the ACL for Layer 3 information, but because the fragments keyword is present, the next ACL entry (the second line) is processed. The second line of the ACL permits the initial or nonfragments because they match the ACL line for Layer 3 and Layer 4 information.

Noninitial fragments destined for the TCP ports of other hosts on the 171.16.23.0 network are blocked by this ACL. The Layer 3 information in these packets does not match the Layer 3 information in the first ACL line, so the next ACL line is processed. The Layer 3 information in these packets does not match the Layer 3 information in the second ACL line either, so the third ACL line is processed. The third line is implicit and denies all traffic.

Basic Attack Mitigation

Say that an attack gets past your ACL policywhat's next? Because the list of bogon addresses is being constantly updated with subsequent operational changes to security ACLs, how do you protect yourself when an attack is crafted using a new bogon address or one that has accidentally not been filtered? How can you track the source of an attack if the source address of the attack packets is bogus? In fact, filtering out these packets without first identifying their source may not be in the best interest of the network operator. Instead of hoping that the attack does not change to a different set of fake source addresses, a better option is to take the miscreant host off the network. For this reason, something more than plain security ACLs are necessary.

In a Cisco environment, Cisco Express Forwarding (CEF) and NetFlow provide the functionality required to track these attacks and identify the source host, because clearly relying on routing table information is not helpful when tracking a bogon source address:

  • CEF provides the fastest packet-switching option available in Cisco routers.

  • NetFlow provides an export of data that describes the traffic flows through the network. NetFlow is enabled on a per-interface basis with the ip route-cache flow command. NetFlow data can also be viewed on the router with commands such as show ip cache flow. This command displays information about things such as the IP packet distribution seen on the interface and the total number of flows used by each protocol on the interface. This information is useful when identifying a DoS attack, because the packet sizes tend to be fixed and also use a single protocol type.

As NetFlow logs flow information, it can tell you about source address information and is therefore most useful in tracking DDoS attacks using bogon addresses. Figure 7-8 shows a simple example of tracking spoofed source addresses through a network (with reference to the network).

Figure 7-8. Tracking Packets with Spoofed Bogon Addresses


Note

A fuller description of the methodology described here, with links explaining the component technologies in more depth, can be found at http://www.cymru.com.


Assume that route information, either static or dynamically sourced, exists in each router. In Figure 7-8, an attacker resides on host Mindy and selects host Mork at the target of attack. The actual IP addresses are clearly not what would be found in a real situation; they are just for illustrative purposes. The attack could be of any formlots of bogus UDP traffic, TCP connection request, anything. However, to avoid being caught, the attacker located on Mindy decides to spoof his address to be 96.170.4.8. The attacker knows that the entire 96/8 prefix is unassigned, so any packets destined for this network (being returned from Mork) do not arrive at an actual site.

The administrator of Mork is alerted to the attack by an unusually high CPU on Mork, or perhaps users complaining of a poor response or no response. A packet analyzer quickly identifies the source of the problem as excessive numbers of packets hitting server Mork with a source address of 96.170.4.8, the spoofed IP address. Clearly, examining the routing table to trace the source of the attack does not help, because that address block is not there. So the first action is to look at the NetFlow data on router 1 for information on this spoofed address, which shows something like the following:

router1#sh ip cache flow | include 96.120 Se0           96.120.2.2      Et0           10.1.1.1


This syntax asks router 1 to show NetFlow entries that include 96.120 in the address. The result is information that packets destined for 10.1.1.1 are coming in on Serial 0 with source address 96.120.2.2. We now follow the trail through the network. The next step is to use CEF to determine the active sources on serial 0:

router1#sh ip cef se0 Prefix              Next Hop             Interface 0.0.0.0/0           172.16.10.2          Serial0 172.16.10.0         attached             Serial0


This syntax tells us a few things. The router has a default route to 172.16.10.2, the subnet 172.16.10.0 is directly attached, and 172.16.10.2 is the only active source on that interface. This process of finding the interface receiving the packets with the spoofed source address and then using CEF to identify the active source on that interface can be followed all the way through the network to Router 4, which identifies host Mindy as sending the packets. Clearly, Mindy has a non-Cisco MAC address, and the network operator cannot access this device. Shutting off Ethernet 0 on router 4 will prove the source of the attack, assuming that spoofed packets to Mork stop appearing on the network. There are cases in which a router may have multiple active sources shown by CEF, as in the case where Ethernet connectivity is used. In this case, the resolution is to log on to all the routers listed as potential sources by CEF and enter the sh ip cache flow | include 96.170 command to see if they are receiving traffic from the spoofed address. Should that command return no data, the potential source is not receiving packets with the spoofed source address. This narrows down the potential number of sources to one, and the hunt resumes.

This and similar techniques that are described in sources in the "References" section are most useful for attacks emanating from a single location. However, more and more attackers are leveraging techniques that initiate attacks from multiple sources. When that happens, it is usually the result of a compromised set of hosts, and the attack may be originating from hundreds of hosts (or more) using nonspoofed addresses. Clearly in these circumstances, a different approach is required. The following sections address some basic techniques to reduce the likelihood of these types of attacks, tell you how these types of attacks can be initiated, and show you how to deal with them when they arise.




Selecting MPLS VPN Services
Selecting MPLS VPN Services
ISBN: 1587051915
EAN: 2147483647
Year: 2004
Pages: 136

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net