4. Choosing a Method of DDoS Mitigation

Wanguard provides a complete network-level protection against volumetric Denial of Service attacks by using several complementary methods:

► Wanguard Sensor can be configured to send announcements to your upstream providers to stop routing traffic towards the attacked destinations. This is a simple and widely-used DDoS protection technique that requires only a preexistent agreement with your BGP peers. The attacked targets will be blocked from accessing the Internet, avoiding the congestion of upstream and downstream links

► Wanguard Filter can be configured to clean the malicious traffic at the network’s border, protecting critical services against attacks that are not congesting the upstream links. Dedicated filtering servers can be clustered in packet scrubbing farms

► Wanguard Filter can detect and apply filtering rules on third-party DDoS mitigation appliances, firewalls, load-balancers or routers via helper scripts or BGP Flowspec

► Wanguard Filter can be configured to send automatic notification emails to the ISPs originating attacks

► Wanguard Sensor can be configured to trigger an Internet Service Provider (ISP) or Managed Security Service Provider (MMSP) which offers cloud-based anti-DDoS services to start scrubbing the malicious traffic

4.1. DDoS Mitigation with Wanguard Filter

When Wanguard Sensor detects that a destination is under attack, it executes a preconfigured Response which could activate a Wanguard Filter instance. Filter instances cannot run stand-alone and can only be started via Responses.

Wanguard Filter includes a sophisticated traffic analysis engine that detects attack patterns heuristically, by inspecting the packets/flows sent to the attacked destinations.

Each attack pattern is formed by malicious packets that share some common OSI Layer 3-7 data:

● When an attack is launched from a non-spoofed IP address, the attack pattern is always the IP of the attacker

● When the attack is spoofed and comes from random IP addresses, the attack pattern can be a common source or destination TCP or UDP port, source or destination IP address, IP protocol number, packet length, packet content, TTL, ICMP type, DNS Transaction ID, originating country, and so on

● When Wanguard Filter detects multiple attack patterns, it generates only the filtering rule(s) that have the least negative impact on regular customer traffic

Each attack pattern detected by Wanguard Filter is translated into a filtering rule that can be applied on the server’s NetFilter stateless firewall, on the network adapter’s hardware packet filter, or on a third-party appliance or router. Wanguard Filter is designed to generate filtering rules that block the malicious traffic in a granular manner, without impacting the user experience or resulting in downtime.

The stateless operation of Wanguard Sensor and Wanguard Filter ensures detection and mitigation of volumetric attacks that may cripple even the most powerful stateful devices such as firewalls, Intrusion Detection Systems (IDS) or Intrusion Protection Systems (IPS). This is why, in most cases, the servers running Wanguard should be installed near the network’s entry points, in front of other stateful devices. The single major disadvantage of the stateless operation is that Wanguard Sensor and Wanguard Filter are unable to detect and block low-volume application layer (OSI Layer 7) attacks, unlike traditional IPSes.

There are several Wanguard Filter “flavors”, each having a different way of obtaining traffic information:

● Packet Filter analyzes packets passing through appliances (servers, firewalls, routers, bridges, IDSes, load-balancers) deployed in-line, connected to a mirrored port, or that make use of BGP traffic diversion. It needs to run on a powerful server to be able to do packet inspection on high-speed interfaces. Each configuration option is covered under Configuration » Components » Packet Filter

● Flow Filter analyzes NetFlow®, sFlow® or IPFIX flow data. It works only in cooperation with Flow Sensor, therefore it is not able to generate filtering rules as fast as Packet Filter. Because flows provide a limited amount of traffic information, filtering rules generated from flows can contain only IP addresses, TCP ports, UDP ports and IP protocols. Each configuration option is covered under Configuration » Components » Flow Filter

● Filter Cluster aggregates traffic data collected by multiple Packet Filter and Flow Filter instances. It can be used to create clusters of filtering servers. Each configuration option is covered under Configuration » Components » Filter Cluster

4.2. Technologies used by Wanguard Filter for DDoS mitigation

	PF_RING + Netfilter / Libpcap + Chelsio	BGP FlowSpec	DPDK
