Section 11.10 Distributed Denial of Service (Coordinated) Attacks

   


11.10 Distributed Denial of Service (Coordinated) Attacks

graphics/twodangerlevel.gif

Tribe Flood Network (TFN), TFN2000, and Stacheldraht (German for Barbed Wire) are three of the best-known Distributed Denial of Service attacks, abbreviated as DDoS in this book and in most of the literature. Some others are trin00, shaft, and mstream.

Tribe Flood Network was created and released by a cracker calling himself Mixter. Despite it causing millions of dollars of lost business by well-known ethical companies, a German court sentenced Mixter to a mere suspended six-month sentence and two years of parole.


There are two types of "standard" Denial of Service (DoS) attacks. In the first, the attacker takes advantage of some bug in the attacked system and uses up some resource in short supply. Usually this is done by violating a communications protocol via a raw interface. "SYN Flood Attack Explained" on page 245 discusses one such attack where the attacker fails to complete the three-way TCP open protocol.

Another example is where an attacker will repeatedly open up ports on the attacked system, running it out of resources such as forked sendmail daemons. In Linux, these types of attacks that rely on a bug in the attacked system's software get fixed quickly, usually within hours.

The second type of attack is where the attacker simply floods the system with junk packets. Usually the attacker will use a message type that will cause the attacked system to send a packet in response to double the bandwidth used by the attacked system because of the following rule (with apologies to Dr. Seuss).

Send a packet to a port without a process to reply, and cause the system to respond that there's no daemon so go die.


Of course, the attacker will spoof the source address so that the reply goes to a different system, possibly even the attacked system. This will cause the "real" system, which corresponds to the fake source address, to send an "ICMP host/network unreachable packet" back to the victim. Thus, the traffic will be tripled.

The response to this second type of attack is to try to contact the system's administrator (with the assumption that she is innocent and unaware that her system has been compromised). The compromise might not involve someone breaking her system's security. All it takes is an unprivileged user compiling some C code downloaded from a cracker site, and it is "script kiddie heaven."

If the problem cannot be resolved via the SysAdmin of the attacking system, the solution is to contact that system's ISP or upstream provider and have that system "cut off." Failing this, contact your ISP or upstream provider and have data from that system blocked at their firewall or router.

In the meantime, block that system at your firewall. Even if you have only a single Linux box, IP Chains provides you with a firewall, and a rule should be added to block the site by dropping its packets.

By "dropping packets," it is meant that the action is to ignore them instead of sending a reply. Sending the reply would double the required bandwidth. By blocking it at the firewall (even IP Chains in a single-system shop), your overhead is reduced to the minimum possible.

Certainly, this is a "battle of the bandwidth." If the attacker has a T1 and you are on a dial-up PPP connection, you will lose until you get the attack stopped upstream. Similarly, if you have a T1 and they have a T3, you lose. What if you have a T3? Why, it is DDoS time. Instead of attacking you through one system, a cracker or even a network of crackers will break into dozens or even hundreds of systems. These systems will be scattered among dozens or hundreds of networks around the world.

As you can imagine, it could take many hours or days to track down each of these systems and get their attacks stopped. Most likely they will be using spoofed source addresses that might even change over time. Thus, tracking each of them down might involve tracking each hop by seeing what system is flooding it with packets addressed to you, while ignoring legitimate traffic. You will need to do this for each of dozens or hundreds of streams.

DDoS attacks are very hard to stop and are very effective. Many elite crackers and those who consider themselves hackers consider it the incompetent's solution for those unable to actually crack security. Certainly, if the goal is to put a site out of business for a while, DDoS attacks are extremely effective. The beauty of a DDoS attack is that the attacked system does not have to do anything wrong. It can be completely secure and doing all the right things.

All it takes is an imperfect SysAdmin, and another Trojan is planted on a system from which an attack may be launched. PCs on cable networks running non-Linux operating systems are prime targets. University networks containing hundreds of systems with a high bandwidth Internet connection, too, are a popular target for planting DDoS Trojans.

These DDoS Trojans sometimes are called zombies because they can kill a system but have no mind of their own. Instead they obey their master, which is what the single program that directs the zombies is called. Sometimes the term agent is used instead of master.


The Trojans wait for an instruction from their master for the IP of a system to attack and what type of packets to attack with. The Trojans can be hard to detect. Typically the Trojans will listen on a high-numbered UDP port, sometimes on a TCP port. Because the port is above 1023, they can run as ordinary users instead of needing root access. Because high numbered ports also are used for the client side of a normal network connection, such as to sendmail, telnet, FTP, or ssh, these will escape casual notice. Tribe Flood Network and Stacheldraht (Barbed Wire) work this way.

The ports program will detect these on the system that it is invoked on. It does this by indicating if any process is listening on the default port numbers used by popular cracker Trojans. Also, it has the innovation of detecting whether any high numbered port is in the listen state that only a server should be in.

Unless your installation has custom servers listening on high numbered ports, any such port is likely a Trojan. Unlike TCP, UDP does not have states per se, but most sites do not use many UDP services. Thus, any UDP process on a high numbered port might be suspicious and the ports program will detect these; it is discussed in "Turn Off Unneeded Services" on page 86 and its source is on the CD-ROM.

Because an ICMP echo reply message is also the response to the packets sent out by the ping program, all but the most strict firewalls will let in TFN2000's "attack" packet. Of course, the source address is spoofed so usually it is impossible to track down the cracker once the TFN2000 Trojan is installed.

The easiest way to detect TFN2000 possibly running on a system is to detect that the network interface is in Promiscuous mode. Although this is as easy as invoking ifconfig, this important check rarely is done. It is time to do it. This technique is discussed in "Detecting Promiscuous Network Interface Cards" on page 656 and in "Finding Promiscuous Processes" on page 660, which cover ways to detect this problem automatically and alert you, including paging you.

TFN2000 is brilliant in that it does not listen on any UDP or TCP port. Thus, port scans for it (even via the ports program) will not detect it. It will evade most efforts to detect it because those efforts involve looking for open UDP and TCP ports. Even those powerful tools that scan every IP address on your network for any with high numbered ports open will not find TFN2000. L0pht's AntiSniff should detect it by detecting that its host system is running the Ethernet card in Promiscuous mode.

TFN2000 works by putting the network interface in Promiscuous mode and listening on a raw port, which is neither TCP nor UDP. It listens for an ICMP echo reply message that contains the IP address of the machine to attack and the form of attack that should be used. It even encrypts this message.


On Red Hat systems (and possibly some other versions of Linux), the ifconfig program fails to indicate that a network interface is in Promiscuous mode. The chapters referenced here give more details and reference a program that will detect processes that have an interface in Promiscuous mode, even on Linux systems with this bug.



       
    Top


    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    Real World Linux Security Prentice Hall Ptr Open Source Technology Series
    ISBN: N/A
    EAN: N/A
    Year: 2002
    Pages: 260

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