Transcript World Wide Security Report Worldwide Security Report and

Worldwide Infrastructure Security Report
Large Scale DDoS Attacks Update
CF Chui – Solutions Architect, Arbor Networks
Sept 2014
Worldwide Infrastructure Security
Report (WISR) Q2 2014 Update
The Arbor ATLAS Initiative: Internet Trends
 290+ ISPs sharing real-time data - > ATLAS Internet Trends
– Automated hourly export of XML file to Arbor server (HTTPS)
– File is anonymous, only tagged with
– User Specified Region e.g. Europe
– Provider Type (self categorized) e.g. Tier 1
 Data derived from Flow / BGP / SNMP correlation
– Arbor Peakflow SP product
– Correlates Sampled Flow / BGP in real-time
– Distributed in nature
– Network / Router / Interface etc. Traffic Reporting
– Threat Detection (DDoS / infected sub)
– Multiple detection mechanisms
 ATLAS currently monitoring a peak of around 90Tbps of IPv4 traffic
(peak) across all respondents.
- A significant proportion of Internet traffic
ATLAS Global Threat Analysis System
The ATLAS Global Threat Analysis and
Monitoring System is actively monitoring more
than 90 Tbps or 1/3 of all internet traffic 24/7
The Arbor ATLAS Initiative: Internet Trends 2014
 Key Findings :
 Q1 2014 saw probably the most concentrated burst of large volumetric
DDoS attacks ever, things have calmed down again in Q2.
 NTP reflection attacks still significant, but reduced numbers / size compared
to Q1. NTP traffic volumes falling globally, but still not back to ‘normal’.
 Largest attack in Q2 is NTP reflection, but ‘ONLY’ 154Gbps, target in Spain.
 Already seen more than 2x the number of events over 20Gbps compared to
2013.
 Already seen more than 100 events over 100Gb/sec this year.
 Non Initial Fragment attacks still the most common, but big increase in
proportion of attacks targeting DNS (53) in Q2.
2014 ATLAS : World-Wide
 Second quarter of new ATLAS data-set
 Focus on providing baseline data for future comparisons
 Comparisons to Q1 2014
 2014 Q2 Summary :
 2014 Q2 Average:
 2014 Q2 Peak:
 759.83 Mb/sec (- 47% from Q1)
 199.85 Kpps (- 36% from Q1)
World 2014 Q1 Size Break-Out, BPS
 154.69 Gb/sec (-101% from Q1)
 80 Mpps (-18% from Q1)
World 2014 Q2 Size Break-Out, BPS
<500Mbps
<500Mbps
>500Mbps<1Gbps
>500Mbps<1Gbps
>1<2Gbps
>1<2Gbps
>2<5Gbps
>2<5Gbps
>5<10Gbps
>5<10Gbps
>10<20Gbps
>10<20Gbps
>20Gbps
>20Gbps
2014 ATLAS: Hong Kong
 2014 Q2 Summary :
 2014 Q2 Average:
 2014 Q2 Peak:
 713.26 Mb/sec (+20.4% from
Q1)
 232.46 Kpps (+40.5% from Q1)
ATLAS data for HK 2014 Q1
 47.24 Gb/sec (+67% from Q1)
 8.52 Mpps (+32% from Q1)
ATLAS data for HK 2014 Q2
>20Gbps
>20Gbps
10-20Gbps
10-20Gbps
5-10Gbps
5-10Gbps
2-5Gbps
2-5Gbps
1-2Gbps
1-2Gbps
500Mbps-1Gbps
500Mbps-1Gbps
<500Mbps
<500Mbps
2014 ATLAS : World-Wide
NTP Reflection / Amplification
 NTP attacks clearly shown in
ATLAS traffic data.
 NTP cooling off through the end of
March and into Q2
 Average of 1.29 Gbps NTP traffic
globally in November 2013
 Average of 351.64 Gbps in February
2014
 Average of 32.3 Gbps in June 2014
 Still significantly above 2013 levels
 6% of events overall (down from 14% in Q1)
 34% of events over 10Gbps (down from
56%)
 48.7% of events over 100Gbps (down
84.7%)
NTP (Gbps)
Proportion of Events
with Source Port 123
1400
1200
1000
800
600
400
200
11/01/2013 00:00
11/13/2013 00:00:00
11/25/2013 00:00:00
12/07/2013 00:00
12/19/2013 00:00:00
12/31/2013 00:00:00
01/12/2014 00:00
01/24/2014 00:00:00
02/05/2014 00:00
02/17/2014 00:00:00
03/01/2014 00:00
03/13/2014 00:00:00
03/25/2014 00:00:00
04/06/2014 00:00
04/18/2014 00:00:00
04/30/2014 00:00:00
05/12/2014 00:00
05/24/2014 00:00:00
06/05/2014 00:00
06/17/2014 00:00:00
06/29/2014 00:00:00
0
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
All
>10G
>100G
Dec
Jan
Feb
March
April
May
June
2014 ATLAS: Hong Kong
 Majority of the attacks seen were NOT NTP reflection attacks
 Most attacks were TCP SYN to port 80
