Solutions for data centers and Autonomous System Numbers (ASN) from VAS experts

Protection against DDoS attacks

SSG has the functionality of protection against external cyber threats, such as DDoS attacks like TCP SYN flood. Such attacks are aimed at depleting server resources, making it inaccessible to legitimate users. They exploit a TCP connection establishment mechanism known as the three-way/triple handshake.

How does the TCP SYN flood attack work?

First, let’s look at the TCP connection mechanism:

1. SYN (Synchronize): The client sends a SYN segment to the server, requesting that a connection be established.
2. SYN-ACK (Synchronize-Acknowledge): The server responds to the client with a SYN-ACK segment, acknowledging receipt of the SYN and requesting an acknowledgement from the client.
3. ACK (Acknowledge): The client sends an ACK segment to the server acknowledging receipt of the SYN-ACK and the connection is considered established.

In a TCP SYN flood DDoS attack, the attacker sends multiple SYN requests to the target server using a network of a large number of infected devices (from PCs and servers to IoT devices and game consoles), also known as a botnet. When using a botnet, the attacker does not need to hide the IP addresses of each device on the network.

The server responds to each request with a SYN-ACK segment and waits for an ACK confirmation from the client. Since no acknowledgement is received, the server keeps the connection open for a certain amount of time (usually a few seconds) until the timeout expires. Since the number of simultaneous connections is limited, the server quickly fills its connection pool, making it inaccessible to legitimate users.

Protection against TCP SYN flood DDoS attacks based on SSG: a practical case study

The SSG-based TCP SYN flood DDoS protection system is widely used by data centers and cloud providers. Let’s consider how this system was organized in one of the largest Russian data centers.

To test the SSG complex, the following configuration was organized on the test bench:

• RTR1 (Juniper MX204 router) – used as ASBR (autonomous system border router).
• RTR2 (Juniper MX204 router) – used as an Access router
• MPLS is configured between RTR1 and RTR2
• Client-1 (Mikrotik RB951Ui 2HnD router) – emulates a host on the Internet and acts as a source of legitimate connections.
• Client-2 (CRS305-1G-4S+IN router) – emulates a client in the data center network and acts as a receiver of both legitimate and illegitimate traffic (victim).
• Client-1 and Client-2 are connected to the routers through switches (not shown in the diagrams for simplicity).
• The RTR1 interface to which Client-1 is connected is considered an Uplink interface
• The following rules are configured on RTR1:
  • flowspec redirect-to-next-hop – a rule to redirect forward traffic toward the victim through the filter’s input interface.flowspec redirect-to-routing-instance – rule for redirecting back traffic from the victim through the output interface of the filter.
  • flowspec redirect-to-routing-instance – a rule for redirecting back traffic from the victim through the output interface of the filter.
• VAS Experts SSG DDoS protection complex is used for traffic cleaning, operating in L2 mode.

Network layout in the absence of active attacks:

At the moment the attack starts, legitimate traffic is exchanged between Client-1 and Client-2.

The scheme of traffic flow at the moment of the attack start:

After a TCP SYN flood attack from the Perpetrator (malicious host) with different spoofed source addresses starts, within about 20-25 seconds, traffic, both legitimate and malicious, flows directly through the router to the victim.

When the attack traffic exceeds the set thresholds on bitrate or packet rate, after about 20-25 seconds, a redirect-to-next-hop rule (either manually or announced through automation and BGP) appears on the ASBR of RTR1, redirecting traffic through the RTR1 interface to the SSG.

Scheme of traffic passing in protection mode:

If the attack stops or its intensity decreases below the threshold values, the flowspec rule is removed (manually or by automation means) and the traffic stops passing through the filter.

Test results

The real picture showed successful redirection of all traffic, both legitimate and malicious, intended for the victim client. At the same time, all malicious TCP SYN flood attack traffic up to 360 Mbps was successfully blocked.

Both in synthetic tests and on real product traffic, legitimate protected services between the client and the victim worked correctly. At the moment when traffic was transferred to the filter, services with already established connections continued to work stably.

When traffic was removed from the device, TCP sessions related to protected resources that were established through it during the attack were broken. While the sessions established through the filter but not related to the protected ports were not broken.

Virus activity monitoring based on QoE Analytics and Kaspersky Lab

Kaspersky Threat Data Feeds and SSG’s Quality of Experience (QoE) traffic analytics module were combined to create a highly effective solution for analyzing and countering cyber threats.

Kaspersky Threat Data Feeds is a structured, constantly updated and voluminous database of various types of cyber threats such as DDoS attacks, phishing sites, botnet networks, spam and other malicious influences. There are 16 types of feeds in the database, out of which SCAT deals with seven major ones:

1. Malicious URL
2. Phishing URL
3. Botnet C&C
4. Mobile Botnet
5. IP Reputation
6. Ransomware URL
7. IoT URL Data

Using proprietary crawlers, spam traps and botnet monitoring systems, Kaspersky Threat Data Feeds tests, analyzes and collects data on all currently known cyber threats into a single reference.

To implement a collaborative solution, a synchronized copy of the threat database is hosted on a server with user behavior statistics. The user behavior statistics on the SCAT are then compared to the threat database, allowing conclusions to be drawn about potential threats within the data center network.

Benefits of integrating Kaspersky and VAS Experts

• Identification of users with virus activity.
• Detection of botnets at an early stage.
• Determining the degree of network infection.
•  Create a list of identified threats and infected users for the network administrator.

Once the network is infected, the network administrator can quickly and efficiently solve problems with SCAT:

• Restrict or block users using policies on network devices.
• Downloading data on infected users for processing by technical support specialists.

Thus, the integration of Kaspersky Threat Data Feeds and VAS Experts’ SSG platform is a powerful tool for monitoring and countering cyber threats in data center networks. Thanks to deep synchronization of cyber threat data with user behavioral statistics, this system provides a high level of protection by quickly identifying potential threats such as virus activity and botnets at early stages. This allows network administrators to respond to incidents in a timely manner, minimizing risks and preventing the spread of malware within the network. So, the implementation of this solution helps to improve security in corporate networks and reduce the risks associated with cyberattacks.

Network health monitoring with QoE analytics module

Network condition monitoring allows to detect, for example, such problems with service availability for users as malfunctions or overload of upstream aplinks, as well as slow operation or unavailability of services without special online expertise.

Let’s consider a real case of application of QoE analytics module by one of the largest data centers to monitor the state of its own network and optimize traffic routing.

Description of QoE connection

Traffic from the customer’s virtual infrastructure was directed through the mirror to the BareMetal port of the server with SSG. The task of SSG was to collect statistics on NetFlow v10 protocol, using custom fields including RTT and Retransmit information for TCP sessions. The collected statistics were fed into a virtual machine where the QoE Stor statistics collection module was deployed.

Test results

Checking whether the retransmit share matches the manually configured losses on the host.

For the test, a host was used on which Linux TC was used to set parameters that artificially discard 30% of incoming traffic on the interface. As a result of the test, the QoE analytics showed 30% retransmits and corresponding RTT values.

Improve host connectivity by re-routing traffic

One of the hosts was experiencing retransmits on a TCP session. At 13:00, the outbound traffic route for the problematic prefix was changed, resulting in the retransmits disappearing and a decrease in RTT. These metrics were also confirmed by the statistics obtained from the QoE.

Clear changes in the traffic path can be seen in the illustrations below.

Before

After

Thus, the functionality of the QoE module allows to identify network bottlenecks and can be used for monitoring in order to identify and proactively deal with problem areas in a timely manner. Using API, it is possible to integrate SSG into an existing monitoring system to control the moments of connectivity degradation in the network.