Packet Filter¶

The functionality of Wanguard Filter is briefly described in the chapter Choosing a Method of DDoS Mitigation.

Packet Filter can be deployed in one of the following topologies:

● Inline filtering – Packet Filter runs on a server that resides in the main data path, configured as a network bridge or as an OSI Layer 3 router. To enable routing on the filtering server follow the steps required by your Linux distribution. At least the following commands need to be executed:
[root@localhost ~]# sysctl -w net.ipv4.ip_forward=1
[root@localhost ~]# sysctl -w net.ipv4.conf.all.forwarding=1
[root@localhost ~]# sysctl -w net.ipv4.conf.default.rp_filter=0
[root@localhost ~]# sysctl -w net.ipv4.conf.all.rp_filter=0
To run Packet Filter in this mode, set the interface connected to the peering/border router as Inbound Interface. To inject the packets back into the network, set a core router as the default gateway, reachable through the Outbound Interface, either directly (recommended) or through a GRE or IP-in-IP tunnel.

To configure the filtering server as a network bridge, follow the steps required by your Linux distribution. To enable packet filtering when doing bridging, at least the following commands need to be executed:
[root@localhost ~]# sysctl -w net.bridge.bridge-nf-call-ip6tables=1
[root@localhost ~]# sysctl -w net.bridge.bridge-nf-call-iptables=1
[root@localhost ~]# sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=1
To run Packet Filter in this mode, set the Inbound Interface to the bridged interface (usually br0).

● Inline monitoring – Packet Filter runs on a server that resides in the main data path, configured as an OSI Layer 3 router or network bridge. Direct filtering is disabled, but the filtering rules will improve the visibility of attacks and can be applied to other in-line appliances, firewalls, or sent via FlowSpec. To run Packet Filter in this mode, set the parameters like in the Inline filtering mode.

● Out-of-line filtering – To run Packet Filter in this mode, set the Traffic Diversion parameter to a BGP Connector configured for rerouting traffic. Other parameters must be set as in the Inline filtering mode.

● Out-of-line monitoring – Packet Filter runs on a server that receives a copy of packets from a network TAP or mirroring port. Direct filtering is disabled, but the filtering rules will improve the visibility of attacks and can be applied to other in-line appliances, firewalls, or sent via FlowSpec. To run Packet Filter in this mode, set the Sniffing Interface to be the same as the Sniffing Interface configured in Packet Sensor.

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

● Filter Name – A short name that helps you identify the Packet Filter

● Filter Color – Color used in graphs for the Packet Filter. The default color is a random one, which can be changed by clicking the drop-down menu

● Filter Visibility – Select if the Packet Filter should be listed in Reports » Devices

● Device Group – Optional description used within Console to group up components (e.g. by location or role). It can be used to restrict the access of Guest accounts

● Filter Server – Which Server runs the Packet Filter. The configuration of servers is described in the Configuration » Servers chapter

● Capture Engine – Select the preferred packet capturing engine. LibPcap requires no additional setup but it is often too slow for multi-gigabit sniffing and it does not run on multiple threads. PF_RING is much faster but requires the installation of an additional kernel module. DPDK provides the fastest packet capturing engine but it is much more complicated to setup and the allocated CPUs will always be used at 100%.

○ Embedded LibPcap – Select to use the built-in LibPcap 1.8.1 library

○ System LibPcap – Select to use the LibPcap library installed by the Linux distribution

○ PF_RING – Select to use the PF_RING framework to speed up packet processing. Click the options button for PF_RING-specific settings

○ DPDK – Select to use the DPDK framework, then click the options button to configure DPDK-specific parameters as described in Appendix 1

○ DPDK [Packet Sensor] – Select to use a DPDK-enabled Packet Sensor as a packet capturing engine. DPDK offers exclusive access to the hardware to a single process, so this option embeds the Packet Filter’s logic into a Packet Sensor in order to have both Wanguard components listening to the same interface

● Capture Engine Options – This button shows specific options for the selected Capture Engine. The Packet Sampling (1/N) field is enabled for all capturing engines, and it must be equal to the number of filtering servers activated for the same anomaly when the Packet Filter is used in a clustered architecture where each filtering server receives traffic from a round-robin packet scheduler. The correct value in most cases is 1

● Sniffing Interface – Network interface(s) listened by the Packet Filter. Listening to the Inbound Interface increases CPU usage because even the traffic that doesn’t get forwarded must to be inspected. Listening to the Outbound Interface decreases CPU usage because only the forwarded traffic reaches that interface. Packet Filter can still obtain traffic statistics about the dropped traffic by inspecting the firewall’s counters