Largest attacks
50
45
40
35
30
25
20
15
10
5
0
Attacks > 10 Gbps
>10 Gbps
NTP > 10Gbps
38
44
26.38
Gbps
22.86
14
17.97
15.45
5
9.92
Jan
0
Feb
Mar
Apr
May
Jun
0
Jan
1
0
Feb
0
Mar
3
Apr
1
0
May
0
Jun
2014 ATLAS : World-Wide
Other Protocols for Amplification
 Given the huge storm of NTP
 Only two protocols show any
reflection activity, there has been
significant activity
some focus (in the media) on other
 Virtually nothing on QOTD, SSDP,
Quake3.
protocols that can be used in this
 NOTE: Some of these attacks make use
way.
of non-initial-fragments which are not
accounted for below.
Protocol
UDP Port
Percentage
of Attacks in
Q2
Max Size
Average Size
SNMP
161
0.1%
18.61Gbps
765.6Mbps
Chargen
19
1.4%
54.4Gbps
1.18Gbps
2014 ATLAS : World-Wide
Largest Monitored Attack Sizes Year on Year
BPS
2012
2013
2014
(so far)
PPS
• 100.84Gb/sec, destination
unknown
• 82.36Mpps, destination
unknown
• Lasted 20 mins
• Lasted 24 mins
• 245Gb/sec (TCP SYN)
• 202Mpps (UDP/9656)
• Lasted 16 mins
• Lasted 8 mins
• 325Gb/sec (NTP), France
• 94.42Mpps, port 80, US
• Lasted 4 h 22 mins
• Lasted 7 mins
DDoS Amplification Attacks
What are Reflection/Amplification Attacks?
Amplification DDoS Attack
• Is when an attacker makes a relatively small request that
generates a larger response/reply.
Reflection DDoS Attack
• A DDoS attack in which forged requests are sent to a very
large number of devices that reply to the requests. Using IP
address spoofing, the ‘source’ address is set to the actual
target of the attack, where all replies are sent.
A Reflection/Amplification DDoS Attack combines both
techniques to create a DDoS attack which is both high-volume
and difficult to trace back to its point(s) of origin.
Why NTP for These Attacks?
Abbreviation
Protocol
Ports
Amplification
Factor
# Abusable
Servers
CHARGEN
Character
Generation
Protocol
UDP / 19
~17.75x
Tens of
thousands
(~90K)
DNS
Domain
Name
System
UDP / 53
~160x
Millions
(~30M)
NTP
Network
Time
Protocol
UDP / 123
~1000x
Over One
Hundred
Thousand
(~128K)
SNMP
Simple
Network
Management
Protocol
UDP / 161
~880x
Millions
(~5M)
Danger of NTP Reflection/Amplification Attacks
 Implemented in all major operating systems, network
infrastructure, and embedded devices
 Availability of over a hundred thousand of abusable NTP
servers with admin functions incorrectly open to the general
Internet
 Gaps in anti-spoofing deployment at network edges
 High amplification ratio
 Low difficulty of execution
 Readily-available attack tools
 High impact
