* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download spoofed IP packets
Network tap wikipedia , lookup
Point-to-Point Protocol over Ethernet wikipedia , lookup
Wireless security wikipedia , lookup
Computer network wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Dynamic Host Configuration Protocol wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Distributed firewall wikipedia , lookup
Remote Desktop Services wikipedia , lookup
Serial digital interface wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Deep packet inspection wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Internet protocol suite wikipedia , lookup
Zero-configuration networking wikipedia , lookup
TCP congestion control wikipedia , lookup
DoS Seminar 2 Spoofed Packet Attacks and Detection Methods By Prateek Arora Introduction • When a denial of service (DoS) attack occurs, a computer or a network user is unable to access resources like e-mail and the Internet. An attack can be directed at an operating system or at the network. Types of DoS attacks • • • • • • • • • • • • Ping Flood Attack (ICMP echo) SYN Flood Attack (DoS attack) DDoS Attack (Distributed SYN Flood) UDP Flood Attacks Smurf Attack DNS name server Attack Land Attack Ping of Death Attack Fragmentation / Teardrop Attack Connection Spoofing Bounce Scanning Stealth Communication What is a “Spoofed Packet”? • Packets sent by an attacker such that the true source is not authentic – MAC spoofing – IP packet spoofing – Email spoofing • This is not same as routing attacks – These cause packets to be redirected • e.g. DNS cache poisoning; router table attacks; ARP spoofing Significance of “Spoofed Packets” in DoS attacks • Spoofed packets are a part of many attacks – SYN Flood Attack – Smurf Attack – Connection Spoofing – Bounce Scanning – Stealth Communication IP/TCP Header Review IP Header Format version header length TOS identification TTL total length flags protocol fragment offset header checksum source IP address destination IP address options (if any) data 20 bytes IP/TCP Header Review TCP Header Format source port number destination port number sequence number acknowledgement number header length reserved U A P R S F R C S S Y I G K H T N N TCP checksum window size urgent pointer options (if any) data (if any) 20 bytes Smurf Attack • In this attack, spoofed IP packets containing ICMP Echo-Request with a source address equal to that of the attacked system and a broadcast destination address are sent to the intermediate network. • Sending a ICMP Echo Request to a broadcast address triggers all hosts included in the network to respond with an ICMP response packet, thus creating a large mass of packets which are routed to the victim's spoofed address. Smurf Attack (contd.) ICMP echo (spoofed source address of victim) Sent to IP broadcast address ICMP echo reply ICMP = Internet Control Message Protocol INTERNET 1 SYN PERPETRATOR VICTIM Simultaneous10,000 SYN/ACKs - VICTIM IS DEAD INNOCENT REFLECTOR SITES BANDWIDTH MULTIPLICATION: A T1 (1.54 Mbps) can easily yield 100 MBbps of attack SOURCE: CISCO SYN Flood Attack • TCP Handshake Review – client SYN • sends SYN packet to server • waits for SYN-ACK from server – server • responds with SYN-ACK packet • waits for ACK packet from client SYN-ACK – client • sends ACK to server ACK SYN Flood Attack • Attacker causes TCP buffer to be exhausted with half-open connections • No reply from target needed, so source may be spoofed. • Claimed source must not be an active host. TCP Buffers 169.237.5.23 168.150.241.155 169.237.7.114 Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer SYN Flood Attack • Attacker causes TCP buffer to be exhausted with half-open connections • No reply from target needed, so source may be spoofed. • Claimed source must not be an active host. TCP Buffers 128.120.254.1 128.120.254.2 128.120.254.3 128.120.254.4 128.120.254.5 128.120.254.6 128.120.254.7 128.120.254.8 128.120.254.9 128.120.254.10 128.120.254.11 128.120.254.12 128.120.254.13 128.120.254.14 169.237.7.114 128.120.254.15 Half-open connection; Waiting for ACK Completed handshake; connection open empty buffer Summary of attack methods Attack packets Reply packets Smurf ICMP echo queries to broadcast address ICMP echo replies SYN flooding TCP SYN packets TCP SYN ACK packets RST flooding TCP packets to closed ports TCP RST packets ICMP flooding •ICMP queries •UDP packets to closed ports •IP packets with low TTL •ICMP replies •Port unreachable •Time exceeded DNS reply flooding DNS queries (recursive) to DNS servers DNS replies Detection Methods • Routing-based • Active – Proactive – Reactive • Passive Routing-based Method • For a given network topology certain source IP addresses should never be seen – Internal addresses arriving on external interface – External addresses arriving on internal interface – IANA non-routable addresses on external interface – Other special addresses External NIC Internal NIC Special Addresses • • • • • • • • • • 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 172.16.0.0/12 192.0.2.0/24 192.168.0.0/16 240.0.0.0/5 248.0.0.0/5 255.255.255.255/32 - Historical Broadcast - RFC 1918 Private Network - Loopback - Link Local Networks - RFC 1918 Private Network - TEST-NET - RFC 1918 Private Network - Class E Reserved - Unallocated - Broadcast Routing-based Methods • Most commonly used method – firewalls, filtering routers • Relies on knowledge of network topology and routing specs. • Primarily used at organizational border. • Cannot detect many examples of spoofing – Externally spoofed external addresses – Internally spoofed internal addresses Proactive methods • Looks for behavior that would not occur if client actually processed packet from client. • Method: change in IP stack behavior • Can observe suspicious activity • Examples – – TCP window games – SYN-Cookies (block with out detection) TCP Window Games • Modified TCP Handshake – client • • – server • • • – sends SYN packet and ACK number to server waits for SYN-ACK from server w/ matching ACK number responds with SYN-ACK packet w/ initial “random” sequence number Sets window size to zero waits for ACK packet from client with matching sequence number client • • • sends ACK to server with matching sequence number, but no data Waits for ACK with window > 0 After receiving larger window, client sends data. Spoofer will not see 0-len window and will send data without waiting. SYN ack-number SYN-ACK seq-number, ack-number window = 0 ACK seq_number, ack-number (no data) ACK seq-number, ack-number window = 4096 ACK seq_number, ack-number w/ data SYN-Cookies • • Modified TCP Handshake Example of “stateless” handshake – client • • – • • responds with SYN-ACK packet with initial SYN-cookie sequence number Sequence number is cryptographically generated value based on client address, port, and time. No TCP buffers are allocated SYN-ACK • NO BUFFER ALLOCATED sends ACK to server with matching sequence number server • seq-number as SYN-cookie, ack-number ACK client • – ack-number server • – sends SYN packet and ACK number to server waits for SYN-ACK from server with matching ACK number SYN If ACK is to an unopened socket, server validates returned sequence number as SYN-cookie If value is reasonable, a buffer is allocated and socket is opened. seq_number ack-number+data SYN-ACK . Spoofed packets will not consume TCP buffers seq-number, ack-number TCP BUFFER ALLOCATED Reactive methods • When a suspicious packet is received, a probe of the source is conducted to verify if the packet was spoofed • May use same techniques as proactive methods • Example probes – – – – Is TTL appropriate? Is ID appropriate? Is host up? Change window size Passive Methods • Learn expected values for observed packets • When an anomalous packet is received, treat it as suspicious • Example values – – Expected TTL – Expected client port – Expected client OS idiosyncrasies Experiments • Determine the validity of various spoofedpacket detection methods • Predictability of TTL • Predictability of TTL (active) • Predictability of ID (active) Experiment Description Passive • Monitor network traffic • Record – Source IP address – TTL – Protocol • Count occurrences of all unique combinations • Statistically analyze predictability of the data Results - Passive • Data collected over 2 week periods at University of California, Davis • 23,000,000 IP packets observed – 23461 source IP addresses • 110 internal • 23351 external Results - Passive • Predictability measure – Conditional Entropy (unpredictability) H (Y | X ) P( x, y ) log P( x | y ) x, y • Values closer to zero indicate higher predictability Results - Passive All packets Protocol H mean H variance Number Addresses Number Packets All 0.055759 0.029728 23461 22999999 ICMP 0.027458 0.023726 801 223341 IGMP 0 0 23 297 TCP 0.046149 0.023114 15891 20925893 UDP 0.065164 0.040655 7397 1850468 Results - Passive External addresses only Protocol H mean H variance Number Addresses Number Packets All 0.055505 0.029731 23351 9229608 ICMP 0.026159 0.023271 780 88371 IGMP 0 0 3 26 TCP 0.046324 0.023201 15825 8857983 UDP 0.065537 0.041015 7306 283228 Results - Passive Internal Addresses Only Protocol H mean H variance Number Addresses Number Packets 0.109633 0.026097 110 13770391 0.075714 0.03822 21 134970 0 0 20 271 0.004189 0.000321 66 12067910 0.035207 0.010859 91 1567240 All ICMP IGMP TCP UDP Results - Passive Only Addresses with more than 250 packets Protocol H mean H variance Number Addresses Number Packets All 0.060041 0.035521 2876 22338795 ICMP 0.035778 0.020212 33 219605 IGMP 0 0 1 0 TCP 0.051132 0.027288 2713 20332940 UDP 0.165818 0.175238 148 1779896 Results - Passive Only Addresses with more than 500 packets Protocol H mean H variance Number Addresses Number Packets All 0.050635 0.031506 2306 22140140 ICMP 0.022401 0.014516 30 218560 IGMP 0 0 1 0 TCP 0.042716 0.022273 2190 20150197 UDP 0.164326 0.209436 104 1764716 Results - Passive • TTL differs by protocol • UDP most unreliable – traceroute is major contributor (can be filtered) – certain programs set TTL anomalously – ToS may be useful in reducing inconsistencies • TTL on local network highly regular – must filter traceroute traffic Experiment Description Reactive • Monitor network traffic • Record IP address, Protocol, TTL and ID • Send probe packet(s) – ICMP echo reply packet – TCP syn packet – UDP packet • Note the differences between the stored TTL/ID to that of the returning probes. Results - Reactive • Evaluate – – initial vs. probe reply TTL – Initial vs. probe reply ID (delta from original) • Predictability measure – Conditional Entropy (unpredictability) • Values closer to zero indicate higher predictability Results - Reactive • Preliminary only – Ran for 18 hours – 8058 probes sent – 218 unique addresses • 173 external • 45 internal Results - Reactive • TTL off by: – Total # probes – +/- 2 or less – +/-1 or less –0 8058 6467 6096 5110 1591 371 986 80% 75% 63% Results - Reactive • ID off by: – Total # probes 8058 – – – – – – – – Offset 1 2 4 6 5 7 8 Count 601 57 21 16 14 11 9 – – – – – Offset 256 512 768 1280 Count 73 5 22 10 Conclusion • Spoofed-packets used in many different attacks • Spoofed-packets can be detected by a number of methods • High predictability in TTL and ID allow use of passive and active methods References • • • • • • www.google.co.in http://seclab.cs.ucdavis.edu/ www.cert.org www.caida.com http://www.uspto.gov/ www.cisco.com