Distributed Denial-of-Service (DDoS) attacks on blockchain networks and how to defend against them

DDoS (Distributed Denial of Service) attacks are very common and can happen anywhere. They aim at making various network parts to stop working.. The principle involves creating a snowballing wave of queries to an on-line service to put a strain on it and until i can’t take it anymore and goes out of action. The attack may be targeting a whole infrastructure or specific services or channels in a network. The attack is committed from numerous devices at once, which are usually away from one another physically (special servers or botnets of gadgets and computers infected with malicious scripts. The infecting is typically done using malware, with the user unaware of their device’s side activities).

In the majority of cases the reason for those attacks is purely commercial (to crash the system and blackmail the owner or crash the competitor’s website to confuse and disappoint their customers). However, there might be other reasons such as political, personal revenge, hacker’s practice or even just ‘for fun’.

As a result of such an attack the targeted channel is overloaded with parasite traffic consisting of blank requests or bursts, crippling the server which has to analyze all this traffic. The system or the website becomes inaccessible or even fails. Apart from these two outcomes, DDoS attacks can also bring long-term negative effects:

• Financial loss. Users may still have to pay for the traffic while waiting for the response, even though the service is unavailable.
• Rating loss. If the service or website has been unavailable for 24 hours or more, searching bots lower its rating and it will take time to fight back to the initial position.
• Loss of trust. Customers would lose their trust in the service or website and turn to competitors even after it recovers in an attempt to escape risks.
• Incorrect service operation. It goes without saying that infrastructure elements act incorrectly being under attack. They may hand out insider information of the database, which is normally private.

Types of DDoS attacks

Types of DDoS attacks vary. They may be divided into low-level and high-level attacks.

Low-level attacks are very common. The idea is to use some parts of an infrastructure, jam channels and stuff utility datasheets. They can happen on the L3 (network level) aiming at specific protocols (such as IPv4, IPv6, ICMP, IGMP, RIP, etc.) to crash the network hardware. They can also happen on L4 (traffic level), aiming at TCP and UDP protocols to reach destination servers (for example, spuffing). High-level attacks happen on the application level and affect application protocols (such as HTTP) aiming at destination servers and services.

The most frequent attacks are:

• UPD Flood. An attacker generates innumerous data packets of a maximal allowed size (usually hiding their initial IP address pretending that the packets come from multiple addresses) and sends them to the targeted server. Quite often game and voice chat servers become targets of such attacks. The proper defense is to set up the firewall so that only addresses sending packets of a certain size are marked as ‘trusted’ (it is easily done by means of dump analysis. The easiest way is to simply turn off UPD if the user does not need it (for instance, when internal DNS servers are used).
• Fragmented UPD Flood. This type of DDoS resembles the previous with one exception. The attack does not just overload the target server with packets ‘out of hand’ but notifies it that they are only fragments, which forces the server to reserve the space for new fragments (which never appear). The defense is to set up the server to skip packages with an expected size above a certain value
• Ping Flood and Ping of Death. Ping Flood (ICMP flood) overflows the target server with ICMP Echo request packets, which an attacker sends at a high speed without waiting for response. It consumes outgoing and incoming throughput capacity which leads to the whole system slowing down.A ‘Ping of Death’ (PoD) attacker sends malicious or malformed pings, which exceed the maximum packet length. It leads to memory buffers overloading and the denial of service for legitimate packets.
• TCP SYN Flood. This attack happens on the connection stage. An attacker generates a specific SYN packet (a request for connection) to initiate a new session with the targeted server, but the connection fails and the connection base becomes overloaded which leads to a performance hit and a lack of space for legitimate connection requests. It can be prevented by putting up limitations of the SYN-packs quantity per minute.
• Slowloris. It is a sophisticated highly-targeted type of attack, which forces one server to take down another without impact on other services or ports in the network. An attacker sends false (partial) connection requests constantly but never accomplishes them. It leads to overflowing of the concurrent connection pool and, as a result, denial of connections from legitimate addresses.
• HTTP Flood. This attack is targeted at the service itself and usually affects the application layer of the OSI model. This attack consists of innumerous distributed queries, generated by an attacker, which leads to inaccessibility of the server. The main danger of this type of DDoS attack is that anyone can commit it as it does not require any special tools. Setting up better authentication and restriction of requests (only from trusted IPs) may help here.
• NTP Amplification. This attack is committed with the use of Network Time Protocol (or NTP) servers. An attacker uses these publicly accessible services to target the servers with UPD traffic. They get a list of open NTP servers and use them to generate high-volume and high-bandwidth attacks on the target server or service.

There are also so-called ‘Zero-day’ attacks, which include all the unknown new types which exploit vulnerabilities for which no patches have been developed yet.

How to defend

The best way of protection is prevention. Here are some basic methods:

• Analyzing the infrastructure. A carefully  planned and organized service is harder to crash. After making a plan and analyzing the list of used servers and services it is better to state which elements need to remain accessible (the rest should be closed and secured). All the infrastructure IPs should be checked for being compromised (because even if an attack on one element failed, the next time another element can become a target)
• Attack area minimization. First the server firewall should be better customized. Default settings aren’t good enough. Only trusted addresses and networks should be welcome. It is also a good practice to hide some of real IPs (and even change them from time to time) and start using HTTPS instead of HTTP (which protects not only from DDoS attacks but makes the server more secure in general). To distinguish legitimate queries easier, it’s better to check business logic as well. And finally, if the server contains a number of services it’s better to delimit their resource consumption (for if one of the services fails, it would not consume all resources or even damage other services).
• Correct monitoring. DDoS attacks are not always obvious and will not necessarily be detected easily. Thus, the complete monitoring of all elements (such as channels, CPU load, memory capacity, micro services, etc.) should be set up. In this case the attack can be detected on time and stopped early.

Not just one or a couple of services should be protected and secured but all of them (if one of them was under attack, but in vain, it does not mean the attacker will not simply try again with another service). Frequent audit and interim examination and maintenance are vitally important, as long as parts of code may contain vulnerabilities.