Terminology and methods for implementing the MITIGATOR DDoS protection system into the network.
Logically MITIGATOR is connected to two networks:
MITIGATOR can work with symmetric and asymmetric traffic routing.
With a symmetrical deployment scheme, traffic from the external network to the internal and vice versa passes
through the MITIGATOR.
With an asymmetric deployment scheme, traffic from the external network passes through MITIGATOR, and traffic from the internal network passes by. When using an asymmetric deployment scheme, no resources are spent on processing traffic on the internal network.
Defense methods can be divided into:
Advantages of the “Always-on” method:
Flaws of the “Always-on” method:
In MITIGATOR, to reduce the impact on legitimate traffic and background load,
each countermeasure can be enabled individually only at the moment an anomaly is detected. It takes 1+ second for the countermeasure to activate.
Advantages of the “On-demand” method:
Flaws of the “On-demand” method:
To avoid resetting previously established sessions with the “On-demand” method a soft start mode is implemented in the MITIGATOR countermeasures.
MITIGATOR can be connected to the network in two ways at the physical level:
When connecting “Inline”, the network from which the frame arrived is determined by the physical port from which the frame was received: “ext” ports – external network, “int” ports – internal network. Inside the system, “ext” and “int” ports are switch in pairs and the frame – is sent from the port with the same number as the receiving port. Both traffic with VLAN ID and without it is processed.
When choosing the “On-a-stick” connection method, a traffic re-tagging table is set, consisting of pairs of external and internal VLAN IDs. A frame with an external VLAN ID received from any physical port is considered as coming from an external network. The processed frame is sent to the internal network over the same port through which it was received, and its VLAN ID is replaced with the corresponding internal one. If the incoming frame contains a VLAN tag with an internal VLAN ID, it is replaced with the corresponding external VLAN ID, and the frame is sent through the same port.
At the network level, MITIGATOR can be L2-transparent or act as an L3 device with limited functionality.
In the “L2 transparent” mode, MITIGATOR is invisible to surrounding network devices
and does not affect the interaction at the network level in any way. The frame passing through the MITIGATOR is not changed.
In the “L3 router” mode, the system performs a number of basic functions of an L3-device, which allows routers in connected networks to use MITIGATOR as a next-hop and act as next-hop for MITIGATOR using IPv4 and IPv6 protocols.
It is assumed that there is a router in the external network to which the MITIGATOR is connected. An internal router is located in the internal network. When a frame arrives from the external network, the frame’s source MAC address is replaced with the MAC address of the MITIGATOR’s internal interface, and the destination MAC address is replaced with the MAC address of the internal router. For frames from internal network, the MAC addresses are reversed.
Own routing parameters can be set for each pair of VLAN IDs in “L3 router” mode.
The system supports the functions of the ARP and NDP protocols
To determine the MAC addresses of neighboring routers. The IP addresses of the MITIGATOR interfaces and the IP addresses
of the internal and external routers are set. MITIGATOR sends requests to resolve the MAC addresses of routers
once every 30 seconds. Polling parameters are set in the configuration file
data-plane.conf (description). The MAC addresses
of the external and internal interfaces of MITIGATOR can be set manually.
Also, the MITIGATOR packet processor can respond to ping messages.
Until the process of resolving the MAC addresses of neighboring routers is completed, all frames are dropped. Frames that are not addressed to the MITIGATOR’s internal or external MAC address are always dropped.
The MITIGATOR can be connected to the network in four ways:
Inline L2 transparent:
On-a-stick L2 transparent:
Inline L3 router:
On-a-stick L3 router:
For the Inline L2-transparent deployment method, traffic balancing between MITIGATOR instances is possible due to LACP between R1 and R2.
For the L3 router deployment method, it is possible to balance traffic between MITIGATOR instances using ECMP.
In all cases, balancing across MITIGATOR instances must be configured
so that the src_ip + dst_ip pair always hits the same device.
Centralized management of multiple instances of MITIGATOR is possible in cluster mode Schematic diagrams of the cluster and settings are described in separate section.
To ensure network connectivity in case of accidents and scheduled work, you can use:
MITIGATOR supports network interfaces with Hardware Bypass. Their use allows you to maintain network connectivity in the event of a power outage or a software error in the packet handler. For scheduled jobs, you can control the Bypass operation mode via the Web interface.
If, in the absence of an attack, traffic does not pass through the MITIGATOR, then detection requires receiving telemetry on traffic from network equipment. Telemetry from the upstream router is sent to Collector via flow protocols. Collector sends traffic statistics to MITIGATOR. The detection subsystem in MITIGATOR, having detected an anomaly, sends a BGP announcement to redirect traffic for cleaning.
Such interaction may be set up also with third-party flow collectors.
GRE tunneling can be used in MITIGATOR in two scenarios:
For service provider of DDoS protection service.
The provider provides a service to a consumer that is outside its network, or the delivery of cleared traffic to the protected resource is complicated by the peculiarities of routing in the provider’s network. In this case, traffic arrives at MITIGATOR from the external network, undergoes cleaning, after which it is packed into a GRE tunnel and sent to the protected resource in the external network. Outgoing traffic of the protected server can be packed into a GRE tunnel
or sent directly to the user over the Internet.
For service consumer of DDoS protection service.
The consumer does not have a direct connection to the service provider’s network, or the service provider is having difficulty delivering traffic. In this case, the traffic enters the MITIGATOR through the GRE tunnel, is unpacked and cleaned, and then sent to the protected resource on the internal network. Outgoing traffic of the protected server can be packed into a GRE tunnel.
or sent directly to the user over the Internet.
Let’s consider an asymmetric implementation of several instances of MITIGATOR, in which both protection scenarios can be used simultaneously.
A route is set on router R1, according to which the IPs / 24 prefix is available through router R2, ECMP support is enabled, balancing is configured so that the src_ip + dst_ip pair falls on the same next-hop. MITIGATOR is assembled into a cluster. Each MITIGATOR instance has established a BGP session with R1. R2 has a default route set to R1.
Thus, if there is no need for protection, traffic to the protected resource comes directly from R1 to R2, bypassing the MITIGATOR. At the moment when it is necessary to activate protection, MITIGATOR instances send a BGP announcement to R1 stating that the protected IPs1/32 prefix is available over IPm1 and IPm2. Due to ECMP balancing, traffic will be distributed between two devices.
This deployment option allows to: