Distributed Denial of Service Defense TacticsSimple NomadBindView RAZOR Team 14 Feb 2000 [email protected] AbstractThis paper details some practical strategies that can be used by
system administrators to help protect themselves from distributed
denial of service attacks as well as protect themselves from becoming
unwitting attack nodes against other companies.
AudienceThe intended audience of this paper is system administrators, IS
managers, and other technical and semi-technical people with an interest
in learning more about defending against distributed attacks.
HistoryDistributed denial of service (DDoS) attacks have recently become
mainstream, although they have actually been around for a while. The
first rumoured attacks occurred in Australia and Europe, but the first
fairly well documented attack occurred on August 17, 1999 against
the University of Minnesota. Other U.S. locations followed, and as
attacks were traced to the attacking machines, copies of the attacking
software were discovered. Once the analysis of the software had begun
by security researchers [1], copies of the source code used for DDoS
began to appear along with detection methods [2]. The DDoS tools are
Trinoo, TFN, TFN2K, and Stacheldraht.
A Quick Review of the Attack ModelThe basic model of the DDoS tools involves the following:
*----------*
| |
| Attacker |
| |
*----------*
|
|
*----------*
| |
| Client |
| |
*----------*
|
(commands to nodes)
|
*------------*------*------*------------*
| | | |
| | | |
v v v v
*----------* *----------* *----------* *----------*
| | | | | | | |
| Node | | Node | | Node | | Node |
| | | | | | | |
*----------* *----------* *----------* *----------*
\ \ / /
\ \ / /
\ \ / /
(any number of floods or attacks)
\ \ / /
\ \ / /
\ \ / /
V V V
*-----------------------*
| |
| Victim |
| |
*-----------------------*
The attacker, sitting at home, uses client software to send commands to the nodes. The nodes in turn send floods of packets, or malformed packets to crash systems (or both) toward the victim. Typically, the client software the attacker is using to direct these attacks is not on his/her home system, but sitting on another system (usually a compromised host several hops from the attacker's home system to help prevent authorities from tracking down the attacker). From here, a set of commands are currently sent using ICMP packets, with the data possibly encrypted. TFN2K advances this "stealth" mode of communication by allowing for remote one-way communication, decoy packets, and fairly sophisticated encryption. The nodes themselves can number in the thousands. With one node, thousands
of packets can be sent per minute, flooding the target. With a hundred
nodes, millions of packets can be sent per minute, using up all of the
available bandwidth a victim might have. With a thousand geographically
dispersed nodes, *billions* of packets could certainly cripple virtually
any victim, including victims with multiple ISPs, redundant Internet
connections, server farms, and high-bandwidth routers.
Weaknesses in the Attack ModelBy finding weaknesses in the attack model itself, one can possibly
disrupt and thwart the attacks before they occur. A technical paper I
wrote on January 21, 2000 [3] focused heavily on the attack model
itself, and should be used as a technical reference. To outline some
of the weaknesses, let's look at each component of the model.
AttackerThe biggest weakness for the attacker is two critical phases -- checking his/her work, and communications with the client. It is entirely possible that the attacker will do a DNS lookup of the address of the target, possibly ping or try to access the site via a web browser from the home machine right before or right after the attack starts [4]. These accesses may appear in log files at the target location. If the client software is running on the home machine, it is possible
that the nodes running the attack software will have telltale signs of
the connectivity, such as the home machine's IP address viewable in a
netstat listing.
The ClientSimilar weaknesses exist for the client as to the attacker. If the
attacker is running the client software on a remote machine,
it is probable that the attacker may not have legitimate
access to that machine, but may have left telltale signs of
connectivity from the home machine.
The NodesThe nodes, which could number in the thousands, are obviously housing
and running the attack software that launches the denial of service.
There exists software to detect if your system is running the attack
software [5]. software locally [5] and remotely [8]. Commercial scanners
such as HackerShield [9], and others have, or will shortly have checks
for these. Ensuring that your system is secured with all of the known
holes patched will help prevent a compromise that could turn you into a
very bad Internet neighbor.
Communication LinksThe communications links can be disrupted several different ways. For
starters, you could try to tell the flood to stop, assuming the default
settings have not been changed [6]. Also, to prevent communication
channels from crossing into your network, fairly tight firewall rules
should be in place to prevent the client from directing the nodes [3].
Floods and AttacksBy ensuring that your network does not send forged IP packets you could also set up your firewall rules to limit outbound packets to only the traffic you should be sending. This way if a distributed attack is being launched by your own computers, you could prevent the bad IP packets with forged source addresses from passing out your network [3],[7]. Most modern firewalls and IDSs are capable of at least identifying an
attack against your site. Make sure you have configured them to detect
and (in the case of firewalls) block such attacks, both inbound and
outbound.
Defending Against AttacksThere are a few things you can do to help prevent becoming buried under a mountain of packets. First off, you need to be able to determine the source address of the rogue packets that are coming in. To do this you need to have *physical* access to a device or devices on the outer perimeter of your network. During the flood of packets, you will probably not be able to communicate with outer perimeter devices, so make sure you can get to the device. This device can be a firewall, router, intrusion detection system, or
network monitoring device (such as a sniffer) that will allow you to
view the source and destination IP addresses of packets flying by. Once
you have determined the source addresses, I recommend the following
four steps (as simultaneously as possible):
Protect Your Own NetworkSet up filters and rules in outer perimeter routers and firewalls to
drop packets from the questionable addresses. Do not log the dropping
of the packets! Logs will fill hard drives quickly. This will not gain
back any bandwidth to the Internet, but it will help unclog your
internal network. In the event servers were overwhelmed to the point
of crashing or locking up, you can at least start working on getting your
equipment back in working order. And while this step may seem pointless
considering the next two steps, remember that while you should contact
your ISP, if it takes 30 minutes to get a technician on the phone you've
wasted time that could be used to recover crashed servers and routers.
Contact Your ISPContact your ISP and ask to have the offending addresses blocked at their
end. The ISP should be able to block the addresses on their own Internet
feeds. This will start freeing up some (if not most) of your bandwidth.
Your ISP's ISPEncourage your ISP to contact any other second-tier Internet provider
they use to ask them to block the addresses as well. Once this is done
you should be able to see the Internet fairly clearly, and Internet
users can start seeing you as well.
Take the OffensiveDepending on which DDoS is used, it is possible to send packets toward
the offending addresses and cause the attack to shut down. By using the
zombie_zapper program, it might be possible to shut off attacking DDoS nodes.
Act FastDo not wait to get a list of IP addresses before you start calling your ISP. Call them immediately and work with them to help determine IP addresses. You could possibly end up with a technician who can see what the addresses are, but personally lacks the access level or skill set to make the adjustments at the ISP. Although the current DDos tools typically use overtly offensive packets,
such as ICMP floods, it is entirely possible that the tools merely produce
inflated amounts of legitimate traffic. It may therefore be difficult to
determine the exact source of rogue traffic. It is also possible that packets
have random source IP addresses, further restricting the ability to insert
filters.
ThanksI'd like to thank my wife for being patience during writing and coding on
Valentine's Day, and the entire BindView RAZOR team for input into this
paper. I'd especially like to thank Paul Ashton for some serious wordsmithing.
References
|