MITIGATOR Protection Quick Setup

The materials in this article are intended to facilitate understanding of the protection organizing basic principles using MITIGATOR. Below is an example of setting up the system in the first iteration.

First, all packets are processed in “General Protection”, then 5-tuple routing rules distribute traffic to protection policies, and after the policies, the traffic returns to “General Protection” for the remaining countermeasures.

Processing of back traffic from the protected resource is not considered in this article.

Info

MITIGATOR supports Flow collectors. Statistics from the collector can be useful both for additional analytics and for detecting attacks.

The Case Under Consideration

Let’s consider the protection of the corporate network Х.Х.Х.0/24, in which several services operate. We can highlight the host Х.Х.Х.100/32, on which the site operates (HTTP, HTTPS), and an application operating on proprietary protocols over TCP/7777, UDP/8888. There is a WAF in protected network.

Preparation

Let’s assume that initial system setup has already been completed.

MITIGATOR provides for the creation and use of named lists. The source of such lists can be, for example, WAF on the protected network. The MITIGATOR team also provides a wide range of feeds for filtering and analytics. Feeds from other sources can also be used.

Let’s create some named lists, they will be useful for further customization.

  1. Named list of prefixes waf_list. The source is a WAF on the protected network.

  2. Named list of prefixes proxy_general_7d. The source is MITIGATOR feeds (additional license required). The list includes IP addresses belonging to attacking proxies.

  3. Named list of prefixes intersect_tbl_tbl_2_1d. The source is MITIGATOR feeds (additional license required). The list includes IP addresses blocked on 2 or more MITIGATOR installations at different clients over the past 24 hours.

  4. Named list of prefixes policies_tbl. The source are TBL countermeasures in protection policies.

Info

Most countermeasures have a Test mode. In test mode, countermeasures build traffic drop graphs, but in reality, traffic passes through without being dropped or changed. This is useful for assessing the impact of countermeasure settings on legitimate traffic. Therefore, before enabling a countermeasure, you should check the impact of the settings in test mode.

Let’s move on to “General Protection” setting up.

General Protection

General protection processes all traffic coming to MITIGATOR from the external network. General protection is convenient to use when it is necessary to cut off traffic for the entire device. For the current task, we will need to configure BL, ACL and DLIM countermeasures.

BL

BL allows to effectively protect network from various attacks by dropping all traffic coming from specified IP addresses. In addition, it may be convenient to drop traffic based on autonomous system affiliation. For example, if you know that hosting IP addresses should not connect to the protected resources, you can specify the numbers of the corresponding autonomous systems in the list.

We will specify in BL the numbers of autonomous systems and IPs, legitimate traffic from which is not expected in the protected network using named lists waf_list, proxy_general_7d, intersect_tbl_tbl_2_1d and policies_tbl.

ACL

ACL allows processing packets according to rules for IP, TCP, UDP, ICMP headers. Let’s set rules for dropping all initially unnecessary traffic. This will greatly reduce the possible attack volume. For example:

# Dropping spoofed packets from our own network addresses
drop src X.X.X.0/24

# Dropping traffic from non-routable networks
drop src (0.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.0/8 169.254.0.0/16
192.0.2.0/24 198.51.100.0/24 203.0.113.0/24 198.18.0.0/15 224.0.0.0/4 240.0.0.0/4)

# Amplification packets drop for protocols not used in the protected network
# The list of ports and a description of the amplification protocols can be seen here
# https://github.com/Phenomite/AMP-Research. Amplification protocols are constantly being
# added, so the list needs to be updated periodically
drop udp sport (19 6881 389 751 11211 1434 5353 137 111 17 27960 520 1900 27015 7001
3283 5683 37810 2362 30718 502 5351 53413 32414 161 3702 177 17185)

# If no one is playing online games
drop udp sport (27015 30120)

# If the network needs traffic from any NTP and DNS, then we will process it further
# in the protection policy.
# But in a corporate network it is enough to allow NTP and DNS traffic only according
# to the list
pass udp sport 53 src (77.88.8.88 77.88.8.2)
drop udp sport 53
pass udp sport 123 src 194.190.168.1
drop udp sport 123

