4. Choosing a Method of DDoS Mitigation

Wanguard delivers comprehensive, network-level defense against high-volume DoS attacks through multiple, complementary strategies:

✔ BGP BLACKHOLING

Wanguard Sensor can send BGP announcements to upstream providers. With a pre-established agreement, these providers will cease routing traffic to attacked targets, preventing the congestion of both upstream and downstream links. Although affected targets lose Internet access, this method ensures that the rest of the network remains stable and available.

✔ ON-PREMISE SCRUBBING

Wanguard Filter can isolate and remove malicious traffic at the network’s edge, safeguarding critical services from attacks that do not fully saturate upstream connectivity. By clustering dedicated filtering servers into a packet-scrubbing farm, organizations can scale their defense and maintain service continuity during high-intensity attacks.

✔ INTEGRATION WITH THIRD-PARTY DEFENSE

Wanguard Filter detects attacks and applies filtering rules to third-party DDoS mitigation appliances, firewalls, load balancers, and routers. This can be automated via helper scripts or by employing BGP Flowspec, ensuring seamless interoperability with existing infrastructure and mitigation solutions.

✔ ISP NOTIFICATIONS

Wanguard Filter can send automatic notification emails to the ISPs originating the attacks, encouraging prompt remediation and cooperation.

✔ TRIGGERING CLOUD-BASED MITIGATION

Wanguard Sensor can signal an ISP or Managed Security Service Provider (MSSP) offering cloud-based DDoS scrubbing services to step in and neutralize the malicious traffic upstream, further strengthening the network’s resilience.

By leveraging these integrated methods, Wanguard provides layered, adaptive defenses that protect networks from large-scale, volumetric DDoS threats.

4.1. DDoS Mitigation with Wanguard Sensor

If your network lacks the bandwidth and hardware resources necessary to mitigate attacks at its edge—and if you don’t require detailed information about attackers—then Wanguard Sensor alone is sufficient. It can identify targeted destinations and issue BGP announcements (via a BGP Connector) directly to upstream providers using a blackhole community, or to a cloud-based DDoS mitigation service (such as Voxility) using a mitigation community.

However, if you need deeper insights into attackers or more granular attack patterns, you’ll need to deploy Wanguard Filter in addition to Wanguard Sensor.

4.2. DDoS Mitigation with Wanguard Filter

When a destination is under attack, Wanguard Sensor detects it and triggers a preconfigured Response that can activate a Wanguard Filter instance. While Wanguard Sensor can identify the victim of the attack, it does not pinpoint the attackers’ sources.

Wanguard Filter, on the other hand, employs an advanced traffic analysis engine that heuristically identifies attack patterns by examining the packets or flows targeting the attacked destinations. These patterns consist of malicious packets sharing common OSI Layer 3-7 attributes:

● Non-Spoofed Attacks: If attackers use their real IP addresses, the attack pattern typically corresponds directly to the attacker’s IP.

● Spoofed Attacks: For attacks using spoofed IP addresses, patterns emerge from common traits such as source or destination TCP/UDP ports, IP protocols, packet lengths, packet contents, TTL values, ICMP types, DNS transaction IDs, or even geographic origin.

If multiple attack patterns are detected, Wanguard Filter automatically selects filtering rules designed to minimize collateral damage. By default, network stability is prioritized over the availability of the attacked address. Consequently, in certain situations, temporarily blocking traffic to the targeted destination may be necessary and unavoidable.

Each detected attack pattern is translated into a filtering rule that can be applied in various ways:

● On the server’s Netfilter stateless firewall

● On the network adapter’s hardware packet filter

● On a third-party appliance or router

Wanguard Filter is optimized for stateless filtering, blocking malicious traffic in a granular, non-disruptive manner. Since neither Wanguard Sensor nor Wanguard Filter maintains state information, this approach is resilient against asymmetric routing scenarios and effectively mitigates large-scale volumetric attacks that could overwhelm stateful security devices like firewalls, IDS, or IPS systems. For best results, Wanguard should be deployed at the network’s entry points, before any stateful protection layers. The primary drawback of stateless operation is that Wanguard Sensor and Wanguard Filter cannot detect or block low-volume, Layer 7 (application-layer) attacks as effectively as a traditional IPS might.

Wanguard Filter (or simply “Filter”) is a product name encompassing three software components with a shared feature set but distinct methods of obtaining traffic data:

● Packet Filter analyzes packets passing through appliances (servers, firewalls, routers, bridges, IDSes, load balancers) that are deployed inline, connected to a mirrored port, or utilize BGP traffic diversion. Provides immediate, detailed packet-level analysis. Generally needs a high-performance server to handle packet inspection at high speeds. Configuration details are found in Components » Packet Filter.

● Flow Filter analyzes NetFlow®, sFlow®, or IPFIX data in cooperation with Flow Sensor. Since flows are aggregated over time, Flow Filter cannot react as quickly as Packet Filter. Also, flow data provides limited traffic details, so filtering rules can only include IP addresses, TCP ports, UDP ports, and IP protocols. Configuration details are found in Components » Flow Filter.

● Filter Cluster aggregates traffic data from multiple Packet Filter and Flow Filter instances, enabling the creation of filtering server clusters for scalable and redundant DDoS mitigation. Configuration details are found in Components » Filter Cluster.

4.3. Deployment Scenarios for Wanguard Filter

Wanguard Filter supports three primary deployment topologies, each offering unique advantages and considerations depending on your network’s infrastructure, performance requirements, and mitigation goals.

4.3.1. Out-of-line Monitoring

In this topology, Wanguard Filter runs on a server that is not placed directly in the main data path, meaning it cannot directly filter traffic. However, it can still detect and define filtering rules, providing detailed information about attackers and enabling other in-line devices (firewalls, switches, Flowspec routers) to apply those rules.

Traffic Acquisition Methods:

● Flow Filter receives flow data 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. It can run independently or on the same server with a Packet Sensor that listens to the same interface. Because it inspects every packet, Packet Filter requires more powerful hardware. Costs can be reduced through packet sampling if supported by the switch/TAP. Packet Filter can push filtering rules to firewalls, Flowspec routers, or other in-line devices

4.3.2. Side Filtering

In this scenario, Wanguard Filter runs on a mitigation server that becomes the next hop for attacked destinations after it announces a special BGP route (via a BGP Connector). Implementing side filtering is more complex and requires integration with a BGP router. Refer to Appendix 3 – Network Integration Guide for details.

Key Advantages:

✔ No Single Point of Failure: If the mitigation server fails, the BGP session drops automatically, and traffic reverts to its normal routing path.

✔ Targeted Mitigation: Only traffic destined for attacked addresses is diverted to the mitigation server, reducing its workload.

Traffic Acquisition Methods:

● 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 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 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 examines to each packet in real-time. 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 criteria are supported

4.3.3. Inline Filtering

Inline filtering places a powerful Wanguard Filter server directly in the network’s forwarding path. This server must handle all inbound and outbound traffic, perform packet filtering, and potentially route or bridge the network traffic. Due to these demands, inline deployments may introduce a single point of failure if not properly designed with redundancy.

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 10-30 seconds. Flow Sensor detects the attack within 1-2 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.