Transcript Distributed Denial of Service Attacks Prepared For: Prof. Ruby Lee ELE 572 Prepared By: Ali Bayazit [email protected] (609) 986September 23, 2002 Qiang Huang Stephen Specht [email protected] [email protected] (609) 947-3131 (609) 986-9572 Princeton University Electrical.

Distributed Denial of Service Attacks
Prepared For:
Prof. Ruby Lee
ELE 572
Prepared By:
Ali Bayazit
[email protected]
(609) 986September 23, 2002
Qiang Huang
Stephen Specht
[email protected] [email protected]
(609) 947-3131
(609) 986-9572
Princeton University
Electrical Engineering Department
Presentation Overview
• Introduction to DDoS
– Overview of DoS - Specht
– Overview of DDoS – Specht
– Case Study of DDoS victim GRC.com - Specht
• Defending Against DDoS Attacks
–
–
–
–
–
–
–
Conceptual Model – Huang
Layer 1 Coordinated Technical Solutions – Huang
IDIP: An Example of Anti-Flooding – Huang
Layer 2 Consistent Incentive Structure – Huang
Defending Wireless Networks Against DDoS – Huang
Reflectors Analysis – Bayazit
Traffic Tracking – Specht
September 23, 2002
Princeton University
Electrical Engineering Department
Introduction to DDoS
• Overview of DoS
–
–
–
–
Background Information: Denial of Service Attacks
Classification of Denial of Service Attacks
Countermeasures for Denial of Service Attacks
Denial of Service Attacks Shortfalls
• Overview of DDoS
– Distributed Denial of Service Attacks
– Distributed Denial of Service Attack Architecture
– Widely Used Distributed Denial of Service Tools
• Trinoo
• TFN/TFN2K
• Stacheldraht
– Common DDoS Countermeasures
– DDoS Protection Environment
• Case Study of DDoS victim GRC.com
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Background Information: Denial of Service Attacks
• Denial of Service Attack: an attack on a
computer or network that prevents legitimate use
of its resources.[1]
• DoS Attacks Affect:
– Software Systems
– Network Routers/Equipment/Servers
– Servers and End-User PCs
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Classification of DoS Attacks[1]
Attack
Affected Area
Example
Description
Network Level
Device
Routers, IP
Switches,
Firewalls
Ascend Kill II,
“Christmas Tree Packets”
Attack attempts to exhaust hardware
resources using multiple duplicate packets
or a software bug.
OS Level
Equipment
Vendor OS, EndUser Equipment.
Ping of Death,
ICMP Echo Attacks,
Teardrop
Attack takes advantage of the way operating
systems implement protocols.
Application
Level Attacks
Finger Bomb
Finger Bomb,
Windows NT RealServer
G2 6.0
Attack a service or machine by using an
application attack to exhaust resources.
Data Flood
Host computer or
network
Smurf Attack (amplifier
attack)
UDP Echo (oscillation
attack)
Attack in which massive quantities of data
are sent to a target with the intention of
using up bandwidth/processing resources.
Servers, Client
PC, DNS Servers
SYN (connection
depletion)
Attack in which “bugs” in protocol are
utilized to take down network resources.
Methods of attack include: IP address
spoofing, and corrupting DNS server cache.
(Amplification,
Oscillation, Simple
Flooding)
Protocol Feature
Attacks
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Countermeasures for DoS Attacks[1]
Attack
Countermeasure
Options
Example
Description
Network Level
Device
Software patches,
packet filtering
Ingress and Egress
Filtering
Software upgrades can fix known bugs and
packet filtering can prevent attacking traffic
from entering a network.
OS Level
SYN Cookies, drop
backlog connections,
shorten timeout time
SYN Cookies
Shortening the backlog time and dropping
backlog connections will free up resources.
SYN cookies proactively prevent attacks.
Application
Level Attacks
Intrusion Detection
System
GuardDog, other
vendors.
Software used to detect illicit activity.
Data Flood
Replication and Load
Balancing
Akami/Digital
Island provide
content
distribution.
Extend the volume of content under attack
makes it more complicated and harder for
attackers to identify services to attack and
accomplish complete attacks.
Extend protocols to
support security.
ITEF standard for
itrace, DNSSEC
Trace source/destination packets by a means
other than the IP address (blocks against IP
address spoofing). DNSSEC would provide
authorization and authentication on DNS
information.
(Amplification,
Oscillation, Simple
Flooding)
Protocol Feature
Attacks
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
DoS Shortfalls
• DoS attacks are unable to attack large bandwidth websites
– one upstream client cannot generate enough bandwidth
to cripple major megabit websites.
• New distributed server architecture makes it harder for one
DoS to take down an entire site.
• New software protections neutralize existing DoS attacks
quickly
• Service Providers know how to prevent these attacks from
effecting their networks.
• “Old” Internet Technology – something new needs to take
it’s place (Hackers want the challenge of a new
technology).
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Distributed Denial of Service Attacks
• What is a Distributed Denial of Service Attack?
As Defined by the World Wide Web Security FAQ: A Distributed Denial of
Service (DDoS) attack uses many computers to launch a coordinated DoS
attack against one or more targets. Using client/server technology, the
perpetrator is able to multiply the effectiveness of the Denial of Service
significantly by harnessing the resources of multiple unwitting accomplice
computers which serve as attack platforms. Typically a DDoS master program
is installed on one computer using a stolen account. The master program, at a
designated time, then communicates to any number of "agent" programs,
installed on computers anywhere on the internet. The agents, when they
receive the command, initiate the attack. Using client/server technology, the
master program can initiate hundreds or even thousands of agent programs
within seconds.[3]
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
DDoS Architecture
Client
Handler
Client
Handler
Handler
Handler
Agents
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Widely Used DDoS Programs
•
•
•
•
Trinoo
Tribe Flood Network
TFN2K
stacheldraht (barbed wire)
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Trinoo
• First DDoS Tool widely available[2].
• Uses UDP flooding attack strategy [2].
• TCP connectivity between master and
hosts [2].
• UDP connectivity between master and
agents [2].
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Analysis of trinoo[4]
1. A stolen account is set up as a repository for pre-compiled versions of attack tools including
trinoo daemon and master programs. This would include a list of vulnerable hosts. (it would
ideally have high bandwidth and little administrative oversight).
2. A scan is performed to identify potential targets (large network blocks are scanned). Systems
running services known to have exploitable buffer overflow bugs (Solaris 2.x / Linux) are ideal.
3. The list of vulnerable systems is used to create a script that performs the exploit (on the TCP
port, commonly 1524 “ingresslock” service port) and connects to this port to verify the exploit is
successful. From this exploit, a list of “owned” systems gets generated. These systems will be
candidates for the trinoo system.
4. A subset of “owned” systems with desirable attributes is selected for the attack network. Precompiled binaries of the trinoo daemon are created and stored on a stolen account somewhere.
5. A new script is written to automatically install the trinoo daemon on the selected systems. Some
systems will fail to install, but all successful installations create the attacking network.
6. Next, the master system is set up (typically on a service provider’s primary name server).
Remote control to the master is set up via TCP port 27665. The master system can communicate
with the agents via UDP on port 27444 and the agents send responses to the master on UDP port
31335.
7. The user can now use the master system to launch DDoS attacks against select targets.
8. Master and Agents are password protected.
9. Commands are three bit letters – in binary won’t show up as strings.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
TFN (Tribe Flood Network)
• Written in 1999 by “Mixter” [2].
• Allows for UDP flooding, TCP SYN, ICMP
flood, and smurf attacks[2].
• Communication between handlers and
agents is accomplished with
ICMP_Echo_Reply packets which are
harder to detect than UDP packets and can
pass through firewalls[2].
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Analysis of TFN[5]
• Installation steps similar to trinoo.
• Commands to the agents are sent in the form of a
16 bit binary number in the id field of an
ICMP_ECHO_REPLY packet. (The sequence
number is a constant 0x0000, which would make
it look like the response to the initial packet sent
out by the "ping" command)
• Difficulty in stopping this attack – one method is
to stop ICMP_ECHO_REPLY packets, however
this effectively stops all ICMP traffic.
• Provides no authentication, so that only one packet
captured will identify the source.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
TFN2K
• The successor to TFN, also written by “Mixter” [2].
• Allows for encrypted messaging between
components [2].
• Handlers and agents can communicate using ICMP,
UDP, or TCP. Random protocol selection is possible
[2].
• Adds an additional attack form called TARGA
(sends malformed IP packets known to slow down or
“hang up” the network stacks) [2].
• Also adds a MIX attack which uses UDP, SYN, and
ICMP_Echo_Reply Flooding [2].
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
stacheldraht
• German for “barbed wire”
• Based on early TFN versions[2].
• Provides ICMP, UDP, and TCP SYN attack
options[2].
• Has the ability to perform daemon updates
automatically[2].
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Analysis of stacheldraht[6]
• Combines trinoo and TFN tools and adds encryption of communication
between the attacker and stacheldraht masters
• Provides automatic updates to agents on demand (using Berkley “rcp”
command (514) all agents will log on to a server and upload a new
version).
• Includes a secure telnet (symmetric key encryption) connection
between attacker and master (prevents session hijacking).
• Built in limit of 1000 agents so as to not exceed the maximum number
of open file handles (1024).
• Agents and handlers continually send ICMP_ECHORPLY packets
between each other. These can be used to identify stacheldraht with a
packet sniffer.
• Agents can also perform an ID test to handlers.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Common DDoS Countermeasures [2]
•
•
•
•
Prevent Initial Hack
Use of Firewalls and Demilitarized Zone
Check Ingress/Egress Packets
Use a server farm and load balancer to offset the
effects of a DDoS attack
• Prevent SYN flood attacks by discarding the first
SYN packet (causes delay for legitimate users)
• Change IP address of attacked system (problem for
updating legitimate users of new system IP address)
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
DDoS Protection Environment [2]
• Linux Kernal (immune to TARGA & teardrop)
• Linux Virtual Server (provides balancing algorithms)
– NAT via load balancer (translates incoming traffic before it hits the
server).
– Direct Routing Request Dispatching (allows MAC addresses to
directly communicate with the server, bypassing the load
balancer).
– IP Tunneling
• Firewall – packet filtering
• Class Based Queuing (assigns repetitive packets to smaller queue
freeing up queue space for legitimate users)
• Traffic Monitor
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
DDoS Case Study: GRC.com[7]
• Gibson Research Corporation
• Provides free internet security testing
software: Shields Up, LeakTest, etc.
• Attacked in May 2001 by a DDoS attack.
The DDoS attack was using a “zombie bot”
which is a new form of DDoS tool.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.com Network[7]
Internet
100Mbps
Router
Firewall
T1 Trunk
T1 Trunk
100Mbps
Verio Router
GRC.COM
Internet
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: Initial Attack [7]
• May 4, 2001, GRC.COM Dropped Off of
the Internet.
• Both GRC T1 lines were at full 1.54 Mbps
capacity.
• GRC identified that it was the victim of a
DoS Attack
• GRC Firewall and Router were able to stop
flood traffic from affecting GRC equipment,
but T1 lines were completely used up.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: Initial Response to
DDoS Attack [7]
• GRC uses a packet sniffer to see that the packets
on the T1 lines are an attack. With this
information, GRC contacts its ISP, Verio. During
the 1st 17 hours, GRC captured 16.1 Gigabytes of
malicious packet data.
• The packet data revealed to GRC a number
network domain hosts where attacks originated
(most originated from cable ISPs).
• ISP Verio set up packet filters on their router so
that DDoS packets were not allowed on to the T1
lines. This brought GRC.com back online,
however the attack was not stopped.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: Additional Attacks [7]
• May 13 – Second attack occurs. Identical to the
first and using the same host machines. GRC
contacts Verio to reapply the packet filters.
• May 14th – 2 new attacks using new IP addresses
(of the GRC Firewall) which shut the system
down again. Verio asked again to apply new
packet filters. One T1 was still attacked, so it was
shut down.
• May 15th – New attack directly to the port of GRC
Cisco Routers, takes GRC off of the internet again
and due to a bug in Cisco routers, traffic gets
through and takes down GRC servers.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: Attacker’s Mistake [7]
• Attacker used compromised Windows machines –
which allowed for packet filtering. Other
machines (like Unix have ports that can generate
un-filterable packets). This allowed GRC to filter
and analyze the packets.
• GRC also gets e-mail posted to its message board
from 13 year old claiming to be responsible. –
Multiple e-mails are traded between “Wicked” and
GRC. The e-mails were used to trace “Wicked” to
a small network owned by Earthlink.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: Difficulty in Getting
Help Stopping DDoS Attacks [7]
• GRC contacts Earthlink but receives no help.
• GRC contact @Home (over 100 @Home PCs
were identified as hosts for the attack).
@Home however did not want to help.
• FBI unable to help GRC either.
• GRC then receives an anonymous e-mail in
their web-based Spyware drop box which
contains the “Zombie” (DDoS Daemon).
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: GRC’s Infiltration [7]
• GRC sets up “Sitting Duck” dummy computer
running DDoS daemon to see what happens (see
next slide).
• “Sitting Duck” successfully connects to IRC chat
server, gets instructions to attack a system in
Finland.
• GRC disables the packet generation feature of
“Sitting Duck” so no malicious packets will be sent.
• GRC writes an IRC chat Zombie to enter IRC
servers where hackers communicate/trade Zombie
DDoS tools.
• GRC communicates with hackers to “lay off”.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Case Study: GRC’s Infiltration
Network [7]
“Sitting Duck”
T1 Trunk
Packet sniffer
T1 Trunk
1.
2.
3.
IRC Servers
4.
Sitting Duck runs the Zombie DDoS
daemon.
Sitting Duck connects to an IRC server
On IRC server, Sitting Duck waited for
Instructions
When Instructions came, Sitting Duck
attacked a site in Finland.
Internet
Finland
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
GRC.COM Attack Network Setup
Attacker
1. Attacker logs on to IRC server
(IRC Server does not store IP address
and provides anonymous access.
IRC Servers
Internet
T1 Trunk
2. Zombie “bots” or DDoS tools that
were previously inserted to PCs out
in the network “wake up” and
connect to IRC server waiting for
instructions.
September 23, 2002
T1 Trunk
Verio Router
Princeton University
Electrical Engineering Department
GRC.COM
Specht
GRC.COM Attack Network Attacking
IRC Servers
Attacker
1. Attacker issues
command to attack
GRC.COM
Internet
T1 Trunk
2. Each DDoS daemon begins to
attack the selected website.
T1 Trunk
Verio Router
September 23, 2002
Princeton University
Electrical Engineering Department
GRC.COM
Specht
Defending Against DDoS Attacks
• Conceptual Model For Defending Against
DDoS
• Layer 1 Coordinated Technical Solutions
• IDIP Anti-Flooding System Example
• Layer 2 Consistent Incentive Structure
• Special Issue for Wireless Network
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Defending Against DDoS Attacks
1.
We need two things, suitable technological solutions in the Internet and
suitable incentives upon the users of the Internet. The machinery and the
incentives interlock and must be designed together. We also need to
consider the cost-effective issue: to construct technical solutions and
incentive structures in a cost-effective way.
2.
The biggest barrier in defending against DDoS attacks is the lack of
economic incentives for Internet users to cooperate. Sample
research by icsa.net shows that less than 15 percent of all corporate
users are filtering source IP addresses. An even smaller percentage
of Internet service providers – less than 8 percent – are doing this
type of filtering.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Defending Against DDoS Attacks
•
The inconsistent incentive structure in Internet traffic pricing: the victim
has the incentive to defend but cannot defend effectively, whereas the
owners of zombie computers and ISPs can defend effectively but do
not have the incentive to do so.
•
Flat monthly fee payments for wired Internet access: the owner of a
zombie computer incurs little cost due to DDoS attacks since all that is
stolen is just some traffic, but preventing a personal computer from
being controlled by any potential attacker requires frequent monitoring
and updating, at considerable cost.
•
Similar logic applies to ISPs who can always collect the monthly fees
no matter whether a DDoS attack happens or not. Thus, they may
hesitate to install filters since they will lower network performance.
•
So the technical solutions must work together with consistent incentive.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Defending Against DDoS Attacks
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• Device Security improvement
User-Level
• User level traffic control
• Coordinated filters
• Server level traffic monitor and class based queuing
• Tracing back
Server-level
Different solutions can coexist to achieve a better defense and
coordination is often required to be global.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 1. Improving the security of all relevant devices. (
More detail to be explained by Ali)
Before initiating an effective DDoS attack, the attacker needs to break
into enough zombie devices to secure an ability to generate sufficient
traffic. A direct counterstrike is to secure all devices to make it difficult
for the attacker to seize enough zombies.
It is not practical, nor potentially beneficial, to secure all computers on
the wired Internet. Alternatively, an effective and efficient solution would
be to selectively secure those computers that have high traffic
throughput – such as routers –or high performance and high bandwidth
workstations so that the marginal benefit for each dollar spent on
security is optimized.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 2. User-level traffic control
User-level traffic control is embodied in a set of traffic control rules specifically
for a given network device. For example, a wireless device user can set up a
daily traffic cap that is high enough not to disturb her/his normal usage, while
abnormally large traffic will be stopped.
Traffic control rules can be contingent on factors including other users’ usage
status. For example, a user can specify her/his data to be dropped or delayed if
the network is experiencing congestion.
For the wired Internet, Geng and Whinston propose to save the rules in edge
routers because routers, given their concentrated and limited functionalities, are
relatively easier to protect than other computers.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 3. Coordinated filters
3.1
Block certain types of packets:
If there is no legitimate need for UDP packets to pass, then a
firewall or
router can block them. Multicasts from one subnet to
another are not always needed. A firewall or router can block these.
3.2 Block packets by source address:
IP touters can improve traceability by discarding packets whose source
address is impossible given the wire on which the packet arrived.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 3. Coordinated filters
3.3 Derive attack signatures for the harmful packets
Filters detect anomalies, deviations from past behavior: more
than x connection requests (SYNs) per minute for a single IP
address, more than two standard deviations above the mean of a
packets-per-minute value for a single IP address, etc.
Attack signature: record the IP being flooded, the IP generating
the flood and IP of the nodes that the flood is traveling.
Participating routers and firewalls can discard some or all packets that
match the signature. The purpose of coordination among filters is to
stop the traffic as early as possible along the attacking paths.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 4. IP Tracing (more detail to be explained by Steve)
Even if the coordinated filters cannot effectively stop the attack, possibly
because the attacking traffic is hard to distinguish from normal traffic, there still
exists another technological solution – to trace back to the zombie devices to
shut down the attack from the source.
In any case, when a zombie is used in the attack, it is very hard to trace past the zombie
and find the attacker. Our concern here is not catch the attacker as to stop the attack. The
attacker can stay anonymous as long as the attack is stopped. IP routers can apply
address filtering, discarding packets when the source address does not match the wire on
which the packet arrived. This will limit IP forgery at least to a sub-network. So the
tracing system should be efficient to prevent zombies.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 5. Server level traffic Monitor and Class Based Queuing
If the traffic monitor in the load balancer detects a possible DoS attack it
gradually slows down all incoming traffic from the origination IP address by
assigning it to more and more slower queues. If even this does not stop the
attack, the IP address is blocked in a firewall list for a configurable amount of
time. Otherwise, after a certain interval of normal activity, the downgraded IP
can be upgraded to better queues. To decide whether a potential attacker is
indeed malicious, we will use Bayesian estimation method.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 1: Coordinated Technical Solutions
• 5. Server level traffic Monitor and Class Based Queuing
Bayesian estimation method: Likelyhood Evaluation
Let y be the set of filter readings defining a possible attack, and let x be the set of
hypothesis’s we believe to have caused these readings. Two determinations must be
made: the likelyhood of having received readings y given hypothesis x, and the
probability of hypothesis x. Through the use of Baye’s theorem, we have:
p( x y)  L( y x) p( x)
If multiple observations are made of the target, and each filter has an independent
likelyhood function (L1, L2,…Ln), the overall probability can be calculated as
p( x y1 , y2 )  L2 ( y2 x)L1 ( y1 x) p( x)  L2 ( y2 x) p( x y1 )
This process may be repeated any number of times.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
IDIP: An Example of Anti-flood System
IDIP (Intruder Detection and Isolation Protocol) in general:
Trace and Block
• (1) When an attack traverses an IDIP-protected network, each IDIP
node along the path is responsible for auditing the connection;
• (2) when a component detects an intrusion attempt, the detector
distributes an attack report to its neighbors who can then help trace the
attack path and respond to the intrusion;
• (3) these neighbors further distribute the attack description along the
path of the attack.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
IDIP: An Example of Anti-flood System
• BC: boundary controllers (router, a firewall, etc.) do the blocking.
• A node n and a BC b are neighbors if they can send one another IP
packets that do not pass through another BC
• If two non-BCs can send one another IP packets that do not pass
through a BC, then the two non-BCs are considered to be in the
same IDIP domain. So BCs form the boundary of a domain.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
IDIP: An Example of Anti-flood System
IDIP against Floods
•
The basic message could be "I am seeing a flood for IP address xx.xx.xx.xx." The victim
or an intrusion detection system (IDS) could pass this message to its neighboring BCs.
Each of them could look to see if it too was seeing a flood for that IP address. If so, the
BC could begin discarding all or most packets bound for that address and send the IDIP
message on to its own neighbors in turn. Once a BC stopped seeing a flood for IP
address xx.xx.xx.xx, it would stop discarding packets for that address. This would
restore service.
•
A victim or an IDS watching all traffic to the victim can tell whether the victim is
getting too much traffic. For a BC it is harder. A BC must check whether the flood is
coming through it, wholly or partly. To reduce false positives and false negatives, use
Bayesian Estimation Method.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
IDIP: An Example of Anti-flood System
Example:
•
The figure represents a possible configuration of IDIP and a possible attack. The attacker a is
flooding the victim v. The flood is taking just one route through the network, passing through BCs r4,
r3, r2, and r1. They are probably routers. IV0-IV4 is each a set of indirect victims - those who cannot
communicate with v because of the attack. S1, S2, S3, S4 are other sets of BCs in the network. The
intrusion detector w can be part of v or another program.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 2: Consistent Incentive Structure
Incentive for Zombie Prevention
•
To stop the Million Zombie Flood we must make it much harder to hijack
zombies. If hosts used well known cures to well known vulnerabilities, then
they would be much harder to hijack and the Million Zombie Flood would be
much more expensive to mount. A great challenge is to induce everyone to
protect their hosts.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 2: Consistent Incentive Structure
Incentive for Zombie Prevention
• Non-Economic Approaches:
1. Sue a zombie owner:
Who can sue a million zombie owners?
2. Government regulations:
Hard to get uniform enforcement across the globe
Not necessarily the right regulations
Not fast enough to changes of technology
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 2: Consistent Incentive Structure
Incentive for Zombie Prevention
• Economic incentives:
Anti-flood participants upstream would block traffic bound for the flood's destination.
"Destination" could be a single IP address, a net, a subnet, or other unit.
Internet Service Providers (ISPs) will have an incentive to police their subscribers, or to
police them better. Consider an ISP that is not participating in the anti-flood system and
not policing its subscribers. Whenever some of its subscribers flood a victim, the antiflood system will trace the flood to the ISP and block it from sending packets to the
victim. All of the other subscribers will suffer. They will not like this, so that is the ISP's
incentive. Companies and organizations will likewise have an incentive to make sure
that their machines are not used as zombies.
In effect, the consequences of neglect (allowing hosts to be hijacked) are pushed closer
to the neglector. Now some areas of the Interact will be well policed and suffer few
flooding attacks. Other areas will be unpoliced and will suffer a lot.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Layer 2: Consistent Incentive Structure
Incentive to Join an Anti-Flood System
It helps that if more nodes support IDIP. The farther you can trace an attack, the more
selective can be your blocking. In the example, if r4 did not support IDIP, then IV3
would continue to suffer, but others would not. So if a customer wants to be able to get
to www.amazon.com even when someone is flooding it, it’s better to choose an internet
backbone with anti-flood machinery. There is a clear incentive both to the customer and
to the backbone operator.
Communication providers, and anyone who runs a router, will be motivated to offer the
anti-flood system as a quality-of-service feature. It is valuable to those downstream of
the router who may be flooded. They will be willing to pay for this protection.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
DDoS attacks can be a real threat in the near future given the increasing
computational power, network bandwidth, and users in the wireless Internet
economy.
Two significant events:
1. In the summer of 2000, there appeared the first preliminary virus against
mobile
phones. Eugene Kaspersky: “This is not the first and obviously not
the last security breach discovered in mobile phones. Moreover, I believe as
more functionality is added to mobile phones, it will result in more breaches
being found.”
2. The emergence of the first DDoS attack tool toward mobile phones, known as
the SMS-flooder. It tries to use the wired Internet to attack a wireless victim. First
it proliferates through Microsoft Outlook just as the Melissa virus does. Then it
commands all infected Microsoft Outlook software to send short messages
(SMS-messages) to a certain victim’s mobile phone to inundate it.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
Possible forms of DDoS attacks for wireless network:
1. Ones that are found on the wired Internet
2. Attacking the radio spectrum that is naturally a scarce resource
3. the attack across both the wireless and wired Internet. Given the
differences in computational power and the bandwidth between wired
and wireless devices, it is easier for an attacker to use wired devices to
initiate cross platform attacks toward wireless devices.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
Three different infrastructures of wireless Internet: the Wireless Extended
Internet, the Wireless Portal Network, and the Wireless Ad Hoc Network.
•
The Wireless Extended Internet: merely an extension of the wired Internet for
mobility convenience. Wireless access providers, or wireless ISPs, connect
mobile devices to fixed networks via radio frequency (RF) channels. The
traditional Client/Server architecture, as well as existing transport layer protocols
(usually TCP), is also used for the Wireless Extended Internet. Therefore, DDoS
attacks seen in the wired Internet are still feasible in the Wireless Extended
Internet.
•
•
•
•
Attacking devices using aggregated traffic.
Attacking the asymmetric structure.
Attacking the radio spectrum.
Avoiding tracing back by mobility: allowing a mobile device to send out IP datagrams
using its fixed home address rather than care-of address even if it roams away, the NonDisclosure Method (NDM) preventing the tracking of user movements by third parties…
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
•
The Wireless Portal Network: developed and privately owned by wireless
telecommunication providers, thus are highly centralized. Clients, contracted
content providers, and the service center become a walled community, i.e., a
reliable “security island”. It is difficult to launch attacks from outside the island.
However, the network could be vulnerable to internal attacks.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
DDoS attacks on the Wireless Portal Network:
•
Attacking the radio spectrum: Mimicking this natural congestion, it is possible to
disable a particular base station by simultaneously sending connection requests
and a mass of traffic from mobile zombies. As a result, all wireless devices
within this cell will not be able to connect to the network.
•
Attacking TCP/IP gateway: The TCP/IP gateway translates between wireless
bearer protocols and the Internet TCP/IP protocols. It is one crucial bottleneck in
the Wireless Portal Network.
•
Attacking value-added services: All these services are invisible outside the
portal net-works and will survive under outside DDoS flooding. But sophisticated
methods can launch attacks from devices within the portal network.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Special Issue: Wireless Network Against DDoS
Wireless Ad Hoc Network: formed temporarily by a group of mobile devices,
which have a common mission or interest. Adhering to a strict admission policy
and communication rules, all these devices form a special community of equals
to share information. There is no designated client or server.
•
The Ad Hoc Network is the best architecture against DDoS attacks: dynamic
routing protocols and mobility of the network components self-adjusting
properties.
1. It has no central server.
2. It may implement strict admission policies making it very hard for outsiders to
hack into the communication system.
3. No central point and no crucial resource means any blocked route can be
substituted by redundant links.
4. The community can reject an abnormal member by voting based on certain
admission policies.
•
The interconnection among Wireless Ad Hoc Networks through wired relay
services creates an asymmetric infrastructure in which critical points can be
attacked.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Layer 1: Coordinated technical solutions
•
Improving the security of devices with high bandwidth connections, e.g.,3G devices, to
prevent them be used as zombies.
•
User-level traffic control: For the wireless Internet, the candidate host for traffic control
rules can be flexible: unique IDs or PINs to identify wireless devices and restricted
access functions that enable secure traffic control even if the wireless device is hacked-no software control and modification
•
Coordinated filters and tracing back: a Wireless Ad Hoc Network, filtering is not
applicable due to the symmetric structure. However, community rules, e.g., a voting
mechanism, may play the role of a central filter to decide which user device to block.
•
Server-level traffic control
•
Spread Spectrum: can’t simply say that “spread spectrum” is used and therefore
interference is not an issue.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Layer 2: A consistent incentive structure
• An incentive structure based on usage-based fees
The direct effect of a usage-based fee is a sharp increase in the cost to zombie
devices if they are sending out attacking traffic.
With a usage-based fee structure, the owners of high-performance, highbandwidth devices will have the greatest immediate incentive to take security
actions. Specifically, such a usage-based fee plan makes ISPs more likely to
install coordinated filters and to support user-level traffic controls.
Fortunately and unlike the wired Internet industry, the wireless Internet industry
starts with usage-based fees. For example, Japanese vendor DoKoMo’s i-mode
service pricing is mainly packet based, as shown in table 1.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Layer 2: A consistent incentive structure
•
Dynamic usage-based fees: a more targeted incentive structure against DDoS
A dynamic usage-based fee scheme deals with unpredictable congestions,
including those caused by DDoS attacks. The characteristic of a dynamic usagebased fee is the increase in unit price when congestion happens or will happen.
So the wireless device owners are more likely to set up traffic control rules in
their device to instruct to delay or cancel the data transmission when the
network is congested or approaching congestion. Therefore, even if an attacker
instruct all zombie devices to send attacking traffic at the same time, an
effectively synchronized attack is unlikely to occur.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Layer 2: A consistent incentive structure
•
Usage-based fees can be flexible
A consistent incentive structure can be flexible in its form while still representing
the essence of a usage-based fee plan. In case that people dislike the
uncertainty and complexity associated with usage-based fees, we can adopt the
variants.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Layer 2: A consistent incentive structure
•
A monetary incentive structure may not be available for the Wireless Ad Hoc
Network, simply because of the lack of a charging system. Instead, other
incentive mechanisms, e.g., a voting mechanism which effectively rules out a
member upon heavy radio frequency usage, can serve the same purpose.
•
For defending the Wireless Extended Internet, a usage-based fee plan is also
needed for the wired Internet, which is mainly used to prevent DDoS attacks
inside the wired Internet.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Cost-effectiveness
Solution must be proactive and consistent with mainstream and commercial
Internet technologies. Employing these existing technologies will significantly
reduce the costs and risks in designing future wireless Internet. The Policy
Based Networking (PBN) is one promising technology for implementing usagebased fees.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Conceptual Model for Wireless Network Against DDoS
Cost-effectiveness
A usage-based fee scheme can be implemented by using PDPs and PEPs:
•
First, once the fee scheme is decided, it is implemented as a set of policies in
PDPs at the Wireless Authentication Centers.
•
Secondly, based on the fee scheme and the real-time traffic condition, a PDP
decides the pricing rules for every related mobile terminal and send these rules
as policies to PEPs on these mobile terminals.
•
Thirdly PEPs on mobile terminals enforce these pricing rules. Whenever there is
a surge in traffic, possibly caused by DDoS attacks, PEPs report the traffic
change and any possible congestion to the coordinating PDP, who in return
dynamically adjusts pricing rules according to the given fee scheme and
instructs PEPs to update their pricing rules.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
Wireless Network Against DDoS
Remarks
When DDoS attacks came to the wired Internet, the infrastructure of the
wired Internet had been stable for decades, lacking reliable
mechanisms for QoS control and incentive structures for traffic control.
As a result, it was repeatedly targeted by DDoS attacks. In comparison,
the wireless Internet industry has a chance to address DDoS attacks
before it fully matures.
September 23, 2002
Princeton University
Electrical Engineering Department
Huang
General Protections against DDoS
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Motivation
• The first computers in DARPAnet failed in
communicating, bacuase of a hand-shaking
problem, which was nothing but DoS.
• Examples:
– Code Red (July 2001)
– EFNet.org (July 2001)
– Microsoft (January 2001)
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Network Tracking Solutions
• Forward Tracing
– ICMP ECHO
– UDP
– TTL
• Backward Tracing
– Probabilistic Packet Marking
– Itrace
– SPIE
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Probabilistic Packet Marking
• Properties
– ID Field of IP
– Encryption
• Disadvantages
–
–
–
–
–
Requires High Volume of Traffic
Some applications use ID Field
Low Probability/Heavy Processing
Hardware Acceleration?
IPv6 doesn’t have ID field
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
ITrace
• Send a Packet
• Why Low Probability?
• Why probability pseudo random? Why not
just a counter?
• Higher volume of traffic
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
SPIE
• Traffic Logging
• Bloom Filtering
• Hash Function (k functions map to n bit
target space)
• High correlation between the headers?
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Computer Based Protection
•
•
•
•
•
Intrusion Detection Systems
Utilizing Basic Protections, SYN Cookies
Secure Operating Systems
Filtering, Firewalls
Security Updates and Tools
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Intrusion Detection Systems
Anomaly Based
Signature Based
Anomaly Based vs.
Signature Based
• Network Based
• Host Based
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Operating System
• Windows NT5/XP? Spoofing
• Linux
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Filtering
• Ingress Filtering
• Egress Filtering
– ISP Responsibility – Good Neighbor Network
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Problems with Filtering
• Local Domain Spoofing
• Non-Spoofing Attacks
• Spoofing Necessary
– Some Wireless Applications
– Inter-network Connections
• Requires Processing Power
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Filtering In Detail
• What can be filtered?
• Case Study on Reflectors
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Defending Against Reflectors
• Ingress Filtering
– Solves Everything?
– Recursive DNS Queries
– HTTP Proxy Request
• Signature Catch
– Wide screen deployment of Filtering
– Complex, heavy processing
– Impractical for large volume of traffic
• Trace Back
– Heavy Deployment of new Software
– There are many different Software Vendors
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
What can be filtered?
IP
Comments
Version
Insignificant
Header Length
Insignificant
TOS/DSCP
Could Be Useful
Length
Insignificant
Fragments
If Not Using NFS, AFS, GRE
TTL
None (is it?)
Protocol
None
Checksum
None
Source
????
Destination
????
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
What Can Be Filtered?
ICMP
Comments
Request/Reply
Filterable
Problem
Filterable
TCP
Comments
Source Port
Not Much, Depends
SYN ACK
Not Much, Depends
RST
Dangerous
Sequence numbers
DANGEROUS!
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
What Can Be Filtered?
UDP
Comments
Connectionless
No big deal
Length
Insignificant
Checksum
Insignificant
September 23, 2002
Princeton University
Electrical Engineering Department
Bayazit
Defending Against DDoS – Traffic Tracking
•
•
•
•
Network Traffic Tracking Systems (NTTS)
Model of Network Anonymity
Desirable Properties of an NTTS
Three Model Environments
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Network Traffic Tracking Systems [8]
• NTTS (Network Traffic Tracking Systems)
– System to track network traffic
– Difficult to track network traffic due to:
• Spoofing (network traffic source is a lie)
• Redirection (network entity receives traffic and edits
it in some way before resending)
– Issues
• NTTS – can be successful in a closed environment
with strong infrastructure
• In an open, global network (Internet) it is not
possible to deploy a perfect NTTS
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Model of Network Anonymity [8]
•
•
•
•
Addition of User Session Layer to 7 layer
OSI Model.
User Session Layer – models the
behavior of user login sessions in which
a user logs into a node by way of some
application, performs some action, and
eventually logs off.
User Session Layer allows for “island
hopping” and relaying. A relay node is a
network node that accepts a flow from
the network attack, possibly modifies it,
and passes it on to another node on the
network.
Typical attacks use multiple relays in a
serial connection. The last serial node is
left with attacker’s print, and previous
serial relays are undisclosed, including
the location/information of the attacker.
September 23, 2002
User Session Layer
Application Layer
Presentation Layer
Network Session Layer
Transport Layer
Privacy
Sensitivity
Network/Internetwork
Layer
Data Link Layer
Physical Layer
Princeton University
Electrical Engineering Department
Specht
Desirable properties of an NTTS [8]
• Accuracy
– Probability that source found for a certain piece of network traffic
will be correct
– Accuracy needed to get legal search warrant
• Precision
– Level of specificity that the NTTS identifies the source (i.e. NTTS
may identify the host, but not sub-network)
• Resist Subversion
• Low Overhead (bandwidth, processing, memory)
• Low Cost
• Scalability (sizing + full vs. partial network coverage)
• Realtime vs. Non-realtime tracing
• Privacy and Control
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
Three Model Environments [8]
•
Closed Model
–
–
–
–
–
•
Academic Model
–
–
–
–
•
Central authority controls all network hosts
Independent network, not connected to outside networks
All packet information and logs stored
Limited end-user privacy expectations (corporate networks)
Tracing higher protocol layers is easiest
Central authority controls network that connects hosts, but not hosts directly
Limitations due to host relaying and high overhead
Privacy issues would exist with end-users
Possible to trace low level protocols, but high level protocols are difficult
Internet Model
–
–
–
–
–
–
No Authority controls hosts
Modify internetworking protocols to provide “traceability”
Issues of cost and overhead
Scalability is on the order of millions of systems
Privacy Issues
Internet spans multinational/multi-government regions
September 23, 2002
Princeton University
Electrical Engineering Department
Specht
References
1.
2.
3.
4.
5.
6.
7.
8.
Karig, David and Ruby Lee. Remote Denial of Service Attacks and Countermeasures, Princeton
University Department of Electrical Engineering Technical Report CE-L2001-002, October 2001.
Kargl, Frank, Joern Maier, and Michael Weber. Protecting Web Servers from Distributed Denial
of Service Attacks. WWW10, May 1-5 Hong Kong. ACM 1-58113-348-0/01/0005.
Stein, Lincoln. The World Wide Web Security FAQ, Version 3.1.2, February 4, 2002.
http://www.s3.org/security/faq/ - visited on October 1, 2002.
Dittrich, David. The DoS Project’s “trinoo” Distributed Denial of Service Attack Tool.
University of Washington, October 21, 1999.
http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt – visited on October 1, 2002
Dittrich, David. The “Tribe Flood Network” Distributed Denial of Service Attack Tool.
University of Washington, October 21, 1999.
http://staff.washington.edu/dittrich/misc/trinoo.analysis.txt – visited on October 1, 2002
Dittrich, David. The “stacheldraht” Distributed Denial of Service Attack Tool. University of
Washington, December 31, 1999.
http://staff.washington.edu/dittrich/misc/stacheldraht.analysis.txt – visited on October 1, 2002
Gibson, Steve. The Strange Tale of the Denial of Service Attacks Against GRC.com. Gibson
Research Corporation, March 5, 2002. http://grc.com/dos/grcdos.htm
Daniels, Thomas E. and Eugene H. Spafford. Network Traffic Tracking Systems: Folly in the
Large? Center for Education and Research in Information Assurance and Security (CERIAS).
Lafayette, IN, ©2001.
September 23, 2002
Princeton University
Electrical Engineering Department
Specht