Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation By VIJAY CHAND UYYURU

Introduction and Motivation Internet attacks are rising: Frequency of reported security incidents grows exponentially Frequency of reported security incidents grows exponentially 1988: 6 incidents  2003: 137‘529 incidents reported by CERT/CC Organised crime is blackmailing owners of e- commerce web sites („pay or you will go offline“): e.g. casino, ad distribution, sport bet sites Organised crime is blackmailing owners of e- commerce web sites („pay or you will go offline“): e.g. casino, ad distribution, sport bet sites New worms, viruses, trojans, and exploits announced almost daily New worms, viruses, trojans, and exploits announced almost daily

Introduction and Motivation Why? More and more computers operated by security unaware users get broadband Internet access More and more computers operated by security unaware users get broadband Internet access Knowledge and tools for attackers abound Knowledge and tools for attackers abound Attackers can use cheap resources (bandwidth, CPU) of thousands of compromised Internet hosts Attackers can use cheap resources (bandwidth, CPU) of thousands of compromised Internet hosts

Direct DDoS Attack Attacker Masters M i From:X i (spoofed) To:Victim V … attack packet From: X i (spoofed) To:Agent A i … control packet From:X i (spoofed) To:Master M i … control packet Victim V Agents A i

Reflector DDoS Attack A new variant of DDoS attacks became known as DDoS “reflector” attack. A new variant of DDoS attacks became known as DDoS “reflector” attack. This attack form is especially difficult to defense against as the victim is flooded with traffic from ordinary Internet servers that were not even compromised. This attack form is especially difficult to defense against as the victim is flooded with traffic from ordinary Internet servers that were not even compromised. Any server that supports a protocol which replies with a packet after it has received a request packet can be misused as a reflector without the need for a server compromise. Any server that supports a protocol which replies with a packet after it has received a request packet can be misused as a reflector without the need for a server compromise.

How DDoS Reflector Attack Works The agents send their packets with the spoofed address set to the victim’s address to “innocent” servers, which act as reflectors. The agents send their packets with the spoofed address set to the victim’s address to “innocent” servers, which act as reflectors. The source addresses of the actual attack packets received by the victim are not spoofed. They belong to legitimate uncompromised servers. The source addresses of the actual attack packets received by the victim are not spoofed. They belong to legitimate uncompromised servers. Stopping traffic from these sources will also terminate access to Internet services that the victim might reply on. Stopping traffic from these sources will also terminate access to Internet services that the victim might reply on.

Reflector DDoS Attack Reflectors R i Attacker Victim V Agents A i From: V (spoofed) To:Reflector R i … attack trigger packet From: X i (spoofed) To:Agent A i … control packet From:X i (spoofed) To:Master M i … control packet From:R i To:Victim V … attack packet Masters M i Note: Reflectors are NOT compromised. They simply answer requests.

Analysis of Mitigation Mechanisms There are two basic mitigation mechanisms: There are two basic mitigation mechanisms: 1. Reactive Mitigation Strategies 2. Proactive mitigation Strategies

Reactive Mitigation Strategies Reactive schemes often proceed in three phases: Reactive schemes often proceed in three phases: In the first phase, distributed monitoring components try to detect on-going DDoS attacks. In the first phase, distributed monitoring components try to detect on-going DDoS attacks. Once an attack is detected, the detector triggers the second phase resulting in the deployment of countermeasures. Once an attack is detected, the detector triggers the second phase resulting in the deployment of countermeasures. In the third phase, when the DDoS attack subsides or stops, countermeasures are relieved or removed. In the third phase, when the DDoS attack subsides or stops, countermeasures are relieved or removed.

Some Examples of Reactive Strategies 1. Traceback mechanisms 2. Internet Indirection Infrastructure 3. Pushback

