Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions

A lot of useful data can be obtained from querying routing protocols or sniffing routing updates leaking from the networks of interest, including the following:

• Network addressing schemes

• Information about the network owner and location (BGPv4 enumeration)

• Interesting hosts (gateways, routers with special roles in the routing domain)

• Routing policies and rules implemented ( mainly BGPv4 enumeration)

• Security of the routing protocol enumerated (which provides a direct avenue to the routing protocol exploitation in the form of remote insertion of malicious routes to block or redirect legitimate traffic)

Autonomous System Discovery and Mapping: BGPv4 Interrogation

BGPv4 is the glue that holds the modern Internet together. Want to know which networks belong to a given organization or even a country? How about finding which countries and organizations are interconnected , and what kinds of routing policies govern these connections? Need to know where the routes you advertise spread on the Internet and who filters them, or find out through which organizations and locations the traffic flows? Ask BGP.

Before doing that, you should become well-accustomed to the concept of autonomous systems . An autonomous system (AS) is a set of routers that shares a single routing policy under a single technical administration. Usually, an AS is bound to an organization, although large organizations can deploy multiple ASs. While in many sources this term is used for interior gateway protocols (IGPs) such as Open Shortest Path First (OSPF) as well as for BGPv4 ASs, we do not consider this to be correct. In this book, the term AS is used exclusively to define BGPv4 ASs. For IGPs, the term routing domain is applied. The IGP routing domains are defined by local system administrators and can have any numbers assigned to them. To the contrary, the 16-bit identifying numbers for BGPv4 ASs are assigned by an Internet registry unless they belong to the private range (6541265535). In that case, the AS numbers are usually handed out by the ISP.

BGPv4 ASs introduce an additional layer of hierarchy to the Internet and large intranets . This can be seen as an additional layer of network separation above the network IP ranges and is underlined by routes aggregation, usually at AS borders. Hierarchy means more control, and, indeed, the primary reasons for defining BGP routes are not technical, but political, security- related , and economical. For example, U.S. government organizations would not like to route any traffic via ASs that belong to "Axis of Evil" countries. On the other hand, this makes BGP routing an attractive target for politically motivated hackers (so-called "hacktivists") or people with grudges against a particular organization. While the first type may try to impair a country's connectivity to the Internet, the second type could have a go at rerouting a targeted organization's traffic via a more expensive link, causing a substantial financial loss.

A BGPv4 AS is seen as a single entity to the outside observer. However, there are different types of ASs. Single- homed ASs with a single point of entry between an organization and the ISP (a so-called stub AS ) should use BGP only if the organization possesses too many noncontiguous network ranges to use static routes efficiently . If such is the case, it is likely that an ISP would assign a private AS number to the customer organization. Querying such numbers from the Internet would not provide attackers any information.

Multihomed nontransit AS is a typical way of connecting a multihomed organization to the Internet. Here, nontransit refers to the fact that no transit (remote AS to remote AS) traffic is passing across such AS, and it does not advertise routes learned from other ASs. This is the theory. In practice, however, everything depends on how well the BGP filters are configured on the nontransit AS border routers, and any filter misconfiguration can be abused to pass illegitimate traffic through the AS.

Another concern considering the security of multihomed nontransit ASs is whether they are interconnected to a single or different providers and, in the second case, whether the different providers involved may share the same path to the Internet backbone. One of the modern-day reasons why people want a multihomed network is DoS/DDoS attack resilience. However, multihoming to a single ISP or two ISPs that converge the routes on a single path to the higher tier providers gives only a limited DoS/DDoS resilience, complemented by a fake sense of security.

Multihomed transit AS is open to the traffic that does not belong to it. Usually, such ASs belong to ISPs and have transit routers that carry routing information from other ASs via Internal BGP (iBGP) within the AS as well as border routers that interface with other ASs employing External BGP (eBGP). The transit router's iBGP routing is vulnerable to lateral attacks that abuse IGP routing, often necessary to carry iBGP updates through a vast internal network of the AS. This kind of attack is even more threatening if route distribution from IGPs into BGP is enabled (which is often the case). The IGP protocols are sometimes less protected than the BGP (for example, RIPv1) and do not have that much attention paid to their security.

So where should we look for the information related to AS assignment, structure, and policies?

Internet Routing Registries, Route Servers, and Looking Glasses Querying

The need for a unified routing and routing policy database was recognized as early as 1989. The first such database, the NFSNET policy routing database (PRDB) was deployed back in 1991. Since that time, many routing databases, collectively known as the Internet Routing Registry (IRR), came into existence. The oldest routing registries (RRs) still in operation are the RIPE RR and the Routing Arbiter Database (RADB).

