DDoS.ppt

Stephen Specht
sspecht@princeton.edu
(609) 986-9572
Prepared By:
Ali Bayazit Qiang Huang
abayazit@princeton.edu qhuang@princeton.edu
(609) 986- (609) 947-3131
September 23, 2002 Princeton University
Electrical Engineering Department
Distributed Denial of Service Attacks
Prepared For:
Prof. Ruby Lee
ELE 572

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

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
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
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, End-
User 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
(Amplification,
Oscillation, Simple
Flooding)
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.
Protocol Feature
Attacks
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.
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
(Amplification,
Oscillation, Simple
Flooding)
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.
Protocol Feature
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.
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).
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]
Specht

DDoS Architecture
Client Client
Handler Handler Handler Handler
Agents
Specht

Widely Used DDoS Programs
• Trinoo
• Tribe Flood Network
• TFN2K
• stacheldraht (barbed wire)
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].
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. Pre-
compiled 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.
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].
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.
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].
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].
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.
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)
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
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.
Specht

GRC.com Network[7]
Verio Router
T1 Trunk
T1 Trunk
Internet
Internet
GRC.COM
Firewall
Router
100Mbps
100Mbps
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.
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.
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.
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.
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).
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”.
Specht

GRC.COM Case Study: GRC’s Infiltration
Network [7]
“Sitting Duck”
T1 Trunk
T1 Trunk
Internet
Packet sniffer
1. Sitting Duck runs the Zombie DDoS
daemon.
2. Sitting Duck connects to an IRC server
3. On IRC server, Sitting Duck waited for
Instructions
4. When Instructions came, Sitting Duck
attacked a site in Finland.
Finland
Specht
IRC Servers

GRC.COM Attack Network Setup
Verio Router
T1 Trunk
T1 Trunk
Internet
GRC.COM
IRC Servers
Attacker 1. Attacker logs on to IRC server
(IRC Server does not store IP address
and provides anonymous access.
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.
Specht

GRC.COM Attack Network Attacking
Verio Router
T1 Trunk
T1 Trunk
Internet
GRC.COM
IRC Servers
Attacker
1. Attacker issues
command to attack
GRC.COM
2. Each DDoS daemon begins to
attack the selected website.
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
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.
Huang

• 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.
Huang

Huang

Layer 1: Coordinated Technical Solutions
• Device Security improvement
• User level traffic control
• Coordinated filters
• Server level traffic monitor and class based queuing
• Tracing back
Different solutions can coexist to achieve a better defense and
coordination is often required to be global.
User-Level
Server-level
Huang

• 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.
Huang

• 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.
Huang

• 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.
Huang

• 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.
Huang

• 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.
Huang

• 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.
Huang

• 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:
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
This process may be repeated any number of times.
)
(
)
(
)
( x
p
x
y
L
y
x
p 
)
(
)
(
)
(
)
(
)
(
)
,
( 1
2
2
1
1
2
2
2
1 y
x
p
x
y
L
x
p
x
y
L
x
y
L
y
y
x
p 

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.
Huang

• 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.
Huang

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.
Huang

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.
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.
Huang

• 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
Huang

• 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 anti-
flood 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.
Huang

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.
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.
Huang

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.
Huang

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 Non-
Disclosure Method (NDM) preventing the tracking of user movements by third parties…
Huang

• 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.
Huang

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.
Huang

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.
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.
Huang

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, high-
bandwidth 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.
Huang

• 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 usage-
based 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.
Huang

• 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.
Huang

• 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.
Huang

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 usage-
based fees.
Huang

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.
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.
Huang

General Protections against DDoS
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)
Bayazit

Network Tracking Solutions
• Forward Tracing
– ICMP ECHO
– UDP
– TTL
• Backward Tracing
– Probabilistic Packet Marking
– Itrace
– SPIE
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
Bayazit

ITrace
• Send a Packet
• Why Low Probability?
• Why probability pseudo random? Why not
just a counter?
• Higher volume of traffic
Bayazit

SPIE
• Traffic Logging
• Bloom Filtering
• Hash Function (k functions map to n bit
target space)
• High correlation between the headers?
Bayazit

Computer Based Protection
• Intrusion Detection Systems
• Utilizing Basic Protections, SYN Cookies
• Secure Operating Systems
• Filtering, Firewalls
• Security Updates and Tools
Bayazit

Intrusion Detection Systems
• Network Based
• Host Based
Anomaly Based vs.
Signature Based
Anomaly Based Signature Based
Bayazit

Operating System
• Windows NT5/XP? Spoofing
• Linux
Bayazit

Filtering
• Ingress Filtering
• Egress Filtering
– ISP Responsibility – Good Neighbor Network
Bayazit

Problems with Filtering
• Local Domain Spoofing
• Non-Spoofing Attacks
• Spoofing Necessary
– Some Wireless Applications
– Inter-network Connections
• Requires Processing Power
Bayazit

Filtering In Detail
• What can be filtered?
• Case Study on Reflectors
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
Bayazit

What can be filtered?
Bayazit
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 ????

What Can Be Filtered?
Bayazit
ICMP Comments
Request/Reply Filterable
Problem Filterable
TCP Comments
Source Port Not Much, Depends
SYN ACK Not Much, Depends
RST Dangerous
Sequence numbers DANGEROUS!

What Can Be Filtered?
Bayazit
UDP Comments
Connectionless No big deal
Length Insignificant
Checksum Insignificant

Defending Against DDoS – Traffic Tracking
• Network Traffic Tracking Systems (NTTS)
• Model of Network Anonymity
• Desirable Properties of an NTTS
• Three Model Environments
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
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.
Specht
Application Layer
User Session Layer
Network Session Layer
Presentation Layer
Network/Internetwork
Layer
Transport Layer
Physical Layer
Data Link Layer
Privacy
Sensitivity

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
Specht

Three Model Environments [8]
• Closed 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
• Academic Model
– 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
Specht

References
1. 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.
2. 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.
3. 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.
4. 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
5. 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
6. 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
7. 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
8. 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.
Specht

DDoS.ppt

More Related Content

Similar to DDoS.ppt

Recently uploaded

DDoS.ppt