● CPU Threads – Depending on the chosen Capture Engine, Packet Filter is able to run multi-threaded on a given set of CPU cores. Each thread increases the RAM usage. On most systems, activating more than 6 CPU threads hurts performance. The number of threads used by each Filter instance is also dependent on the NIC’s RSS queues

● Filtering Interface – Select where to apply the filtering rules:

○ None – Packet Filter does not apply the filtering rules directly

○ Inbound – Packet Filter applies the filtering rules on the inbound Interface

○ Outbound – Packet Filter applies the filtering rules on the outbound interface

● Traffic Diversion – Provides a selection of BGP Connectors that can be used for traffic diversion. If the server is deployed in-line, or if you do not plan to use traffic diversion, leave the field set to “None”.

When a BGP Connector is selected, the Packet Filter sends routing updates that set the server as next-hop for the attacked IP addresses. When the attack ends, the announcement is automatically withdrawn which causes the traffic towards the attacked IP to be routed normally

● Inbound Interface – Enter the interface that receives incoming traffic. For a bridged interface, prepend the string physdev: in front of the interface name

● Outbound Interface – The cleaned traffic is sent to the downstream router/switch via the outbound interface, which should hold the route to the default gateway. For GRE / IP over IP tunneling, configure virtual network interfaces with the ip command, part of the iproute2 package. For a bridged interface, prepend the string physdev: in front of the interface name

● BGP Flowspec – Select which policy to apply when the Response is configured to send BGP FlowSpec announcements for filtering rules

● Netfilter Firewall – Select the Netfilter policy that will be applied when the Packet Filter generates a filtering rule. Packet Filter can do software-based packet filtering and packet rate limiting using the Netfilter framework provided by the Linux kernel. The software-based packet filter is very flexible, and since Packet Filter does not use the connection tracking mechanism specific to stateful firewalls, it is very fast as well.

○ Disabled – Packet Filter detects and reports filtering rules, but the Linux firewall API is not used

○ Filtering rules drop matched traffic. Valid traffic is accepted – Packet Filter detects, reports and applies filtering rules using the Netfilter firewall. If the filtering rule is not whitelisted, the traffic matched by it is blocked. The remaining traffic passes

○ Filtering rules drop matched traffic. Valid traffic is rate-limited – Packet Filter detects, reports and applies filtering rules, and rate-limits the remaining traffic. If the filtering rule is not whitelisted, the traffic matched by it is blocked. The traffic that exceeds the packets/second threshold value is not passed. Rate-limiting is supported by Netfilter only for packets/s thresholds, not for bits/s thresholds Also, some kernel versions will fail to rate-limit traffic above 10000 pkts/s and will block all traffic instead!

○ Filtering rules rate-limit matched traffic. Valid traffic is accepted – Packet Filter detects and reports filtering rules and rate-limits matched traffic to the threshold value. Rate-limiting is supported by Netfilter only for packets/s thresholds, not for bits/s thresholds Also, some kernel versions will fail to rate-limit traffic above 10000 pkts/s and will block all traffic instead!

○ Apply the default Netfilter chain policy – Packet Filter detects and reports filtering rules, and applies the default Netfilter chain policy. The Netfilter framework is still being used, but all rules have the “RETURN” target. This option is usually used for testing and debugging purposes

Click the options button on the right to be able to configure the following additional parameters:

○ Netfilter Chain – set to FORWARD if the server forwards traffic or INPUT if it does not

○ Netfilter Table – the raw option requires both Inbound and Outbound interfaces to be set, and doesn’t work for all virtual interfaces. It provides a better packet filtering performance compared to the filter option

● Dataplane Firewall – This option selects the policy of the Dataplane Firewall, which is a built-in software- based firewall that uses DPDK as a Capture Engine. It is better performing than Netfilter but less flexible.

● Hardware Offload – If you have a NIC that provides hardware filters, select the appropriate option. Since hardware filters do not consume CPU, use this option to complement the Netfilter Firewall and Dataplane Firewall.

○ Disabled – Hardware filters are not applied

○ DPDK Flow API – Packet Filter uses the Flow API supported by several DPDK-supported NIC chipsets (Chelsio, Intel, etc.) to offload the filtering of packets to the hardware

○ Intel x520+ 1/10/40 Gigabit adapter configured to block IPv4 sources – Packet Filter programs the Intel chipset to drop IPv4 addresses from filtering rules that contain source IPs. Up to 4086 hardware filters are possible

○ Intel x520+ 1/10/40 Gigabit adapter configured to block IPv4 destinations – Packet Filter programs the Intel chipset to drop IPv4 addresses from filtering rules that contain destination IPs. Up to 4086 hardware filters are possible

