On April 25, 1997, at 11:30 A.M., a misconfigured AS7007 router flooded the entire Internet with tons of /24 BGP routes that should have been aggregated. The memory of this amazing incident still lives on in the networking community, and you can check the NANOG thread dedicated to the event at http://www.merit.edu/mail.archives/nanog/199704/msg00340.html for information.
This massive de-aggregation had immediate effects on the entire Internet. Routing was globally disrupted, as the more specific prefixes took precedence over the aggregated routes (remember, the longer netmask wins!). Routers with 32MB of RAM, which was enough for the Global Internet Route table back in 1997, now had tens of thousands of additional routes to handle. In some cases, such routers simply crashed. More specific routes advertised from AS7007 into AS1239 attracted traffic from all over the Internet into the unlucky AS1239, saturating links and causing more failures. For about an hour , the whole Internet experienced connectivity problems, which resolved only when the offending router was unplugged.
This was a BGP misconfiguration without any malicious intent. What would have happened if this was a well-planned and-executed hacking attack aimed to cause maximum damage?
Of course, the consequences would have been severe. However, BGPv4 is not as insecure as many would like to think, and the attacks against this complex protocol are far from being straightforward. This is well outlined in the infamous "BGP Vulnerability Testing: Separating Fact from FUD v1.1" presentation by Sean Convery and Matthew Franz, available all over the Internet. To a large extent, this section is inspired by their presentation.
First of all, unlike other routing protocols we have discussed previously, BGP is running over TCP. Thus, a remote intrusion into BGP routing will require guessing correct TCP numbers to insert data. Modern routers' TCP/IP stacks usually have hard-to-predict or unpredictable TCP sequence numbers , eliminating such opportunities. Then, to participate in BGP routing, a rogue router must be defined in the target's BGP configuration as a neighbor with a correct netmask and AS number. Thus, a blind attackersomeone on a remote network without any opportunity to sniff the wire and run ARP (or similar) IP spoofing and TCP hijacking attackshas little, if any, chance to hack BGP.
The most efficient way to succeed in attacking BGP routing is to take over one of the BGP peers (speakers) and reconfigure it. This is not as easy as you might expect, since backbone routers running BGP are usually looked after and reasonably well protected from external intruders. Of course, a truly massive "I'm on DShield!" type of a scan will eventually discover a few insecure BGP speakers, but this is not the kind of attack a dedicated, focused, considerate Black Hat is seeking. The second approach is to become a semi-blind attacker who seeks to "own" a host on the same network with the targeted BGP routers. This opens up a chance to inject malicious updates by combining both ARP spoofing and TCP hijacking techniques aimed at positioning the hacked host between the BGP speakers and inserting an update with a correct TCP sequence. Also, if MD5based authentication of BGP packets is in use (as it should be), the ability to sniff these packets makes MD5 cracking a more realistic task.
The attacks from the semi-blind attacker position are the main topic of this section. Taking over a Cisco router is described elsewhere in this book and is not BGP- related (so far). Internal BGP (iBGP), running within a single AS, is more susceptible to semi-blind attacks since there is a higher probability of taking over a host within that AS and close to a BGP router. External BGP (eBGP) is sometimes run over a dedicated line between two peers belonging to different autonomous systems, making such attacks impossible .
An additional factor to consider is synchronization. Unless the autonomous system in question is not a transit domain carrying BGPv4 updates between other ASs, or all routers in a transit domain AS are running BGP and are fully meshed, iBGP must be synchronized with an interior gateway protocol (IGPsuch as EIGRP or OSPF). In other words, an IGP becomes responsible for routing BGP updates through the AS. By attacking this IGP, as described in the previous sections of this chapter, an attacker can indirectly, but strongly, influence BGP routing. And, of course, if route redistribution is in use, routes injected into the redistributed IGP will become injected into BGP. This is when the methodology of attacking becomes somewhat of an art as well as a deep understanding of the technology involved.
While this should really be a topic for Chapter 10 as a methodology to be applied after getting enable, reviewing this topic here at least gives us a chance to outline some of the basics of BGPv4 before switching to semi-blind attacks.
Describing this complex protocol requires a book of its own. If you are serious about attacking BGP, you must be proficient in BGP. We strongly recommend that you consult specific literature about this protocol, such as Iljitsch van Beijnum's BGP (O'Reilly), John W. Stewart's BGP4: Inter-Domain Routing in the Internet (Addison-Wesley), Sam Halabi's Internet Routing Architectures (Cisco Press), and various Cisco Certified Internetwork Expert (CCIE) guides. By any means, this is not a section a script kiddie type of attacker would grasp. It also demands that you pay a lot of attention to every word. In particular, note whether we are talking about inbound or outbound traffic to the AS, in which the controlled router is positioned.
First of all, you need to understand how BGP selects the best route. BGP is a path vector protocol. It has something in common with static routing (the peers must be defined manually by a system administrator), something in common with distance-vector protocols (it also carries and looks at the path , alas, with whole autonomous systems as hops), and link state protocols (relationships with neighbors, keepalive packets, detection of a failed route, and exchange of information about specific routing changes).
Of course, one can always use the longer netmask to overwrite other, legitimate routes. Such is the nature of de-aggregation attacks a la the AS7007 incident. One can simply define plenty of networks with long netmasks via the network command or use no aggregate-address and, if route redistribution from an IGP is enabled, no autosummary . Another way is to modify the BGP metric, which is far more complex if compared to other routing protocols. But don't worry. Out of the multiple BGP attributes, only a few are usually used to select one route above another on real networks.
Here is how the selection process goes:
If more than one relevant route to the destination is available, the route with the highest weight variable is used. This variable is a Cisco proprietary function set by a neighbor command on a per-neighbor basisfor example, neighbor 192.168.66.191 weight <number from 0 to 65535> . The weight is not propagated to other routers.
If the weights are the same, a route with a highest local preference is selected. Local preference is local for the router's AS and equals 100 by default. If you want to force all routers in the AS to prefer the same outbound path, you can create a route map setting necessary local preference, like so:
c2600(config-router)#neighbor 192.168.66.191 route-map redirect in c2600(config-router)#end c2600(config)#route-map redirect permit 10 c2600(config-route-map)#set local-preference 1000
The number after the permit statement is simply a route map sequence. The local-preference parameter can take values from 0 to 4294967295the higher the better (from the route takeover point of view).
If the routes have the same local preference, a route that has originated on this particular router is preferred. This is straightforward: either define the route via the network command or define a static route and use the redistribute static command.
If no routes have originated on this particular box, the AS_Path attribute is evaluated and a route with the shortest path is selected. This is essentially a RIP-like operation. AS_Path is updated by the sending router with its own AS number and is used by BGP to detect routing loops . You can disable the use of this variable with the bgp bestpath as-path ignore command. This may create a nasty routing loop. There is definitely more value for an attacker to manipulate the AS_Path via AS number prependingadding additional AS numbers to the AS_Path via the as-path prepend statement. You can even prepend your own AS number several times to make the AS_Path longer and thus less preferable. The prepending can be done using both in and out route mapsfor example:
c2600(config)#ip as-path access-list 10 permit ^$ c2600(config)#route-map prepend permit 10 c2600(config-route-map)#match as-path 10 c2600(config-route-map)#set as-path prepend 65500 65000 65000 65000 c2600(config-route-map)#route-map prepend 20 c2600(config-route-map)#exit c2600(config)#router bgp 65500 c2600(config-router)#neighbor 192.168.66.191 remote-as 65501 c2600(config-router)#neighbor 192.168.66.191 route-map prepend out
If even the AS_Path is of the same length, the lowest origin code attribute is used. In practice, this means that internal BGP (iBGP) routes are preferred to the external BGP (eBGP) routes and eBGP routes are preferred to those marked as INCOMPLETE (which means such routes are redistributed from other routing protocols). This is important for an attacker to remember if he is planning to inject routes into BGP via route redistribution from vulnerable IGPs.
If the origin codes are the same, the path with the lowest Multiexit Discriminator (MED) is chosen . The values of the MED attribute must be sent from the same neighbor AS and are used between two neighboring ASs only. Thus, the only use for MED in traffic redirection is when more than one connection exists between such ASssetting a lower MED for a route will force the inbound traffic to flow through it. To redirect this inbound traffic, BGP packets with an appropriate MED are sent in the outbound direction to the neighbor AS, from which the traffic comes. The lowest MED value is zero; this is also the default value if MED is not explicitly set. Just as with the AS_Path prepending, MED is set via a route map using a set metric command:
c2600(config)#router bgp 65500 c2600(config-router)#neighbor 192.168.66.191 route-map change-MED out c2600(config-router)#exit c2600(config)#route-map change-MED permit 10 c2600(config-route-map)#set metric 100
And if somehow the default zero MED stands in your way, it is always possible to reverse it by executing bgp bestpath med missing-as-worst in a router configuration mode. This will force the router to treat the missing MED configuration as infinity rather than zero and make the path without a preset MED value the least desirable path. Also, by default, MED is compared only among paths from the same AS. If accepting MED from a different AS "tilts the balance" in your favor, a comparison of MEDs among routes regardless of the AS from which these routes are received can be enabled with bgp alwayscompare-med in the router configuration mode.
If the MED values are the same, then eBGP routes have preference over the iBGP routes. This is of a little value to the attacker.
If we are talking about iBGP routes only, the one with a shortest path to the next hop router will be selected. This provides an opportunity for the attacker to manipulate iBGP routes by attacking the "supporting" IGP if synchronization is enabled.
If everything above fails (which is not very likely), the router with the lowest router ID is going to be selected as the next hop. The router ID is usually the loopback interface IP or the highest IP address on a router. You can always verify it with a show ip bgp command.
While every listed route selection process element can, and should, be considered when reconfiguring the router to meet your aims, in reality manipulating weights, local preference, AS_Path, and MED should suffice.
So what can the crackers do with all the possibilities opened up by taking over a BGP router or inserting a rogue BGP router into the network? One such scenario, massive route de-aggregation, was already mentioned. When the stars are right (that is, the upstream providers do not filter the de-aggregated routes using appropriate prefix lists), this can lead to massive network destabilization, a DDoS kiddie's dream. However, experienced crackers can do many other things.
Possibly the most important and practical attack is prefixes or even AS numbers hijacking. This happens when a router starts advertising illegitimate prefixes and AS numbers onto the Internet or when someone sets up a rogue router connected to a hacked legitimate BGP speaker that was reconfigured to accept such a peer and pass illegitimate prefixes and AS numbers. Essentially, this is stealing someone else's IP address space and/or AS number. Usually, this type of an attack is complemented by changing Whois information in a Routing Information Registry (RIR) Whois registry to show the hijacker's name servers and e-mail address. Unused or old routable IP ranges (so-called zombie blocks ) and unused or little-propagated AS numbers ( Bogon ASs ) are targeted. Such AS numbers would not show in various RIRs, as can be checked with such tools as Hermes.
A typical example of Bogon ASs are ASs from 64512 to 65535, reserved by the Internet Assigned Numbers Authority (IANA) for private use (IANA-RSVD2). For example, such ASs can be used on the intranet of a large corporation with many remote branch offices and multiple links between them. Using BGP instead of OSPF or EIGRP on such an intranet offers more policy control and granularity for the corporation IT management. These AS numbers must be filtered out by providers, but this isn't always the case. A check in August 2003 demonstrated the presence of 11 bogus AS numbers advertised on the Internet. Thus, such incidents are real. And running the hijacking attack is ridiculously easy: it may only require the use of router bgp <AS number> and network <IP> mask <netmask> commands!
Why would anyone want to hijack IP address space and whole autonomous systems? The prime suspects are spammers, porn advertisers, and DDoS gangsor someone who sells or leases hijacked IP ranges and autonomous systems to spammers, porn advertisers, and DDoS gangs. But there is an even more sinister aspect to this. By hijacking and actively advertising the AS, which is not actively propagated through the Internet and registered with Internet Routing Registry (IRR) by its owners , a cracker has a chance of redirecting traffic to his router instead of the legitimate destination. This can be used to eavesdrop on this traffic and blackhole it as a form of a highly malicious DoS attack. To suck the traffic in, the attacker can advertise longer prefixes (as in a de-aggregation attack) and try to manipulate the AS_Path attribute, so that the path to his router is shorter than that of the legitimate one.
The quieter the AS in terms of its advertisement through the Internet and IRR registration, the more it is vulnerable to such a "shouting router" hijacking attack. This applies to ASs of smaller, recently registered companies on the "outer rim" of the Internet, or to the ASs whose owners (military or government agencies) do not want widespread advertisement. Here, matters of national security definitely enter into the game.
A lot of interesting information about hijacking attacks and their actual perpetrators can be found at http://www.completewhois.com/hijacked/index.htm and http://www.completewhois.com/hijacked/hijackers.htm . The AS numbers of ISPs actually supporting the hijackers or even the whole rogue ISPs are listedand there are quite a few of them.
How about other types of traffic redirection attacks? It's been said that while the IGPs are oriented toward reliability, convergence speed, and so on, BGP is designed and implemented with politics, money, and security (via policy routing and various types of filtering) in mind. The money aspect is very interesting. A cracker can modify BGP attributes to redirect network traffic through a more expensive path, thus causing serious financial loss to the target company or organization. Both inbound and outbound traffic can be a target of such attack, and the more expensive links are often backup lines installed for resilience or load-balancing purposes. Similar to ISDN dial-on-demand lines, such links are not supposed to operate in normal conditions. Sucking in traffic via deaggregation or BGP attributes manipulation can activate additional load-balancing links and generate responses to this unnecessary traffic, so-called scatterback , that congests the network and incurs additional costs. In addition, the scatterback (replies) can be employed in more sophisticated than run-of-the-mill script kiddie DDoS attacks.
Talking about DoS, a great magnitude of possibilities are opened up by interfering with BGP routing. One such possibility is blackholing. This refers to active advertisement of a route to the target trying to overtake the legitimate route. The intercepted traffic goes to null0 or is redirected to a sink interface. This is essentially a rogue sinkhole router, a routing honeypot that has been turned to the dark side. In network defense, sinkhole routers are used to consume DDoS traffic sent by attackers , but who said that the same techniques cannot be used by crackers to suck the legitimate traffic into nothingness ?
While we cannot devote much space to describing sinkhole routers here, we recommend that you consult RFC 3882 for more details on the topic. An 84-page tutorial by Barry Raveendran Greene and Danny McPherson on sinkholing, entitled "ISP Security-Real World Techniques," is downloadable from http://www.arbornetworks.com/downloads/research36/ . Together with "Customer-Triggered Real-Time Blackholes," by Tim Battles, Danny McPherson, and Chris Morrow ( http://www.nanog.org/mtg-0402/pdf/morrow.pdf ), this is a very good starting point for studying these techniques.
Another method is intentionally flapping the route. A route is flapping when it is repeatedly available, then unavailable, then available, then unavailable, and so on. A cracker can flap the route manually or write a shell script to do the job via Telnet login or SNMP (see RFC 1657). Depending on the network topology, configuration, and the attacker's position, route flapping can cause network instability in the form of intermittent reachability and blackholing to the victim prefixes.
To combat route flapping, the route dampening feature was introduced. When route dampening is enabled with a bgp dampening command, the route that has flapped so often will not be advertised to BGP neighbors. While this makes perfect sense, route dampening can also be abused by attackers to block traffic to an upstream router. Even a single BGP withdrawal followed by a re-announcement can trigger route dampening and kill the route for up to an hour. If a different path is available, the traffic will have to take that path. Thus, a skilled attacker can use intentional route flapping for traffic redirection.
Finally, an attacker can potentially cause network havoc by advertising private RFC 1918 prefixes and IANA-RSVD2 AS numbers via BGP. Whether such an attack would work or not obviously depends on how strict the neighbors are at filtering bogus IP and AS numbers. If they aren't strict, routing loops, splits , and leaking internal information to the outside from networks using these IP ranges and AS numbers privately may occur.
You can view Bogon lists and real-world Bogon advertisement cases at http://www.cymru.com/Bogons/index.html and http://www.completewhois.com/bogons/index.htm .
It is possible to invade a BGP routing process by taking over a machine plugged into the same switch with legitimate BGP speakers. This type of attack is largely opportunistic in nature and dependent on answers to several questions: Would such host be close to the BGP routers attacked ? Would it be vulnerable? Are ARP spoofing countermeasures available and enabled on a switch? Is TCP Options MD5 authentication of the BGP process in use? Thus, possible in this particular case is far away from definite , although for most attackers, something is always better than nothing.
In this scenario, a semi-blind attacker would first sniff out the BGP packets to determine the necessary parameters for the rogue router configuration. We have already discussed various aspects pertaining to switched network sniffing, including Layer 2 attacks that can come in handy in this case. If MD5-based authentication is in use, it will have to be cracked first. (We'll discuss TCP Options MD5 cracking soon in the chapter, so don't worry about this attack for now.) After deciding how the rogue router should be configured, we recommend you prepare the configuration file before launching the actual attack. If you are using Quagga, the sample configuration file is called bgpd.conf.sample , and it is stored in the /etc/quagga/samples directory. (Another sample configuration file, bgpd.conf.sample2 , is also located in this directory. This file illustrates running BGP on IPv6 networks and we will not dwell on it here.)
Enter or change all the configuration lines you deem to be necessary in bgpd.conf.sample apart from logging, the syntax is essentially the same as on an IOS router. The configuration of the rogue router must reflect the guessed configuration of a router you are going to masquerade, plus it must contain the changes representing the actual attackfor example, added prefixes, changed netmasks, altered weights, local preference, AS_Path, and MED. Obviously, we cannot give you a precise configuration example here, since its contents would depend on the masqueraded router's settings and the alterations to routing that you want to make.
You can use one of many free, open source implementations of the BGPv4 protocol to set up a rogue router. In fact, probably more of them exist for BGPv4 than for any other common IP routing protocol. Many such implementations , some quite compact (OpenBGPD, for example), can be downloaded from http://www.bgp4.as/tools .
Next, isolate the targeted BGP speaker via an ARP attackfor example, using the Ettercap isolate plug-in or host isolation option in ArpWorks for Windows ( http://www.packetstormsecurity.nl/Win/ArpWorks10.EXE ). Check whether the isolation is successful via ping , traceroute , TCP ping, and so on. Launch your rogue router to substitute the isolated BGP speaker by running bgpd -d. Voil ! You can now feed malicious routes to the non-isolated BGP peer. Of course, this attack is brutal, easy to discover, and causes loss of connectivity for the router you have isolated. However, if the aim of a cracker is to cause utter global network carnage via route flapping, de-aggregation, and so on, this will do the job. For a more "gentle" BGP route injection, a more elegant solution is needed.
A more gentle BGP route injection can come in the form of a bidirectional man-in-the-middle attack. While this looks quite feasible in theory, in practice it is an entirely different manner. Take, for example, a standard ARP spoofing man-in-the-middle attack. It is easy to insert a host plugged into the same switch in between two BGP speakers, but what comes next? Both speakers have defined each other as neighbors in the configuration. Thus, for a successful insertion of a "neighbor between neighbors," a rogue router must do the following:
Spoof the addresses of both neighbors simultaneously .
Present each neighbor an IP address (the ip addr add command in Linux 2.6.x does not require the creation of separate subinterfaces to do that) and the AS number of its legitimate peer.
Bind two instances of Quagga or another routing suite to these two specific addresses.
Route traffic between these two IP addresses, likely with a need to establish a BGP session between both instances of Quagga within a single host and calculate an impact of this session on the overall BGP routing process.
By no means is this an easy task, especially on the "owned" remote host, when a single error can cut the attacker off for good. Unfortunately, due to time constraints, we didn't have a chance to test these settings in a routing lab and determine whether such an attack is feasible; this is one of the many things on our TODO list. Meantime, a tested and tried attack against BGP sessions is available: BGP route insertion via TCP session hijacking.
A successful TCP hijacking attack against BGP requires the following:
Correctly matching source address
Correctly matching source port
Correctly matching destination port
Correctly matching TTL if a BGP TTL hack (more on this in the Countermeasures section) is applied
Correctly matching TCP sequence numbers (a great trouble for a blind remote attacker, but not a problem when you can sniff the section)
Bypassing TCP Options MD5 authentication (if applied)
To launch the actual hijacking attack, we will employ tcphijack from CIAG BGP tools ( http://www.cisco.com/security_services/ciag/tools/ ). It is quite straightforward to use:
arhontus # ./tcphijack Usage: tcphijack [-hv] -c client_name -s server_name -p server_port [-t trigger_file] [-P payload_file] [-d fire_delay] -h: this help -c: Client host name or IP address. -s: Server (victim) host name or IP address. -p: Server TCP port. -t: Trigger file. -P: Payload file. If payload_file is "-" then read from stdin. -d: Fire delay. -v: Show version information.
The payload file can be a text file with a command to be executed when a Telnet session is hijacked. This is very useful when attacking a Telnet connection to a router; however, this is not the purpose of this chapter. In our case, the payload file is a payload binary of a BGP Update or a BGP (error) Notification packet. We are not really interested in BGP Open or BGP keepalive packets, since the session is already present and the peers exchange keepalives anyway.
The first thing to do before running the attack is to build a necessary binary payload. Tcphijack is supplied with a bgp-update-create utility that takes AS number, next hop router IP address, and a route to advertise as input:
arhontus# ./bgp-update-create --as 6500 --nexthop 192.168.10.1 --destnet 192.168.15.1/24 > evilpacket
You can also capture live BGP packets from routers into pcap format files, edit these files with NetDude (has a nice GUI and can be downloaded with all the necessary drivers at http://www. sourceforge .net/projects/netdude/ ), open the edited packets with Ethereal, and cut/ paste the binary payload from there. This is similar to what we described in Chapter 7 when talking about creating SNMP test cases for Protos. Consult the SNMP fuzzing information in Chapter 7 for a greater understanding of the technique. Instead of using an actual BGP router (which can be a Linux box with a software routing suite anyway), you can try packet generators that support BGPv4 constructionfor example, IPsend and Spoof.
The next step is to ARP spoof the connection between both BGP peers using your favorite ARP-based man-in-the-middle attack tool, such as Dsniff or Ettercap. You can also try ARP spoofing across VLANs using Yersinia. (Classic ARP spoofing is described in all editions of Hacking Exposed as well as many other security tomes and online sources; we won't spend precious time and space outlining them here.) After the ARP spoofing succeeds, launch tcphijack and feed the generated payload into the targeted session:
arhontus# ./tcphijack -c 192.168.10.12 -s 192.168.10.15 -p 179 -P evilpacket
Voil ! The route has been inserted. The inevitable ACK storm would occur for a few minutes, but it is unlikely to affect the BGP session attacked.
The authentication mechanism of BGPv4 is described in RFC 2385, "Protection of BGP Sessions via the TCP MD5 Signature Option." In accordance with this RFC, every segment sent on a TCP connection is authenticated by a 16-bit MD5 hash generated by running the MD5 algorithm against the following packet fields:
TCP pseudo-header (in this order: source IP address, destination IP address, zero- padded protocol number, and segment length)
TCP header, excluding TCP options and with a null checksum TCP segment data if present
In a nutshell , all the information we need to calculate MD5 authentication hash is present in the TCP packet except for the shared secret, which we can attempt to crack via a dictionary or bruteforce attack. For that, we are going to use bgpcrack from CIAG BGP tools. In fact, the TCP segment MD5 hash can be used to authenticate any protocol running over TCP, and the utility can be employed to attack all such cases. Nevertheless, here we are interested only in BGPv4, so the name is quite appropriate.
Bgpcrack can be run in online and offline modes. An online mode bombards the target with TCP segments with a set SYN flag and MD5 signature generated using different passwords. If the signature is valid, the router will send back a SYN-ACK. This is not an efficient attack methodology, however, since generating and sending TCP packets with MD5 signatures is resourceand time-consuming . Thus, it is recommended only for blind-attack attempts. One can also use a combination of ciag-bgp-tools ttt TCP generator and John the Ripper for online BGP authentication cracking. A small Perl script called tcp-sig-crack.pl in the examples directory of ttt is useful to run such attackshere's an example:
john -wordfile:/path_to_a_dictionary_file/ dictionary.txt -stdout examples/tcp-sig-crack.pl -S <source IP> -D <target IP> --dport bgp --syn
A much better approach is running bgpcrack offline against a captured pcap file containing signed BGP packets. For a semi-blind attacker, capturing BGP packets after using ARP-based or another man-in-the-middle attack is not a problem. Just make sure that at least one complete BGP packet is caught for the attack to be possible. An example of an offline attack is as follows :
arhontus# ./bgpcrack -r bgppackets.pcap -w dictionary-file port bgp 90 frames have been processed. There are 73 TCP segments with MD5 signatures. Using 6720 bytes for storage of MD5 data. Found a match in frame 5. Password is 'secretbgp'. Bye.
In this example, port bgp is an optional pcap/tcpdump expression that limits which frames from the pcap dump we pay attention to.
While DoS attacks may not be extremely exciting, bringing down an important BGP peer or causing route flapping or dampening may have devastating consequences. In addition, to run a DoS attack, you don't have to be in close proximity to the target. The simplest scenario for such a DoS attack is a SYN flood against TCP port 179. However simple, the efficiency of such an attack is questionable if one compares the capabilities of a typical DoS kiddie machine and network link with a modern backbone Cisco router. Nevertheless, the possibility of a massive DDoS SYN flood should never be discarded as a valid threat.
A more interesting option is flooding the target BGP service with enabled MD5 authentication using SYN TCP packets with MD5 signatures. This adds a load of MD5 processing by the attacked router and thus consumes more resources. Such an attack is easy to implement with ttt using its --md5 <string> option. To optimize the flood, four instances of ttt can be launched at both peers, hitting the "server" TCP 179 ports and high "client" TCP ports simultaneously. This task is made easier by the fact that the high BGP "client" ports always appear to be the same on both routers and in all our observations belonged to the lower 11000-something port range.
Here is an example of a double flood that successfully hanged an old 2500 router one hop away from the attacking machine and caused BGP route flapping:
arhontus# ./ttt --flood 10000000 -y 11006 --syn --md5 allyourbgparebelongtous -D 192.168.66.191 && ./ttt --flood 10000000 -y 179 --syn --md5 allyourbgparebelongtous -D 192.168.66.191
A success in attacking more powerful routers with such a flood is still problematic .
Recently, a lot of noise has been made about a potential remote connection reset attack utilizing a TCP window size and the fact that TCP sequence numbers need to fit into this window rather than being precisely matched to be accepted. Cisco even released an appropriate advisory ( http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml ), assigned two Bug IDs (CSCed27956 and CSCed38527) to this particular vulnerability, and provided a fix for it in accordance with the IETF draft, available at http://www.1.ietf.org/proceedings_new/04nov/IDs/draft-ietf-tcpm-tcpsecure-01.txt . A variety of DoS tools written in various languages and aimed at resetting TCP connections in a way that is supposed to be more efficient than a straightforward TCP sequence numbers bruteforcing immediately sprang to life. You can download nearly a dozen of them at http://www.osvdb.org/4030 , including a modified version of ttt we used earlier to flood.
To check whether such an attack can be successful, we have employed this tweaked ttt version as well as reset-tcp_rfc31337-compliant.c and bgp-dosv2.pl against two BGP peersone being a new 2600 router running IOS 12.3.6 and another an ancient 2500 machine running an obsolete IOS 11.0(8). Of course, the TCP Options MD5 BGP session authentication was turned off during the testing. To our surprise, the attack did not work even against the old, battered Cisco 2500 and even when left to run overnight, casting a shadow of doubt on whether the whole issue was somewhat exaggerated. Not even a single BGP session was reset and only four retransmits occurred, which could well be attributed to other factors, such as network congestion caused by nightly scheduled updates of Gentoo and Debian boxes running Quagga on a testing network. In comparison, a single SYN-MD5 flood with ttt mentioned earlier caused 425 BGP retransmits.
Many IOS TCP/IP stacks have hard-to-predict TCP sequence numbers, which is the main reason why the blind TCP RST attack may not have been successful. Many tools are available for checking TCP sequence numbers randomization remotely, including Nmap (run with a -O flag), hping2 , and isnprober . It is recommended that they be run against the target router prior to the attack to estimate the chances of possible success.
Consider the DoS-tested 2600 router from the preceding example:
arhontus# nmap -sS -O -vvvv 192.168.66.215 <skip> TCP Sequence Prediction: Class=truly random Difficulty=9999999 (Good luck!) TCP ISN Seq. Numbers: 5142798B A95D7AC9 71F42B5A 4D684349 FF2B94D4 B764FD5C <skip> arhontus# # perl isnprober.pl -n 10 -i eth0 -p 23 192.168.66.215 -- ISNprober / 1.02 / Tom Vandepoel (Tom.Vandepoel@ubizen.com) -- Using eth0:192.168.77.5 Probing host: 192.168.66.215 on TCP port 23. Host:port ISN Delta 192.168.66.202:23 -1154503313 192.168.66.202:23 -24125463 1130377850 192.168.66.202:23 2031059534 2055184997 192.168.66.202:23 965205234 -1065854300 192.168.66.202:23 -1974685094 -2939890328 192.168.66.202:23 1760147902 3734832996 192.168.66.202:23 2089287258 329139356 192.168.66.202:23 -923724721 -3013011979 192.168.66.202:23 -934490140 -10765419 192.168.66.202:23 -1262713275 -328223135
The fact that this TCP RST attack did not work hardly comes as a surprise!
The variety of countermeasures against BGP abuse reflects both the importance and complexity of this protocol. In this brief section, we can give you only a taste of what they are like. BGP defenses can be split into several categories:
While it is exciting to dwell on new BGPv4 security propositions , such as AS Path Validation or Listen and Whisper protocols, this is a practical, down-to-earth book and we have to protect the network with what we have at hand. Thus, we shall briefly discuss BGPv4 security countermeasures based on Cisco SAFE: Best Practices for Securing Routing Protocols and Team Cymru Secure BGP Template (Version 4.0, 03 Aug 2005). If you are interested in deeper and more theoretical aspects of BGP security, we recommend skimming through a wonderful collection of relevant papers at http://www.bgp4.as/security .
BGPv4 MD5-based authentication is done on a neighbor basis:
c2600(config)#router bgp 65500 c2600(config-router)#neighbor <IP address> password <shared secret>
More security countermeasures can be put in place using the neighbor command, including the following:
Announcing only those networks we specifically list with neighbor <IP address> prefix-list announce out . This would also prevent the network from becoming a transit provider and is a useful countermeasure to add for nontransit ASs.
Block inbound Bogons with a prefix list: neighbor <IP address> prefix-list bogons in
Set up appropriate route distribute lists: neighbor <ip-address peer- group -name> distribute-list <access-list-number name> <in out>
Set the limit on the amount of advertised prefixes to prevent de-aggregation type of attacks: neighbor <IP address> maximum-prefix 175000
Use the loopback interface for iBGP announcements to increase the iBGP stability: neighbor <IP address> update-source Loopback0
Of course, the actual Bogons and announce prefix lists must be in place first. The general filtering recommendations for creating such lists are shown here:
Deny special prefixes assigned and reserved for future use.
Deny overspecific prefix lengths (de-aggregation, "traffic sucking").
Deny exchange point prefixes.
Deny routes to internal IP spaces (RFC 1918).
If you are an ISP, restrict routes exchanged with customers to those concerning customer-declared IP space.
If you are an ISP, restrict routes exchanged with peers, depending on the relationship with peers and between peers.
Deny over-general prefix lengths (this is more likely to be an error than an attack).
Deny inappropriate length RIR allocations .
Deny inappropriate announcements for legacy A/B/C space (we use CIDR, don't we?).
Defend critical networks (backbone, specific customers) by defining different network levels, such as platinum , gold, and silver, and allowing only certain routes on each level.
Deny route flap dampening on "gold" and "platinum" networks.
We have already demonstrated how to write prefix lists when describing defenses against IGP attacks. For more information on the topic, please consult the Cisco web site at http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdbgp.htm#wp1001483 . In addition to filtering network prefixes, you can also filter incoming and outbound BGP updates based on the BGP autonomous system paths or, to be more precise, the AS numbers in these paths. This may involve big politics: a country or a whole political block doesn't want any traffic coming from or going to the opposing country or alliance territory, a large corporation trying to do the same with their competitors ' ASs, and so forth. It can also involve big money (Tier 1 ISP tariffs) and chopping away entire rogue ISPs and massive networks abused by spammers or DDoS racket gangs. AS path filtering is done via setting an AS path access list and assigning it to an appropriate neighbor:
c2600(config)# ip as-path access-list <access list number from 1 to 500> <permit deny> <A regular-expression to match BGP AS paths> c2600(config)#router bgp <AS number> c2600(config-router)#neighbor <IP address peer-group-name> filter-list <as-path access list number> <in out>
A primer on using regular expressions in AS path filtering on Cisco routers is available at http://www.cisco.com/warp/public/459/26.html and http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/arbook/arapptrn.htm . A useful crammed reference to these expressions can be viewed at http://www.911networks.com/pages/cisco/bgp/regularexpressions.php .
After you have configured the mighty AS path lists, do not forget about the casual extended ACLs to block access to the TCP port 179 from nonneighbor IP addresses.
As for BGP flapping route dampening, enable it even though, as mentioned earlier, the attackers may actually abuse it. However, a proper BGP dampening configuration goes well beyond the bgp dampening command and involves creation of route maps and a variety of prefix lists to reduce the effect of dampening on the shorter and historically more stable prefixes, as well as IP ranges that contain DNS root servers. This is done in accordance to the RIPE recommendations on flapping route dampening safety. Ready and working examples of these prefix lists and route maps can be taken directly from the Team Cymru Secure BGP Template ( http://www.cymru.com/Documents/secure-bgp-template.html ).
Our last stop is the so-called "BGP TTL hack," defined more politely as a BGP TTL Security Check. Turning on this lightweight security mechanism blocks attempts to hijack eBGP peering sessions by a cracker on a network segment that is not part of either BGP network or by a cracker on a network segment that is not between the eBGP peers. BGP TTL Security Check was first introduced into IOS 12.0(27)S and further integrated into the IOS releases 12.3(7)T and 12.2(25)S. This feature protects eBGP but not iBGP peering sessions by comparing the value in the TTL field of received IP packets with a hop count that is configured locally for each eBGP peering session. If the value in the TTL field of the incoming IP packet is greater than or equal to the locally configured value, as it should be, the IP packet is accepted and processed normally. If the TTL value in the incoming packet is lower than the locally configured value, the packet is silently dropped. Any response to a spoofed packet is unnecessary and will only consume the router's resources.
Before configuring the BGP TTL Security Check, you must turn the neighbor ebgp- multihop setting off. Then enable the check with a neighbor <IP address> ttl-security hops < hop-count > command in a router BGP configuration mode. The hop count defines how far an external BGP neighbor can be. All eBGP packets sent from hosts farther away than the hop count set will be discarded.
Finally, do not go berserk over an accidentally lost BGP keepalive packet and turn bgp fast-external-fallover off. This can help to withstand DoS floods without flapping the routes. Also, do not forget to enable bgp log-neighbor-changes to see whether your BGP neighborhood is OK when running an occasional show logging command.