4. Choosing a Method of DDoS Mitigation

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

► Wanguard Sensor can be configured to send BGP announcements to the upstream providers, which will then stop routing traffic towards the attacked destinations. This widely-used and straightforward technique requires only a preexistent agreement with the 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 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 into packet scrubbing farms

► Wanguard Filter can detect and apply filtering rules on third-party DDoS mitigation appliances, firewalls, load-balancers, and routers via helper scripts or via 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 Sensor

If you don’t have the bandwidth and the necessary hardware to mitigate attacks on your network’s edge, and if you don’t need any information about the attackers, then Wanguard Sensor is the only component you need to use. Wanguard Sensor is capable of detecting the attacked destinations, so you can configure it to send BGP announcements (via a BGP Connector) either to the upstream providers with a black hole community or to a cloud-based DDoS mitigation provider (such as Voxility) with a mitigation community.

If you need to detect the attackers or other attack patterns, you will have to use Wanguard Filter.

4.2. DDoS Mitigation with Wanguard Filter

When a destination is under attack, Wanguard Sensor detects it and executes a preconfigured Response which can activate a Wanguard Filter instance. Wanguard Sensor can only detect the destination of each attack (the victim), not the sources (the attackers).

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 the filtering rules that have the least negative impact on regular customer traffic. By default, the protection of the network is considered more important than the protection of the attacked address, therefore the blocking of the attacked address is possible, and in some cases unavoidable

Each attack pattern detected by Wanguard Filter is translated into a filtering rule which 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 stateless 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 works with asymmetric routing and 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 at 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.

Wanguard Filter (or just Filter in short) is a product name that describes three software components that share a common feature set but differ in the way they obtain traffic information:

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

● Flow Filter analyzes NetFlow®, sFlow®, or IPFIX flow data. It works only in cooperation with Flow Sensor; therefore, it cannot 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 in the Components » Flow Filter chapter

● 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 in the Components » Filter Cluster chapter

4.3. Deployment Scenarios for Wanguard Filter

Wanguard Filter can be deployed in three topologies:

4.3.1. Out-of-line Monitoring

Wanguard Filter runs on a server not connected to the main data path, therefore unable to perform traffic filtering by itself. However, filtering rules can still be detected, offering detailed information about attackers and facilitating attack mitigation by other inline devices such as firewalls, switches, or Flowspec-capable routers.

In this topology, the traffic information can be received in two ways:

● Flow Filter receives flows from any Flow Sensor deployed within the network, without any additional network configuration steps. If the router supports Flowspec, then this combination provides a cost-effective and simple way to mitigate extremely powerful attacks (>1 Tbps)

● Packet Filter can listen to a port-mirrored/TAP interface connected to the main data path. Packet Filter can run independently or on the same server with a Packet Sensor that listens to the same interface. Traffic analysis is done on a packet-by-packet basis, so the hardware requirements are much higher. The high cost can be alleviated by using packet sampling, if the switch/TAP supports this feature. Packet Filter can also push filtering rules to firewalls, Flowspec-compatible routers, or other inline devices

4.3.2. Side Filtering

Wanguard Filter runs on a server that becomes next-hop for the attacked destinations after it sends a special BGP announcement via a BGP Connector. This topology requires a BGP router and much more complex network configuration steps, see Appendix 3 – Network Integration Guide.

This topology ensures reliability and performance:

✔ The mitigation server will not become a single point of failure for the whole network; if the server crashes or becomes unresponsive, the BGP connection drops, and the traffic will be re-routed automatically in its usual path

✔ The mitigation server will only receive the traffic directed towards the attacked address(es), so it won’t have to switch/route the traffic of the whole network

The traffic can be analyzed in two ways:

● Flow Filter detects filtering rules by analyzing the flows from any Flow Sensor deployed within the network. The filtering rules are applied locally on the mitigation server. This option offers a very cost-effective way to mitigate attacks because the mitigation server doesn’t have to be very powerful. Flow Filter uses very little CPU, and when the server is equipped with a NIC that supports hardware-based packet filtering, such as Chelsio or Mellanox, it can do 100 Gbps attack mitigation without using any CPU resources. The only task that will use significant resources will be the kernel doing the routing or switching of the good traffic.

The flow-based approach has two main disadvantages when compared with the packet-based approach: the filtering rules can be detected only after several tens of seconds, and due to the limited information presented in flows it is not possible to detect filtering rules for packet lengths, TTLs, ICMP types or packet payloads

