Presentation on theme: "COMP 7320 Internet Security: Prevention of DDoS Attacks By Dack Phillips."— Presentation transcript:
COMP 7320 Internet Security: Prevention of DDoS Attacks By Dack Phillips
Presentation Overview What are DoS Attacks? DoS Facts and Figures Current Solutions Problems Proposed Solutions Conclusions References Questions
What are DoS Attacks? A malicious attack that consumes resources of remote hosts or networks denying or degrading service to legitimate users, .
Types of DoS Attacks Bandwidth Consumption Program Flaw Exploitation Resource Starvation Routing/DNS Attacks SYN Floods DDoS Attacks
Bandwidth Consumption A computer having more bandwidth floods a smaller server with packets. The smaller server can not respond to the overwhelming load. A computer with small bandwidth convinces a network to flood a host with more bandwidth - A 56 Kbps modem can take down a T1 line like this
Program Flaw Exploitation An attacker sends an operating system, application, or hardware exceptional conditions that it cant handle. - OOBPort 139 on Windows 95 boxen - F00FC7C8Pentium Instruction
Resource Starvation Attacker aims to deplete system, rather than network resources. - CPU - Memory - File System Quotas
Routing/DNS Attacks Routing Information Protocol (RIP) and Border Gateway Protocol (BGP) have very weak authentication. Routing tables are changed to route traffic through an attackers network, another network, or a black hole (non-existent network) DNS is similar except DNS tables are falsified
SYN Floods TCP Connection Handshake client sends server TCP SYN server sends client TCP SYN ACK client sends server ACK or RST In case of a spoofed source address, server keeps trying to send SYN ACKs. Connection Queue fills up with these requests and no legitimate traffic is served
DDoS Attacks An attacker compromises many machines (agents or zombies) and installs DoS daemons The attacker uses a controlling machine (handler) to control the zombie machines to attack a server. More than one handler to prevent single point of failure
DoS Facts and Figures One of the hardest security problems Simple to implement Difficult to prevent Difficult to trace 1989 – 95: CERT reports DoS attacks increased 50% per year Tools are easy to find and use – Smurf, Fraggle, Teardrop, Stream, TFN, Trinoo Stacheldracht, Shaft, Plague, Trinity, et al. February 2000 – eBay, Yahoo, Amazon, etc.
Current Solutions Preventative: Make the OS/IP stack more robust Reactive Phone ISPs and trace back manually, call next ISP in the chain… This is time consuming and ISPs are often unwilling to spend time doing this. In addition, the trace has to be done while the attack is still in progress.
Problems The Internet is stateless; destination driven Source addresses can be easily falsified (spoofed) Attackers use connection chains to hide identities Routers can be compromised Login chains and address spoofing have legitimate uses
Ingress Filtering Defined in RFC 2267 Edge Routers drop and log packets with invalid Source IPs or those coming from outside the network Border Routers should not be allowed to transmit broadcast packets (MAC address FF:FF:FF:FF:FF:FF) to other routers by default
Ingress Filtering (cont) System Diagnostic UDP packets from outside domains should not be allowed into a network Ingress filtering poses problems with Mobile IP. Currently the Mobile IP Working Group is investigating reverse tunneling to solve this problem.
Upstream Router Mapping Network Administrators should make an upstream router map Manually via traceroute Mercator – program that uses hop limited probes and source routers to create upstream maps
Counter Flooding Network Administrators send UDP chargen floods upstream (small scale DoS attack). If a router is perturbed then it is probably being used in the attack. Repeat upstream. Ethical issue – If the trace causes more damage than the attack, should it be used?
PPM PPM – Probabilistic Packet Marking 4 schemes Savage, Wetherall, Karlin & Anderson Song & Perrig Park & Lee Dean, Franklin & Stubblefield
PPM (cont) These schemes overload the IP Identification field used for packet fragmentation In most schemes, a hashing function computes a hash of the routers IP address and writes this hash to the Identification field A distance field is normally included as well that keeps track of how many hops a packet has travelled
PPM (cont) Typical IP Packet
PPM (cont) Dean, etc. employ an algebraic scheme rather than a hash based wherein routers stamp coefficients of their IP addresses % a prime number
PPM (cont) Assumptions: Most paths are less than 25 hops Packets can be addressed to more than one host Duplicate Packets can exist Routers can be compromised Attackers know they can be traced
PPM (cont) PPM schemes must minimize false positives while eliminating false negatives Adding bits to IP headers causes packet fragmentation
PPM (cont) Problems Packets can take more than one path to a destination IPSec requires IP Identification field IP fragmentation is small (<0.25% of traffic) but does exist Routers do not need more overhead
ICMP Traceback Traceroute only works in the forward direction, not in reverse Routers send out ICMP traceback information (interface name, Time stamp) probabilistically (1/1000 – 1/20000) Public key system used to authenticate packets TTL set to 255 to show distance Problem – ICMP is filtered in some networks
Stepping Stone Traceback Stepping Stone – one link in a connection chain If ON/OFF timing between 2 hosts is similar, it is probably a stepping stone Packets often encrypted, check headers Check clear text packets to see if the text from one host is transmitted to another Problem – too much legitimate traffic, not an adequate solution
CenterTrack Edge routers are connected to a special overlay network composed of tracing routers via IP Tunnels In case of attack, the packets are forwarded to the tracking routers which follow the stream back to the source of the attack
CenterTrack (cont) Full packet capture can be added easily to provide attack evidence Problems – Attacks have to be detected to be rerouted TTL is modified and ICMP TTL exceeded messages are sent back, possibly alerting the attacker to the trace
STM Network SPIEs (Source Path Isolation Engines) are installed in routers, or connected to them These SPIEs generate packet digests from 28 non changing bits in the packet (20 from the header, 8 from the payload). The digest is stored in router memory or external storage
STM Network (cont) SPIEs transfer data to SCARs (SPIE Collection and Reduction Agents) if interesting traffic occurs A SCAR can produce an attack graph of a local network STMs (SPIE Traceback Managers) can request information from one or more SCARs and generate a complete attack graph
Conclusions ISPs, unless they offer Mobile IP should use Ingress Filtering Network Administrators should make upstream router maps IPv6 should employ better packet tracing methods
References S. Bellovin. ICMP traceback messages. Internet Draft, IETF, Mar. 2000. draft-bellovin-itrace-05.txt (work in progress).  H. Burch and B. Cheswick. Tracing anonymous packets to their approximate source. In Proc. USENIX LISA 00 (Dec. 2000).  D. Dean, M. Franklin, and A. Stubblefield, "An Algebraic Approach to IP Traceback," in Network and Distributed System Security Symposium, NDSS '01, February 2001.
References S. Dietrich, N. Long, and D. Dittrich, Analyzing ditributed denial of service attack tools: The shaft case, in 14 th Systems Administration Conference, LISA 2000, 2000, http://netsec.gsfc.nasa.gov/spock/lisa2000-shaft.pdf. http://netsec.gsfc.nasa.gov/spock/lisa2000-shaft.pdf P. Ferguson and D. Senie. Network ingress filtering: Defeating denial of service attacks which employ IP source address spoofing. May 2000.RFC 2827. IEEE INFOCOM 2001. R. Govindan and H. Tangmunarunkit. Heuristics for Internet Map Discovery. In Proc. of the 2000 IEEE INFOCOM Conference, Tel Aviv, Israel, Mar. 2000.
References K. Park and H. Lee. On the effectiveness of probabilistic packet marking for IP traceback under denial of service attack. In Proc. IEEE INFOCOM 2001, pages 338-347, 2001. S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Practical network support for IP traceback. In Proc. of ACM SIGCOMM 00, pages 295-306, Aug.2000. A. Snoeren, and C. Partridge. Hash-based IP Traceback. In Proc. ACM SIGCOMM 01, pages 3-14, Aug. 2001.
References D. Song and A. Perrig. Advanced and authenticated marking schemes for IP traceback. Technical Report UCB/CSD-00-1107, Computer Science Department, University of California, Berkeley, 2000. In Proc. IEEE INFOCOM 2001. R. Stone. CenterTrack: An IP Overlay Network for Tracking DoS Floods. In Proc. of the 2000 USENIX Security Symposium, Denver, CO, July 2000. *J. Scambray, S. McClure, and G. Kurtz. Hacking Exposed: Network Security Secrets and Solutions. Second Edition. New York: Osborne/McGraw-Hill, 2001. pages 484-506.
References Y. Zhang and V. Paxson. Stepping Stone Detection. In Proc. of the 2000 USENIX Security Symposium, Denver, CO, July 2000.