Cyberattacks come in many forms, such as secret spying on company networks, sabotage, and disruptive actions. In a disruptive action, denial of service (DoS), the attacker attempts to overload a server with requests until it stops working. This attack is easier said than done, because servers usually have more power in reserve than a single client can call up. The obvious idea is to attack the same server with many clients. The resulting attack is called a distributed denial of service (DDoS). The attacker rounds up a huge number of computers in the form of a botnet.

You are not powerless against DDoS attacks, but it is important to introduce appropriate measures up front, because during such an attack, the Internet line is flattened by the flood of client requests and the server farm no longer responds. The simplest, albeit most expensive, measure is to upgrade your infrastructure with more servers and more bandwidth. If your budget allows for this approach, you need read no further. For everyone else, this article describes various ways of efficiently protecting your infrastructure. The aim is not to provide protection against huge attacks that hit at terabit per second rates, but simply to make your servers more robust. The box "CDN" describes why CDNs and DDoS are often mentioned together.

Hardening Operating Systems

The first level of protection is provided by stricter settings on the operating system side, ranging from shorter timeouts, more restrictive firewall rules, and general recommendations for software and libraries, to specific kernel settings. Rather than standardized guidelines, numerous recommendations are offered for hardening the operating system [1].

All best practices are aimed at keeping the attack surface as small as possible. If you don't feel like typing the numerous commands for these steps by hand, you can easily use a preconfigured script [2]. However, only do this if you understand the individual lines of the script and they match your security policy. The result is a fireproofed operating system that is not so easy to mess around with.

Trust is good, control is better. Software auditors apply this principle to check local computers for insecure settings and known vulnerabilities. If you don't want to fire OpenVAS at your servers, you can use the leaner Lynis [3]. The tool runs more than 200 tests and after a few minutes presents its report in the terminal or by email. Everything that is suspicious or insecure is highlighted in red. At the end of the report, the tool provides specific recommendations for a more secure configuration.

Protection at OSI Layers 3 and 4

The major providers refer to protection Layers 3 and 4 of the Open Systems Interconnection (OSI) model for network protection, which means blocking clients by IP address and geo-blocking, which ultimately only consists of a long list of IPs. For example, the FireHOL blacklist contains all addresses that have occupied a place on a blacklist in the past [4].

Although this step will exclude the known troublemakers, the list does not take into account the individual attack situation, which is where dynamic blocking with Fail2Ban [5] comes into play (Figure 1). The tool assumes that every IP address is benevolent, but if an address appears in the logbook on several occasions from failed login attempts, it creates a block entry in iptables/nftables. The result is no communication with this address. After a short wait, the client with this address can join the game again and start its three attempts. Of course, the values and timeouts are customizable and can be increased to many hours for aggressive would-be attackers.

Figure 1: Fail2Ban remembers the IP addresses of failed login attempts and sets up a firewall block for them.

The community takes this one step further with CrowdSec [6]. The principle is similar to Fail2Ban; all participants share the list of blocked addresses. When an unknown attacker attacks its first server, this server informs the CrowdSec community and all participants block the attacker's IP address. This puts a quick end to a dictionary attack on the SSH service. Conversely, you can also quickly lock out your IP address if your tired fingers fail to type in your password correctly late at night.

Although the Fail2Ban and CrowdSec approach effectively prevents brute forcing of user-password combinations, it has two flaws. On one hand, the CPU load increases if the server receives many requests and Fail2Ban has to parse large logfiles. On the other hand, Fail2Ban can block several clients with one IP address if they share a public address – which is likely to be the case with most IPv4 Internet connections.

Setting Up Geo-Blocking

If you want to appeal to an international audience, you have to grant access to all countries on your website. The reverse is also true: If you do not have any trade relations with Asia and Africa, a geo-block can exclude almost 100 countries. An attacker in Somalia will not see an SSH prompt where they can try out password combinations.

Thanks to the geoip module and the free country IP list from MaxMind, the Linux firewall becomes a geo-filter in next to no time. The filter command contains the country code as the source instead of an IP address. For example, a block for Somalia implemented by iptables is:

iptables -A INPUT -m state --state NEW -m geoip --source-country SO -j DROP

Depending on the infrastructure or hosting offer, a firewall with a geo-function can be installed upstream of the server, which enables convenient configuration of the security policy in a web GUI. In Figure 2, the OPNsense open source firewall blocks access to individual countries by clicking on the flag symbols.

Figure 2: The free OPNsense firewall filters access by country of origin.