•  Merike Kaeo •  CEO, Double Shot Security •  merike@doubleshotsecurity.com

Routing Security DDoS and Route Hijacks

DISCUSSION POINTS

• Understanding The Growing Complexity • DDoS Attack Trends • Packet Filters and RTBH • Admitting We Need to Take More Action • Our Collective Responsibility

HOW DO ANY ATTACKS START ?

• Protocols have flaws •  Implementations have bugs •  Implementations have poor default settings • Home users are IoT operators but not network engineers •  If someone floods traffic, how do you NOT cause collateral

damage to legitimate traffic?

DDoS AND ROUTING INFRASTRUCTURES

• Distributed and mostly coordinated attacks –  Increasing in rate and sophistication – Hundreds of Gbps is not uncommon in extreme cases

•  Infrastructure availability at risk – Coordinated attack against infrastructure – Attacks against multiple infrastructure components

• Overwhelming amounts of data – Huge effort required to analyze – Lots of uninteresting events

AUTOMATED DDoS ATTACKS

Attacker

Victim

Initiate port scan 1

2 Vulnerable hosts are compromised and attack tools installed

2

Further scanning for compromises

3 Further scanning for compromises

3

Massive DDoS attack launched

4

Vulnerable hosts are compromised and attack tools installed

HISTORICAL VIEW: DoS •  Single Machine and relatively unsophisticated •  Ping of Death (1996)

–  Attacker sends ping packet larger than 65,536 bytes •  Land.c (1997)

–  Attacker sends TCP SYN spoofed packet where source and destination IPs and ports are identical

•  Smurf (1999) –  Large number of ICMP messages sent using target spoofed source IP

address and destination IP broadcast address

•  Fraggle –  Variation of SMURF attack using UDP port 7 (echo) and port 23

(chargen) instead of ICMP

HISTORICAL VIEW: DDoS

•  Multiple Machines used to orchestrate attack •  Distributed and automated •  Trinoo (1999)

–  The attacker(s) control one or more "master" servers, each of which can control many "daemons”. The daemons are all instructed to coordinate a packet based attack against one or more victim systems.

–  Specific ports are used in communications – Utilizes UDP and ‘ICMP Port Unreachable’ messages

HISTORICAL VIEW: DDoS •  TFN (Tribal Flood Network) (1999)

- More sophisticated tool that can cause ICMP flood, SYN flood, UDP flood and SMURT-style attacks

- Communications between attack infrastructures uses ICMP echo and echo-reply packets

-  IP Identification and payload of ICMP echo-reply identify type of attack -  IP address can be spoofed

•  TFN2K (1999/2000) – Newer variant of TFN and doesn’t use specific ports

•  Stacheldraht (2000) – Combines features of Trinoo and original TFN tool –  It can encrypt communications

OTHER WELL KNOWN ATTACKS • YouTube [Blackhole Traffic]

–  Pakistan Telecom was ordered to block YouTube –  YouTube’s traffic was temporarily rerouted to Pakistan

•  Turk Telekom [DNS Cache Poisoning] –  Turkish president ordered censorship of twitter –  Turk Telekom’s DNS servers configured to return false IP –  Turk Telekom hijacked Google’s IP addresses to disable using 8.8.8.8

• Mirai – Up to 1.2Gbps DDoS targeting Dyn

• Many Many More (many not in mainstream media) – www.digitalattackmap.com

CURRENT DDoS TRENDS

Source:VerisignDDoSTrendsReportVolume5,Issue1–1stQuarter2018

GAME CHANGERS •  PEAK SIZE •  DURATION •  COMPLEXITY

Source:VerisignDDoSTrendsReportVolume5,Issue1–1stQuarter2018

RECENT DNS ATTACK VIA ROUTE HIJACK •  Amazon route prefixes were hijacked •  Amazon’s Route53 DNS traffic was re-routed towards a malicious

DNS server •  The malicious DNS authoritative server had a legitimate IP

address •  These malicious DNS authoritative servers sent DNS answers

back to DNS resolvers that pointed to malicious sites (i.e. cache poisoning)

•  Traffic to any query to DNS resolvers that asked for names handled by Route53 would route to malicious sites.

BGP ROUTE HIJACK

Iusuallyannounce205.251.192.0/23205.251.194.0/23205.251.196.0/23205.251.198.0/23

IhijacktheAmazonAWS53routesbysendingmorespecificprefixes

IaccepttheAmazonAWS53rangeswithmorespecificrouteprefixes(/24s)andsend

themon.Idon’tprefixfilterand

propagatetheBADroutes

IhearandbelievethehijackedroutestoRoute53

Internet

Vic@mRecursiveDNSServers

VicRmClient

DNS CACHE POISONING

HowdoIgettotheEthereumsite

IroutetherequesttogettoRoute53authoritaRveserverswhicharenowthemaliciousauthoritaRveDNSservers

Internet

RecursiveDNSServersVicRmClient

IsendfakeanswerfortheEthereumsitetocachepoisonrecursiveDNSservers

MaliciousAuthoritaRveRoute53DNSServers

ThereisnoentryincachesoletmegoaskauthoritaRveDNSserver

ATTACK MITIGATION TECHNIQUES