# Passing only used L4 protocols: TCP, UDP, ICMP, IPSEC
pass protocol (1 6 17 50 51 )

# If GRE, IP-IP, L2TP tunnels are used
pass protocol (47 4 115)

# Dropping all other traffic
drop

A hint on the rules syntax is in the countermeasure help panel. The rules are triggered in order.

If the ACL drops packets without any attack, then the packet capture panel can help us to capture the packets dropped by the ACL countermeasure and perform fine-tuning.

A properly configured ACL can save you from a lot of trouble. It is advisable to use such a list at the network boundary, and it is even better to agree with the upstream and write similar rules on the operator router.

DLIM

The DLIM countermeasure limits traffic in pps and bps to destination IP address. DLIM processes packets after all filtering in protection policies and is used to save the network behind MITIGATOR at the cost of partially dropping legitimate traffic towards the victim.

Example:

There are 40 servers in a rack, each server is connected via 1GbE to the ToR switch, the ToR switch is connected via 10GbE to the network core. At the same time, the network has 100G of uplinks. If one of the servers is attacked by 25G, and protection is poorly configured for this server, then the ToR link of the switch will be clogged and all 40 servers will be lost. To avoid this, DLIM sets a limit of 1.1G for each address. Thus, at the time of the attack, only 1.1G will reach the ToR switch, and the remaining 39 servers will be saved. In this case, in the absence of an attack, the server will be able to completely utilize its link.

A margin in excess of 1G is needed so that legitimate traffic is not cut off during load bursts due to a limiting error. The error arises due to the peculiarities of counting and specific of traffic passing through the network. A 10% margin is usually excessive, but in the context of this example, there is no task to drop traffic exactly along the border of the server link.

For the current task, let’s assume that each address in the network needs 100 Mbps, except X.X.X.100/32, which can have up to 1 Gbps of legitimate traffic.

When specifying thresholds for X.X.X.0/24, DLIM will decompose the network by /32 and enter thresholds with the same specified values. Then for X.X.X.100/32 we set the threshold separately.

If the user subscribes to notifications by mail, Vestochka or Telegram, he will receive notifications about threshold excession for each /32, which can be used as an additional tool to monitor attacks.

Distribution of Traffic to Protection Policies

Now you need to create protection policies and distribute traffic among them.

Let’s create the following policies:

policy_DNS
policy_NTP
policy_TCP_sport 80,443
policy_X.X.X.100_HTTP_HTTPS
policy_X.X.X.100_TCP_7777
policy_X.X.X.100_UDP_8888
policy_X.X.X.100
policy_net_X.X.X.0/24

Policies Routing Rules:

1. udp sport 53 -> policy_DNS
2. udp dport 53 -> policy_DNS
3. udp sport 123 -> policy_NTP
4. tcp sport 80, 443 -> policy_TCP_sport 80,443
5. tcp dst X.X.X.100 dport 80, 443 -> policy_X.X.X.100_HTTP_HTTPS
6. tcp dst X.X.X.100 dport 7777-> policy_X.X.X.100_TCP_7777
7. udp dst X.X.X.100 dport 8888 -> policy_X.X.X.100_UDP_8888
8. dst X.X.X.100 -> policy_X.X.X.100
9. dst X.X.X.0/24 -> policy_net_X.X.X.0/24

Protection Policies Setup

When setting up protection policies, you should check yourself against the policy settings checklist.

Autodetection

Another feature of MITIGATOR is autodetection in protection policies. Autodetection changes the status of a countermeasure when a condition (predicate) is met, or when an anomaly is detected after training. After installation, MITIGATOR already contains a set of predicates. When setting up a protection policy, the user needs to specify thresholds for the required predicates.

Thresholds have names that characterize the predicate, for example:

  • ACL.TcpPps.On — threshold for enabling ACL countermeasures when the rate of packets with TCP segments on the protection policy input is exceeded;
  • GEO.PassBps.On — threshold for enabling GEO countermeasures when the traffic rate in bps, passed in the protection policy, increases;
  • TCP.SYNACKFactor — threshold for enabling TCP countermeasure if the ratio of SYN to ACK segments is greater than expected.

Also, through the web interface within the policy, you can set the autodetection parameters “Number of analyzed intervals” and “Number of detected intervals”, each interval is 5 seconds.

