24. 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.

The Filter Cluster Configuration window opens on a form whose Filter Name, Filter Server and Associated Filters are mandatory: [Save] stays greyed out until all three of them are filled in.

Filter Cluster Configuration parameters:

● Filter Name – Assign a short, descriptive name to easily identify the Filter Cluster. The colored square inside the field sets the color used by the Cluster in graphs; every new Filter Cluster starts with a random color

● Device Group – (Optional) A label for organizing components, such as by location or characteristics, or to permit roles-based access. The combo box is editable, so you can type a new group instead of selecting an existing one

● Filter Server – Choose a server that meets the minimum system requirements for running the Filter Cluster. The button on the right opens the configuration of that server

● Associated Filters – Choose which Packet Filter and/or Flow Filter components feed aggregated traffic data to the Filter Cluster. These Filters are automatically started by the Cluster when needed. The drop-down carries a search box that narrows the list as you type, a Select All checkbox that selects every entry currently matching the search, and a counter showing how many Filters are selected out of the total. At least one Filter must be selected

● 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. This is the default, and it greys out the Filtering Interface, the Inbound Interface and the Outbound Interface, because those belong to the associated Filters

▪ Filter Cluster – The rules are applied solely on the server hosting the Filter Cluster, over the interfaces configured below

● Filtering Interface – Select on which interface the Filter Cluster applies the filtering rules. It defaults to None, and it is greyed out while Apply Rules By is set to Associated Filters:

▪ None – Detects and reports filtering rules but does not apply them. It greys out the Inbound Interface and the Outbound Interface, and, while Apply Rules By is set to Filter Cluster, also the Netfilter Firewall and the Hardware Offload, which the Console then resets to Disabled when you save

▪ Inbound interface – Applies filtering on the Inbound Interface, which becomes mandatory

▪ Outbound interface – Applies filtering on the Outbound Interface, which becomes mandatory

The button on the right opens Filtering Interface Options, and it stays greyed out while the Filtering Interface is None:

• Interface Type – Leave it on Generic, or choose TUN/TAP or GRE if the filtering interface is of that type

● 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

The Mitigation section selects which firewalls carry out the filtering rules. Each one has an options button on its right that becomes available once the firewall is enabled.

● BGP Flowspec – Choose the policy to apply when sending BGP Flowspec announcements via a Response:

▪ Disabled – Filter Cluster does not send Flowspec announcements

▪ Filtering rules drop matched traffic. Valid traffic is accepted – Matched traffic is discarded by the router; everything else passes

▪ Filtering rules rate-limit matched traffic. Valid traffic is accepted – 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. While Apply Rules By is set to Filter Cluster, it is greyed out unless a Filtering Interface is selected:

▪ 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

The options button opens Netfilter Firewall Options:

• Manual Execution – When Enabled, filtering rules are applied only manually, by clicking the Netfilter icon in Reports » Tools » Anomalies

• Netfilter Table – The raw option typically offers better performance, and it may not work on virtual interfaces. Leave it on filter, the default, while Apply Rules By is set to Associated Filters: raw demands both the Inbound Interface and the Outbound Interface, and those two fields are greyed out in that mode

• Netfilter Chain – Use FORWARD if the server forwards traffic, or INPUT if it doesn’t. It is greyed out while the Netfilter Table is set to raw, which always uses FORWARD

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

● Hardware Offload – Choose a NIC hardware-filtering option if available. Because hardware filters don’t use CPU cycles, they can complement the Netfilter Firewall for better performance. While Apply Rules By is set to Filter Cluster, it is greyed out unless a Filtering Interface is selected:

▪ 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

The options button opens Hardware Offload Options:

• Manual Execution – When Enabled, filtering rules are applied only manually, by clicking the NIC chipset icon in Reports » Tools » Anomalies

The Whitelist section contains a set of rules that prevent critical traffic from being blocked.

● Whitelist Template – Leave it on None to give this Filter Cluster a private set of rules, or select a Whitelist Template to share one set of rules between several components. Selecting a template loads its rules into the grid and makes them read-only; the button on its right opens the configuration of that template

● [Add Rule], [Edit Rule] and [Delete Rule] – Manage the private rules of the Filter Cluster. They are greyed out while a Whitelist Template is selected, and a rule can also be edited by double-clicking it. The whitelisting rules and their columns are described in the Whitelist Template chapter

● Comments – (Optional) A collapsed section at the bottom that stores internal notes about this Filter Cluster. These notes are not displayed elsewhere

[Save] writes the configuration, and [Delete] — shown only after the Filter Cluster has been saved once — removes it after asking for confirmation. A Filter Cluster that a Reports » Dashboards widget, another Filter Cluster, a Scheduled Reports entry or a Response action still refers to cannot be deleted; the Console names what uses it.

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].