stephen specht [email protected] (609) 986-9572 prepared by: ali bayazit qiang huang...

September 23, 2002 Princeton University Electrical Engineering Department

Stephen Specht

[email protected]

(609) 986-9572

Prepared By:

Ali Bayazit Qiang Huang

[email protected] [email protected]

(609) 986- (609) 947-3131

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

FirewallRouter100Mbps

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

Instructions4. 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 ServersAttacker 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 ServersAttacker

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 controlUser-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 filters3.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.

)()()( xpxyLyxp

)()()()()(),( 122112221 yxpxyLxpxyLxyLyyxp

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 controlrules 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



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



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.

Huang



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.

Huang



Cost-effectivenessSolution 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 CommentsVersion 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 CommentsRequest/Reply Filterable

Problem Filterable

TCP CommentsSource Port Not Much, Depends

SYN ACK Not Much, Depends

RST Dangerous

Sequence numbers DANGEROUS!


What Can Be Filtered?

Bayazit

UDP CommentsConnectionless 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

stephen specht [email protected] (609) 986-9572 prepared by: ali bayazit qiang huang...

Documents

application attack

teardrop attack

methods of attack

icmp echo attacks

network resources

pcs specht slide

stephen specht

hardware resources