IP Zone¶

IP Zones are hierarchical, tree-like data structures used by Sensor to extract per-subnet settings and to learn the protected network’s boundaries.

In most configurations, you will have to add your IP blocks to the IP Zones listed in Configuration » Network & Policy. There are several ways to add prefixes (IPs/IP blocks/subnets/ranges): from the web interface, via the REST API by accessing http://<console_ip>/wanguard-api-ui, or by executing the command php /opt/andrisoft/api/cli_api.php on the Console server.

To add a new IP Zone, go to Configuration » Network & Policy » [+] and select [IP Zone]. You only need more than one IP Zone when you want to use different per-subnet settings for different Sensors. If this is the case, it may be easier to open an existing IP Zone that already includes your IP address ranges, and duplicate it by pressing the [Duplicate] button.

The IP Zone Configuration window is divided into two vertical sections. The buttons that manage prefixes are located in the upper part of the left section. When a new prefix is added the tree below automatically updates itself. The section on the right contains panels with user-provided settings for the selected prefix.

To enter IP addresses or IP blocks, use the CIDR notation. To enter individual hosts in IP Zones, use the /32 CIDR mask for IPv4 and /128 for IPv6.

Every IP Zone contains the network 0.0.0.0/0. Because it’s CIDR mask is /0, this “supernet” includes all IP addresses available for IPv4 and IPv6. For an easier configuration, every new prefix that you define inherits by default the properties of the most-specific (having the biggest CIDR mask) IP class that includes it.

The IP Settings panel from the section on the right provides the following parameters:

● IP Group – Set a short description of the selected prefix, or the name of the customer that uses it. When you set the same IP group on multiple prefixes you will be able to generate aggregated traffic reports. This combo box is editable

● IP Graphing – Set to “Yes” to permit the collection of graph data for every IP contained in the selected prefix. The Graph IP Sweeps option from Configuration » General Settings » Graphs & Storage can be used to prevent generating graph data for IPs that only receive traffic without sending traffic in return. IP Graphing is always enabled for the subnets explicitly defined in the IP Zone. Do not enable this option on many/large subnets without a performance impact assessment

● IP Accounting – Set to “Yes” for the Sensor to generate daily accounting data for each IP contained in the selected prefix. IP Accounting is always enabled for the subnets explicitly defined in the IP Zone. Do not enable on many/large subnets without a performance impact assessment

The Storage Requirements column indicates the disk space needed by each Packet Sensor and Flow Sensor interface to store the generated data. Enabling IP graphing and IP accounting for very large prefixes (e.g. 0.0.0.0/0) might generate data that could overload the Console server and fill the disk space. The storage requirements for IP graph data is possible to estimate only for RRD files. For InfluxDB this is not possible.

The Comments panel allows you to enter a comment for the selected prefix. It is not visible elsewhere.

12. Traffic Thresholds¶

You can define traffic threshold rules by adding them to the Thresholds panel in the IP Zone Configuration window. To ease the addition of identical thresholds on multiple prefixes, go to Configuration » Network & Policy » [+] and select [Threshold Template].

Each threshold rule contains the following metrics:

● Domain – Sensors can detect anomalies to/from an internal IP contained in the selected subnet or to/from the subnet taken as a whole. If the selected subnet is 0.0.0.0/0 then a third option is possible, which allows detection anomalies to/from external IPs (for this third option to work, the Stats Engine parameter from the Sensor configuration must be set accordingly)

● Direction – The direction of traffic can be “receives” for the inbound traffic received by the prefix, or “sends” for the outbound traffic sent by the prefix

● Comparison – Select “over” to detect volumetric anomalies (e.g. DrDoS, DDoS) or “under” to detect a gap in traffic

● Value – The threshold value can be entered as an absolute number, or as a percentage of the total traffic matched by selected decoder per Sensor interface. Absolute values can be multiples of 1000 with K (kilo) appended, multiples of 1 million with M (mega) appended, or multiples of 1 billion with G (giga) appended

