How botnet attacks work and how to defend against them

There is one downside to cheap internet and accessible cloud technologies, which is botnets. Previously, cyber criminals 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 counteract it.

What technologies are used by botnet owners?

Let’s start with some theory. What gear and technology 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 them to attack random targets in the botnet to block them at different stack levels.
• virtual machines are the favorite weapon of botnet owners. Cloud platforms are constantly evolving to create and deploy virtual instances to customers faster. It also plays into the hands of attackers: they gain quick access to a large pool of cheap resources.
• IoT devices are a common victim of botnet creators. These networks of devices (usually routers) connected to the Internet of Things can be infected with malware and used for attacks.

Another technology that cybercriminals may be able to exploit is serverless computing. It is believed that with the development of cloud services such as Function as a Service (FaaS), the botnet owner will not need any infrastructure at all and can use stateless entities that run 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 have yet been reported, apart from controlled experiments.

What are the challenges for cloud providers?

While malicious use of serverless technologies is still a theory, let’s look at more traditional infrastructure – physical or virtual. In most cases, attackers infect such infrastructures using mass vulnerabilities. How it works: When a bug is found in a particular brand or model of router, attackers scan the networks and install bulk malware on the routers to launch attacks from them. The same applies to physical servers and virtual machines.

Cyber ​​criminals 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 is growing every year, the volume of incoming traffic is increasing and, as a result, the load on the security perimeter is increasing.

How should cloud providers behave under these new conditions? Of course, the capacity of the filter centers could simply be increased further and further so that they can absorb the increasing volume of traffic. However, this will lead to new difficulties: firstly, it is expensive, and secondly, these centers need regular maintenance, equipment replacement and more. Because of this, 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 balancing. That’s how it works.

How Gcore protection works

Gcore’s Protection Purge Center consists of three levels:

1. DDOS protection– This layer includes solutions to protect against volumetric L3/L4 attacks.
2. Bot protection is a set of algorithms for cleaning traffic that has already entered the perimeter.
3. WAF is a firewall to protect web applications from hackers and access to confidential data.

This multi-level security system allows us to analyze all requests. If it sees that there are many requests for a URL from an IP, the session is flagged and blocked. The system reacts automatically to an excess of inquiries, as it tracks the average utilization of resources and then independently determines the normal and abnormal values. Thus, it lets legitimate traffic through but blocks volumetric attacks like UDP/ICMP flood, amplification, SYN-ACK and RST-SYN flood at the first layer of protection. The situation becomes even more interesting with another attack vector – the HTTP flood.

How HTTP Flood Protection works

The second tier of the cleanup center – Bot Protection – is responsible for protecting against HTTP flood. In this type of attack, we must be more careful not to block suspicious IP addresses without additional verification, since behind them, behind NAT, there are both legitimate visitors and users whose computers are infected.

To prevent this, we use multi-level analytics:

1. behavior analysis. Checking the number and frequency of requests.
2. JS Challenge/Captcha. Before deciding it’s a bot, we send a verification request using JS Challenge/Captcha.

The first method – JS Challenge – involves sending a JavaScript code to the client with a specific task. If a user is legitimate and, unlike a typical bot, is using a browser with JavaScript support, they pass the test without even realizing it – they don’t have to tag traffic lights and bikes.

The second method – JS Captcha – is less intelligent but more reliable. After completing the challenge, the client is temporarily added to the list of verified IPs. During the test, we learn, among other things, information that is useful for bot protection and that we will use in the future (e.g. browser version).

3. HTTP header analysis. Comparison of headers and JS Challenge results.
4. TLS session analysis with JA3 hash. JA3 hash is an efficient way to analyze a session. Each hash consists of several values ​​that enable the tenant to be determined. Since it is created using a special hash function based on the information received in the TLS Hello packet, any browser version and client can be identified by comparing the received hash with that stored in the filtering center’s database.

If the filter center detects a hash within TLS Hello that isn’t in the database or that is obviously illegitimate – for example, a JA3 hash is received from curl labeled “Internet Explorer” in the user agent – the center blocks it or starts an exam.

All these test phases clearly show how the bot protection works at a high level. But what is happening inside, on a lower level?

How eBPF blocks attacks on L3—L4

On heavy attacks, integration with eBPF is activated, blocking attacks on L3—L4. This also reduces the risk of overloading the filter center.

The combined use of low-level analytics technologies along with algorithmic methods from above reduces the chances of legitimate traffic being blocked, even when both malicious and legitimate traffic originate from the same IP address. Our false positive rate is less than 0.01%.

Why did we choose eBPF? Since it is a kernel built-in monolith – compared to the one used previously (dpdk), some issues can be solved more easily and sometimes even eliminated entirely. For example, unlike dpdk, eBPF can be used on a network interface along with another role. Therefore, in the future we plan to use it more actively on CDN nodes running 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 the outbound traffic (customers receiving content), while the inbound channel is underutilized. Thanks to the integration of CDN and eBPF, we plan to combine these capacities with traffic cleaning while staying as close as possible to the customer.

Enable protection against bots and other types of attacks

Gcore users are fully protected: from both general attacks like volumetric DDoS and attacks that can be masked or mixed with legitimate traffic. All of this, along with the ability to integrate with WAF, allows clients to mitigate the consequences of attacks that run at the network, transport, and application layers of the stack.

Sponsored by Gcore