slides - ECL Labs

Report
Yuri Gushin & Alex Behar
Introduction
DoS Attacks – overview & evolution
DoS Protection Technology
Operational mode
Detection
Mitigation
Performance
Wikileaks (LOIC) attack tool analysis
Roboo release & live demonstration
Summary
labs
Newton’s Third Law (of Denial of Service)
For every action, there is an equal and opposite reaction.

Research and mitigate DoS attacks

Core founders of the Radware ERT

In charge of Radware’s strategic security customers around
EMEA and the Americas

Goal – exhaust target resources to a point where
service is interrupted

Common motives
 Hacktivism
 Extortion
 Rivalry

Most big attacks succeed!

Scoping the threat – main targets at risk
 On-line businesses, converting uptime to revenue
 Cloud subscribers, paying per-use for bandwidth
utilization

Layer 3 - muscle-based attacks
 Flood of TCP/UDP/ICMP/IGMP packets, overloading infrastructure due
to high rate processing/discarding of packets and filling up the packet
queues, or saturating pipes
 Introduce a packet workload most gear isn't designed for
 Example - UDP flood to non-listening port
I’m hit!
I’m hit!
I’m hit!
CPU
overloaded
CPU
overloaded
CPU
overloaded
UDP to port 80
Internet
Access
Router
Firewall
IPS
Switch
DMZ

Layer 4 – slightly more sophisticated
 DoS attacks consuming extra memory, CPU cycles, and triggering
responses




TCP SYN flood
TCP new connections flood
TCP concurrent connections exhaustion
TCP/UDP garbage data flood to listening services (ala LOIC)
I’m hit!
SYN queue is full,
dropping new
connections
 Example – SYN flood
SYN
Internet
Access
Router
Firewall
IPS
Switch
DMZ
SYN+ACK

Layer 7 – the culmination of evil!
 DoS attacks abusing application-server memory and performance
limitations – masquerading as legitimate transactions





HTTP page flood
HTTP bandwidth consumption
DNS query flood
SIP INVITE flood
Low rate, high impact attacks - e.g. Slowloris, HTTP POST DoS
I’m hit!
HTTP requests/second at
the maximum
HTTP: GET /
Internet
Access
Router
Firewall
IPS
Switch
DMZ
HTTP:
200 OK
HTTP: 503 Service
Unavailable
①
Operational modes
②
Detection
③
Mitigation
Operational mode
①
Operational mode
The operational mode is defined during the configuration of
an Anti-DoS system.
There are two typical operational modes:
 Static – static rate-based thresholds are set for
detection (e.g. SYNs/second, HTTP
requests/second)

Adaptive – the system learns and adapts dynamic
thresholds continuously, according to the network
characteristics
 Static thresholds

×
×
Put the user in control
Requires constant tuning and maintenance – decreasing
accuracy and increasing operational expenses
Restricts detection phase to a single-dimension (rate)
 Adaptive thresholds



Adapts to the real traffic characteristics, improving accuracy
Automatic – no need to tune every time before Christmas!
Anything can be learned – allowing the detection phase for
behavioral multi-dimensional decision-making (rate & ratio)
Detection
②
Detection
Reliant on the data from the previous phase – the
detection phase can be one of the following:

Rate-based (single-dimensional) – the detection engine
will detect anything breaching the threshold as an attack

Behavioral (multi-dimensional) – the detection engine
will correlate the dynamic thresholds and real-time traffic
of several dimensions (e.g. rate & ratio) to detect an
attack
Rate-based (single-dimensional)

×
×
Prone to false-positives (legitimate traffic identified as attack)
Prone to false-negatives (attack traffic below the radar) Attack
No attacks
Detected
Examples:
 SYNs / second
 HTTP requests / second
 HTTP requests / second / source IP
Current rate
Current rate
Threshold
HTTP requests
/second
Behavioral (multi-dimensional)


Highly accurate due to correlation of multiple dimensions

Rate dimension consists of the throughput and rate of
packets/requests/messages (depending on the protected layer)
▪

E.g. PPS, BPS, HTTP requests per second, SIP messages per second, DNS queries
per second
Ratio dimension consists of the ratio, per protocol, of
message/packet/request/data types
▪
E.g. L4 Protocol %, TCP flag %, HTTP content-type %, DNS query type %
 Logic – both dimensions must identify “anomalies” to decide an
attack is ongoing
Example: L3 flood
Decision = Attack!
Z-axis
X-axis
Attack Degree axis
Attack area
Suspicious
area
Normal area
Y-axis
Abnormal protocol
distribution [%]
Abnormal rate
of packets,…
Example: L4 flood
Decision = Attack!
Z-axis
X-axis
Attack Degree axis
Attack area
Suspicious
area
Normal area
Y-axis
Abnormal TCP flag
distribution [%]
Abnormal rate
of SYN packets
Example: L7 flood
Decision = Attack!
Z-axis
X-axis
Attack Degree axis
Attack area
Suspicious
area
Normal area
Y-axis
Abnormal content-type
distribution [%]
Abnormal rate of
HTTP requests
Example: Flash Crowd scenario
Z-axis
X-axis
Attack Degree axis
Attack area
Suspicious
area
Normal area
Normal TCP flag
distribution [%]
Decision = not an
attack!
Y-axis
Abnormal rate of
SYN packets
Mitigation
③
Mitigation
An attack has been detected, now we need to analyze it
and start mitigating!
Mitigation flow
 Analysis
 Active & passive mitigation

