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 may struggle to route/switch more than ~5–6 Mpps due to its reliance on interrupts. Packet Filter has modest packet-sniffing performance when using Libpcap; PF_RING can improve sniffing but only supports a limited set of NICs. Packet filtering is performed either by the kernel or by the NIC. Wanguard supports several 10/40/100 Gbps NICs that can filter most DDoS traffic patterns at line rate in hardware.	A single Flow Filter instance can mitigate attacks >1 Tbps without performance issues, thanks to analyzing pre-aggregated flows rather than raw packets; the router itself performs the filtering and routing tasks.	Using DPDK, Packet Sensor and Packet Filter become sufficiently fast for inline deployments. On a single Intel Xeon 6212U CPU, Packet Sensor and Packet Filter can potentially analyze, switch, and filter around 50 Mpps between two 100 Gbps interfaces.
Reaction Time	Packet Sensor detects attacks within 5 seconds by default (configurable down to 1 second). After detection, it starts Packet Filter, which takes <1 second to divert traffic and <5 seconds to detect/apply filtering rules.	Dependent on the router’s flow aging configuration (typical 5–30 seconds). Attack detection in 1–2 seconds after flows are exported. Flow Filter generates filtering rules in ~5–10 seconds. BGP routing updates take only a few milliseconds.	Packet Sensor detects attacks in under 1 second. Packet Filter needs up to ~5 seconds for pattern detection and rule application. Packets are processed/forwarded in batches (min. 4 packets at once, configurable), so for low/medium traffic volumes, latency can reach hundreds of milliseconds.
Reliability	Old and proven solution, extensively tested.	Recent solution, well tested.	Brand-new solution, not thoroughly tested – still considered experimental. If deployed inline, it becomes a single point of failure.
Flexibility	Extremely flexible and easy to troubleshoot. Can filter virtually all attack patterns, including by country or packet payload. Because the kernel retains interface visibility, it can handle bridging/routing and lets third-party tools inspect packets.	Most flow exporters lack detailed traffic info (TCP flags, IP fragments, packet sizes, TTL, etc.), limiting the range of detectable and filterable attacks.	Supports more filtering rules than Flowspec but fewer than Netfilter. In inline mode, it cannot do routing. The kernel and other apps are isolated from the NIC, which is used exclusively by one process that integrates Packet Sensor and Packet Filter logic.
Network Integration	Easy to configure at the host level, but a networking specialist may be needed at the network level for BGP router configuration and traffic diversion.	Requires edge routers supporting BGP Flowspec. Relatively straightforward, but a networking specialist is needed for configuring gobgp/exabgp and the router.	Packet Sensor and Packet Filter in DPDK mode are somewhat complex to configure/optimize. After setup, the server can be placed inline as a transparent bridge, simplifying network integration. Packet Filter can be configured for traffic diversion via BGP; however, lacking a full TCP/IP stack limits this functionality.
Attack Details	Can capture/save malicious packets for evidence or forensics. Packet counters exist for Netfilter and Chelsio, but Mellanox does not provide counters.	Flow data is stored in a compressed format for future inspection. Packet counters for filtered traffic are typically unavailable, except on certain Juniper MX routers.	Limited to one capturing thread at a time, so cannot capture packets for more than one anomaly simultaneously. Packet counters are available.
Hardware Considerations	Prefers fewer cores but higher CPU frequency. PF_RING supports a limited set of NIC chipsets, while Libpcap supports all NICs.	No special hardware required. Very low resource requirements.	Optimized for many CPU cores, so a CPU with more cores is better than one with fewer, faster cores. Supports more NICs than PF_RING. Dual-socket systems might be problematic due to NUMA considerations (inter-socket communication can be slow).
Power Consumption	Moderate power usage. If not deployed inline, the CPU only ramps up during attacks.	Very low power consumption.	High power draw under the “run-to-completion” model, using 100% CPU even on idle traffic.
Sensor Licensing	Packet Sensor: One license for each interface sniffed with Libpcap. With PF_RING, a single Sensor can sniff multiple interfaces.	Flow Sensor: One license per flow exporter, regardless of the number of interfaces on that exporter.	Packet Sensor: Can listen/perform packet switching among many interfaces on one server with two licenses: a Wanguard Sensor license and a DPDK Capture Engine license.
Filter Licensing	Packet Filter: One license per interface that needs traffic cleansing.	Flow Filter: Needs only one license, even if multiple Flow Sensors feed it.	Packet Filter: The licensing is analogous to Packet Sensor (one license for filtering plus a DPDK license if required.