Cheap Internet and accessible cloud technologies have a downside, which is botnets. Previously, cybercriminals created them based on local servers. However, with the development of cloud technologies and IoT, the number of devices, virtual machines, and physical servers—potential elements of botnets—has grown exponentially. Experts believe that the development of serverless technologies will further simplify the creation of botnets. Here’s how we can counter this.
What technologies are used by botnet owners
Let’s start with some theory. What equipment and technologies can be used to launch attacks? Here are some basic options:
- Physical servers are the most inconvenient and expensive option for an attacker. However, when attackers target physical servers, it is enough to infect the infrastructure and force it to attack random targets in the botnet to block it at different stack levels.
- Virtual machines are botnet owners’ favorite weapon. Cloud platforms are constantly evolving to create and deliver virtual instances to clients faster. It also plays into the hands of attackers: they get quick access to a large pool of cheap resources.
- IoT devices are a frequent victim of botnet creators. These networks of devices connected to the Internet of Things (usually routers) can get infected with malware and used in attacks.
Another technology that cybercriminals can potentially use is serverless computing. It is assumed that with the development of cloud services such as Function as a Service (FaaS), the botnet owner will not need any infrastructure at all, being able to use stateless units that execute code on schedule, and then shut down. In this case, each trigger creates a new instance of the same function. Fortunately, no cases of using serverless computing for botnets apart from controlled experiments have been recorded yet.
What are the challenges for cloud providers
While malicious use of serverless technologies is still a theory, let’s consider the more traditional infrastructure—physical or virtual. In most cases, attackers infect such infrastructure using mass vulnerabilities. This is how it works: when a flaw is detected in routers of a particular brand or model, attackers scan the networks and install malware on the routers in large quantities to launch attacks from them. The same is true for physical servers and virtual machines.
Cybercriminals launch a bot on each node of the infected infrastructure. This small script automatically performs the specified function—a DDoS attack. The number of such attacks grows every year, the volume of incoming traffic increases, and, as a result, the load on the security perimeter is becoming heavier.
How should cloud providers act in these new conditions? Of course, you could simply keep increasing the capacity of filtering centers so that they absorb the increasing traffic volume. However, this will lead to new difficulties: firstly, it is expensive, and secondly, those centers will require regular maintenance, equipment replacements, and more. This is why various cloud and hosting providers willing to block malicious traffic and keep the legitimate requests try to redistribute the load as much as possible. CDN is perfect for load distribution. Here’s how it works.
How Gcore Protection works
Our purge center consists of three levels:
- DDOS protection—this level includes solutions for protection against L3/L4 volumetric attacks.
- Bot Protection is a set of algorithms for cleaning traffic that has already entered the perimeter.
- WAF is a firewall to protect web applications from hacking and access to confidential data.
- Purge center
This multi-level security system allows us to analyze all requests. If it sees that there are many requests for one URL from one IP, the session is flagged and blocked. The system automatically reacts to an excess of requests, since it keeps track of the average load on the resources and then independently determines the normal and abnormal values. Thus, it allows legitimate traffic to pass through, but blocks such volumetric attacks as UDP/ICMP flood, amplification, SYN-ACK, and RST-SYN flood at the first level of protection. The situation becomes even more interesting with another attack vector—HTTP flood.
How HTTP flood protection works
The second level of the purge center—Bot Protection—is responsible for protection from HTTP flood. With these types of attacks, we need to be more careful so as not to block suspicious IP addresses without additional checking, since behind them, behind NAT, there are both legitimate visitors and users whose computers are infected.
To prevent this from happening, we use multi-stage analytics:
1. Behavioral analysis. Checking the number and frequency of requests.
2. JS Challenge/Captcha. Before deciding that we are dealing with a bot, we send a request for verification using JS Challenge/Captcha.
The first method—JS Challenge—involves sending a jаvascript code to the client with a particular task. If a user is legitimate and, unlike a typical bot, uses a browser with jаvascript support, they will pass the test without even noticing it—they will not have to mark traffic lights and bicycles.
The second method—JS Captcha—is less intelligent, but more reliable. After completing the challenge, the client is temporarily included in the list of verified IPs. Among other things, during the test, we learn information that is useful for bot protection, and which we use in the future (for example, the browser version).
3. HTTP headers analysis. Comparing headers and JS Challenge results.
4. TLS session analysis using JA3 hash. JA3 hash is an efficient way to analyze a session. Each hash consists of several values that allow the client to be determined. Since it is created using a special hash function based on the information received within the TLS Hello package, each browser version and each client can be identified by comparing the received hash with the one that is stored in the filtering center database.
When the filtering center detects a hash inside TLS Hello that is not in the database or that is obviously illegitimate—for example, a JA3 hash is received from curl saying ‘Internet Explorer’ in the User Agent—the center blocks it or launches a check.
All these stages of testing clearly demonstrate how the bot protection works at a high level. But what happens inside, at a lower level?
How eBPF blocks attacks at L3—L4
In the event of serious attacks, integration with eBPF is activated, which blocks attacks on L3—L4. Thus, we also reduce the risk of overloading the filtering center.
The combined use of low-level analysis technologies together with algorithmic methods from the top reduces the likelihood of legitimate traffic being blocked even when both malicious and legitimate traffic comes from the same IP address. Our False Positive Rate is less than 0.01%.
Why did we decide to use eBPF? Because it is a monolith built into the kernel—compared to the one used before (dpdk), some issues can be solved more easily, and sometimes they can be completely eliminated. For example, unlike dpdk, eBPF can be used on one network interface together with another role. Therefore, in the future, we plan to use it more actively on CDN nodes that run on powerful 3rd Generation Intel® Xeon® Scalable processors. Gcore has a large content delivery network—its total capacity is about 100 TB of traffic per second, but at the same time, the duplex channel is used for 85% of outgoing traffic (customers receiving content), while the incoming channel is underutilized. Thanks to the integration of CDN and eBPF, we plan to connect these capacities to traffic cleaning, staying as close to the client as possible.
Enable protection against bots and other types of attacks
Gcore users have comprehensive protection: both from general attacks, such as volumetric DDoS, and from attacks that can be masked or mixed with legitimate traffic. All this, together with the ability to integrate with WAF, allows clients to mitigate the consequences of attacks performed at the stack’s network, transport, and application layers.