“Number of analyzed intervals” indicates the time period on which the predicate values ​​are looked at, and “Number of detected intervals” indicates how many intervals the predicates should be triggered on before changing the countermeasure status. By changing these parameters, you can control the reaction speed and detection sensitivity.

Detailed description of the autodetection mechanism and predicates in the built-in MITIGATOR documentation.

Autodetection only enables or disables the countermeasure, and whether the packet is dropped or passed depends on the countermeasure settings at the time of enablement. In this case, we are considering a situation, in which we cannot or do not want to understand in detail the specifics of real traffic. Therefore, the settings will be far from ideal, but in general they will protect.

policy_DNS

1. udp sport 53 -> policy_DNS
2. udp dport 53 -> policy_DNS

With rules 1 and 2 we directed all DNS traffic of the network into one policy, both requests and responses. In autodetection mode: DNS, SORB. Constantly enabled: LIM.

DNS

The countermeasure validates DNS traffic and authenticates senders. Activate autodetection mode. Specify the threshold DNS.UDP.Rps after how many DNS requests the countermeasure will be enabled. The countermeasure settings depend on the location of authoritative and recursive DNS servers in the network.

SORB

The SORB countermeasure blocks IP addresses that send traffic greater than thresholds in pps, bps. It will be enough to specify thresholds SORB.Input.Bps.On to enable the countermeasure and SORB.Input.Bps.Off to disable it.

LIM

The LIM countermeasure limits the traffic passed by the policy in pps, bps. Specify DNS traffic thresholds, more than which you would not like to observe in network.

policy_NTP

3. udp sport 123 -> policy_NTP

Rule 3 collected all incoming NTP messages into one policy. In autodetection mode: ACL. Constantly enabled: LIM.

ACL

In case of an NTP Amplification attack, you can specify a pass based on the size of legitimate packets and a drop of the rest (the length is calculated as IP header + UPD header + UPD payload):

pass udp sport 123 len 76
drop

Autodetection thresholds: ACL.Input.Bps.On, ACL.Input.Bps.Off for countermeasure enabling and disabling.

LIM

Specify thresholds in pps, bps.

policy_TCP_sport 80,443

4. tcp sport 80, 443 -> policy_TCP_sport 80,443

Since public web servers are often used for TCP SYN-ACK Reflection, and hosts in the protected network will connect to internet for updates one way or another, it is better to put such traffic in a separate policy with rule 4. In autodetection mode: ACL, TCP and SORB. Constantly enabled: LIM.

ACL

Rules:

drop tcp tcp-flags S/SA
drop tcp dport 0-1023

Autodetection thresholds:

ACL.Input.Bps.On, ACL.Input.Bps.Off, ACL.Input.Pps.On, ACL.Input.Pps.Off.

TCP

SYN+ACK packet authentication: “Check by reset with RST+ACK send”.

Autodetection thresholds:

TCP.InputPps.On, TCP.InputPps.Off, TCP.InputBps.On, TCP.InputBps.Off, TCP.AckRate.On, TCP.AckRate.Off, TCP.SynAckRate.On, TCP.SynAckRate.Off, TCP.RstFloodFactor, Low.Pps, Low.Bps.

Since predicates based on the ratio of the number of some packets to others (TCP.RstFloodFactor) are used, the ratio can change significantly at low speeds. Therefore, to avoid false positives, it is recommended to set (.Low.) thresholds, below which autodetection will not change the countermeasures status.

SORB

Specify thresholds in pps, bps. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

LIM

Specify thresholds in pps, bps.

policy_X.X.X.100_HTTP_HTTPS

5. tcp dst X.X.X.100 dport 80, 443 -> policy_X.X.X.100_HTTP_HTTPS

Direct web server’s traffic to address X.X.X.100 in separate policy with rule 5. In autodetection mode: ACL, TCP, CRB, LCON, HTTP, ATLS, SORB and GEO if permissible.

ACL

Rules:

drop tcp tcp-flags SA/SA
drop tcp sport 0-1023

Autodetection thresholds:

ACL.Input.Bps.On, ACL.Input.Bps.Off, ACL.Input.Pps.On, ACL.Input.Pps.Off.

