D do s

Distributed Denial of Service Attacks Prepared For: Prof. Ruby Lee ELE 572 September 23, 2002 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] September 23, 2002 Princeton University Electrical Engineering Department Specht 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.

Countermeasures for DoS Attacks [1] September 23, 2002 Princeton University Electrical Engineering Department Specht 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.

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 September 23, 2002 Princeton University Electrical Engineering Department Specht Client Client Handler Handler Handler Handler Agents

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] 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). 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. 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. 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. 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. 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. The user can now use the master system to launch DDoS attacks against select targets. Master and Agents are password protected. 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] September 23, 2002 Princeton University Electrical Engineering Department 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. 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 1 st 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 14 th – 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 15 th – 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] September 23, 2002 Princeton University Electrical Engineering Department Specht IRC Servers “ Sitting Duck” T1 Trunk T1 Trunk Internet Packet sniffer 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. Finland

GRC.COM Attack Network Setup September 23, 2002 Princeton University Electrical Engineering Department 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 September 23, 2002 Princeton University Electrical Engineering Department 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 September 23, 2002 Princeton University Electrical Engineering Department Huang

Conceptual Model for Defending Against DDoS Attacks 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. 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 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. September 23, 2002 Princeton University Electrical Engineering Department User-Level Server-level 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: If multiple observations are made of the target, and each filter has an independent likelyhood function ( L 1 , L 2 ,… L n ), the overall probability can be calculated as 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 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. 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 Non-Disclosure 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, 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. 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 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. 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 usage-based 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 Network Based Host Based September 23, 2002 Princeton University Electrical Engineering Department Bayazit Anomaly Based vs. Signature Based Anomaly Based Signature Based

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? September 23, 2002 Princeton University Electrical Engineering Department 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? September 23, 2002 Princeton University Electrical Engineering Department 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? September 23, 2002 Princeton University Electrical Engineering Department 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 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 Princeton University Electrical Engineering Department Specht Privacy Sensitivity Application Layer User Session Layer Network Session Layer Presentation Layer Network/Internetwork Layer Transport Layer Physical Layer Data Link Layer

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 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 September 23, 2002 Princeton University Electrical Engineering Department Specht

References 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

D do s

More Related Content

What's hot (20)

Viewers also liked (19)

Similar to D do s (20)

Recently uploaded (20)

D do s

Editor's Notes