23. Components » Filter Cluster

The functionality of Wanguard Filter is described in the Choosing a Method of DDoS Mitigation chapter. Filter Cluster receives aggregated traffic information from Packet Filter(s) and/or from Flow Filter(s).

To add a Filter Cluster, click the [+] button found in the title bar of the Configuration » Components panel. To configure an existing Filter Cluster, go to Configuration » Components and click its name.

Filter Cluster Configuration parameters:

● Filter Name – Assign a short, descriptive name to easily identify the Filter Cluster

● Filter Color – By default, a random color is used in graphs. You can change it via the dropdown menu

● Filter Visibility – Toggles the listing inside the Reports » Devices panel

● Device Group – Enter a description if you wish to organize components (e.g. by location, characteristics) or to permit fine-grained access for roles

● Filter Server – Choose a server that meets the minimum system requirements for running the Filter Cluster

● Associated Filters – Choose which Packet Filters and/or Flow Filters will feed aggregated traffic data to the Filter Cluster. These Filters are automatically started by the Cluster when needed

● Apply Rules By – Determine where the filtering rules detected by the Filter Cluster are enforced:

▪ Associated Filters – Each server running an associated Filter applies the rules

▪ Filter Cluster – The rules are applied solely on the server hosting the Filter Cluster

● Filtering Interface – Select on which interface to apply the filtering rules:

▪ None – Detects/reports filtering rules but does not apply them

▪ Inbound interface – Applies filtering on the inbound interface (defined below)

▪ Outbound interface – Applies filtering on the outbound interface (defined below)

● Inbound Interface – Enter the interface receiving incoming (ingress) traffic. This parameter can be omitted if Filtering Interface is the same as Outbound Interface. For bridged interfaces, prepend “physdev:” to the interface name

● Outbound Interface – Cleaned traffic is sent to the downstream router/switch via this interface, which should have a route to the default gateway. Omit if Filtering Interface is the same as Inbound Interface. For bridged interfaces, prepend “physdev:” to the interface name

● Associated Filters – Select the Packet Filter(s) and/or Flow Filter(s) that should provide aggregated traffic information to the Filter Cluster. The associated Filters are launched automatically by the Filter Cluster instance

● BGP Flowspec – Choose the policy to apply when sending BGP Flowspec announcements via a Response. The rate-limit policy applies only to bits/s anomalies; for pkts/s anomalies, any matched traffic is fully discarded

● Netfilter Firewall – Filter Cluster utilizes the Netfilter framework in the Linux kernel for software-based packet filtering and rate limiting. Because Filter Cluster avoids the connection tracking of stateful firewalls, it operates very quickly and remains highly flexible

▪ Disabled – Filter Cluster detects/reports rules but does not invoke the Netfilter firewall

▪ Filtering rules drop matched traffic. Valid traffic is accepted – Filter Cluster detects/reports/applies filtering rules via Netfilter. If a rule is not whitelisted, matched traffic is blocked; everything else passes

▪ Filtering rules drop matched traffic. Valid traffic is rate-limited – Filter Cluster applies filtering rules, dropping non-whitelisted traffic and rate-limiting the rest. Netfilter only supports pkts/s thresholds, and some kernels fail above 10000 pkts/s

▪ Filtering rules rate-limit matched traffic. Valid traffic is accepted – Filter Cluster rate-limits matched traffic to the threshold. Netfilter does not support bits/s thresholds; some kernels fail above 10000 pkts/s

▪ Apply the default Netfilter chain policy – For testing only. Filter Cluster detects/reports rules, but all rules have the RETURN target

When using the Netfilter Firewall, the following options become available:

• Execution – Filtering rules can be applied automatically or manually (by clicking the Netfilter icon in Reports » Tools » Anomalies)

• Netfilter Table – The raw option typically offers better performance but needs both Inbound and Outbound interfaces to be set. It may not work on virtual interfaces. The filter option is usually slower

• Netfilter Chain – Use FORWARD if the server forwards traffic, or INPUT if it doesn’t

• Operating Layer – Choose OSI Layer 2 if the server is configured as a bridge, OSI Layer 3 otherwise

● Dataplane Firewall – Controls the built-in, DPDK-based firewall, which outperforms Netfilter but is less flexible and more complex to configure

• Execution – Filtering rules can be applied automatically or manually (by clicking the Dataplane icon in Reports » Tools » Anomalies)

● Hardware Offload – Choose a NIC hardware-filtering option if available. Because hardware filters don’t use CPU cycles, they can complement Netfilter or Dataplane Firewall for better performance

▪ Disabled – No hardware filters are applied

▪ Chelsio T5+ 10/40/100 Gigabit adapter with LE-TCAM filters – Uses the cxgbtool utility to apply up to 487 filtering rules for source/destination IPv4/IPv6 addresses, source/destination TCP/UDP ports, and IP protocols. The utility can be installed by the Chelsio Unified Wire driver. Drop counters are available for packets, not for bytes

▪ Mellanox ConnectX NIC with OFED driver – Uses the ethtool utility to apply up to 924 rules for source/destination IPv4/IPv6 addresses, source/destination TCP/UDP ports, and IP protocols. The utility must be installed by the OFED driver driver in /opt/mellanox/ethtool/sbin/. No drop counters available

▪ Intel x520+ 1/10/40 Gigabit adapter configured to block IPv4 sources – Programs the Intel chipset to drop IPv4 source IPs. Up to 4086 hardware filters; no drop counters

▪ Intel x520+ 1/10/40 Gigabit adapter configured to block IPv4 destinations – Programs the Intel chipset to drop IPv4 destination IPs. Up to 4086 hardware filters; no drop counters

When using Hardware Offload, the following option becomes available:

• Execution – Filtering rules can be applied automatically or manually (by clicking the NIC chipset icon in Reports » Tools » Anomalies)

● Whitelist – Contains a set of rules preventing critical traffic from being blocked. Refer to the Whitelist Template chapter for more information

● Comments – (Optional) Store internal notes about this Filter Cluster. These notes are not displayed elsewhere

Enable the Filter Cluster by clicking the on/off button next to its name in Configuration » Components. If a traffic anomaly triggers the Response action “Detect filtering rules and mitigate the attack with Wanguard Filter”, a Filter Cluster instance is launched automatically. If there are no anomalies requiring a Filter instance, Reports » Devices » Overview displays “No active instance”.

Note

You can test any firewall supported by Filter Cluster in Reports » Tools » Firewall by clicking [Add Firewall Rule].