Throughput	Relatively small throughput. The Linux kernel performs the routing, so there are scaling issues above 10 Gbps with small packets due to its use of interrupts. The filtering is done either by the kernel, or by the Chelsio chipset (these inexpensive 10/40/100 Gbps NICs are able to filter most attack patterns at wire speed). PF_RING is faster than Libpcap but it does not support Chelsio.	A single Flow Filter instance can mitigate >1 Tbps attacks without any problem. Works very well on modest hardware because it uses preaggregated flows instead of packets, and the router performs the filtering and the routing.	With DPDK, a single Intel Xeon 6212U CPU is able to switch and filter around 50 Mpps between two 100 Gbps interfaces, which make Packet Sensor and Packet Filter fast enough to use inline.
Delay	Packet Sensor detects attacks within 5 seconds by default, but can be configured to detect attacks within 1 second. After detection, it starts Packet Filter which needs <1 second to divert traffic and <5 seconds to detect and apply filtering rules.	Depends on the router’s flow aging configuration. Routers typically export flows after 30- 120 seconds. Flow Sensor detects the attack within 20 seconds. Flow Filter generates filtering rules within 5-10 seconds. The BGP routing update takes around 1 second.	In DPDK mode, Packet Sensor can detect attacks in under 1 second. Packet Filter needs up to 5 seconds to detect attack patterns and apply filtering rules. With DPDK the packets are processed and forwarded in bulk (configurable, minimum 4), adding latency to low volume traffic.
Reliability	Old and proven solution, very well tested.	Recent solution, well tested.	New solution, poorly tested; deemed as experimental. When used inline, it becomes a single point of failure.
Flexibility	Extremely flexible and easy to troubleshoot. Netfilter is able to filter all attack patterns, including countries and packet payloads. It can do bridging, routing, use NICs offload functions, allows third-party tools to inspect packets.	Flow protocols are not collecting useful traffic information about TCP flags, IP fragments, packet sizes, TTL, etc, so a limited number of attack patterns can be detected and filtered.	Supports more filtering rules than Flowspec but fewer than Netfilter. In inline mode it can’t do routing. The kernel and other programs are isolated from the NIC, which is used exclusively by a single process which incorporates Packet Sensor’s and Packet Filter’s logic.
Network Integration	Very simple to configure at the host level. At the network level, a BGP expert might be needed because it requires BGP routers for traffic diversion.	Requires edge routers with support for BGP FlowSpec. (e.g. Juniper MX). Relatively simple to configure. A network expert is needed to configure exabgp and the router.	Much harder to configure and optimize. Once configured, it can be easily installed as an inline bridge, which makes it very easy to integrate into the network. In this case, no BGP is required. Can be configured for traffic diversion via BGP, but since it has no real TCP/IP stack the functionality is severity limited.
Attack Details	Can capture and save malicious packets for proof and forensic investigation. Packet counters are available for the traffic filtered by Netfilter or by the Chelsio NIC.	Flow data is saved in a compressed format and can be inspected at any later date. Packet counters are not yet available for the filtered traffic.	Currently it is not possible to capture packets and save packet dumps in DPDK mode. Packet counters are available for the filtered traffic.
Hardware Considerations	Works better with CPUs with fewer cores but very high frequency. PF_RING supports only few NIC chipsets. Libpcap supports all NICs.	No special hardware necessary.	The architecture is optimized for many CPU cores, so CPUs with lots of cores are better than CPUs with fewer cores but higher frequency. Supports more NICs than PF_RING. Dual-socket systems are not recommended (inter-socket speed is too low).
Power Consumption	Moderate power consumption. When not deployed inline, the CPUs are used only during attacks	Very low power consumption.	High power consumption under the current “run-to-completion” model. Uses CPUs at 100% even on 0 traffic.
Licensing	Packet Sensor needs a license for each sniffed interface when it uses Libpcap. With PF_RING it is possible to use a single Packet Sensor for multiple interfaces. Packet Filter needs a license for each interface that receives traffic that needs cleaning.	Flow Sensor needs a license for each flow exporter, irrespective of the number of interfaces of the flow exporter. Flow Filter needs a single license even if it is used by multiple Flow Sensors.	In DPDK mode, Packet Sensor can listen and perform packet switching between many interfaces, on the same server, with a single license. Packet Filter needs as many licenses as Packet Sensor.

4.3. Packet Filter Deployment Scenarios

Packet Filter can be deployed on servers configured for:

➢ Side-filtering – Packet Filter sends a BGP routing update to a border router (or route reflector) that sets its server’s IP as next hop for the suspect traffic. The cleaned traffic is routed back into the network using static or dynamic routing. For more details, see Appendix 4

➢ In-line routing – Packet Filter runs on a server that resides in the main data path, configured as router

➢ In-line network bridging – Packet Filter runs on a server that resides in the main data path, configured as an OSI Layer 2 Linux network bridge

➢ Out-of-line monitoring – Packet Filter runs on a server connected outside the main data path and which receives a copy of packets from a TAP or mirroring port. The filtering rules improve the visibility of attacks and can be applied via helper scripts or BGP Flowspec on other in-line appliances, routers, switches or firewalls

➢ Local protection – Packet Filter runs as a service on each Linux server that provides critical services. The filtering rules are applied using the local firewall