● Decoder – Select one of the decoders enabled in Configuration » General Settings » Anomaly Detection

● Unit – DDoS attacks usually reach a very high number of packets per second, so the “pkts/s” option is the best way to detect them. For bandwidth-related anomalies, select “bits/s”

● Response – Select a previously defined Response, or select “None” to have no reaction to anomalies other than displaying them in Reports » Tools » Anomalies » Active Anomalies

● Parent – Select “Yes” if more specific prefixes should inherit the threshold. You can cancel inherited thresholds by defining a similar threshold with “Unlimited” selected in the Value field

● Inheritance – Displays the parent prefix when the rule is inherited from a less specific prefix

Adding a threshold rule on 0.0.0.0/0 that reads, “Internal IP receives over 5% TCP+SYN pkts/s” catches port scans and all significant SYN attacks towards any IP address belonging to your network. A threshold rule on 0.0.0.0/0 that reads, “Subnet sends under 1 IP bits/s” executes the Response when the link goes down.

12. Best practices for setting up traffic thresholds¶

✔ TCP+SYN thresholds on IPs should be configured to low values, usually at around 500-1000 packets/s. TCP uses packets with the SYN flag set only for establishing new TCP connections, and few services (e.g. very high volume websites) are able to handle more than 1000 new connections every second. SYN packets are frequently used for flooding
✔ TCP bits/s thresholds should be configured to your maximum bandwidth level per IP. TCP packets carry on average around 500 bytes of data. Setting a threshold of 15k TCP packets/s should be enough for medium-sized networks
✔ ICMP thresholds should be configured to very low levels, 50-100 packets/s. ICMP is frequently used for flooding, while legitimate ICMP traffic is never above a few packets/s
✔ UDP traffic usually exhibits high packets/s and low bits/s values, so you can configure low values for bits/s. Setting UDP packets/s thresholds at around 15k/s per destination should not generate false positives while catching all significant UDP floods. UDP is also frequently used for flooding. A special attention must be paid lately to the QUIC protocol which encapsulates high-bandwidth HTTP traffic inside UDP packets
✔ OTHER decoder matches all non-TCP, non-UDP and non-ICMP traffic. You can configure thresholds for OTHER if you have non-standard applications in your network. More than 90% of Internet traffic is either TCP or UDP
✔ Enable additional decoders, such as HTTP, MAIL, NTP, etc., to be able to configure thresholds for specific services and servers
✔ Configure illegal IP address ranges that should never be seen in normal traffic (unallocated IP addresses or parts of your internal IP address range that are unoccupied). Then, add small thresholds to these, to catch malicious activities such as scans and worms
✔ If you open an IP Zone and select 0.0.0.0/0 you will be able to configure thresholds for external IPs (IPs not belonging to your network). This is useful to catch external IPs that scan your network with very few packets sent to each of your IPs

Adding similar threshold rules for the same prefix is not allowed, even when the rules have different values or Responses. To execute different actions for different threshold values, define only the smallest threshold value in IP Zone, and then use preconditions inside the Response. For example, if you want to activate Wanguard Filter for UDP attacks stronger than 100 Mbps but you also want to null-route them in BGP when they reach 1 Gbps, add only the “Internal IP receives over 100M UDP bits/s” rule. Then, inside the Response add two actions: one that activates Filter without Preconditions, and another that executes a BGP announcement with the Precondition “Peak Value” “over” “1G”.

12. Traffic Profiling¶

The Profile Anomalies panel contains the Profiling Data parameter, which manages the detection of traffic anomalies by profiling traffic behavior:

● Inherit – The value is inherited from the parent prefix

● No – Do not generate profiling data for the selected prefix

● Subnet – Generate profiling data for all traffic received by the prefix as a whole

● IPs – Use carefully as it will generate profiling data for every IP contained in the prefix. Enabling this option is not recommended for large subnets because it can overwhelm the I/O of the server, and potentially generate false positives because the traffic of single IPs is not always predictable

● Subnet + IPs – Activate both options from above