• Route hijack would not have been possible if there had been effective BGP prefix filtering

– Most environments do NOT filter comprehensively –  ISPs should be filtering customer’s prefixes –  ISPs should be filtering prefixes going out of their network

•  Route hijack would not have been possible if RPKI used •  Recursive DNS server cache poisoning would not have been

possible if DNSSEC had been deployed

WHY NETWORK HYGIENE MATTERS

• Best practices for network infrastructure security risk mitigation techniques have existed for decades

• Without deploying appropriate mitigation techniques we leave ourselves at risk for attackers to succeed with more sophisticated attacks.

• BGP and DNS have inter-dependencies which recently caused a successful attack.

• How many more attacks of this nature are in our immediate future?

DDoS AND ROUTER CPU OVERLOAD

• Attacks on applications affect CPU performance and leads to BGP instability

•  Increasing numbers infected hosts that still used forged source IP addresses

• Small packet processing is taxing on many routers, even high-end architectures

•  Filtering is useful but also has CPU hit

DEFENDING AGAINST DDoS

• Packet filters at customer site – Must consider that packets have already traversed link –  Link could already be swamped

•  Filters at ISP side could help – Requires human intervention – Requires serious CPU power on ISP access router doing the filtering

• Using all the ISPs routers to help – Manually null route all traffic to IP address under attack – Automated solution via Remotely Triggered Blackhole Filtering (RTBH)

REMOTELY TRIGGERED BLACKHOLE ROUTING

• BGP used to trigger network wide response –  Exploits router’s forwarding logic to drop packets –  Packets are forwarded to a Null interface (aka ‘Discard Interface’)

• Effective against spoofed and valid source IP addresses •  Fast response times

–  Triggers network wide black holes as fast as iBGP can update the network

• Operational Deployments/Standardization –  Operationally used since the early 2000s –  RFC3882 “Configuring BGP to Block Denial-of-Service Attacks”(2004) –  RFC5635 “Remotely Triggered Black Hole Filtering with uRPF” (2009) –  RFC7999 “Blackhole Community” (2016)

COMPONENTS OF RTBH

eBGPSession

TriggerRouter

iBGP

TARGET

Provider Edge Routers

Attack Traffic

BGP Update

DESTINATION BASED RTBH

iBGP

TARGETPE configured with static route to unused space set to Null0 (192.0.2.6/32 set to Null0)

TR configured to redistribute static into every iBGP peer

11

Steps1.  Prepara@on2.  Trigger3.  Withdrawal

Add static route which sets next hop to target destination (192.0.2.6)Receives iBGP update which

states next hop for target is 192.0.2.6/32

22

Manually remove static route which causes BGP route withdrawlInstalls new (valid) route to target

33

NOTE: All traffic to the target is dropped, even legitimate traffic

TriggerRouter

UNICAST REVERSE PATH FORWARDING • Originally created to scale BCP38 ingress filtering • Check router’s FIB for matching source IP address • Strict vs Loose Mode •  Loose mode uRPF provided ISPs with the means to trigger

a network wide, source based black hole filter

BLACKHOLE FILTER CPU ADVANTAGES

FIB------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Ingress Packet Filter

------------------------------------------------------------------------------------

Null0/Discard

PacketsArrive

•  ForwardpackettotheBitBucket

•  BlackholeFilteringSavesonCPUandACLprocessing

EgressInterface

SOURCE BASED RTBH

iBGP

TARGETPE configured with static route to unused space set to Null0 (192.0.2.6/32 set to Null0) and loose mode uRPF on external interfaces

TR configured to redistribute static into every iBGP peer

1 1

Steps1.  Prepara@on2.  Trigger3.  Withdrawal

Add static route which sets next hop to target destination (192.0.2.6)

Manually remove static route which causes BGP route withdrawl

Receives iBGP update which states next hop for target is 192.0.2.6/32. All traffic from source IP will fail loose uRPF check.

2

Installs new (valid) route to target3

NOTE: Only traffic from the attack sources get dropped

TriggerRouter

2

3

COMBINE PACKET FILTERS AND RTBH

• Packet Filter Strengths – Detailed filtering (ports, protocols, ranges, fragments, etc.) – Enlist support of upstream ISP

• Packet Filter Weaknesses – Operationally challenging with frequent changes – Difficult to deploy simultaneously on a multitude of devices

• Utilize Both Packet Filters and RTBH to Address Strengths – Packet filters handle the strict static policies – uRPF remote-triggered black hole handles the dynamic source-

based drops

ADDED CONSIDERATIONS • Deploy Ingress Filtering [IETF - BCP 38] • Segment Areas for Route Distribution • Design Networks to Avoid Fate Sharing

– Outages don’t affect entire network but only portions of it • Control Router Access

– Watch against internal attacks [physical and/or virtual] – Use different credentials for router root (‘enable’) access – Use cryptographically protected protocols for device access

and management (SSH, NTP, SNMP, SCP, etc) • Monitor for Configurations Changes • Scanning Craze for all Kinds of Ports and

Vulnerabilities Will Be a Never Ending Battle

ASSUMING RESPONSIBILITY

A smart man learns from his own mistakes, a wise man learns from

mistakes of others, and a fool never learns