○ Chelsio T5+ 10/40/100 Gigabit adapter with LE-TCAM filters – Packet Filter uses the Chelsio API to apply up to 487 filtering rules that contain any combination of source/destination IPv4/IPv6 addresses, source/destination UDP/TCP port, and IP protocol

● Whitelist – See the dedicated section from below

● Comments – Comments about the Packet Filter can be saved here. These observations are not visible elsewhere

Enable the Packet Filter by clicking the small play/stop button displayed next to its name in Configuration » Components.

An instance of the Packet Filter will be launched when a traffic anomaly triggers the Response action “Detect filtering rules and mitigate the attack with Wanguard Filter”.

Whitelist¶

A Filter Whitelist is a collection of user-created rules that prevent the filtering of critical traffic. To add similar rules for multiple Filters, configure a new Whitelist Template in Configuration » Network & Policy.

Note

Whitelists were implemented because, by default, the software might block attack patterns that you don’t want to be blocked. Destination ports and destination IP addresses are blocked only in worst-case scenarios when no other attack pattern is found. In some cases though, it is better to let potential malicious traffic enter the network instead of filtering critical traffic. For example, if your DNS server is attacked by spoofed addresses on port 53 UDP, the software might block port 53 UDP traffic towards your DNS server, making it partially unreachable from the Internet. In this case, configure a whitelist rule (Rule Type: Dst Port UDP, Operator: equal, Rule Value: 53) and review the settings from Configuration » General Settings » Anomaly Mitigation.

To add a new rule to the whitelist, enter the following information:

● Prefix – Enter a subnet that must include the anomaly IP address, for the whitelist rule to be valid only for that particular subnet. Enter 0.0.0.0/0 for a generic whitelist rule
● Decoder – Select the decoder of the anomaly, or select All for a generic whitelist rule
● Rule Type – Possible values: Source IP, Src Port TCP, Dst Port TCP, Src Port UDP, Dst Port UDP, Packet Length, IP TimeToLive, IP Protocol
● Operator – Operators for strings and numbers: equal, non-equal. Operators for numbers: less than, greater than.  The operator equal can match IP Addresses in CIDR notation, port ranges written as <port_min>:<port_max>, and packet size ranges written as <pkt_size_min>:<pkt_size_max>
● Rule Value – A user-defined value that should match
● FW Policy – When FW Policy is Permit and Operator is equal, the Packet Filter explicitly allows the matched traffic to pass through the Netfilter Firewall. Otherwise, a more generic filtering rule might take precedence over the whitelisted filtering rule
● Description – An optional description for the whitelist rule. When a filtering rule cannot be applied because it conflicts with a whitelist rule, a small white flag icon appears next to it in Console reports.

Packet Filter Troubleshooting¶

✔ To view the counters for each Netfilter or Chelsio filtering rule go to Reports » Tools » Firewall

✔ To see the filtering rules applied by the Netfilter firewall via the CLI:

[root@localhost ~]# iptables -L -n -v && iptables -L -n -v -t raw

To delete all chains:

[root@localhost ~]# for chain in `iptables -L -t raw | grep wanguard | awk '{ print $2 }'`; do iptables -X $chain; done

✔ To view the filtering rules applied on the Intel 80599 chipset:

[root@localhost ~]# ethtool --show-ntuple <filtering_interface>

or, for kernels >3.1:

[root@localhost ~]# ethtool --show-nfc <filtering_interface>

✔ To ensure that filtering rules can be applied on the Intel 80599 chipset, load the ixgbe driver with the parameter FdirPballoc=3. To prevent getting “Location out of range” errors from the ixgbe driver, load it with the right parameters in order to activate the maximum number of 8k filtering rules

✔ To view filtering rules applied on the Chelsio T4+ chipset:

[root@localhost ~]# cxgbtool <filtering_interface> filter show

✔ If the CPU usage of the Packet Filter instance is too high, install PF_RING (no ZC/DNA/LibZero needed), or use a network adapter that allows distributing Packet Filters over multiple CPU cores
✔ For PF_RING installation issues, contact ntop.org. To increase the maximum number of PF_RING programs from 64 to 256, increase the MAX_NUM_RING_SOCKETS defined in kernel/linux/pf_ring.h and recompile the pf_ring kernel module
✔ Event log error “License key not compatible with the existing server” can be fixed by sending the string from Configuration » Servers » [Packet Filter’s server] » Hardware Key to sales@andrisoft.com
✔ Make sure you are running the latest version of the software by checking Help » Software Updates