redGuardian DP100 appliance/software can mitigate large scale DDoS attacks using DPI, state filters and regexps.

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