Routing Security DDoS and Route Hijacks Merike Kaeo CEO, Double Shot Security merike@doubleshotsecurity.com
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 2 Vulnerable hosts are compromised and attack tools installed Attacker 1 Initiate port scan 2 Vulnerable hosts are compromised and attack tools installed 3 Further scanning for compromises 3 Further scanning for compromises 4 Massive DDoS attack launched Victim
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: Verisign DDoS Trends Report Volume 5, Issue 1 1 st Quarter 2018
GAME CHANGERS PEAK SIZE DURATION COMPLEXITY Source: Verisign DDoS Trends Report Volume 5, Issue 1 1 st Quarter 2018
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 I usually announce 205.251.192.0/23 205.251.194.0/23 205.251.196.0/23 205.251.198.0/23 I don t prefix filter and propagate the BAD routes Internet I hijack the Amazon AWS53 routes by sending more specific prefixes I accept the Amazon AWS 53 ranges with more specific route prefixes (/24s) and send them on. VicRm Client Recursive DNS Servers Vic@m I hear and believe the hijacked routes to Route53
DNS CACHE POISONING I send fake answer for the Ethereum site to cache poison recursive DNS servers Malicious AuthoritaRve Route53 DNS Servers Internet How do I get to the Ethereum site VicRm Client Recursive DNS Servers I route the request to get to Route53 authoritarve servers which are now the malicious authoritarve DNS servers There is no entry in cache so let me go ask authoritarve DNS server
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 ebgp Session Provider Edge Routers Attack Traffic BGP Update ibgp Trigger Router TARGET
DESTINATION BASED RTBH Steps 1. Prepara@on 2. Trigger 3. Withdrawal ibgp Trigger Router 1 2 3 PE configured with static route to unused space set to Null0 (192.0.2.6/32 set to Null0) Receives ibgp update which states next hop for target is 192.0.2.6/32 Installs new (valid) route to target NOTE: All traffic to the target is dropped, even legitimate traffic TARGET 2 3 1 TR configured to redistribute static into every ibgp peer Add static route which sets next hop to target destination (192.0.2.6) Manually remove static route which causes BGP route withdrawl
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 Packets Arrive FIB --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- --------------------- Null0/Discard Ingress Packet Filter --------------------- --------------------- --------------------- --------------------- Egress Interface Forward packet to the Bit Bucket Blackhole Filtering Saves on CPU and ACL processing
SOURCE BASED RTBH Steps 1. Prepara@on 2. Trigger 3. Withdrawal ibgp Trigger Router 1 PE configured with static route to unused space set to Null0 TARGET 1 (192.0.2.6/32 set to Null0) and loose mode urpf on external interfaces 2 3 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. Installs new (valid) route to target NOTE: Only traffic from the attack sources get dropped 3 2 TR configured to redistribute static into every ibgp peer Add static route which sets next hop to target destination (192.0.2.6) Manually remove static route which causes BGP route withdrawl
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 sourcebased 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