Traceback mechanisms Traceback is very valuable in forensics to find the origins and may be the originator of the attack, it deals with neither detecting attacks not deploying any dipositions against ongoing attacks. Traceback is very valuable in forensics to find the origins and may be the originator of the attack, it deals with neither detecting attacks not deploying any dipositions against ongoing attacks. Traceback mechanisms play an important role in other reactive mitigation schemes to determine where countermeasures should be deployed and which filtering rules should be applied. Traceback mechanisms play an important role in other reactive mitigation schemes to determine where countermeasures should be deployed and which filtering rules should be applied. Reactive strategies involving traceback mechanisms, will yield a wrong “attack source”- the reflectors – to be identified and possibly filtered, if DDoS attacks involve reflectors. Reactive strategies involving traceback mechanisms, will yield a wrong “attack source”- the reflectors – to be identified and possibly filtered, if DDoS attacks involve reflectors.

Internet Indirection Infrastructure(i3) i3 is implemented as an overlay that is used to route a client’s packets to a trigger and from there to the server. i3 is implemented as an overlay that is used to route a client’s packets to a trigger and from there to the server. Due to performance concerns, i3 would only be used if a server were under attack. Otherwise communication could be established directly between the client and server. Due to performance concerns, i3 would only be used if a server were under attack. Otherwise communication could be established directly between the client and server. To use i3 as a defense mechanisms, IP addresses of the attached servers are assumed to be hidden from the attackers. It remains unclear how server IP addresses can be hidden under attack, when they are known under normal operation. To use i3 as a defense mechanisms, IP addresses of the attached servers are assumed to be hidden from the attackers. It remains unclear how server IP addresses can be hidden under attack, when they are known under normal operation.

Pushback Pushback performs monitoring by observing packet drop statistics in individual routers. Pushback performs monitoring by observing packet drop statistics in individual routers. Once a link becomes overloaded to a certain degree, the pushback logic, which is co-located with routers, classifies dropped packets according to source addresses. The class of source addresses with the highest dropped packet count is then considered to originate form the attacker. Once a link becomes overloaded to a certain degree, the pushback logic, which is co-located with routers, classifies dropped packets according to source addresses. The class of source addresses with the highest dropped packet count is then considered to originate form the attacker. Filter rules to rate limit packets from the identified source address(es) are automatically installed on the concerned router. Routers on the path towards the source(s) of attack are informed about the detected attacks and install the same rules. In this way, the attack is pushed back and confined. Filter rules to rate limit packets from the identified source address(es) are automatically installed on the concerned router. Routers on the path towards the source(s) of attack are informed about the detected attacks and install the same rules. In this way, the attack is pushed back and confined. In many cases, however, an attacked server’s resources are exhausted before its uplink is overloaded. In many cases, however, an attacked server’s resources are exhausted before its uplink is overloaded.

Proactive mitigation Strategies Proactive strategies intend to reduce the possibility of successful DDoS attacks by taking appropriate provisions prior to attack. Some of the strategies are: Proactive strategies intend to reduce the possibility of successful DDoS attacks by taking appropriate provisions prior to attack. Some of the strategies are: 1. Ingress Filtering 2. Secure Overlay networks

Ingress Filtering Ingress filtering rejects packets with spoofed source address at the ingress of a network. (e.g. ISP’s backbone) Ingress filtering rejects packets with spoofed source address at the ingress of a network. (e.g. ISP’s backbone) Attacks involving reflectors with legitimate source addresses, however, are only affected if ingress routing is applied on paths between agents and reflectors. Attacks involving reflectors with legitimate source addresses, however, are only affected if ingress routing is applied on paths between agents and reflectors. Performing ingress filtering puts a management burden on ISPs, because they must keep all filtering rules up to date and defective rules will disgruntle their customers. Performing ingress filtering puts a management burden on ISPs, because they must keep all filtering rules up to date and defective rules will disgruntle their customers.

Secure Overlay networks Secure overlay networks like SOS and Mayday reduce the risk that a DDoS attack severely affects the communication among members of the overlay network to a minimum. Secure overlay networks like SOS and Mayday reduce the risk that a DDoS attack severely affects the communication among members of the overlay network to a minimum. It requires each user of a group wanting to communicate to pre-establish a trust relationship with the other group members. It requires each user of a group wanting to communicate to pre-establish a trust relationship with the other group members. Keeping malicious users out of an overlay will be a challenge for a large user base. Keeping malicious users out of an overlay will be a challenge for a large user base.

