Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation

1
Adaptive Distributed Traffic Control Service for
DDoS Attack Mitigation

• By
• VIJAY CHAND UYYURU

2
Introduction and Motivation

• Internet attacks are rising
• Frequency of reported security incidents grows
  exponentially
• 1988 6 incidents ? 2003 137529 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
• New worms, viruses, trojans, and exploits
  announced almost daily

3
Introduction and Motivation

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

4
Direct DDoS Attack
Attacker
Victim V
Masters Mi
Agents Ai
From Xi (spoofed) To Victim V
From Xi (spoofed) To Agent Ai
From Xi (spoofed) To Master Mi
attack packet
control packet
control packet
5
Reflector DDoS 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.
• 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.

6
How DDoS Reflector Attack Works

• The agents send their packets with the spoofed
  address set to the victims 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.
• Stopping traffic from these sources will also
  terminate access to Internet services that the
  victim might reply on.

7
Reflector DDoS Attack
Note Reflectors are NOT compromised. They simply
answer requests.
Attacker
Victim V
Agents Ai
Masters Mi
From V (spoofed) To Reflector Ri
From Xi (spoofed) To Agent Ai
From Xi (spoofed) To Master Mi
From Ri To Victim V
attack trigger packet
control packet
control packet
attack packet
8
Analysis of Mitigation Mechanisms

• There are two basic mitigation mechanisms
• Reactive Mitigation Strategies
• Proactive mitigation Strategies

9
Reactive Mitigation Strategies

• Reactive schemes often proceed in three phases
• 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.
• In the third phase, when the DDoS attack subsides
  or stops, countermeasures are relieved or
  removed.

10
Some Examples of Reactive Strategies

• Traceback mechanisms
• Internet Indirection Infrastructure
• Pushback

11
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 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.

12
Internet Indirection Infrastructure(i3)

• i3 is implemented as an overlay that is used to
  route a clients 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.
• 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.

13
Pushback

• 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.
• 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 servers
  resources are exhausted before its uplink is
  overloaded.

14
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
• Ingress Filtering
• Secure Overlay networks

15
Ingress Filtering

• Ingress filtering rejects packets with spoofed
  source address at the ingress of a network. (e.g.
  ISPs backbone)
• 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.

16
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.
• 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.

17
Mitigation Effectiveness

• 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.
• 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.

18
Mitigation Effectiveness

• 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.
• 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.

19
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 users control over his
  traffic to the Internet core (and right to the
  attackers uplink) by a novel distributed
  Internet traffic control service.

payload
toserver S
fromclient C
IP packet
20
Adaptive Device for Traffic Control
Idea Let each IP address owner control his/her
Internet traffic Implementation Adaptive devices
to filter/process IP owners traffic ? Premium
service mostly for e-business companies few
packets are rerouted through adaptive device
This path only taken by users own packets
21
Deployment of Traffic Control Service
ISP Internet/Backbone Service Provider
Incremental deploymentFirst at border/edge
routers of major ISPs, later at most major
routers
22
Service Registration
23
Service Deployment
24
Node Architecture
25
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
• Payload deletion
• Source blacklisting
• Traffic rate control
• 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

IP packetfrom S
?
S
A
Internet
?
?
IP packetfrom S
B
IP packetfrom S
26
Ruling Out Misuse of Traffic Control

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

27
Other Enabled Traffic Control Services

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

28
Conclusions and Outlook

• Any chance of success for the Traffic Control
  Service?
• Incrementally deployable
• Add-on box
• Function may be integrated into future 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 issues 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)
• Prototype implementation underway

29
Thank you!

• Any questions?

30
Apply Data Mining to Defense-in-Depth Network
Security System

• Written by Huang, Kao, Hun, Jai, Lin
• Presented by Terry Griffin

31
Introduction
http//www.cert.org/present/cert-overview-trends/
32
Introduction
http//www.cert.org/present/cert-overview-trends/
33
Introduction

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

34
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.

35
Introduction

• IDS/IPS Types
• Misused Detection
• Signature based
• Snort currently has 2200 signatures
• Used alone can lead to gt false positives

36
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

37
Introduction

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

38
Defense-in-Depth Architecture

• The Security Architecture is based on 2 concepts
  / components
• LPS Local Policy Server
• GPS Global Policy Server

39
Defense-in-Depth Architecture

• LPS Local Policy Server
• contains a signature database
• logs all packets
• somewhat of a local IDS/IPS

40
Defense-in-Depth Architecture

• GPS Global Policy Server
• Receives logs from LPSs
• Monitors/Controls LPSs
• Does the Real Time data mining ?
• Can shut down / throttle the LANs

41
Defense-in-Depth Architecture
42
System Architecture of GPS

• Consists of 4 components
• Security Information Management (SIM) module
• Global Log Server (GLS)
• GUI
• Global Database

43
System Architecture of GPS

• Security Information Management (SIM) module
• Does the actual data mining
• Details in next section
• Global Log Server (GLS)
• Manages all logs from the LPS
• Must handle multiple parallel incoming
  connections
• Does no mining, just logging

44
System Architecture of GPS

• Gui
• Well... its a GUI
• Global Database
• Signature database
• Created through the logs received from the GLS

45
System Architecture of GPS

• Sim Module has 4 components
• Online Data Miner
• classifies records in active database
• Rules Tuner
• runs the machine learning algorithms
• tunes the parameters of rules accordingly
• GLS
• Policy Dispatcher
• Waits for commands from online miner

46
System Architecture of GPS

• Data mining framework

47
System Implementation and Experiment Results

