Marek looked at the screen of the laptop in front of him. He was preparing to execute another cyber attack order. This time the site of an e-commerce giant in Poland was the target. The commissioner wanted the store to stop operating in the pre-Christmastime. It could have been a competitor’s representative trying to boost his own company’s performance, or a random displeased customer. It didn’t matter much – for cyber criminals it’s not the reason that matters, it’s the order.
Mark’s experience told him that the simplest attack vectors would not work. Such attacks cost several dollars an hour – if they were effective, the order would not have reached him. He also knew that the most important part of a network attack is the reconnaissance, so he started with the basics. Using a botnet, he scanned the victim’s server for shared services. It didn’t take him more than half an hour to get feedback. As expected, HTTP was the only service available. However, just because the server does not actively respond to packets, does not mean that they do not reach it. So he prepared a simple script that flooded the victim’s server with UDP packets and used a small botnet to see if there would be a change in the service’s performance.
On the other side of the cable, the operators of the network security center actively monitored the levels of network traffic directed to the customers. TAMA, which supported their operations, immediately informed them of the increase in network traffic, and they forwarded this information to the server owner. They also noticed that the attack originated from a known botnet, which consisted of worthless packets, so as agreed with the customer, they began mitigation. The whole traffic directed to the attacked service was redirected to an additional server on the operator’s side, which effectively filtered out all traffic coming from the botnet. GlaDDoS (that is the name of this additional server) was designed to separate packets of the DDoS attacks from regular Internet traffic and effectively block the attack while guaranteeing continuity of service.
Volumetric protection
To analyze what exactly happened here, it is necessary to understand the basic concepts of the Anti-DDoS service offered by EXATEL. It is a comprehensive service composed of cyber security pillars – the people (SOC teams), the technology (TAMA) and the processes (incident handling by SOC teams).
The diagram below shows the components of the TAMA system that support the handling of volumetric attacks.
Traffic analysis begins at the point of entry to the operator’s network. The PE router collects statistics on the packets flowing through it and passes them on to the Aperture.
Aperture collects incoming data in the form of time series, while grouping them on the basis of the purpose and characteristics of the packets (for example, the number of packets of predetermined sizes); detailed information is not collected, so full privacy is maintained. The data prepared by Aperture is sent simultaneously to the database and the Detector component.
The detector immediately analyzes the received information for anomalies in the amount and type of transmitted data. It knows the parameters of the protected services, so it can make conscious decisions regarding the detection (in practice it means an exact configuration of detection conditions for different services). Violations detected by the detector are recorded in the database in the form of alarms, which are immediately reported to the operators of the SOC. The detector constantly updates information about the generated alarms, informing about the change of intensity or the end of the detected attack.
The Chell component makes up the user’s interface where the SOC team and customers analyze the collected data. It prepares graphs describing changes in network traffic over time and provides additional information about its characteristics. This allows cyber security specialists to understand what is really going on in the network and quickly decide on the most appropriate mitigation mechanism.
When mitigating a volumetric attack, all network traffic is redirected to the GlaDDoS component (red line in the diagram), which carefully analyzes each packet and decides whether it is part of valid traffic or an attack. Packets classified as the attack are dropped and never reach the service. Analysis performed by GlaDDoS is very accurate (thus consuming a great deal of hardware resources), so it is conducted only for selected services at the specified time. Such a model makes it possible to effectively defend multiple services at the same time while keeping operating costs low. The GlaDDoS component is located at the entry point of the operator’s network, so that abnormal packets are removed as quickly as possible and do not increase the network load.
CE router is the entry point to the customer’s network. Thanks to GlaDDoS filtering during mitigation, only valid traffic from the service’s customers reaches it.
Interpretation
In the described example, the attacker sent a significant amount of UDP packets to an HTTP server. The detector easily identified such traffic as abnormal due to the sudden increase in volume and the use of an incorrect protocol. Detection is often configured to automatically initiate mitigation in such obvious cases.
The SOC operators were notified of the detection, along with information on whether automatic mitigation had been activated. In response to the notification, they temporarily blocked all UDP and ICMP traffic directed to the service (in agreement with the service owner), even though the attack originated from a known botnet. They made this decision based on their experience, anticipating further attack vectors. It should be noted that current technological solutions are unable to make such multidimensional decisions, which is why cybersecurity specialists are essential for effective protection.
The attacker realised that his actions were ineffective. For a moment, he considered whether to repeat the attempt with a clean botnet which IP is not yet widely known, but quickly dismissed the idea. He didn’t want to reveal himself through such hasty decisions. Instead, he decided to repeat the attempt – this time bouncing the attack off of a poorly secured DNS server. Once again, he noticed it was ineffective. Now he knew for sure – attacks with the UDP protocol will not be effective. The cyber criminal repeated his actions with the ICMP protocol and confirmed that trying to use it would be just as ineffective as using the UDP protocol.
Operators SOC who were monitoring the situation, continuously analyzed the statistics collected by TAMA. They immediately noticed the new attack vectors, but knew that GlaDDoS could easily handle it. They also effectively predicted the increase in TCP protocol packets, followed by a rash of HTTP requests. They remained calm even when the attackers tried to flood the customer’s service with packets from addresses outside known botnets – the abnormal traffic characteristics were successfully filtered out by the GlaDDoS tool. They were patiently waiting for attacks that exploit vulnerabilities in HTTP servers.
Interpretation
The mechanisms of GlaDDoS were activated here, analyzing the traffic volumes directed towards the service. Flood-type DDoS attacks are characterized by a very large number of packets that cannot be generated through normal use of the service. GlaDDoS detects cases of sudden traffic intensity increase and effectively blocks them, while allowing user packets that do not exceed the established limits to pass through. The service protection is based on mitigation configuration, which is tailored to the service parameters. The SOC teams managing the service remain in constant contact with the client, allowing for parameter adjustments based on actual data or adapting them if the nature of the service changes. The described example perfectly illustrates the importance of the collaboration between people, technology, and processes in anti-DDoS protection. An irregularity in any of these pillars can create a gateway for cybercriminals. Improper configuration of service parameters could lead to a situation where a portion of legitimate traffic is interpreted as an attack, thereby increasing its effectiveness.
Marek crossed his arms. His gaze was focused on the terminal on the screen, but he saw through it, as he was deep in thought. I knew that attacks outside of TCP won’t work, but blocking the flooding of HTTP requests – he thought – I used the botnet too quickly and just screwed it up. I have to be more careful not to reveal the other controlled addresses. I could try to scale the flooding, but if the traffic is monitored it would cost a few extra botnets. I guess now it’s best to abandon volumetrics and attack the service itself’ – he concluded.
Interpretation
Many different networks and services have their own implementation of protection against volumetric attacks, so it is natural that attackers will not only realize the existence of such protection but also its general structure. The mere existence of volumetric protection limits the possibilities of using unknown botnets because their addresses can be revealed and easily blocked in the future.
Linear protection
Service-directed attacks definitely differ from volumetric attacks. First of all, they cannot be detected through irregularities in network traffic statistics. This means that volumetric protection modules will not detect them and therefore the attack. The GlaDDoS component itself is designed to instantly separate the traffic of a volumetric attack from the correct one. The filter for such attacks must endure the processing of millions of packets per second, which would be impossible with a thorough analysis of their contents at the application layer. For this reason anti-DDoS protection offered by EXATEL, implements a separate line protection module that subjects traffic cleared of volumetric attacks to additional analysis. The following diagram shows the implementation of service protection in TAMA.
Egida is a line protection component, configured for the precised type of service. Unlike GlaDDoS, it is located at the edge of the network, on the customer’s side. Egida’s configuration was made to be fully aware of the type and implementation of the protected service, therefore it is able to protect said service from attacks that exploit its vulnerabilities. Additionally, Egida collects accurate statistics on the traffic associated with the execution of the service (full privacy is maintained, just like with the GlaDDoS). Egida is not launched selectively – it always works. An audit of the actions it has taken, along with traffic statistics, is recorded in the database.
Egida is designed for contactless operation after the initial setup. SOC only analyzes information about Egida’s decisions and traffic statistics to monitor the correctness of the component’s operation and adjust the configuration in case of changes or deviations.
Interpretation
Slow Loris attacks and TLS encryption changes will not be filtered by GlaDDoS because they constitute legitimate traffic. The violation here is not the artificial creation of large volumes but the exploitation of specific vulnerabilities in the service implementation (thread management in the case of Slow Loris and decentralized control for TLS renegotiation). In this case, the second-level protection module was activated, which operates on much smaller volumes of traffic than those handled by GlaDDoS.
Marek’s attack scenario demonstrates that two mutually complementary components are necessary for proper attack handling. GlaDDoS handles large traffic volumes and guarantees the filtering of junk packets that hold no value for the service or its clients. The filtered traffic undergoes more thorough analysis, which detects sophisticated attacks exploiting vulnerabilities in specific services.
GlaDDoS cannot provide service-level protection because it would not be able to handle large traffic volumes. Egida cannot provide protection for traffic that has not been filtered by GlaDDoS because, due to its precision, it handles significantly fewer packets. Neither of these components would function correctly without the support of specialists managing their configuration. Even the best specialist can make mistakes, which are prevented by continuously adapting processes. Today, Marek had the misfortune of encountering DDoS protection that combines all these elements, creating a DAM (Distributed Attack Mitigation) that precisely controls the flow of data.
At the same time, Marek was putting out another cigarette, watching the perfect operation of the service he was trying to destroy. He tried many different possibilities but failed to fulfill the order. I still have some options – he thought while closing the laptop. – Maybe tomorrow I try with the encrypted traffic….
