• No results found

Traceback in the Service Provider Environment

For the implementation of traceback techniques to be successful, they must meet the following requirements:

Do not violate current protocol semantics and can be successful without changes in the core routing structure

Are difficult for the attacker to detect and can function in a passive mode, without requiring much intervention

Are useful in asymmetric environments

Work through multiple hops, across jurisdictions

Allow you to generate a good postmortem after an attack has mitigated

In some cases, it is difficult for the implementation of traceback techniques to meet all the requirements previously listed, and it is especially difficult for service providers. This is why it is extremely important for service providers to cooperate with each other to successfully trace back attacks. This is especially true because attackers are aware of many traceback schemes.

TIP Major cooperative efforts exist between service providers and several organizations that promote these efforts. An example is the North American Network Operators Group (NANOG), which has excellent resources and information at http://www.nanog.org. Another example is the Forum for Incident Response and Security Teams

(FIRST), which has excellent resources and best practice guides at http://www.first.org/resources/guides.

When there are large numbers of sources or when sources are well distributed, traceback solutions often become extremely complex and expensive. Speed is a significant limitation of hop-by-hop traceback; therefore, hop-by-hop traceback can be difficult. It also requires

substantial collaboration. For example, Figure 4-1 illustrates an old method being used by an individual who is attacking a victim who is numerous hops away from different service providers.

Figure 4-1 Hop-by-Hop Traceback

In this case, collaboration between service providers may be needed, and hop-by-hop traceback may take longer than expected. However, this is not what we typically see today. Figure 4-2 illustrates a more interesting scenario.

Attacker Victim

Service Provider C

Service Provider B Service Provider A

Figure 4-2 Hop-by-Hop Traceback with Botnets or Zombies Attacker Victim BotNet 3 BotNet 2 Service Provider B Service Provider A Service Provider C BotNet 1

In Figure 4-2, the attacker controls three different botnets or groups of zombies. In this case, hop-by-hop traceback can be time consuming and ineffective. Botnets can consist of several hundred compromised machines. Even a relatively small botnet with only a couple of hundred bots can cause significant damage. The IP distribution of these bots makes the implementation of ingress filters (or filtering) difficult, especially because separate organizations are involved. In most cases, botnets are used to infect or spread malware to other machines. In numerous cases, botnets are controlled by the attacker who is using encrypted tunnels to protect his own communication channel.

Botnets come in hundreds of different types, some of which include:

Agobot/Phatbot/Forbot/XtremBot

SDBot/RBot/UrBot/UrXBot

mIRC-based bots

DSNX bots

Q8 bots

kaiten.cPerl-based bots

TIP Shadowserver.com is an excellent website that reports botnet activity on the Internet on a daily basis. Many organizations use this information to become familiar with current trends. This site provides detailed graphics and metrics.

You can also obtain technical information about different types of bots at http://www.cert.org or at http://packetstormsecurity.nl.

Attackers who launch DDoS attacks can gain a major advantage by using reflectors to complicate the traceback process; this is known as attack obfuscation. Instead of the victim being able to trace back the attack traffic from himself directly to the slave, he must induce the operator of one of the reflector sites to do so on his behalf which can be administratively cumbersome or difficult.

Tracking botnets is a dilemma for many service providers and other organizations. To successfully perform traceback, you need to gather a significant amount of data about existing botnets, in many cases by analyzing captured malware. Many organizations are engaged in research to learn more about botnets and new techniques to combat them. An example of this is the Honeynet Project (http://honeynet.org). Honeynets are a collection of purposefully insecure machines (or honeypots) that are placed on the Internet for attackers to compromise. Researchers can then investigate and learn more about current

threats. At the minimum, honeynets collect the following information to learn more about botnets:

DNS name or IP address of the Internet relay chat (IRC) server and port number

In some cases, passwords to connect to the IRC server (when applicable)

Nickname of bot and ident (identification) structure

IRC channel to join and channel password

Many researchers have observed that updates on the botnet malware are performed frequently. To understand this process more fully, consider an old worm whose propagation started in several botnets, Zotob.x. Zotob was created by Farid Essebar (known by his handle as Diabl0). He was a small-time adware/spyware installer, using Mytob (a mass mailing worm) to infect machines and install adware for money. On August 25, 2005, Essebar was arrested in Morocco. The FBI stated that it holds evidence that Essebar was paid by Atilla Ekici (known as coder), who used stolen credit card numbers to build Mytob variants, as well as Zotob. Many service providers and other organizations spent numerous hours investigating this incident. One of the methods used was the backscatter technique. Backscatter is a system that Chris Morrow and Brian Gemberling created while they were working at a major service provider in the United States. This method addresses the need of finding the entry point of a spoofed attack. It combines sinkhole routers and remotely triggered black hole (RTBH) filtering to create a traceback system that provides a result within minutes.

You can use Border Gateway Protocol (BGP)-enabled routers to set specific prefixes to a known and individually handled “next-hop” and see interesting effects when you set the “next-hop” in BGP for a host that is under attack to a single address that will be routed locally. Typically, you set a static route to Null0 so that the attack traffic is advertised with the new “next-hop.” An Internet Control Message Protocol (ICMP) unreachable message is transmitted by a network device when it receives packets whose destination is unreachable (Null0). This “unreachable noise” is called a backscatter.

NOTE Backscatter has been advocated by many people, but many also question its benefits. You can find more details about the backscatter technique at http://www.secsup.org/Tracking. Another good presentation on backscatter, which is by Barry Greene, a senior Cisco SP expert, is located at http://www.nanog.org/mtg-0110/ppt/greene.ppt.

Furthermore, if that traceback is then performed using a scheme that relies on observing a high volume of spoofed traffic, such as ITRACE or probabilistic packet marking, the attacker can undermine the traceback by spreading the trigger traffic of each slave across

many reflectors. Doing this greatly increases the amount of time required by the traceback scheme to gather sufficient traffic to analyze. These methodologies have been suggested due to research initiatives by several organizations (mainly educational institutions). However, the initiatives, in most cases, are considered “science projects.”

Many others have attempted IP traceback techniques such as probabilistic packet marking and deterministic packet markings; these attempts, however, have also been considered science projects.

NOTE Wikipedia has a good, high-level description of probabilistic packet marking and deterministic packet markings at http://en.wikipedia.org/wiki/IP_Traceback.