Mitigation Effectiveness DDoS attacks are so hard to control because of the fact that attack traffic generally contains spoofed source addresses. DDoS attacks are so hard to control because of the fact that attack traffic generally contains spoofed source addresses. In DDoS reflector attacks this is even more complex, because the victim does not receive traffic from the DDoS agents directly, but from legitimate sources without spoofed source addresses. In DDoS reflector attacks this is even more complex, because the victim does not receive traffic from the DDoS agents directly, but from legitimate sources without spoofed source addresses. If source spoofing was impossible, reflector attacks could be prevented. If source spoofing was impossible, reflector attacks could be prevented. Also complex traceback mechanisms would not be needed, because the originator could be identified by the source address in those packets. Also complex traceback mechanisms would not be needed, because the originator could be identified by the source address in those packets.

Mitigation Effectiveness Making source address spoofing impossible requires proactive mechanisms, since measures have to be taken before an attack. Making source address spoofing impossible requires proactive mechanisms, since measures have to be taken before an attack. They may be implemented directly in the IP network or as an overlay network. More effective defense strategies are possible within the IP network. They may be implemented directly in the IP network or as an overlay network. More effective defense strategies are possible within the IP network. Performing Ingress Filtering, a single router is capable of blocking traffic from a big number of malicious nodes. Performing Ingress Filtering, a single router is capable of blocking traffic from a big number of malicious nodes. ISPs currently lack any incentive to implement proactive mechanisms. ISPs currently lack any incentive to implement proactive mechanisms.

Distributed Traffic Control: Concepts and Approach Definition of traffic ownership: A network data packet is „owned“ by the network user who is officially registered to hold either the source or destination IP address or both.  The server operator „owns“ the traffic his server S will finally receive (to: S)  The user of client C „owns“ the traffic sent until it reaches its destination (from : C) Approach:  We extend the network user‘s control over „his traffic“ to the Internet core (and right to the attacker‘s uplink) by a novel distributed Internet traffic control service. payload to: server S from: client C IP packet:

Adaptive Device for Traffic Control This path only taken by user‘s own packets Idea: Let each IP address owner control his/her Internet traffic Implementation: Adaptive devices to filter/process IP owner’s traffic  Premium service mostly for e-business companies; few packets are rerouted through adaptive device

Deployment of Traffic Control Service ISP … Internet/Backbone Service Provider Incremental deployment: First at border/edge routers of major ISPs, later at most major routers

Service Registration

Service Deployment

Node Architecture

Actions for DDoS Attack Mitigation Traffic processing triggered by matching IP packet header fields (source/dest address, ports etc.), payload, timing and link load conditions etc.: Packet dropping Packet dropping Payload deletion Payload deletion Source blacklisting Source blacklisting Traffic rate control Traffic rate control Ingress filtering for owned IP addresses:  Stops DDoS reflector attacks immediately Ingress filtering for owned IP addresses:  Stops DDoS reflector attacks immediately  Reactive and proactive  Filtering close to source of attack traffic  Coordinated Internet wide attack defence Interne t  IP packet from: S IP packet „from: S“ S B A 

Ruling Out Misuse of Traffic Control Restrictions on Traffic Control Service prevent misuse: Traffic Ownership: Acts only on packets owned by network user Traffic Ownership: Acts only on packets owned by network userOthers: Addressing/Routing: No modification of source or destination addresses Addressing/Routing: No modification of source or destination addresses Resource Usage: No change of time to live (TTL) Resource Usage: No change of time to live (TTL) Traffic Amplification: No increase of packet rate and/or size Traffic Amplification: No increase of packet rate and/or size Traffic Processing: User-defined functionality checked at installation or run time Traffic Processing: User-defined functionality checked at installation or run time  Prevention of collateral damage  ISPs/BSPs don‘t lose control over their network

