XFW

Tempesta xFW is a fully open-source volumetric DDoS protection system. It uses eBPF programs attached at XDP and TC hooks to filter malicious traffic.

While Tempesta FW handles application-level (L7) DDoS attacks, Tempesta xFW is responsible for filtering network-layer (L3-L4) attacks. For example, an HTTP flood is handled by Tempesta FW, whereas a SYN flood or an amplification attack are mitigated by Tempesta xFW.

There are two primary deployment scenarios for Tempesta xFW: local host protection and network protection.

Both scenarios can operate in real (default) or evaluation mode.

In all configurations, you must define normal traffic profiles, including TCP/UDP ports, ICMP traffic and the expected traffic volume (in bytes per second, BPS, and/or IP packets per second, PPS).

This mode is useful when building a multi-layer (L3-L7) filtration edge, such as a CDN edge, on-premises ADC (Application Delivery Controller) or authoritative or recursive DNS service.

In this scenario Tempesta xFW protects the local host from DDoS attacks targeting its IP address(es).

While this mode works for both DNS and TCP servers, the main difference between host and gateway modes lies in how they handle TCP traffic. The local host operates as a TCP connection endpoint (proxy): network clients establish TCP connections with the host and the host manages its own connections with all protected backend servers.

In combination with Tempesta FW and Tempesta WebShield, you can accelerate and protect your web service from volumetric and application-layer DDoS attacks, as well as malicious bots.

Typically, in this configuration, an application layer, such as Tempesta FW, is responsible for traffic distribution among the protected services.

In this setup, the Linux server is configured as a router that forwards traffic at the IP layer. Tempesta xFW filters attack traffic before the host forwards it to the protected destination IP addresses.

Similar to host mode, in this configuration the Tempesta xFW gate must receive all ingress traffic, from clients to the protected servers, as well as egress traffic, from the servers back to the clients.

In this mode, Linux operates as a regular router, so you must set the following sysctl parameters:

net.ipv4.ip_forward=1
net.ipv6.conf.all.forwarding=1

You also need to define your routing table, configure network interfaces, and adjust firewall rules.

Tempesta xFW can also operate as a network scrubber. In this architecture, it is typically connected to an edge (border) router or a backbone (core) router.

A network attack sensor receives sampled flow telemetry from the router. When the sensor detects an attack, it notifies a mitigation controller. The controller generates a set of mitigation rules and reconfigures the router to redirect traffic for the attacked destination or prefix through Tempesta xFW instead of forwarding it directly to the data center (DC) routers. Tempesta xFW drops malicious traffic and forwards the remaining legitimate client traffic to the DC routers.

This protection architecture has the following properties:

1. Tempesta xFW receives only traffic for the destinations or prefixes currently under mitigation. This traffic contains both legitimate client traffic and DDoS traffic. Tempesta xFW does not see normal traffic to unaffected destinations.

2. In most cases, there is no need to send return traffic from the protected services through the filtering device. Direct server return (DSR), or another asymmetric return path, can therefore be used, and Tempesta xFW does not see the return traffic.

A redirection-based strategy introduces some delay between the beginning of an attack and the application of the corresponding redirection rules. During this interval, the attacked service and shared network infrastructure may be affected.

Nevertheless, this architecture is widely deployed for several reasons:

1. It allows mitigation resources to be shared across multiple network edges. An operator can use a single filtering cluster, or a smaller number of filtering clusters, shared among several edge or core routers.

2. It reduces the blast radius for unaffected customers because their traffic can continue to be forwarded directly to the DC routers.

3. Filtering logic introduces some latency even when no blocking rules are active. In a redirection-based architecture, traffic that is not under mitigation remains on the normal path and incurs no filtering latency.

4. It provides better failure isolation. If the DDoS protection system fails and the redirection rules are safely withdrawn, the main data plane can continue to operate.

Modern DDoS attacks, including attacks associated with the Aisuru-Kimwolf botnet, may use a hit-and-run strategy in which extremely large traffic bursts last only a few seconds or minutes.

This attack pattern is difficult for the detection-and-redirection architecture described above because the available reaction window is very short. Detection and redirection latency can affect not only the attacked destination or customer, but also other customers sharing the same links, switches, or routers.

An always-on pass-through architecture addresses this problem because the filtering logic is already in the traffic path and mitigation does not require an initial redirection step.

To combine the low reaction latency of an always-on pass-through architecture with the flexibility of on-demand mitigation, Tempesta xFW can operate in a pass-through hybrid mode.

In this mode, Tempesta xFW continuously enforces a small set of simple and computationally inexpensive protection mechanisms, such as coarse-grained rate limits, stateless ACLs, and protocol sanity checks. These baseline mechanisms add minimal latency and can be configured with a very low false-positive rate. They can immediately suppress volumetric attacks with simple and predictable characteristics.

More sophisticated filtering mechanisms, which may be more computationally expensive or have a higher risk of false positives, are activated on demand by the attack sensor or mitigation controller. Such mechanisms may include fine-grained rate limits, dynamically generated filtering rules, and TCP anomaly detection and blocking.

Evaluation mode can be enabled together with any of the previously described modes. In this mode, the system collects statistics on IP addresses that would otherwise be blocked, but no actual traffic blocking is performed.

This mode provides a safe way to assess system behavior and effectiveness under a given workload profile, and to estimate the potential reduction in server load that could be achieved with full blocking enabled.

Tempesta xFW supports native (default) and skb XDP modes. Native mode provides better performance, while skb mode is supported by a wider range of network drivers.

Bonded interfaces in 8023ad mode with vlan source-mac xmit policy require skb mode due to bonding driver limitations:

{
    "devices-mode": "skb",
    ...
}

It is recommended to use 8023ad bonding interfaces with the layer3+4 transmit hash policy, as this configuration is supported by native (fast) XDP mode.