11.10 Distributed Denial of Service (Coordinated) AttacksTribe 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.
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).
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.
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.
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.
|
Top |