= Significant risk for any potential targets
Attack Detection, Classification,
Traceback, and Mitigation for
Amplified DDoS attacks
Characteristics of an NTP Reflection/Amplification Attack
• The attacker spoofs the IP address of the target of the
attack, sends monlist, showpeers, or other NTP level-6/-7
administrative queries to multiple misconfigured, abusable
NTP services running on servers, routers, home CPE
devices, etc.
• The attacker chooses the UDP port which he’d like to
target – typically, UDP/80 or UDP/123, but it can be any
port of the attacker’s choice – and uses that as the source
port. The destination port is UDP/123
• The NTP services ‘reply’ to the attack target with streams
of ~468-byte packets sourced from UDP/123 to the` target;
the destination port is the source port the attacker chose
while generating the NTP queries.
The Two Factors Which Make These Attacks Possible
• Failure to deploy anti-spoofing mechanisms
such as Unicast Reverse-Path Forwarding
(uRPF), ACLs, DHCP Snooping & IP Source
Guard, Cable IP Source Verify, ACLs, etc. on the
edges of ISP and enterprise networks.
• Misconfigured, abusable NTP services running
on servers, routers, switches, home CPE devices,
etc.
Additional Contributing Factors
•
•
•
•
•
•
Failure of some ISPs to utilize flow telemetry (e.g., NetFlow, cflowd/jflow,
et. al.) collection and analysis for attack detection/classification/traceback.
Failure of some ISPs to proactively scan for and remediate abusable
NTP services on their networks and to scan for and alert customers
running abusable NTP services – blocking abusable services until they
are remediated, if necessary.
Failure of some ISPs to deploy and effectively utilize DDoS
reaction/mitigation tools such as Source-Based Remotely-Triggered
Blackholing (S/RTBH), flowspec, and Intelligent DDoS Mitigation
Systems (IDMSes).
Failure of many enterprises/ASPs/etc. to fund and prioritize availability
to the degree that they do confidentiality and integrity in the security
sphere.
Failure of many enterprises/ASPs/etc. to utilize flow telemetry, deploy
DDoS reaction/mitigation tools.
Failure of many enterprises/ASPs/etc. to subscribe to ‘Clean Pipes’ DDoS
mitigation services offered by ISPs/MSSPs.
How Can ISPs Defend Against These Attacks?
• Deploy antispoofing at all network edges.
–
–
–
–
–
–
–
–
uRPF Loose-Mode at the peering edge
uRPF Strict Mode at customer aggregation edge
ACLs at the customer aggregation edge
uRPF Strict-Mode and/or ACLs at the Internet Data Center (IDC)
aggregation edge
DHCP Snooping (works for static addresses, too) and IP Source Verify at
the IDC LAN access edge
PACLs & VACLs at the IDC LAN access edge
Cable IP Source Verify, etc. at the CMTS
Other DOCSIS & DSL mechanisms
• Utilize flow telemetry (NetFlow, cflowd/jflow, etc.) exported from all
network edges for attack detection/classification/traceback
– Open-source flow telemetry collection/analysis tools allow basic visibility; can be
sufficient for high-volume attacks, once impact is evident
– Arbor Peakflow SP, which provides automated detection/classification/traceback
and alerting of DDoS attacks via anomaly-detection technology
How Can ISPs Defend Against These Attacks? (cont.)
•
•
•
Deploy network infrastructure-based reaction/mitigation techniques such as
S/RTBH and flowspec at all network edges to mitigate attacks
Deploy IDMSes such as Arbor Peakflow TMS in mitigation centers located
at topologically-appropriate points within the ISP network to mitigate attacks
Deploy Quality-of-Service (QoS) mechanisms at all network edges to
police non-timesync NTP traffic down to an appropriate level (i.e.,
1mb/sec).
– NTP timesync packets are 76 bytes in length (all sizes are minus layer-2 framing)
– NTP monlist replies are ~468 bytes in length
– Observed NTP monlist requests utilized in these attacks are 50, 60, and 234 bytes in
length
– Option 1 – police all non-76-byte UDP/123 traffic (source, destination, or both) down
to 1mb/sec. This will police both attack source – reflector/amplifier traffic as well as
reflector/amplifier – target traffic
– Option 2 – police all 400-byte or larger UDP/123 traffic (source) down to 1mb/sec.
This will police only reflector/amplifier – target traffic
– NTP timesync traffic will be unaffected
– Additional administrative (rarely-used) NTP functions such as ntptrace will only be
affected during an attack
How Can ISPs Defend Against These Attacks? (cont.)
• Proactively scan for and remediate abusable NTP services on
the ISP network.
• Proactively scan for and remediate abusable NTP services on
customer networks, including blocking traffic to/from abusable
services if necessary in order to attain compliance
• Check http://www.openntpproject.org to see if abusable NTP
services have been identified on ISP and/or customer networks.
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Detection/Classification/Traceback
Mitigation – S/RTBH or Flowspec
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Mitigation – S/RTBH or Flowspec
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Mitigation – S/RTBH or Flowspec
NTP
reflection/amplification
attack traffic ingresses
network, saturating core
links
NTP
reflection/amplification
attack traffic ingresses
network, saturating core
links
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
NTP
reflection/amplification
attack traffic ingresses
network, saturating core
links
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Mitigation – S/RTBH or Flowspec
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Peakflow SP
advertises list
of blackholed
prefixes based
on source or
destination
addresses, or
layer-4
flowspec
classifier
Mitigation – S/RTBH or Flowspec
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Peakflow SP
advertises list
of blackholed
prefixes based
on source or
destination
addresses, or
layer-4
flowspec
classifier
Mitigation – S/RTBH or Flowspec
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Peakflow SP
advertises list
of blackholed
prefixes based
on source or
destination
addresses, or
flowspec layer4 classifier
Mitigation – S/RTBH or Flowspec
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Peer A
IXP-W
Peer B
IXP-E
Upstream
B
Upstream
A
Upstream
B
Mobile
Infrastructure
Upstream
B
Edge routers drop attack
traffic packets based on
source or destination
address, or layer-4
classifier (flowspec)
Video,
Music,
Gaming
etc.)
Arbor CP
NOC
Peakflow SP
advertises list
of blackholed
prefixes based
on source or
destination
addresses, or
layer-4
flowspec
classifier
ASERT Threat Intelligence
Global Intelligence. Local Protection.
We see things others can’t
Arbor Networks’ Product Portfolio
Arbor Cloud DDoS Protection
Arbor Cloud DDoS Service
• Arbor supported (Arbor’s
SOC)
• Integrates with Pravail APS
• Accepts cloud signals
• Pricing based on volume of
peace-time (clean) traffic
• Global cloud scrubbing
capacity with 4 centers
• BGP and/or DNS diversion
options
• SSL decryption option
Cloud Signaling
capable Cloud DDoS
service
Cloud Signaling
Pravail APS
Cloud Portal available
for under-attack
reporting
Enterprise
Thank You