Analysis – generate a real-time signature of the ongoing
DoS attack, by using the highest repeating anomaly
values from L3-L7 headers

Exactly what you do manually when under attack, sifting through
Wireshark looking for patterns 
Juno2.c – Popular SYN Flooder



Very good performance (up to 700K PPS per box)
Creates a fairly static header
Each attack has its own “fixed” characteristics
[src.port + dst.port + win.size + ip.ttl + tcp.ack != 0]

Passive mitigation techniques



Rate-limit packets according to the threshold (skipping analysis)
Drop matches to the real-time signature created during analysis
Active mitigation techniques



Challenge/Response – issue challenges for various protocols to
clean out clients/flooders without a real protocol stack
Session Disruption (effective with stateful attacks) – drop
malicious packets while resetting the session with the server,
occupying the flooders’ TCP/IP stack sockets and forcing
retransmits
Tarpit (effective with stateful attacks) – actively stall malicious TCP
sessions (e.g. TCP window size = 0)

Passive mitigation techniques

Rate-limit packets according to the threshold (skipping analysis)
Attack Detected
Dropped
Current rate
Threshold
HTTP requests
/second

Passive mitigation techniques

Drop matches to the real-time signature created during analysis

Example – Juno2.c
Drop matches to:
[src.port = 1238 && dst.port = 80 &&
win.size = 8192 && tcp.ack != 0]
SYN
Internet
Access
Router
Anti-DoS
Firewall
IPS
Switch
DMZ

Active mitigation techniques

Challenge/Response – issue challenges for various protocols to
clean out clients/flooders without a real protocol stack
Example – HTTP Javascript stack verification
HTTP: GET /
Internet
HTML + Javascript
instructing the
browser to set a
cookie and reload
HTTP: 200 OK
Access
Router
Anti-DoS
Firewall
IPS
Switch
DMZ

Active mitigation techniques

Challenge/Response – issue challenges for various protocols to
clean out clients/flooders without a real protocol stack
Example – HTTP Flash Player verification
HTTP: GET /
Internet
SWF including
Javascript code to
set a cookie and
reload
HTTP: 200 OK
Access
Router
Anti-DoS
Firewall
IPS
Switch
DMZ

Active mitigation techniques

Session Disruption - drop carefully selected packets in
connections, while resetting the session with the server,
occupying the flooders’ sockets and forcing retransmits
GET request packet
is silently dropped
HTTP: GET /
Backend connection
is reset, or avoided
completely
TCP RESET
RETRANSMIT
Internet
RETRANSMIT
Access
Router
RETRANSMIT
Anti-DoS
Firewall
IPS
Switch
DMZ

Active mitigation techniques

Tarpit (effective with stateful attacks) – actively stall malicious TCP
sessions (e.g. TCP window size = 0)
Window size = 5
SYN
SYN+ACK
ACK / Data
Attacker’s TCP stack
enters “persist” state,
periodically sending
window probes
ACK window size=0
Internet
Window probe
Access
Router
ACK window
size=0
Anti-DoS
Firewall
IPS
Switch
DMZ
Mitigation Performance

Link capacity breakdown (for 84-byte untagged frames)

Most off-the-shelf x86 hardware deals poorly with such workloads

Maintaining connection states for the good guys is a must while
blocking the bad guys – even more performance intensive

Resilient mitigation of high-rate attacks is currently only possible
with ASIC-based architectures
Table source: Juniper Networks KB14737





Used in December 2010’s Operation Payback attacks
Flood attack vectors: UDP and TCP data, HTTP requests
Uses windows sockets to send data – stateful
Generates malformed HTTP requests
Terrible thread and IO management

Uses advanced non-interactive HTTP challenge/response
mechanisms to detect & mitigate HTTP Robots

Weeds out the larger percentage of HTTP robots which do
not use real browsers or implement full browser stacks,
resulting in the mitigation of various web threats:
 HTTP Denial of Service tools - e.g. Low Orbit Ion Cannon
 Vulnerability Scanning - e.g. Acunetix Web Vulnerability Scanner, Metasploit
Pro, Nessus
 Web exploits
 Automatic comment posters/comment spam as a replacement of
conventional CAPTCHA methods
 Spiders, Crawlers and other robotic evil

Will respond to each GET or POST request from an
unverified source with a challenge:
 Challenge can be Javascript or Flash based, optionally Gzip
compressed
 A real browser with full HTTP, HTML, Javascript and Flash
player stacks will re-issue the original request after setting a
special HTTP cookie that marks the host as “verified”

Marks verified sources using an HTTP Cookie

Uses a positive security model - all allowed robotic
activity must be whitelisted

Verification cookie is calculated as follows:
 SHA1(client_IP, timebased_rand, secret) – 160bits
▪ Timebased_rand changes every X seconds (cookie validity
window)
▪ Secret is a 512 bit randomly-generated value that initializes
when Roboo starts

Integrates with Nginx web server and reverse
proxy as an embedded Perl module

Available at https://github.com/yuri-gushin/Roboo/
Roboo vs. LOIC & MSF
DoS business is literally booming


Attack power is growing (source: Arbor Networks, December 2010)

Cloud-subscribers become new targets

Anti-DoS technologies have greatly evolved


Goodbye rate-limits
Hello adaptive, behavioral detection, real-time signatures, active
mitigation and dedicated Anti-DoS architectures

similar documents