• Data flow of online detecting phase is separated
  into 3 stages
• Loading
• all drivers are loaded
• classifiers loaded and initialized
• Monitoring
• endless loop monitoring logged packets for
  signatures
• Event Handling
• Alerts LPSs
• Controls / Throttles them if necessary
• Author used IDS Snort and IPS NetKeeper as the
  IDS/IPS backend.

48
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.

49
System Implementation and Experiment Results

• The system was tested with the following 4
  combinations of events
• Single type
• (SYN Flooding, TCP Flooding, UDP Flooding /
  Smurfing, IP Flooding, ICMP Flooding / Smurfing,
  IGMP Flooding)
• 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
• (TCP-SYN-IP, TCP-SYN-UDP,SYN-UDP-IP,
  SYN-IP-ICMP, UDP-ICMP-IP)
• Mix 4
• (SYN-TCP-ICMP-IP,SYN-TCP-UDP-IP, TCP-UDP-ICMP-IP)

50
System Implementation and Experiment Results

• Intrusion Detection Results (Detection Rate)

95 detection rate which is really good (quote
from author)
51
System Implementation and Experiment Results

• Intrusion Detection Results (False Alarm Rate)

around 1 false alarms (if remove IGMP)
52
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
  didnt though)
• Never explained the retraining or tuning phase.
  Whether this was online, or offline. (most
  important part)
• Paper made references to figures that didnt
  exist.

53
DoS Seminar 2Spoofed Packet Attacks and
Detection Methods

• By
• Prateek Arora

54
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.

55
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

56
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

57
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

58
IP/TCP Header Review
IP Header Format
version
TOS
header length
total length
identification
fragment offset
flags
header checksum
TTL
protocol
20 bytes
source IP address
destination IP address
options (if any)
data
59
IP/TCP Header Review
TCP Header Format
source port number
destination port number
sequence number
acknowledgement number
20 bytes
header length
reserved
window size
TCP checksum
urgent pointer
options (if any)
data (if any)
60
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.

61
Smurf Attack (contd.)
ICMP echo (spoofed source address of victim)
Sent to IP broadcast address
ICMP echo reply
ICMP Internet Control Message
Protocol
INTERNET
PERPETRATOR
VICTIM
INNOCENTREFLECTOR SITES
BANDWIDTH MULTIPLICATION A T1 (1.54 Mbps) can
easily yield 100 MBbps of attack
SOURCE CISCO
62
SYN Flood Attack

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

SYN
SYN-ACK
ACK
63
SYN Flood Attack
TCP Buffers

• 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.

169.237.5.23
168.150.241.155
169.237.7.114
64
SYN Flood Attack
TCP Buffers

• 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.

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
65
Summary of attack methods
66
Detection Methods

• Routing-based
• Active
• Proactive
• Reactive
• Passive

67
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
68
Special Addresses

• 0.0.0.0/8 - Historical Broadcast
• 10.0.0.0/8 - RFC 1918 Private Network
• 127.0.0.0/8 - Loopback
• 169.254.0.0/16 - Link Local Networks
• 172.16.0.0/12 - RFC 1918 Private Network
• 192.0.2.0/24 - TEST-NET
• 192.168.0.0/16 - RFC 1918 Private Network
• 240.0.0.0/5 - Class E Reserved
• 248.0.0.0/5 - Unallocated
• 255.255.255.255/32 - Broadcast

69
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

70
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)

71
TCP Window Games
SYN ack-number

• Modified TCP Handshake
• client
• sends SYN packet and ACK number to server
• waits for SYN-ACK from server w/ matching ACK
  number
• server
• 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 gt 0
• After receiving larger window, client sends data.
• Spoofer will not see 0-len window and will send
  data without waiting.

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
72
SYN-Cookies
SYN ack-number

• Modified TCP Handshake
• Example of stateless handshake
• client
• sends SYN packet and ACK number to server
• waits for SYN-ACK from server with matching ACK
  number
• server
• 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
• client
• 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 value is reasonable, a buffer is allocated and
  socket is opened.
• .
• Spoofed packets will not consume TCP buffers

SYN-ACK seq-number as SYN-cookie, ack-number NO
BUFFER ALLOCATED
ACK seq_number ack-numberdata
SYN-ACK seq-number, ack-number TCP BUFFER
ALLOCATED
73
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

74
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

75
Experiments

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

76
Experiment Description - Passive

• Monitor network traffic
• Record
• Source IP address
• TTL
• Protocol
• Count occurrences of all unique combinations
• Statistically analyze predictability of the data

77
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

78
Results - Passive

• Predictability measure
• Conditional Entropy (unpredictability)
• Values closer to zero indicate higher
  predictability

79
Results - Passive
80
Results - Passive
81
Results - Passive
82
Results - Passive
83
Results - Passive
84
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

85
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.

86
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

87
Results - Reactive

• Preliminary only
• Ran for 18 hours
• 8058 probes sent
• 218 unique addresses
• 173 external
• 45 internal

88
Results - Reactive

• TTL off by
• Total probes 8058 1591
• /- 2 or less 6467 371 80
• /-1 or less 6096 986 75
• 0 5110 63

89
Results - Reactive

• ID off by
• Total probes 8058

• Offset Count
• 1 601
• 2 57
• 4 21
• 6 16
• 5 14
• 7 11
• 8 9

• Offset Count
• 256 73
• 512 5
• 768 22
• 1280 10

90
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

91
References

• www.google.co.in
• http//seclab.cs.ucdavis.edu/
• www.cert.org
• www.caida.com
• http//www.uspto.gov/
• www.cisco.com