Other Enabled Traffic Control Services Traceback Proactively collect packet hashes Proactively collect packet hashes Supporting network forensics Supporting network forensics Locate origin of spoofed network traffic Locate origin of spoofed network traffic Automated reaction to traffic anomalies Suspicious increase in connection attempts from/to server or network Suspicious increase in connection attempts from/to server or network Detection of variations in address and/or port usage and spoofing attempts Detection of variations in address and/or port usage and spoofing attempts Network debugging and optimization Measure link delays, packet loss, quality of service Measure link delays, packet loss, quality of service Optimize content distribution network Optimize content distribution network Network forensics Traffic sampling at flow-level and/or packet-level for network forensics Traffic sampling at flow-level and/or packet-level for network forensics

Conclusions and Outlook Any chance of success for the Traffic Control Service? Any chance of success for the Traffic Control Service? –Incrementally deployable Add-on box Add-on box Function may be integrated into future routers Function may be integrated into future routers Not necessary to have complete coverage on all routers Not necessary to have complete coverage on all routers –Premium (paid) service for large customers (not home users!) –Business incentive for network service providers Were issue’s of Internet Service Providers respected? Were issue’s of Internet Service Providers respected? –Approach not “scary” for ISPs: Safe, scalable, controllable –Ever changing shape of DDoS attack threat needs adaptive solution –Technology is not disruptive International patent application filed (PCT/CH2004/000631) International patent application filed (PCT/CH2004/000631) Prototype implementation underway Prototype implementation underway

Thank you! Any questions? Any questions?

Apply Data Mining to Defense-in- Depth Network Security System Written by: Huang, Kao, Hun, Jai, Lin Presented by: Terry Griffin

Introduction

Introduction

Introduction IDS / IPS – –Intrusion Detection / Prevention System IDS – –Packets pass through – –Active logging – –Signature comparisons IPS – –Alters packet data – –Blocks packets (possibly)

Introduction IDS/IPS Types – –Misused Detection Signature based Identifies patterns of traffic or application data presumed to be malicious presumed to be able to detect only 'known' attacks However, sometimes detect new attacks which share characteristics with old attacks, e.g., accessing 'cmd.exe' via a HTTP GET request.

Introduction IDS/IPS Types – –Misused Detection Signature based Snort currently has signatures Used alone can lead to > false positives

Introduction IDS/IPS Types – –Anomaly Detection notify operators of traffic or application content presumed to be different from 'normal' activity on the network or host Typically use “self learning” Require a training phase. Observes “Normal Flow” Normal is relative (set by administrator). Any deviation from normal results in an alert

Introduction This paper attempts to: – –Incorporate data mining within an IDS/IPS – –Obtain real time Dos Alerts – –Decrease number of False Alarms

Defense-in-Depth Architecture The Security Architecture is based on 2 concepts / components: 1.LPS – Local Policy Server 2.GPS – Global Policy Server

Defense-in-Depth Architecture LPS – Local Policy Server –contains a signature database –logs all packets –somewhat of a local IDS/IPS

Defense-in-Depth Architecture GPS – Global Policy Server –Receives logs from LPS’s –Monitors/Controls LPS’s –Does the “Real Time” data mining –Does the “Real Time” data mining –Can shut down / throttle the LANs

Defense-in-Depth Architecture

System Architecture of GPS Consists of 4 components: 1.Security Information Management (SIM) module 2.Global Log Server (GLS) 3.GUI 4.Global Database

System Architecture of GPS 1. Security Information Management (SIM) module Does the actual data miningDoes the actual data mining Details in next sectionDetails in next section 2. Global Log Server (GLS) Manages all logs from the LPSManages all logs from the LPS Must handle multiple parallel incoming connectionsMust handle multiple parallel incoming connections Does no mining, just loggingDoes no mining, just logging

System Architecture of GPS 3.Gui Well... it’s a GUIWell... it’s a GUI 4.Global Database Signature databaseSignature database Created through the logs received from the GLSCreated through the logs received from the GLS

System Architecture of GPS Sim Module has 4 components 1. Online Data Miner classifies records in active databaseclassifies records in active database 2. Rules Tuner runs the machine learning algorithmsruns the machine learning algorithms tunes the parameters of rules accordinglytunes the parameters of rules accordingly 3. GLS 4. Policy Dispatcher Waits for commands from online minerWaits for commands from online miner