TCP

SYN packet authentication: “Check by TCP session reset”.

Autodetection thresholds:

TCP.SYNACKFactor, TCP.InputPps.On, TCP.InputPps.Off, TCP.InputBps.On, TCP.InputBps.Off, TCP.AckRate.On, TCP.AckRate.Off, TCP.RstFloodFactor, TCP.RstRate.On, TCP.RstRate.Off, Low.Pps, Low.Bps.

CRB

Set the threshold for new TCP connections creating rate from one address. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

CRB.SynPps.On, CRB.SynPps.Off.

LCON

Set the threshold for simultaneous connections from one address. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

LCON.InputPps.On, LCON.InputPps.Off, LCON.InputBps.On, LCON.InputBps.Off.

HTTP

Select the appropriate verification method, for example, HTML Meta Refresh. When autodetection is enabled then training is started, so additional thresholds can be omitted. If HTTP requests are rare, it is recommended to set HTTP.Low.Rps to prevent false positives.

ATLS

Select operating mode: active. Other parameters can be changed if the server’s operating features are known, or to filter a specific attack. When autodetection is enabled, training is started, additional thresholds depending on the situation.

SORB

Specify thresholds in pps, bps. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

GEO

If the service users are geographically localized, and it is acceptable to sacrifice traffic from other regions at the time of an attack, then GEO can be used with detection by passed traffic.

Create a group of countries for which traffic should be passed.

Create one or more groups of countries for which you need to limit traffic.

For the rest, specify the default action: “Drop”.

Autodetection thresholds:

GEO.PassBps.On, GEO.PassBps.Off, GEO.PassPps.On, GEO.PassPps.Off.

Detection by passed traffic allow GEO to be enabled when other countermeasures are not filtering effectively. Enabling GEO will reduce passed traffic level, which may trigger the GEO disable, which will cause an increase in passed traffic and enable GEO again. You can control the cycle by specifying autodetection parameters in the “Number of analyzed intervals” and “Number of detected intervals”. The higher the “Number of analyzed intervals” is, the longer the countermeasure will not be turned off after the traffic level drops below the disable threshold.

policy_X.X.X.100_TCP_7777

6. tcp dst X.X.X.100 dport 7777-> policy_X.X.X.100_TCP_7777

Separate the proprietary protocol traffic on host X.X.X.100 with rule 6. In autodetection mode: ACL, CRB, LCON, SORB and GEO if permissible.

The required TCP modes of operation depend heavily on the behavior of the client application. If it is possible to modify the client application, then MCR support should be built in. If modification is not possible, but the protocol is known, then a countermeasure can be created within the BPF.

GEO

Similar to policy_X.X.X.100_HTTP_HTTPS.

Autodetection thresholds:

GEO.PassBps.On, GEO.PassBps.Off, GEO.PassPps.On, GEO.PassPps.Off.

ACL

Rules:

drop tcp tcp-flags SA/SA
drop tcp sport 0-1023

Autodetection thresholds:

ACL.Input.Bps.On, ACL.Input.Bps.Off, ACL.Input.Pps.On, ACL.Input.Pps.Off.

CRB

Set the threshold for new TCP connections creating rate from one address. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

CRB.SynPps.On, CRB.SynPps.Off.

TCP

SYN packet authentication: “Check by TCP session reset”.

LCON

Set the threshold for simultaneous connections from one address. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

LCON.InputPps.On, LCON.InputPps.Off, LCON.InputBps.On, LCON.InputBps.Off.

SORB

Specify thresholds in pps, bps. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

policy_X.X.X.100_UDP_8888

7. udp dst X.X.X.100 dport 8888 -> policy_X.X.X.100_UDP_8888

Traffic of another critical application on the address X.X.X.100 sent to policy with rule 7. Protecting a UDP application can be a very non-trivial task. Therefore, it is recommended to contact support to discuss a scenario for protecting a specific UDP application. MITIGATOR has specialized protection built in for many UDP applications, but mostly gaming ones. If it is possible to modify the client application, then MCR support should be built in. If modification is not possible, but the protocol is known, then a countermeasure can be created within the BPF.

In general:

GEO

