DDoS Protector

The volume of DDoS attacks grows every year. DDoS attacks are not only aimed at big players but smaller services and organizations are targeted with less intense, but effective enough, attacks as well. Unfortunately, the smaller players often lack budget and expertise to introduce adequate protection. CESNET is addressing this shortcoming by developing its custom DDoS protection device – DDoS Protector. The device consists of COMBO FPGA network interface card and a commodity server. The FPGA implements the fast forwarding and filtering data plane while the server implements the control plane that continuously evaluates the network traffic parameters and in case of attacks, it enables FPGA filtering with less than one second delay.

In case of the DDoS attacks the closer to the source the attack is dealt with the better. For example the victim might protect its resources very well but its last mile connectivity will be overwhelmed by the attack anyway and therefore the attack should be mitigated at least one step ahead. Therefore an effective strategy is to deploy DDoS mitigation at the connectivity provider of these services and organizations. Therefore the primary goal of the DDoS Protector is to protect the infrastructure, especially, the last mile connecting the organizations to the backbone network while the Protector is deployed at the backbone where the aggregated capacity of the links is capable to deliver DDoS traffic to the Protector without influencing the legitimate traffic. The particular deployment of the Protector is depicted in the following figure.

The figure shows distributed DDoS attack which arrives in the backbone network over multiple links connecting CESNET with several exchange points or other NRENs. The traffic targeting a victim is forwarded to the Protector due to an automated flow-based detection. The Protector inspects the traffic, drops packets according to a given mitigation strategy and forwards the legitimate traffic to the target organization.

Under normal network conditions the Protector does not drop any packets. Only when DDoS traffic is detected the Protector starts to work as a filter. The goal of the filter is to drop DDoS packets to decrease the amount of traffic below an optimal limit. The Protector follows rules given by an administrator to behave deterministically. During configuration phase, an administrator defines a set of DDoS rules per each protected network prefix. The DDoS rule consists of conditions, limits and optimal traffic rate. The conditions specify which packet can match the rule (for example destination IP address must match IP prefix and dst port number of the packet must match dst port number in the rule). Limits specify the number of packets/s or bytes/s that must be exceeded to detect DDoS traffic targeting given IP prefix. Optimal traffic rate specifies the desired number of bytes/s or packets/s the DDoS traffic should be reduced to. The Protector evaluates rules upon user-defined periodic observation window.

Protector is often deployed in a pair with a router. The router forwards suspicious network traffic into the Protector device. Protector inspects every received packet, updates per rule statistics and decides whether to drop the packet or forward it back to the router. The goal of the router is then to deliver cleansed traffic to the protected network. Typical deployment of DDoS Protector is shown in figure below.

Protector offers a user a command line interface for its configuration and rules specification via SSH. Information about all the dropped traffic is then stored into log files or exported via NetFlow/IPFIX protocol. Protector also supports configurable VLAN mapping to support virtual routing and forwarding (VRF) technology for easier delivery of the cleansed traffic to the protected network. Current mitigation is focused especially on reflection attacks where the IP address is not spoofed. In such a case those IP addresses that contributed the most to exceeding the threshold are selected for mitigation, the packets containing these IP addresses are dropped. However, the Protector offers an interface to implement other mitigation algorithms, for example, we develop a heuristic approach to mitigate TCP SYN flood attacks and our future work is to further extend mitigation algorithms to allow for their flexible utilization according the current attack surface.