redGuardian DP100 large scale DDoS mitigation solution
0 likes1,680 views
The document outlines the RedGuardian DP100, a DDoS mitigation solution designed to handle large-scale attacks ranging from 100 Gbit to 1 Tbit. It emphasizes cost-effective mitigation strategies, high scrubbing capacity, and advanced features like lightweight state filters and rate-limiting, while comparing its advantages over legacy DDoS solutions. The deployment strategies include both on-premises and off-path setups to effectively protect networks from DDoS threats.
redGuardian DP100 large scale DDoS mitigation solution
- 1. redGuardian DP100 large scale DDoS mitigation revision: 2017.08.04
- 2. Introduction 1. Large scale (100Gbit – 1Tbit) DDoS attacks are becoming serious issue for network operators and their customers. 2. DDoS mitigation at this scale is considered complex and expensive task. 3. We wold like to show you we can mitigate such attacks in a cost-effective way.
- 3. redGuardian DP100 (1) • DDoS scrubber for terabit scale DDoS attack mitigation • 100Gbit+ scrubbing capacity per 1RU node • DPI, lightweight unidirectional states, regexps
- 4. redGuardian DP100 (2) • multi tenancy • line rate speed • runs on x86 platform
- 5. DDoS attacks source: Akamai „State of the Internet”, Q4 2016 Notice, almost all high volume attacks are: • reflected and amplified UDP, including fragmented responses • various TCP floods It is the same and well known for years.
- 6. redGuardian – some of mitigated attacks Protocol Name UDP Chargen reflected response flood UDP DNS reflected response flood UDP Echo reflected response flood UDP LDAP query flood UDP LDAP reflected response flood UDP MSSQL reflected response flood UDP NetBIOS reflected response flood UDP NTP reflected response flood UDP QOTD reflected response flood UDP RIP reflected response flood UDP RPC Portmap reflected response flood UDP Sentinel reflected response flood UDP SNMP reflected response flood UDP SSDP reflected response flood UDP Steam query flood UDP Steam reflected response flood UDP fragment flood TCP SYN flood TCP ACK flood TCP FIN flood TCP RST flood TCP fragment flood TCP invalid flags ICMP PING Flood ICMP obsolete/legacy messages ICMP fragment flood GRE destination address validation HTTP Wordpress botnet flood IP invalid checksum IP invalid fragment offset IP packet length mismatch IP source address from private address space IP source address spoofed as myself
- 7. Comparison Legacy DDoS solutions redGuardian D/RTBH blocks destination, makes DDoS succed do not block destination IPs, as service should stay alive S/RTBH blocks source hosts, pushes thousands of entries into FIB, may block legitimate users (spoofed source IPs) logic does not rely on blocking source IPs, as these can be spoofed! manual L3/L4 ACL rules, hard to maintain L3/L4/payload ACLs are preconfigured, harmless; can be adjusted if needed installing Flowspec rules by DDoS detection system introduce pressure on network equipment (thousands of rules pushed) when facing large botnets and multi vector attacks, reaction is too slow (dozen of seconds) and may block legitimate users (spoofed source IPs) does not require instrumentation from anomaly detection system, blocks instantly; can match using more criterias than Flowspec, including packet payload patterns stateless ACL rules have limited functionality, while stateful engines can be easily exhausted by installing millions of states with lightweight states one can maintain billions of states with useful metadata, thanks to that terabit scale inspection does not have to be stateless dedicated appliances using ASICs, NPs or FPGAs make 100Gbit - 1Tbit DDoS solutions price is very high x86 hardware is fast, low cost and may already be installed in your datacenter
- 8. Inside redGuardian x86 scrubber • redGuardian dataplane • 100G capacity • 12 x 10G SFP+ port or 1 x 100G QSFP28 port • Xeon V3/V4 CPU • 64GB RAM • GNU/Linux OS
- 9. Inside redGuardian x86 scrubber: Ops perspective (1) 17: sampler-rx: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 18: sampler-tx: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 19: sampler-drop: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast // sniff sampled packets on received, transmitted or dropped side # tcpdump -ni sampler-drop # service dataplane status ● dataplane.service - Dataplane service Loaded: loaded (/lib/systemd/system/dataplane.service; enabled) Active: active (running) since Tue 2017-05-16 15:25:14 CEST; 6 days ago Docs: man:dataplane(1) man:dataplane.conf(5) Process: 41296 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 37932 (dataplane) CGroup: /system.slice/dataplane.service └─37932 /usr/sbin/dataplane /etc/dataplane/dataplane.conf
- 10. Inside redGuardian x86 scrubber: Ops perspective (2) # dpkg -l | grep dataplane ii dataplane 1880.0 amd64 redGuardian anti-DDoS dataplane service ii dataplane-collectd 280.0 amd64 dataplane collectd integration // easy 3rd party performance management systems integration like Grafana
- 11. redGuardian capabilities (1) • stateless ACL match L3/L4 and payload – drop based on provided or custom sigantures – drop udp sport 1434 data u64 0x5365727665724e61 at 3 – drop udp dport 389 data str "objectclass0" at 34 – drop frag single-or-first icmp type 0 code 1:255 • lightweight, unidirectional state filters – suitable for asymmetric routing scenarios – enforce retries, drop fragment chains – billions of entries
- 12. redGuardian capabilities (2) • rate-limiting – enforce pps per flow with billions of policers – enforce Mbps per rule or per customer on exit • regexp engine – drop packets with payload maching regular expressions – match domain names in DNS query section • source IP tagging for ACL rules – each /24 of global IPv4 space can have one of 16 tags – each /32 of global IPv4 space can have up to 8 marks – drop udp srctag $bad_country – drop udp marked $bad_ips
- 13. Performance CPU: E3-1231 v3 @ 3.40GHz (Turbo mode disabled) Note: only one CPU core used for packet fowarding! Scenario Mpps 10G line rate % ACL basic drop 14,88 100% ACL long drop 8,72 59% TCP SYN state filter 10,04 67% hashed rate-limit 10,44 70% redGuardian can handle 100G line rate on modern multicore Xeon server.
- 14. Deployment (on-prem, off-path) 1. Place redGuardian scrubbers nearby transit and peering routers for effective traffic hijacking. 2. Connect directly to routers or core switches using n×10G or 100G ports (LAG), assign /31 p2p for scrubber. 3. Use 3rd party opensource (pmacct+ExaBGP, FastNetMon) or commercial flow-based analytics tools to detect IP under attack and divert its incoming traffic (change next-hop to scrubber or move packets into special VRF). 4. Ensure injected /32 routes or Flowspec rules are active at transit router tables or transit interfaces only (loop prevention). redGuardian scrubber IP core transit/peering VRF flow-based analytics IP core flows or SPAN BGP /32 injection, Flowspec rules, PBR DDoS victim diverted traffic to /32 victim cleaned traffic injected into IP core normal traffic, other customers
- 15. Deployment (on-prem, inline) redGuardian scrubber protected networkupstream 1. Place redGuardian scrubbers between protected network and upstream providers/transit links, using 2n×10G or 2n×100G ports. 2. Scrubber acts like filtering bridge between pairs of ports.
- 16. Availability • physical 100G appliance • software license – use your own x86 hardware – scale capacity between PoPs as needed • service (BGP scrubbing center)
- 17. Conclusion redGuardian provides: 1. performance typical for specialised hardware 2. elasticity typical for software 3. working solution for large scale DDoS attacks problem
- 18. Additional resources 1. twitter: @redguardianeu 2. https://www.slideshare.net/atendesoftware/presentations 3. https://www.redguardian.eu/ 4. http://www.atendesoftware.pl/ 5. e-mail: info @ redguardian.eu
- 19. DDoS shall not pass! https://twitter.com/redguardianeu