● Packet Filter listens to each packet received by the mitigation server. Since the traffic analysis is done on a packet-by-packet basis, the hardware requirements are much higher than when using Flow Filter. But the attacks can be detected much quicker, packet dumps are available for forensic investigation, and all filtering rules can be detected

4.3.3. Inline Filtering

This topology requires using very powerful servers that can switch/route the network’s inbound and outbound traffic, block packets, and also run Packet Filter or Flow Filter. Inline servers could also become a single point of failure.

This deployment scenario can have two possible implementations, depending on the role of the mitigation server on the forwarding path:

● Routing mode, when the server is configured as an OSI Layer 3 router

● Bridging mode, when the server is configured as an OSI Layer 2 network bridge

The most frequently used Wanguard Filter for this topology is Packet Filter.

4.4. Comparison between Deployment Scenarios

	Side Filtering with Packet Filter + Netfilter/HW Offload	Out-of-band Monitoring with Flow Filter + Flowspec	Inline Filtering with Packet Sensor/Filter + DPDK
Throughput	Depending on the hardware, the Linux kernel might have scaling issues routing/switching more than 5-6 Mpps due to its extensive use of interrupts. Packet Filter has a modest packet sniffing performance when it uses Libpcap; PF_RING improves the sniffing performance, but it supports only a few NICs. The packet filtering task is done either by the kernel or the NIC. Wanguard supports a few inexpensive 10/40/100 Gbps NICs that can filter most attack patterns in hardware at wire speed.	A single Flow Filter instance can mitigate >1 Tbps attacks without performance issues. Works very well on modest hardware because Flow Filter analyzes pre-aggregated flows instead of packets, and the router handles the filtering and the routing tasks.	With DPDK, Packet Sensor and Packet Filter are fast enough to use inline. On a single Intel Xeon 6212U CPU, Packet Sensor and Packet Filter may be able to analyze, switch and filter around 50 Mpps between two 100 Gbps interfaces.
Delay	Packet Sensor detects attacks within 5 seconds by default, but it 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 a few milliseconds.	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 four packets at a time), adding a latency that can reach hundreds of milliseconds for low to medium volume traffic.
Reliability	Old and proven solution, very well tested.	Recent solution, well tested. Flowspec support relies on ExaBGP, which could have some scaling and reliability issues.	New solution, insufficiently tested, considered experimental. When used inline, it becomes a single point of failure.
Flexibility	Extremely flexible and easy to troubleshoot. Netfilter can filter all attack patterns, including countries and packet payloads. Because the kernel retains interface visibility, it can do bridging, routing and allows third-party tools to inspect packets.	Flow exporters don’t collect useful traffic information about TCP flags, IP fragments, packet sizes, TTL, etc., so only 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; the NIC is used exclusively by a single process that incorporates Packet Sensor’s and Packet Filter’s logic.
Network Integration	Very simple to configure at the host level. At the network level, a networking specialist might be needed because it requires BGP routers to do traffic diversion.	Requires edge routers with support for BGP Flowspec, such as Juniper MX. Relatively simple to configure. A networking specialist is needed to configure exabgp and the router.	In DPDK mode, Packet Sensor and Packet Filter are relatively hard to configure and optimize. Once configured, the server can be easily installed as an inline bridge, making it easy to integrate into the network. Packet Filter can be configured to do traffic diversion via BGP, but since it has no real TCP/IP stack the functionality is severely 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 the Chelsio chipset. Mellanox provides no information about packet counters.	Flow data is saved in a highly-compressed binary format that can be inspected at any later date. Packet counters are available for the filtered traffic only for a few Juniper MX routers.	It is currently impossible to capture packets and save packet dumps when using DPDK. Packet counters are available.
Hardware Considerations	Works better with CPU cores that have fewer cores but higher frequency. PF_RING supports only a few NIC chipsets. Libpcap supports all NICs.	No special hardware is necessary.	The architecture is optimized for using many CPU cores, so CPUs with many cores are better than CPUs with fewer cores but higher frequency. Supports more NICs than PF_RING. Dual-socket systems might not work properly due to NUMA-related issues and the slow speed of inter-socket communication.
Power Consumption	Moderate power consumption. When not deployed inline, the CPU is used only during attacks.	Very low power consumption.	High power consumption under the current “run-to-completion” model. Uses CPU cores at 100% even on zero 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 two licenses: a Wanguard Sensor license and a DPDK Capture Engine license. In DPDK mode, Packet Filter has the same licensing requirements as Packet Sensor.