Distributed Denial of Service Attacks Prepared For Prof

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

Presentation Overview • Introduction to DDo. S – Overview of Do. S - Specht – Overview of DDo. S – Specht – Case Study of DDo. S victim GRC. com - Specht • Defending Against DDo. S 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 DDo. S – Huang Reflectors Analysis – Bayazit Traffic Tracking – Specht September 23, 2002 Princeton University Electrical Engineering Department

Introduction to DDo. S • Overview of Do. S – – Background Information: Denial of Service Attacks Classification of Denial of Service Attacks Countermeasures for Denial of Service Attacks Shortfalls • Overview of DDo. S – Distributed Denial of Service Attacks – Distributed Denial of Service Attack Architecture – Widely Used Distributed Denial of Service Tools • Trinoo • TFN/TFN 2 K • Stacheldraht – Common DDo. S Countermeasures – DDo. S Protection Environment • Case Study of DDo. S 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] • Do. S Attacks Affect: – Software Systems – Network Routers/Equipment/Servers – Servers and End-User PCs September 23, 2002 Princeton University Electrical Engineering Department Specht

Classification of Do. S 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, Windows NT Real. Server G 2 6. 0 Attack a service or machine by using an application attack to exhaust resources. Data Flood Host computer or network Smurf Attack (amplifier attack) UDP Echo (oscillation attack) Attack in which massive quantities of data are sent to a target with the intention of using up bandwidth/processing resources. Servers, Client PC, DNS Servers SYN (connection depletion) Attack in which “bugs” in protocol are utilized to take down network resources. Methods of attack include: IP address spoofing, and corrupting DNS server cache. (Amplification, Oscillation, Simple Flooding) Protocol Feature Attacks September 23, 2002 Princeton University Electrical Engineering Department Specht

Countermeasures for Do. S 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 Guard. Dog, other vendors. Software used to detect illicit activity. Data Flood Replication and Load Balancing Akami/Digital Island provide content distribution. Extend the volume of content under attack makes it more complicated and harder for attackers to identify services to attack and accomplish complete attacks. Extend protocols to support security. ITEF standard for itrace, DNSSEC Trace source/destination packets by a means other than the IP address (blocks against IP address spoofing). DNSSEC would provide authorization and authentication on DNS information. (Amplification, Oscillation, Simple Flooding) Protocol Feature Attacks September 23, 2002 Princeton University Electrical Engineering Department Specht

Do. S Shortfalls • Do. S 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 Do. S to take down an entire site. • New software protections neutralize existing Do. S 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 (DDo. S) attack uses many computers to launch a coordinated Do. S 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 DDo. S 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

DDo. S Architecture Client Handler Agents September 23, 2002 Princeton University Electrical Engineering Department Specht

Widely Used DDo. S Programs • • Trinoo Tribe Flood Network TFN 2 K stacheldraht (barbed wire) September 23, 2002 Princeton University Electrical Engineering Department Specht

Trinoo • First DDo. S Tool widely available[2]. • Uses UDP flooding attack strategy [2]. • TCP connectivity between master and hosts [2]. • UDP connectivity between master and agents [2]. September 23, 2002 Princeton University Electrical Engineering Department Specht

Analysis of trinoo[4] 1. A stolen account is set up as a repository for pre-compiled versions of attack tools including trinoo daemon and master programs. This would include a list of vulnerable hosts. (it would ideally have high bandwidth and little administrative oversight). 2. A scan is performed to identify potential targets (large network blocks are scanned). Systems running services known to have exploitable buffer overflow bugs (Solaris 2. x / Linux) are ideal. 3. The list of vulnerable systems is used to create a script that performs the exploit (on the TCP port, commonly 1524 “ingresslock” service port) and connects to this port to verify the exploit is successful. From this exploit, a list of “owned” systems gets generated. These systems will be candidates for the trinoo system. 4. A subset of “owned” systems with desirable attributes is selected for the attack network. Precompiled binaries of the trinoo daemon are created and stored on a stolen account somewhere. 5. A new script is written to automatically install the trinoo daemon on the selected systems. Some systems will fail to install, but all successful installations create the attacking network. 6. Next, the master system is set up (typically on a service provider’s primary name server). Remote control to the master is set up via TCP port 27665. The master system can communicate with the agents via UDP on port 27444 and the agents send responses to the master on UDP port 31335. 7. The user can now use the master system to launch DDo. S attacks against select targets. 8. Master and Agents are password protected. 9. Commands are three bit letters – in binary won’t show up as strings. September 23, 2002 Princeton University Electrical Engineering Department Specht