System Architecture of GPS Data mining framework

System Implementation and Experiment Results Data flow of online detecting phase is separated into 3 stages: 1.Loading all drivers are loaded all drivers are loaded classifiers loaded and initialized classifiers loaded and initialized 2.Monitoring endless loop monitoring logged packets for signatures endless loop monitoring logged packets for signatures 3.Event Handling Alerts LPS’s Alerts LPS’s Controls / Throttles them if necessary Controls / Throttles them if necessary Author used IDS Snort and IPS NetKeeper as the IDS/IPS backend. Author used IDS Snort and IPS NetKeeper as the IDS/IPS backend.

System Implementation and Experiment Results Data Collection Results –For 18 days NetKeeper detected 886,764 events. –For 5 days Snort logged 11,070 events This was the data used to test the system.

The system was tested with the following 4 combinations of events: Single type Single type (SYN Flooding, TCP Flooding, UDP Flooding / Smurfing, IP Flooding, ICMP Flooding / Smurfing, IGMP Flooding) Mix – 2 Mix – 2 (TCP-SYN, TCP-IP,TCP-ICMP, TCP-IGMP, TCP-UDP, UDP-IP, UDP-ICMP,UDP-IGMP, IP-SYN, IP-ICMP, IP-IGMP, ICMP-IGMP) Mix – 3 Mix – 3 (TCP-SYN-IP, TCP-SYN-UDP,SYN-UDP-IP, SYN-IP-ICMP, UDP-ICMP-IP) Mix – 4 Mix – 4 (SYN-TCP-ICMP-IP,SYN-TCP-UDP-IP, TCP-UDP-ICMP-IP) System Implementation and Experiment Results

Intrusion Detection Results (Detection Rate) System Implementation and Experiment Results 95% detection rate which is “really good” (quote from author)

Intrusion Detection Results (False Alarm Rate) System Implementation and Experiment Results around 1% false alarms (if remove IGMP)

Conclusions Author never really gave detail about the real time system. Really just wrote a wrapper around OTB IDS/IPS systems. This explains formatting problems he mentioned (I didn’t though) Never explained the “retraining” or tuning phase. Whether this was online, or offline. (most important part) Paper made references to figures that didn’t exist.

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 and the Internet. An attack can be directed at an operating system or at the network. When a denial of service (DoS) attack occurs, a computer or a network user is unable to access resources like 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) Ping Flood Attack (ICMP echo) SYN Flood Attack (DoS attack) SYN Flood Attack (DoS attack) DDoS Attack (Distributed SYN Flood) DDoS Attack (Distributed SYN Flood) UDP Flood Attacks UDP Flood Attacks Smurf Attack Smurf Attack DNS name server Attack DNS name server Attack Land Attack Land Attack Ping of Death Attack Ping of Death Attack Fragmentation / Teardrop Attack Fragmentation / Teardrop Attack Connection Spoofing Connection Spoofing Bounce Scanning Bounce Scanning Stealth Communication Stealth Communication

What is a “Spoofed Packet”? Packets sent by an attacker such that the true source is not authentic Packets sent by an attacker such that the true source is not authentic –MAC spoofing –IP packet spoofing – spoofing This is not same as routing attacks This is not same as routing attacks –These cause packets to be redirected e.g. DNS cache poisoning; router table attacks; ARP spoofing 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 Spoofed packets are a part of many attacks –SYN Flood Attack –Smurf Attack –Connection Spoofing –Bounce Scanning –Stealth Communication

IP/TCP Header Review identification header checksum versionTOS header length destination IP address source IP address TTLprotocol options (if any) fragment offsetflags total length IP Header Format data 20 bytes