Throughout this chapter, we will extensively use the RADB and RIPE databases and online and offline tools to enumerate networks using BGP. Routing Policy Specification Language (RPSL) is used to describe routing policies in the RRs. In recent times, it has been expanded to become Routing Policy Specification Language next generation (RPSLng). RPSL and RPSLng describe a variety of objects related to the routing policies registered with the RR. While explaining these languages in detail goes beyond the scope of this chapter, if you want to understand the operation of RADB, RIPE, and other RRs, we suggest you consult RFCs 2622, 2650, and 2725, the latter describing the (not-so-flawless) security of the RRs themselves .

Of course, if system administrators do not register with the RR and do not provide routing policy information for it, no interesting data can be retrieved about their networks using these databases. So what makes people provide data about their networks routing peculiarities to the public domain? First of all, many large providers (for example, Sprint) would not propagate your BGP routes unless you register with the RR. Then, if some problem with your AS routing occurs, the peer autonomous systems administrators can check whether your routing policies have changed and what kind of a routing problem you experience. This will help them to reconfigure their routers to alleviate the problem. In addition, this information helps router administrators filter the routing updates they receive to avoid intentional or unintentional routing instability.

This is where security kicks in. Imagine that the attackers have modified the routing updates coming from the network or inserted fake updates into the routing exchange (something we deal with in the last tchapter of this book). Then peering networks' administrators can compare the actual updates with the RR RPSLng entries, spot the difference, and ring the alarm bell. Otherwise , it is quite difficult to discover that the updates were tinkered with and even more difficult to determine that the tinkering was done by hackers and not a legitimate system administrator. Thus, proper RR entries can assist in routing intrusion detection and forensics.

As to employing the RR entries for configuring one's routes and route filters, even online tools use these entries for automatic BGPv4 configuration fragments and filters creation. Examples of such tools are available at http://www.netconfigs.com and are shown in Figures 4-1 and 4-2.

Figure 4-1: Online Cisco BGP Toolkit from http://www.NetConfigs.com

Figure 4-2: Online Cisco BGP Config Tool from http://www.NetConfigs.com