Similar to other policies.

Autodetection thresholds:

GEO.PassBps.On, GEO.PassBps.Off, GEO.PassPps.On, GEO.PassPps.Off.

ACL

Rules:

If it is known that a client application only establishes connections from a certain port or range, then the rest can be blocked.

pass udp sport 8877
drop

Otherwise, we block only system ports:

drop udp sport 0-1023

SORB

Specify thresholds in pps, bps. Since address spoofing is possible, the countermeasure may be ineffective. Enable “Add to Temporary IP Blacklist” checkbox if necessary.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

REX

If you can template the payload of udp packets, then write the traffic signatures: pass (\xDE\xAD\xBE\xEF){3,9}, drop the rest of the packets. Otherwise, try to block the traffic of a specific attack: drop badbotpayload, pass the rest of the packets.

LIM

In this case, it is necessary to specify thresholds in LIM, since there is a high probability of passing attack traffic, which will trigger DLIM for the address X.X.X.100 and affect traffic in other policies with this address. The threshold value should be less than in DLIM.

policy_X.X.X.100

8. dst X.X.X.100 -> policy_X.X.X.100

Rule 8 collects the remaining traffic for host X.X.X.100. In autodetection mode: TCP, SORB. Constantly enabled: ACL, LIM.

ACL

Describe what other packets are expected on this host. If no connections are expected from the Internet to other ports, then drop SYN.

drop tcp tcp-flags S/SA
drop tcp dport 0-1023
drop udp dport 0-1023
pass icmp icmp-type (0 3 8 11)

TCP

SYN+ACK packet authentication: “Check by reset with RST+ACK send”.

Autodetection thresholds:

TCP.InputPps.On, TCP.InputPps.Off, TCP.InputBps.On, TCP.InputBps.Off, TCP.AckRate.On, TCP.AckRate.Off, TCP.SynAckRate.On, TCP.SynAckRate.Off, TCP.RstFloodFactor, Low.Pps, Low.Bps.

SORB

Specify thresholds in pps, bps. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

LIM

Specify thresholds in pps, bps.

policy_net_X.X.X.0/24

9. dst X.X.X.0/24 -> policy_net_X.X.X.0/24

The last rule collects all remaining network traffic. We need to make sure that there is no traffic in the Default policy. When describing the next services, we will need to add rules before this rule. Since we know little about the traffic in this policy, we make very rough settings. In autodetection mode: TCP, SORB. Constantly enabled: LIM.

TCP

SYN packet authentication: “Check by TCP session reset”.

Autodetection thresholds:

TCP.AckRate.On, TCP.AckRate.Off, TCP.SynAckRate.On, TCP.SynAckRate.Off, TCP.RstFloodFactor, TCP.SynRate.On, TCP.SynRate.Off, TCP.SYNACKFactor, TCP.Low.Pps, TCP.Low.Bps, TCP.InputPps.On, TCP.InputPps.Off, TCP.InputBps.On, TCP.InputBps.Off.

SORB

Specify thresholds in pps, bps. Enable “Add to Temporary IP Blacklist” checkbox.

Autodetection thresholds:

SORB.Input.Bps.On, SORB.Input.Bps.Off, SORB.Input.Pps.On, SORB.Input.Pps.Off.

LIM

Since the policy is poorly configured, an attack on all network addresses at once is possible, but there may not be an excess in DLIM for each host, this can cause a failure of the devices behind. Therefore, it is necessary to limit the total output traffic to the internal network.

Specify thresholds in pps, bps at the performance limit of the devices behind the MITIGATOR.

Additionally, it is recommended to change the Policy.Status.DropBps, Policy.Status.DropPps, Policy.Status.InputPps, Policy.Status.InputBps threshold values in each protection policy. Then the color indication of policy statuses in the list of policies will be more adequate.

You also need to configure automatic packet capture with email delivery. To do this, you need to specify a mail server in the system settings, and set the capture parameters in the “Packet capture” card and specify the PCAP.* thresholds. This is useful if the attack was successful and you need to adjust the protection.

Conclusion

This article provides the basic MITIGATOR configuring example. Detailed information of specific countermeasures and other system mechanisms operation is provided in the built-in MITIGATOR help.