IP/TCP Header Review source port number header length acknowledgement number sequence number options (if any) destination port number reservedwindow size TCP Header Format data (if any) TCP checksumurgent pointer URGURG ACKACK PSHPSH SYNSYN FINFIN RSTRST 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. 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. 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.) INTERNET PERPETRATOR VICTIM ICMP echo (spoofed source address of victim) Sent to IP broadcast address ICMP echo reply ICMP = Internet Control Message Protocol INNOCENT REFLECTOR SITES BANDWIDTH MULTIPLICATION: A T1 (1.54 Mbps) can easily yield 100 MBbps of attack 1 SYN Simultaneous10,000 SYN/ACKs - VICTIM IS DEAD SOURCE: CISCO

SYN Flood Attack TCP Handshake Review TCP Handshake Review –client sends SYN packet to server sends SYN packet to server waits for SYN-ACK from server waits for SYN-ACK from server –server responds with SYN-ACK packet responds with SYN-ACK packet waits for ACK packet from client waits for ACK packet from client –client sends ACK to server sends ACK to server SYN SYN-ACK ACK

SYN Flood Attack Attacker causes TCP buffer to be exhausted with half-open connections Attacker causes TCP buffer to be exhausted with half-open connections No reply from target needed, so source may be spoofed. No reply from target needed, so source may be spoofed. Claimed source must not be an active host. Claimed source must not be an active host TCP Buffers 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 Attacker causes TCP buffer to be exhausted with half-open connections No reply from target needed, so source may be spoofed. No reply from target needed, so source may be spoofed. Claimed source must not be an active host. Claimed source must not be an active host TCP Buffers 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 ICMP queries UDP packets to closed ports UDP packets to closed ports IP packets with low TTL IP packets with low TTL ICMP replies ICMP replies Port unreachable Port unreachable Time exceeded Time exceeded DNS reply flooding DNS queries (recursive) to DNS servers DNS replies

Detection Methods Routing-based Routing-based Active Active –Proactive –Reactive Passive Passive

Routing-based Method For a given network topology certain source IP addresses should never be seen 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 Internal NIC External NIC

Special Addresses /8- Historical Broadcast /8- Historical Broadcast /8 - RFC 1918 Private Network /8 - RFC 1918 Private Network /8 - Loopback /8 - Loopback /16 - Link Local Networks /16 - Link Local Networks /12 - RFC 1918 Private Network /12 - RFC 1918 Private Network /24 - TEST-NET /24 - TEST-NET /16 - RFC 1918 Private Network /16 - RFC 1918 Private Network /5 - Class E Reserved /5 - Class E Reserved /5 - Unallocated /5 - Unallocated /32 - Broadcast /32 - Broadcast

Routing-based Methods Most commonly used method Most commonly used method –firewalls, filtering routers Relies on knowledge of network topology and routing specs. Relies on knowledge of network topology and routing specs. Primarily used at organizational border. Primarily used at organizational border. Cannot detect many examples of spoofing 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. Looks for behavior that would not occur if client actually processed packet from client. Method: change in IP stack behavior Method: change in IP stack behavior Can observe suspicious activity Can observe suspicious activity Examples – Examples – –TCP window games –SYN-Cookies (block with out detection)

TCP Window Games Modified TCP Handshake Modified TCP Handshake –client sends SYN packet and ACK number to server sends SYN packet and ACK number to server waits for SYN-ACK from server w/ matching ACK number waits for SYN-ACK from server w/ matching ACK number –server responds with SYN-ACK packet w/ initial “random” sequence number responds with SYN-ACK packet w/ initial “random” sequence number Sets window size to zero Sets window size to zero waits for ACK packet from client with matching sequence number waits for ACK packet from client with matching sequence number –client sends ACK to server with matching sequence number, but no data sends ACK to server with matching sequence number, but no data Waits for ACK with window > 0 Waits for ACK with window > 0 After receiving larger window, client sends data. 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 Modified TCP Handshake Example of “stateless” handshake Example of “stateless” handshake –client sends SYN packet and ACK number to server sends SYN packet and ACK number to server waits for SYN-ACK from server with matching ACK number waits for SYN-ACK from server with matching ACK number –server responds with SYN-ACK packet with initial SYN-cookie sequence number responds with SYN-ACK packet with initial SYN-cookie sequence number Sequence number is cryptographically generated value based on client address, port, and time. Sequence number is cryptographically generated value based on client address, port, and time. No TCP buffers are allocated No TCP buffers are allocated –client sends ACK to server with matching sequence number sends ACK to server with matching sequence number –server If ACK is to an unopened socket, server validates returned sequence number as SYN-cookie 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. If value is reasonable, a buffer is allocated and socket is opened.. Spoofed packets will not consume TCP buffers SYN ack-number SYN-ACK seq-number as SYN-cookie, ack-number NO BUFFER ALLOCATED ACK seq_number ack-number+data SYN-ACK 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 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 May use same techniques as proactive methods Example probes Example probes –Is TTL appropriate? –Is ID appropriate? –Is host up? –Change window size