TFN (Tribe Flood Network) • Written in 1999 by “Mixter” [2]. • Allows for UDP flooding, TCP SYN, ICMP flood, and smurf attacks[2]. • Communication between handlers and agents is accomplished with ICMP_Echo_Reply packets which are harder to detect than UDP packets and can pass through firewalls[2]. September 23, 2002 Princeton University Electrical Engineering Department Specht

Analysis of TFN[5] • Installation steps similar to trinoo. • Commands to the agents are sent in the form of a 16 bit binary number in the id field of an ICMP_ECHO_REPLY packet. (The sequence number is a constant 0 x 0000, 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

TFN 2 K • 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 DDo. S 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 DDo. S 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

DDo. S 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

DDo. S Case Study: GRC. com[7] • Gibson Research Corporation • Provides free internet security testing software: Shields Up, Leak. Test, etc. • Attacked in May 2001 by a DDo. S attack. The DDo. S attack was using a “zombie bot” which is a new form of DDo. S tool. September 23, 2002 Princeton University Electrical Engineering Department Specht

GRC. com Network[7] Internet 100 Mbps Router Firewall T 1 Trunk 100 Mbps T 1 Trunk Verio Router GRC. COM Internet September 23, 2002 Princeton University Electrical Engineering Department Specht

GRC. COM Case Study: Initial Attack [7] • May 4, 2001, GRC. COM Dropped Off of the Internet. • Both GRC T 1 lines were at full 1. 54 Mbps capacity. • GRC identified that it was the victim of a Do. S Attack • GRC Firewall and Router were able to stop flood traffic from affecting GRC equipment, but T 1 lines were completely used up. September 23, 2002 Princeton University Electrical Engineering Department Specht

GRC. COM Case Study: Initial Response to DDo. S Attack [7] • GRC uses a packet sniffer to see that the packets on the T 1 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 DDo. S packets were not allowed on to the T 1 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 T 1 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 DDo. S 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” (DDo. S 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 DDo. S 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 DDo. S tools. • GRC communicates with hackers to “lay off”. September 23, 2002 Princeton University Electrical Engineering Department Specht

GRC. COM Case Study: GRC’s Infiltration Network [7] “Sitting Duck” T 1 Trunk Packet sniffer T 1 Trunk 1. 2. 3. IRC Servers 4. Internet Sitting Duck runs the Zombie DDo. S 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 September 23, 2002 Princeton University Electrical Engineering Department Specht

GRC. COM Attack Network Setup Attacker 1. Attacker logs on to IRC server (IRC Server does not store IP address and provides anonymous access. IRC Servers Internet T 1 Trunk 2. Zombie “bots” or DDo. S tools that were previously inserted to PCs out in the network “wake up” and connect to IRC server waiting for instructions. September 23, 2002 T 1 Trunk Verio Router Princeton University Electrical Engineering Department GRC. COM Specht

GRC. COM Attack Network Attacking IRC Servers Attacker 1. Attacker issues command to attack GRC. COM Internet T 1 Trunk 2. Each DDo. S daemon begins to attack the selected website. T 1 Trunk Verio Router September 23, 2002 Princeton University Electrical Engineering Department GRC. COM Specht

Defending Against DDo. S Attacks • Conceptual Model For Defending Against DDo. S • 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 DDo. S 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 DDo. S 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 DDo. S 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 DDo. S 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 DDo. S 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 DDo. S Attacks September 23, 2002 Princeton University Electrical Engineering Department Huang

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

Layer 1: Coordinated Technical Solutions • 1. Improving the security of all relevant devices. ( More detail to be explained by Ali) Before initiating an effective DDo. S 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 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: 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 flood and IP of the nodes that the flood is traveling. the 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 Do. S 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, …Ln), 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. " 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, 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 r 4, r 3, r 2, and r 1. They are probably routers. IV 0 -IV 4 is each a set of indirect victims - those who cannot communicate with v because of the attack. S 1, S 2, S 3, S 4 are other sets of BCs in the network. The intrusion detector w can be part of v or another program. September 23, 2002 Princeton University Electrical Engineering Department Huang

Layer 2: Consistent Incentive Structure Incentive for Zombie Prevention • To stop the Million Zombie Flood we must make it much harder to hijack zombies. If hosts used well known cures to well known vulnerabilities, then they would be much harder to hijack and the Million Zombie Flood would be much more expensive to mount. A great challenge is to induce everyone to protect their hosts. September 23, 2002 Princeton University Electrical Engineering Department Huang

Layer 2: Consistent Incentive Structure Incentive for Zombie Prevention • Non-Economic Approaches: 1. Sue a zombie owner: Who can sue a million zombie owners? 2. Government regulations: Hard to get uniform enforcement across the globe Not necessarily the right regulations Not fast enough to changes of technology September 23, 2002 Princeton University Electrical Engineering Department Huang

Layer 2: Consistent Incentive Structure Incentive for Zombie Prevention • Economic incentives: Anti-flood participants upstream would block traffic bound for the flood's destination. "Destination" could be a single IP address, a net, a subnet, or other unit. Internet Service Providers (ISPs) will have an incentive to police their subscribers, or to police them better. Consider an ISP that is not participating in the anti-flood system and not policing its subscribers. Whenever some of its subscribers flood a victim, the antiflood system will trace the flood to the ISP and block it from sending packets to the victim. All of the other subscribers will suffer. They will not like this, so that is the ISP's incentive. Companies and organizations will likewise have an incentive to make sure that their machines are not used as zombies. In effect, the consequences of neglect (allowing hosts to be hijacked) are pushed closer to the neglector. Now some areas of the Interact will be well policed and suffer few flooding attacks. Other areas will be unpoliced and will suffer a lot. September 23, 2002 Princeton University Electrical Engineering Department Huang

Layer 2: Consistent Incentive Structure Incentive to Join an Anti-Flood System It helps that if more nodes support IDIP. The farther you can trace an attack, the more selective can be your blocking. In the example, if r 4 did not support IDIP, then IV 3 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 DDo. S 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 DDo. S 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 DDo. S Possible forms of DDo. S 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 DDo. S 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, DDo. S 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 DDo. S • 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 DDo. S 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 DDo. S 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 DDo. S 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 DDo. S 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 DDo. S Layer 1: Coordinated technical solutions • Improving the security of devices with high bandwidth connections, e. g. , 3 G 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 DDo. S Layer 2: A consistent incentive structure • An incentive structure based on usage-based fees The direct effect of a usage-based fee is a sharp increase in the cost to zombie devices if they are sending out attacking traffic. With a usage-based fee structure, the owners of high-performance, highbandwidth devices will have the greatest immediate incentive to take security actions. Specifically, such a usage-based fee plan makes ISPs more likely to install coordinated filters and to support user-level traffic controls. Fortunately and unlike the wired Internet industry, the wireless Internet industry starts with usage-based fees. For example, Japanese vendor Do. Ko. Mo’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 DDo. S Layer 2: A consistent incentive structure • Dynamic usage-based fees: a more targeted incentive structure against DDo. S A dynamic usage-based fee scheme deals with unpredictable congestions, including those caused by DDo. S attacks. The characteristic of a dynamic usagebased fee is the increase in unit price when congestion happens or will happen. So the wireless device owners are more likely to set up traffic control rules in their device to instruct to delay or cancel the data transmission when the network is congested or approaching congestion. Therefore, even if an attacker instruct all zombie devices to send attacking traffic at the same time, an effectively synchronized attack is unlikely to occur. September 23, 2002 Princeton University Electrical Engineering Department Huang

Conceptual Model for Wireless Network Against DDo. S 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 DDo. S 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 DDo. S attacks inside the wired Internet. September 23, 2002 Princeton University Electrical Engineering Department Huang

Conceptual Model for Wireless Network Against DDo. S Cost-effectiveness Solution must be proactive and consistent with mainstream and commercial Internet technologies. Employing these existing technologies will significantly reduce the costs and risks in designing future wireless Internet. The Policy Based Networking (PBN) is one promising technology for implementing usagebased fees. September 23, 2002 Princeton University Electrical Engineering Department Huang

Conceptual Model for Wireless Network Against DDo. S 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 DDo. S 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 DDo. S Remarks When DDo. S attacks came to the wired Internet, the infrastructure of the wired Internet had been stable for decades, lacking reliable mechanisms for Qo. S control and incentive structures for traffic control. As a result, it was repeatedly targeted by DDo. S attacks. In comparison, the wireless Internet industry has a chance to address DDo. S attacks before it fully matures. September 23, 2002 Princeton University Electrical Engineering Department Huang

General Protections against DDo. S 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 Do. S. • 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? – IPv 6 doesn’t have ID field September 23, 2002 Princeton University Electrical Engineering Department Bayazit

ITrace • Send a Packet • Why Low Probability? • Why probability pseudo random? Why not just a counter? • Higher volume of traffic September 23, 2002 Princeton University Electrical Engineering Department Bayazit

SPIE • Traffic Logging • Bloom Filtering • Hash Function (k functions map to n bit target space) • High correlation between the headers? September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Computer Based Protection • • • Intrusion Detection Systems Utilizing Basic Protections, SYN Cookies Secure Operating Systems Filtering, Firewalls Security Updates and Tools September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Intrusion Detection Systems Anomaly Based Signature Based Anomaly Based vs. Signature Based • Network Based • Host Based September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Operating System • Windows NT 5/XP? Spoofing • Linux September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Filtering • Ingress Filtering • Egress Filtering – ISP Responsibility – Good Neighbor Network September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Problems with Filtering • Local Domain Spoofing • Non-Spoofing Attacks • Spoofing Necessary – Some Wireless Applications – Inter-network Connections • Requires Processing Power September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Filtering In Detail • What can be filtered? • Case Study on Reflectors September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Defending Against Reflectors • Ingress Filtering – Solves Everything? – Recursive DNS Queries – HTTP Proxy Request • Signature Catch – Wide screen deployment of Filtering – Complex, heavy processing – Impractical for large volume of traffic • Trace Back – Heavy Deployment of new Software – There are many different Software Vendors September 23, 2002 Princeton University Electrical Engineering Department Bayazit

What can be filtered? IP Comments Version Insignificant Header Length Insignificant TOS/DSCP Could Be Useful Length Insignificant Fragments If Not Using NFS, AFS, GRE TTL None (is it? ) Protocol None Checksum None Source ? ? Destination ? ? September 23, 2002 Princeton University Electrical Engineering Department Bayazit

What Can Be Filtered? ICMP Comments Request/Reply Filterable Problem Filterable TCP Comments Source Port Not Much, Depends SYN ACK Not Much, Depends RST Dangerous Sequence numbers DANGEROUS! September 23, 2002 Princeton University Electrical Engineering Department Bayazit

What Can Be Filtered? UDP Comments Connectionless No big deal Length Insignificant Checksum Insignificant September 23, 2002 Princeton University Electrical Engineering Department Bayazit

Defending Against DDo. S – Traffic Tracking • • Network Traffic Tracking Systems (NTTS) Model of Network Anonymity Desirable Properties of an NTTS Three Model Environments September 23, 2002 Princeton University Electrical Engineering Department Specht

Network Traffic Tracking Systems [8] • NTTS (Network Traffic Tracking Systems) – System to track network traffic – Difficult to track network traffic due to: • Spoofing (network traffic source is a lie) • Redirection (network entity receives traffic and edits it in some way before resending) – Issues • NTTS – can be successful in a closed environment with strong infrastructure • In an open, global network (Internet) it is not possible to deploy a perfect NTTS September 23, 2002 Princeton University Electrical Engineering Department Specht

Model of Network Anonymity [8] • • Addition of User Session Layer to 7 layer OSI Model. User Session Layer – models the behavior of user login sessions in which a user logs into a node by way of some application, performs some action, and eventually logs off. User Session Layer allows for “island hopping” and relaying. A relay node is a network node that accepts a flow from the network attack, possibly modifies it, and passes it on to another node on the network. Typical attacks use multiple relays in a serial connection. The last serial node is left with attacker’s print, and previous serial relays are undisclosed, including the location/information of the attacker. September 23, 2002 User Session Layer Application Layer Presentation Layer Network Session Layer Transport Layer Privacy Sensitivity Network/Internetwork Layer Data Link Layer Physical Layer Princeton University Electrical Engineering Department Specht

Desirable properties of an NTTS [8] • Accuracy – Probability that source found for a certain piece of network traffic will be correct – Accuracy needed to get legal search warrant • Precision – Level of specificity that the NTTS identifies the source (i. e. NTTS may identify the host, but not sub-network) • Resist Subversion • Low Overhead (bandwidth, processing, memory) • Low Cost • Scalability (sizing + full vs. partial network coverage) • Realtime vs. Non-realtime tracing • Privacy and Control September 23, 2002 Princeton University Electrical Engineering Department Specht

Three Model Environments [8] • Closed Model – – – • Academic Model – – • Central authority controls all network hosts Independent network, not connected to outside networks All packet information and logs stored Limited end-user privacy expectations (corporate networks) Tracing higher protocol layers is easiest Central authority controls network that connects hosts, but not hosts directly Limitations due to host relaying and high overhead Privacy issues would exist with end-users Possible to trace low level protocols, but high level protocols are difficult Internet Model – – – No Authority controls hosts Modify internetworking protocols to provide “traceability” Issues of cost and overhead Scalability is on the order of millions of systems Privacy Issues Internet spans multinational/multi-government regions September 23, 2002 Princeton University Electrical Engineering Department Specht

References • • Karig, David and Ruby Lee. Remote Denial of Service Attacks and Countermeasures, Princeton University Department of Electrical Engineering Technical Report CE-L 2001 -002, October 2001. Kargl, Frank, Joern Maier, and Michael Weber. Protecting Web Servers from Distributed Denial of Service Attacks. WWW 10, 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. s 3. org/security/faq/ - visited on October 1, 2002. Dittrich, David. The Do. S 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