Alternatively, you can use the offline RtConfig and peval UNIX tools provided by the RIPE Internet Routing Registry Toolset (IRRToolSet) Project ( http://www.ripe.net/ripencc/pub-services/db/irrtoolset/ ). The online prototypes of these utilities are also available at the RIPE web site. As stated in the tool's man page, "RtConfig analyzes the routing policies registered in the IRR and produces router configuration files. It supports Cisco, junos, nortel /bay, gated, RSd router configuration file formats." At the same time, "peval is a low level policy evaluation tool that can be used to write router configuration generators. Peval, in a command loop, inputs policy expressions; expands the AS sets, route sets, filter sets, AS numbers (unless specified otherwise using command line options); evaluates the resulting expression; and outputs the result. Instead of a command loop, the expression can be given as an argument."

You may also encounter these tools as a part of RAToolSet, which is the previous name of the IRRToolSet before it reached version 4.7.2.

How does one determine whether a route is properly registered in the RR? Try out the Routing Registry Consistency Check site at http://www.rrcc.ripe.net/RRCC_query.html . Mention that you can run a consistency check for multiple autonomous systems at once, perhaps systems that belong to an organization or country of interest. Figure 4-3 shows unregistered AS peerings for Latvia.

Figure 4-3: Routing Registry Consistency Check for the country of Latvia

To summarize, providing up-to-date routing policy information to your friendly RR is a good networking and network security practice, even though this will disclose some information about your network to potential attackers.

Another wonderful source of information about various networks of interest is public route servers and looking glasses . A route server is a host that assists interconnection among ISPs by gathering and redistributing routing information to each ISP it serves. By itself, a route server does not forward packets and switch traffic among the ISPs. It does not have to be a Cisco router and can be, for example, a UNIX/Linux machine with appropriate routing daemons (Zebra, Quagga, BIRD, Gated, MRT, and so on) running. Some route servers are public, which means you can log in to such a box via telnet to access a restricted privilege environment and query the server about the status of its routes.

Looking glass was initially the term used by Ed Kern to describe a functionality of a Common Gateway Interface (CGI) script he ran on the nitrous.digex.net web site (down at the time of writing). The script interfaced with Digex routers and allowed outsiders to check routing tables and execute routing-related show commands on them. Nowadays, this term is widely used to describe router-interfacing CGI scripts (for example, MultiRouter Looking Glass, available at ftp://ftp.enterzone.net/looking-glass ) or actual publicly accessible routers that allow similar functionality. If you want to have a look at various software looking glasses' source code, or even try it out, surf to http://www.traceroute.org/#source%20code for a selection of nearly a dozen looking glass sources.

As well as analyzing network routes, both routing glasses and routing servers are useful for pinging and tracerouting remote hosts and useful for evaluating IP filtering rules of remote routers and firewalls. Can't ping or traceroute a host from your IP? Telnet to an appropriate looking glass or route server (perhaps one close to the evaluated host) and try it from there. While the majority of route servers and looking glasses offer passwordless telnet access, some also provide a friendly web interface in which commands can be executed. Keep in mind that telnet access usually provides a larger variety of commands permitted for remote execution, and different looking glasses/route servers offer different amounts of allowable commands for remote users to run. As a rule of thumb, ping , traceroute , show ip bgp , show ip bgp summary , and show ip bgp neighbors should be available. Figure 4-4 shows the web interface of the RIPE RIS Looking Glass, available at http://www.ris.ripe.net/cgi-bin/lg/index.cgi .

Figure 4-4: RIPE RIS Looking Glass web interface

We strongly suggest that you telnet to various looking glasses and public route servers and play with them, checking which commands are allowed and what output they will produce. This will also significantly enhance your "cybergeography" knowledge.

The Internet lists of publicly accessible route servers and looking glasses are more than abundant. You can check out some of them at the following URLs:

• http://www.traceroute.org/

• http://www.bgp4.as/looking-glasses/

• http://www.netconfigs.com/general/cisco-telnets.htm

• http://www.nanog.org/lookingglass.html

• http://www.mkm.ro/lg/

How do you find a route server or a looking glass for a given area or network range? One way of doing this is by consulting the CAIDA reverse traceroute and looking glass servers at http://www.caida.org/analysis/routing/reversetrace/ (shown in Figure 4-5). You can either click the nodes on the map or use the Live Query/Search for Servers button that will bring you to the Reverse Traceroute/Looking Glass Search menu (Figure 4-6).

Figure 4-5: Worldwide reverse traceroute and looking glass servers on the CAIDA web site

Figure 4-6: Reverse Traceroute/Looking Glass Search menu

While the CAIDA search may help you to find the looking glass for the place or AS of interest, there is no search for the IP or IP range. Of course, you can easily map an IP range to the AS number, as we describe later in the next section. However, you can also employ our old friend Google to find a lot of useful information about the IP range, including a route server or a looking glass belonging to the ISP or other organization that owns this range. For example, if we want to find some information about the randomly picked 195.66.226.0/24 network range, we search for "195.66.226.0/24," and this brings us nothing. Now we enter 195.66.226 and hit "Search," and voila! The looking glasses for this IP range appears as Linx looking glasses at http://www.linx.net/tools/index.html; the routers for that network are of a Foundry make (according to Google anyway)plus, we can also see the network's ICMP traffic statistics, a fat report on its BGP peering, and a whois output published to a comp.security.firewalls mail list. Never underestimate the power of Google! Of course, a detailed whois query for any IP in the example network range will bring us even more information, including an AS number.

Mapping IP Addresses to Autonomous Systems

Knowing to which AS the IP address belongs helps to find the network range for that particular IP, establish its ownership, determine its approximate geographical position, and determine how we can route to or from it. This can be done in many ways. A simple whois query can give you an AS number for the IP queried in the "Origin" field of the response. However, to be sure that you get more useful information, use whois servers with a stated Routing Information Services (RIS) query/RPSL format support. Such servers include RIPE ( http://www.ripe.net/db/whois/whois.html ), RADB ( http://www.radb.net/cgi-bin/radb/advanced-query.cgi ), and Netconfigs ( http://www.netconfigs.com/tools/whois.htm ) whois servers, advanced search web interfaces, some of which are shown in Figures 4-7, 4-8, and 4-9.

Figure 4-7: RIPE whois advanced search

Figure 4-8: RADB advanced whois query

Figure 4-9: NetConfigs whois search

Of course, you don't have to use the web interface to query these serversa traditional command line whois can be used just as well, employing all the options listed in Figure 4-7, while having an advantage of a scriptable output. For example, to query a RIPE whois from the command line, use this command:

whois -h riswhois.ripe.net <IPv4 or IPv6 IP or IP range with a /prefix notation>

Or you can use similar commands. Team Cymru provides a public whois server at http://www.cymru.com/BGP/whois.html , with the specific aim of mapping IPs to AS numbers, bulk mappings included. This server's database is based on information collected from 17 BGP peers and is updated every 30 minutes. The instructions on using the Team Cymru whois server are shown here:

arhontus# whois -h whois.cymru.com help [COMMANDS] help - this message bulk begin - enable bulk input mode (use with netcat) quit end - exit the whois/netcat client (use with netcat) [SYNTAX] Each line may have IP syntax that follows any of these standards: 4.2.2.1 4.2.2.1 06:01 GMT 4.2.2.1:80 4.2.2.1:80 06:01 GMT [EXAMPLES] Bulk input requires the use of ''netcat''. The syntax for a bulk input session might look as follows: netcat whois.cymru.com 43 < ./list.txt Where list.txt must follow the following syntax: begin 4.2.2.1 ... end

Another easy way of mapping IP or domain name to the AS number is by using the network search tools available at http://www.fixedorbit.com/search.htm . This offers an additional advantage of finding detailed information about the AS to which your IP got mapped, simply by clicking the AS name link presented. You'll also find various specific command-line UNIX tools that can perform IP-to-AS mapping, including aslookup ( http://www.bugest.net/software/aslookup/index-e.html ) for FreeBSD (compiles and works on Linux and Solaris, too) and Team Cymru ip2asn Perl scripts, closely related to the Team Cymru whois server mentioned earlier ( http://www.cymru.com/gillsr/tools.html ).

Enumerating an Autonomous System

Now that you have found the AS to which the range of IPs you looked for belongs, it is time to gather information about that particular AS. A FixedOrbit search comes in handy (Figure 4-10).

Figure 4-10: FixedOrbit search tools

Using this search, you can discover the following:

• The AS owner, owner's web site, and whois information

• The AS peers and neighbors

• The amount of IPs controlled and issued by the AS administration

• All network ranges and prefixes that belong to the AS

• The countries where these networks are located

• The utilization of the IP space on these networks

This is invaluable information for an attacker aiming to run a mass scan for some new vulnerabilities against a particular organization, since he or she would be able to pick up the largest and most populated network ranges to scan and select networks that belong to this organization in different countries. This makes legal persecution of the attacker more difficult due to the differences in cybercrime legislation in different countries.

Of course, this information and more can also be obtained manually by logging into the route server or looking glass belonging to the AS and running commands like show ip bgp , show ip route , show bgp summary , show ip bgp summary , show ip bgp neigbors , show ip bgp community , show ip bgp cidr-only , show ip bgp labels , show ip bgp paths , and other more esoteric commands, including show for prefix, filter, and BGP community lists.

A variety of useful queries about an AS of interest can be done against the RIPE RIS database using RIS tools ( http://www.ripe.net/projects/ris/tools/index.html ). Searching RIS for an AS number (Figure 4-11) brings a wealth of information, including its peering routers' IP addresses and next hops from the AS, the Multiexit Discriminator (MED) BGP attribute, the BGP route's origin, AS path, and relevant BGP communities.

Figure 4-11: RIPE RIS AS search

Just as easily, you can check where the number of the AS of interest has appeared in the global routing tables (Figure 4-12).

Figure 4-12: RIPE RIS ASInuse search

The ASInuse search helps to determine where the data originating from or entering into the AS you are looking for can be sniffed and modified. RIS tools also offer the same search types for a network (prefix) rather than the whole AS (search by prefix and PrefixInUse at the RIS tools site). This helps you zero in on a particular network belonging to the AS and is a logical step to follow the AS and ASInuse searches. Another interesting AS-related search to do at RIPE RIS is finding flapping routes for the AS (Figure 4-13).

Figure 4-13: RIPE RIS BGP Routing Hot Spot Utility by AS

From the system administrator's viewpoint, a flapping route indicates a connectivity problem. From the attacker's perspective, such a link is more vulnerable to a DoS/DDoS attack"push the one who is already falling" (F. Nietzsche).

Finally, in case you want to verify the validity of various AS-related online searches and whois queries, you can always consult the extensive lists of AS mappings published on the Internet. First of all, you can see which Internet authority has allocated the AS number you are looking for at http://www.iana.org/assignments/as-numbers . This would provide a vague idea of where the AS of interest is positioned geographically . Proceeding further, the CAIDA list ( http://www.caida.org/analysis/geopolitical/bgp2country/as2country.txt ) provides per-country AS allocation. CAIDA also provides more precise central AS administration location coordinates at http://www.caida.org/analysis/topology/as_core_network/Data/skitter.degree.20020401-20020416.txt . A quick way of searching for these coordinates and other useful information is by using the CAIDA NetGeo tool ( http://www.netgeo.caida.org/perl/netgeo.cgi ), shown in Figure 4-14, but as the NetGeo page states, the tool is not actively maintained and may give inaccurate results.

Figure 4-14: A NetGeo AS lookup

The assignment of autonomous systems to organizations can also be checked at http://www. employees .org/~tbates/autnums.html or http://www.bgp.potaroo.net/cidr/autnums.html, which provide a more complete AS assignment list with clickable whois entries.

Finding Autonomous Systems That Belong to an Organization

While you can find autonomous systems that belong to an organization by using whois to RIS-supporting servers or by checking the AS assignment lists just mentioned, you may find the following tips useful.

You can do a string search at FixedOrbit ( http://www.fixedorbit.com/search.htm ), which will show you all ASs related to the string. For example, a search for Cisco that we conducted revealed 12 different AS numbers that belong (or, at least, belonged) to Cisco Systems.

Another interesting lookup is checking RRs for all AS numbers belonging to the same maintainer. RFC 2622 states that the mntner class defines entities authorized to add, delete, and modify a set of objects. Thus, all objects that belong to the same mntner are likely to be under the same administration or otherwise related. First, you'd find a mntner for the network range of interestfor example, by running whois -h whois.ripe.net <IP or IP range> query and looking for mnt-by: string. Then you'd go to the RADB maintainer query site (Figure 4-15), at http://www.radb.net/maintquery.html, to perform the search.

Figure 4-15: RADB maintainer query

You'll find the results most interesting, since they are likely to outline detailed routing policy and route information for all the autonomous systems involved, as well as provide a wealth of other information, such as administrative contacts and mntner authentication type. While not strictly a Cisco or enumeration-related topic, it deserves to be mentioned that the maintainer authentication can be NONE, CRYPT-PW (UNIX crypt()), MD5-PW, and PGPKEY, with only the PGPKEY supposed to provide strong security. If an attacker manages to obtain the maintainer authentication credentials, he or she can modify the RR entries, causing grief to the AS administrators (since peering AS administrators are likely to take these into account when defining their BGP policies). This can be done via RR web interfacesfor example, the RADB Manage Objects Web Update (Figure 4-16), at http://www.radb.net/cgi-bin/radb/irr-web.cgi .

Figure 4-16: RADB Web Update

The very same Web Update form can be used for enumeration purposes via the RR database string search and a maintainer search, similar to the one at http://www.radb.net/maintquery.html.

AS Path Enumeration, Building BGP Trees, and Finding Border Routers

When looking through the RR databases entries or querying route servers and looking glasses, you have probably noticed the presence of the AS_Path attribute, as shown here:

route-server>show ip bgp BGP table version is 3269093, local router ID is 12.0.1.28 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Path * 4.17.225.0/24 12.123.196.111 0 7018 3561 11853 6496 6496 6496 6496 i * 12.123.17.244 0 7018 3561 11853 6496 6496 6496 6496 i * 12.123.142.124 0 7018 3561 11853 6496 6496 6496 6496 i * 12.123.133.124 0 7018 3561 11853 6496 6496 6496 6496 i * 12.123.37.250 0 7018 701 11853 6496 6496 6496 6496 i

This example is an aligned fragment of the output from the AT&T route server ( route-server.ip.att.net ) with an empty Metric and removed Local Preference and Weight columns . AS_Path is, essentially , a sequence of autonomous systems through which a packet has traveled. This is similar to hop count with simple IGPs, like RIP, but in the AS_Path case one hop is not a single router, but an AS that may contain thousands of routers. In the preceding example, AS 7018 belongs to AT&T, the next AS belongs to Cable & Wireless USA (AS 3561) and UUNET Technologies (AS 701), and then the traffic converges at AS 11853 (Internap Network Services) and enters ANet, an ISP in Chicago (AS 6496). The " i " at the end of the path shows that the information is originated from internal BGP (iBGP). Multiple repetition of the ANet AS number in the path is not a glitch and not a routing loop. It is an example of traffic engineering, namely manipulating an inbound AS_Path. Adding your own AS path number several times in a row is a common practice, which makes the AS path longer and the route to which the AS path is related less preferable. Thus, ANet must have a better route to AT&T (or other Tier 1 ISP) than the one shown in the example.

Why would an attacker want to investigate the AS_Path? There could be multiple reasons for this. Following are some examples.

Suppose a hacker group is planning a vile DDoS attack against a targeted network. The hackers determine which ASs are closest to the target and have the most preferable route to it (which means more bandwidth and less delay in practical terms). Then, they try to take over as many hosts as they can on the selected ASs to launch an attack. A list of preferred ASs with their IP ranges loaded into a vulnerability scanning tool would look like this:

1. Target network AS

2. Peers with the best metric

3. Peers with worse metric or ASs next to the peers with the best metric on the AS path (depending on a situation)

4. ASs with best routes next to those connected to the peers with the best metric on the AS path, and so on

In many cases, the hackers would not even want to scan the target network AS to avoid triggering alarms and having their IPs blacklisted before the actual DDoS attack takes place.

For the next example, suppose a hacker wants to sniff and modify traffic between network A and network B, but he or she is unable to break into any hosts on both networks since their system administrators are paranoid , tough as hell, and read Bugtraq and Packetstorm all night long. So the hacker investigates the best AS path between A and B through which the majority of traffic will go and attacks hosts along the path, trying to take over the AS border routers.

Finally, suppose in the DDoS attack example, hackers managed to take over the BGP routers in the AS path to the target network and manipulate the AS path and other BGP attributes to create the fattest pipe for their DDoS attack reaching the target. Alternatively, such manipulations can be done to redirect the traffic from/to the target network through the least feasible and more costly route, providing that the target network is multihomed. We call such attacks malicious traffic engineering .

Of course, you can telnet to multiple looking glasses and route servers, run show ip bgp , and build up your own grand picture of AS paths and routes to the target network. Or you can use various online tools that show you an AS path between two given AS numbers, such as AS Trace at FixedOrbit ( http://www.fixedorbit.com/trace.htm ). Alternatively, you can employ the prpath tool, supplied as a part of IRRToolSet ( prpath [options] [[<as-no>] <destination-specification>] ), or the older RAToolSet. But wouldn't it be nice to visualize the "BGP trees" of AS paths and observe how they change with time (since using BGP is not static routing, even though there are some similarities)?

A site that allows detailed and colorful building of links between the ASs on the Internet is the Netlantis Project ( http://www.netlantis.org/ ). We have used Netlantis for many years . Unfortunately, at the moment of writing the site is still down for upgrades, but we have no doubts that by the time you hold this book in your hands, the Netlantis Project will be back alive and kicking.

In the meantime, ensure that your browser seamlessly supports Java, because it is necessary to run two brilliant tools we are now going to discuss. The first tool, BGPlay, is available at http://www.bgplay.routeviews.org/bgplay/ . It is a colorful Java application that displays how a prefix (such as 192.83.230.0/24 in the example in Figure 4-17) spreads along the AS paths on the Internet.

Figure 4-17: BGPlay in action

The AS from which the prefix originates (AS 3130) is labeled by a red circle in the tool's output. Most importantly, BGPlay shows how the routes change in a given time period. Some routes along which the prefix is advertised stay stable, some rarely change, and some flap. Now, let us return to the examples of hackers investigating AS paths to optimize their attacks. If the route constantly flaps, it's not a reliable point for the attackbe it sniffing, traffic modification, DoS, or DDoS. Thus, a hacker would want to find stable routes close to the target using BGPlay.

The second tool, Hermes ( http://www.dia.uniroma3.it/~hermes/ ), is truly a "Swiss army knife " of BGP interrogation. We recommend that you spend some time playing with it to familiarize yourself with the multitude of options it provides. After Hermes loads (which may take some time), first create a new document, and then click Explore ASexplore and enter the number or name of the AS you are looking for. You can also use the AS-Search to find the AS or ASs to investigate. As a result of exploration, you'll see a colorful map with the explored AS in the middle and peering ASs connected to it (Figure 4-18).

Figure 4-18: The wonders of Hermes

Practically all the autonomous systems shown are registered with some RR. This is rather typical and shows that the time spent elaborating on RR significance and searches was not spent in vain. By right-clicking the AS in the tool output and querying the menu presented, you can obtain a wealth of information, including the following:

• AS set composition

• RR-supporting whois output

• BGP routing policy for route import and export

• Routes originating from the AS and detailed information about each route

• Hostnames and per-interface routes of the AS border routes

Hermes is very comfortable for "BGP surfing." For example, practically all universities in the U.K. are connected to the JANET backbone. By going through routes from and to JANET in Hermes, you can easily find the routes, their descriptions, and network ranges for separate departments in the universities. This is not information easily obtainable using more traditional enumeration tools like simple whois queries.

While not all border routers can be found or will be shown by Hermes, and not all autonomous systems are registered with RRs, finding these important hosts is not difficult. A few "traceroute-like" tools support showing AS numbers in their output. Here is an example of output of ptraceroute distributed with IRRToolSet/RAToolSet from the tool's man page:

1 [AS226] cisco2-160.isi.edu (128.9.160.2) 9.531 ms 9.755 ms 8.841 ms 2 [AS226] ln-gw32.isi.edu (128.9.32.1) 124.38 ms 15.269 ms 17.034 ms 3 [AS226] 130.152.168.1 (130.152.168.1) 16.77 ms 10.429 ms 10.187 ms 4 [AS2150] SWRL-ISI-GW.LN.NET (204.102.78.2) 63.025 ms 193.177 ms 17.107 ms 5 [AS3561] border1-hssi1-0.Bloomington.mci.net (204.70.48.5) 16.474 ms 15.876 ms 15.211 ms 6 [AS3561] core1-fddi-0.Bloomington.mci.net (204.70.2.129) 53.068 ms 215.841 ms 40.662 ms 7 [AS3561] core1.Washington.mci.net (204.70.4.129) 79.217 ms 84.029 ms 82.851 ms 8 [AS3561] core1-hssi-3.NewYork.mci.net (204.70.1.6) 85.65 ms 85.414 ms 84.62 ms 9 [AS3561] 204.70.2.30 (204.70.2.30) 84.562 ms 85.313 ms 85.524 ms 10 [AS3561] surfnet.NewYork.mci.net (204.189.136.154) 186.696 ms 194.363 ms 184.965 ms 11 [AS1103] Amsterdam2.router.surfnet.nl (145.41.6.66) 195.545 ms 195.767 ms 187.228 ms 12 [AS1200] Amsterdam.ripe.net (193.148.15.68) 193.955 ms 196.1 ms 182.065 ms 13 [AS3333] info.ripe.net (193.0.0.195) 211.185 ms 265.305 ms 278.876 ms Path taken: AS226 AS2150 AS3561 AS1103 AS1200 AS3333 13 AS3333 info.ripe.net destination -> !as-out 12 AS1200 Amsterdam.ripe.net !net-in -> as-out 11 AS1103 Amsterdam2.router.surfnet.nl !as-in -> as-out 10 AS3561 surfnet.NewYork.mci.net as-in: 1 -> internal 9 AS3561 204.70.2.30 internal -> internal 8 AS3561 core1-hssi-3.NewYork.mci.net internal -> internal 7 AS3561 core1.Washington.mci.net internal -> internal 6 AS3561 core1-fddi-0.Bloomington.mci.net internal -> internal 5 AS3561 border1-hssi1-0.Bloomington.mci.net internal -> as-out 4 AS2150 SWRL-ISI-GW.LN.NET !as-in -> !as-out 3 AS226 130.152.168.1 !as-in -> internal 2 AS226 ln-gw32.isi.edu internal -> internal 1 AS226 cisco2-160.isi.edu internal -> internal 0 AS226 kit.isi.edu internal -> source

As you can see from this output, it is very easy to determine border routes for each AS traversed.

Layer Four Traceroute (LFT), at http://www.oppleman.com/lft/, is another traceroute tool we like to use. Instead of using the traditional traceroute, Van Jacobson's UDP-based method, LFT sends TCP SYN and FIN probes to investigate the path. This offers a large advantage when you're trying to traceroute through various packet filters restrictive for UDP and ICMP traffic, since you can send TCP packets to an unfiltered port when enumerating. In fact, LFT has an option ( -E ) that you can use to show stateful firewalls on the way to target. But for our particular purposes, it is important to mention that the -A option will show the AS numbers for each host traversed:

# lft -E -N -A -T 198.133.219.25 Tracing __________________________________________________________________. TTL LFT trace to www.cisco.com (198.133.219.25):80/tcp 1 [ASN?] [IANA-CBLK1] xxx.xxx.arhont.com (192.168.111.111) 0.2/0.3ms ** [firewall] the next gateway may statefully inspect packets 2 [ASN?] [IANA-CBLK1] xxx.yyy.arhont.com (192.168.111.222) 0.4/0.8ms 3 [AS12513] [RIPE-NCC-212/ECLINET] 212.104.130.186 14.3/14.2/* [unreachable net] [ASN?] [RESERVED-1] 0.0.0.0 -1097511192903.3/*ms 4 [AS12513] [81-RIPE/UK-ECLIPSE-CORE] v117-core3.th.eclipse.net.uk (81.5.191.161) 96.6/15.1/*/*/*ms 5 [AS9057] [RIPE-NCC-212/LONDON-E3-CUST2] ge-5-1-620.metro1-londencyh00.London1.Level3.net (212.113.11.49) 17.6/21.6/*ms 6 [AS9057] [RIPE-NCC-212/LONDON-COLO-INFRA] so-1-3-0.gar2.London1.Level3.net (212.113.3.29) 19.6/16.9ms 7 [AS3356] [LVLT-ORG-4-8] ge-0-3-0-0.bbr2.London1.Level3.net (4.68.128.125) 17.1/14.5ms 8 [AS3356] [LVLT-ORG-4-8] as-0-0.bbr1.NewYork1.Level3.net (4.68.128.106) 79.6/80.8ms 9 [AS3356] [LC-ORG-ARIN] so-0-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) 157.4/157.8ms 10 [AS3356] [LC-ORG-ARIN] ge-6-1.ipcolo1.SanJose1.Level3.net (64.159.2.67) 157.5/233.9ms 11 [AS3356] [LVLT-ORG-4-8] p1-0.cisco.bbnplanet.net (4.0.26.14) 160.0/159.6ms 12 [AS109] [CISCO-PRNET1] sjck-dmzbb-gw1.cisco.com (128.107.239.9) 160.0/157.2ms 13 [AS109] [CISCO-PRNET1] sjck-dmzdc-gw1.cisco.com (128.107.224.65) 254.0/159.8ms 14 [AS109] [SWLAB1] [target] www.cisco.com (198.133.219.25):80 157.7/160.4ms LFT's trace took 64.58 seconds. Resolution required 20.06 seconds.

This is an LFT traceroute from the box on which this chapter was written to the Cisco Systems web server. If you want to know how the tool works in great detail (which packets are sent and received), you'd add the -V (verbose output) option. You can clearly see the border routers of each AS traversed, and quite a lot can be guessed from the network and hostnames shown, including the role of the host on the network and its approximate geographical position.

To finish this section of the chapter, we'll cover a few useful things about tracerouting that were not mentioned in the previous Hacking Exposed series books. In many cases, when running traceroute, you can see hops with omitted hostnames or stars. This can be a firewall dropping packets sent by the tool; use both UDP and ICMP tracerouting methods (for example, IRPAS itrace ) and run LFT or IRPAS TCtrace , changing source and destination ports to find out whether this is the case and to determine the type of the firewall. However, a Cisco router could be limiting the rate of bypassing packets, thus causing traceroute output similar to the output of a filtering firewall. We will deal with the use of traffic rate limiting as a DoS/DDoS protection measure in Chapter 11.

To get the information about such hops, use the "set time between the probes" ( -z ) option of traceroute. As suggested by the traceroute man page, 500 milliseconds is a sensible setting to use; by default this value is 0. Another thing you may see in traceroute output is a missing answer to a second or third probe packet sent. This is not usually congestion or a malfunctioning router, but it can be a router that limits the amount of responses to probes per unit of time. But there is still a possibility of a Random Early Detection (RED) queuing algorithm enabled on a router dropping a packet or two. Play with the -z traceroute option to investigate it, if necessary. A sudden, inconsistent increase in delay (for example, for one of the three response times shown only) is not an indicator of network congestion or a slow link; the increase in delay due to these reasons should be even. It is likely that the router at such a hop is experiencing a CPU overload, and such a router is easy prey for DoS/DDoS attacks.

Finally, don't run traceroute, ptraceroute, and LFT only once. Run these tools several times and compare the output. Pay a lot of attention to the last hops before the target. This will reveal whether the host you are investigating is multihomed with load balancing enabled. In fact, with multiple runs you can see whether the load balancing is even or uneven , and whether it uses round robin or a more sophisticated load-balancing algorithm. If you can see that packets follow more than one route to the destination at the last hops, have a look at the AS numbers of these hops. If these numbers for all (likely, two) different routes are the same, then the network is multihomed to a single ISP. As we discussed earlier, this is not a good practice in terms of network outage , DoS, and DDoS protection.

BGP Enumeration Countermeasures

As to various traceroute countermeasures, you can block UDP traffic to high ports used by traceroute (default is port 33434) and egress filter Time to Live (TTL)exceeded ICMP responses from hosts on your network at the gateway. Nevertheless, it is unlikely that you will stay connected to the Internet without a single port open to the outside. Thus, tools like LFT can be used together with a portscan to bypass your anti-traceroute filtering with ease.