Passive Methods Learn expected values for observed packets Learn expected values for observed packets When an anomalous packet is received, treat it as suspicious When an anomalous packet is received, treat it as suspicious Example values – Example values – –Expected TTL –Expected client port –Expected client OS idiosyncrasies

Experiments Determine the validity of various spoofed- packet detection methods Determine the validity of various spoofed- packet detection methods Predictability of TTL Predictability of TTL Predictability of TTL (active) Predictability of TTL (active) Predictability of ID (active) Predictability of ID (active)

Experiment Description - Passive Monitor network traffic Monitor network traffic Record Record –Source IP address –TTL –Protocol Count occurrences of all unique combinations Count occurrences of all unique combinations Statistically analyze predictability of the data Statistically analyze predictability of the data

Results - Passive Data collected over 2 week periods at University of California, Davis Data collected over 2 week periods at University of California, Davis 23,000,000 IP packets observed 23,000,000 IP packets observed –23461 source IP addresses 110 internal 110 internal external external

Results - Passive Predictability measure Predictability measure –Conditional Entropy (unpredictability) Values closer to zero indicate higher predictability Values closer to zero indicate higher predictability

Results - Passive All packets ProtocolH meanH variance Number Addresses Number Packets All ICMP IGMP TCP UDP

Results - Passive External addresses only ProtocolH meanH variance Number Addresses Number Packets All ICMP IGMP00326 TCP UDP

Results - Passive Internal Addresses Only ProtocolH meanH variance Number Addresses Number Packets All ICMP IGMP TCP UDP

Results - Passive Only Addresses with more than 250 packets ProtocolH meanH variance Number Addresses Number Packets All ICMP IGMP0010 TCP UDP

Results - Passive Only Addresses with more than 500 packets ProtocolH meanH variance Number Addresses Number Packets All ICMP IGMP0010 TCP UDP

Results - Passive TTL differs by protocol TTL differs by protocol UDP most unreliable 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 TTL on local network highly regular –must filter traceroute traffic

Experiment Description - Reactive Monitor network traffic Monitor network traffic Record IP address, Protocol, TTL and ID Record IP address, Protocol, TTL and ID Send probe packet(s) 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. Note the differences between the stored TTL/ID to that of the returning probes.

Results - Reactive Evaluate – Evaluate – –initial vs. probe reply TTL –Initial vs. probe reply ID (delta from original) Predictability measure Predictability measure –Conditional Entropy (unpredictability) Values closer to zero indicate higher predictability Values closer to zero indicate higher predictability

Results - Reactive Preliminary only Preliminary only –Ran for 18 hours –8058 probes sent –218 unique addresses 173 external 173 external 45 internal 45 internal

Results - Reactive TTL off by: TTL off by: –Total # probes –+/- 2 or less % –+/-1 or less % – %

Results - Reactive ID off by: ID off by: –Total # probes8058 –OffsetCount –1601 –257 –421 –616 –514 –711 –89 –OffsetCount –25673 –5125 – –128010

Conclusion Spoofed-packets used in many different attacks Spoofed-packets used in many different attacks Spoofed-packets can be detected by a number of methods Spoofed-packets can be detected by a number of methods High predictability in TTL and ID allow use of passive and active methods High predictability in TTL and ID allow use of passive and active methods

References