a reliable protection against DDoS attacks


The other day something extraordinary happened which gave me reason to think more precisely about the issue of DDoS attacks:


I participated in an IT jourfixe meeting where the security infrastructure of a successful startup was analyzed. A rather unusual subject, since this startup operates in a business area which is less prone to DDoS attacks. The question if the IT department is prepared against IT attacks came up. A number of attack scenarios were weighed. XSS and SQL Injection were double checked but the matter of DDoS was not addressed.  So I questioned the topic.. The responsible employee answered short and subtle that one just had to stock up the data center if some kind of DDoS attack happens. It should not be forgotten that this jourfixe meeting concerned a free service provider who earns its surplus due to performance-based commissions. So this startup was not a financial service or product service provider -  which are the preferred targets of DDoS attacks. Is it therefore always proportionate or rather appropriate  to supplement the entire technical infrastructure?


Let's just go back to step and clarify the necessary frame conditions:

What is a DDoS Attack?

A Distributed Denial-of-Service Attack is an attempt to make a server or network resource unavailable to its intended users (mostly). This includes the efforts to temporarily or indefinitely interrupt services of a host server.

Why would anyone want to reach disable a service?

Such an attack can have multiple intentions:

  • Firstly it can harm a competitor.. For example if Amazon would be a day or more offline, that would imply the loss of profits in millions. But also the damage to their reputation would be considerable.

  • A different intention can be by extorting businesses from the said reasons (equivalent to the ambition of data-kidnapping by using trojaner). The BKA estimates the amount of corresponding “business” volume in the millions.

This chart shows the increasing amount of trojaner which are used in order to blackmail companies for ransom.


How does a DDoS work?

There are countless methods how to establish a DDoS attack. A famous example is the “ping of death” method. By sending big packets (>65 kbytes), the target is overwhelmed by the size of the files and crashes. The most widely used form of attack is the Low Orbit Ion Cannon (LOIC). The LOIC floods the target server with TCP or UDP packets. Furthermore it is often used in “manual botnets”. For more details one individual attack methods you may check out the omniscient wikipedia


What about the legal part?

The topic of DDoS or rather IT attacks in the legal sciences is pretty new. The German case law has just a few right-looking legal paragraphs. Law experts evaluated an DDoS attack as a kind of computer sabotage which includes up to 3 years imprisoned after § 303b Abs. 1 StGB or a fine. The so called “hackerparagraph” as part of § 202c StGB defines the creation, usage or distribution of every kind of software - which could be used for improper or dishonest intention - as a federal crime. The LOIC would be such a software.

An interesting fact is, that the reseller is subject to the contract risk  - which means - in case of a DDoS the reseller has to pay for possible unavailability of infrastructure (due to case law of the district court Gelnhausen, Germany).


In Addition, the United Kingdom defines DDoS attacks in its  Police and Justice Act 2006,as specifically outlawed with a maximum penalty of 10 years in prison.

The US also consider DDoS attacks as a federal crime under the Computer Fraud and Abuse Act .


So, how can we prevent this kind of attacks?

Prevention is in most cases the best method, but it is not always possible or necessary. There are 3 counter opportunities:

  1. Software Settings”, like limiting the amount of possible accesses to every single IP address mapped to the corresponding server or decreasing the priority of every request send by the same dynamic IP (recognizable by dissolving the rDNS entry).

  2. Infrastructural Design Patterns”: using “smart” infrastructures. it is not necessary to use the biggest and most badass server to handle the entire incoming traffic. Think smart and have an eye on scalability. A well designed and scalable infrastructure is the best way to handle DDoS. There are different design patterns which solves such “traffic overheads” like the following design pattern:


    In this case there is a bigger cluster performing the task of a inverse multiplexer. All incoming traffic is randomly or ordered splitted and handed over to a different slave server which processes the package.



On the way back, the corresponding answer packet is handed back the same way it came. This process makes the infrastructure just flexible and scalable. If more resources are needed, you only have to clone a “cheap” server. only the first component which simulates the multiplexer as kind of proxy has to be powerful (e.g. dual 10 Gbit/s depending on the needs).

Actually there are two option how to solve outgoing traffic. The first one is to let each server response with its own ip. This technique decreases the risk of system failure but also increases the efficiency of DDoS attacks, because a potential attacker may collect the slave server ips in order to attack them directly. The second technique is to reroute the traffic over a proxy. This could be the same server cluster which handles the incoming traffic or a separate on which specializes on the outgoing traffic. The advantages and disadvantages would be opposite to the first option.


3. “Smart Handling of Traffic Packages”: This involves the analysis of the incoming packets in order to discard unwanted, unimportant or redundant packets. A so called smart system, which is based on the predictives behavioral pattern recognition on which we are currently researching.

The predictive behavioral pattern recognition helps us to understand the intention of the client which is sending the packet, however it presupposes the possibility to read and analysis incoming messages.


In Addition, there is the option to use Round Robin for DNS. This technique is used for load balancing which already differs from the requirements for higher availability. One may use multiple DNS A Records (for IPv6 AAA Records) equivalent to the MX setup. At the moment the first destination of the DNS entry is unreachable, the host will try to connect the second one. And then the third, fourth and so one. The "Resource Record Set" method neglects the weight of the items. Accordingly, the DNS server returns all the records on request, however, this order changes during every query. Bind-level name servers support three types: cyclical, random and fixed. In more modern resource record types like SRV or NAPTR one is able to define a weight that determines which server IP addresses most commonly come first. Therefore the relevant servers are addressed more often. This concept could also be expand in order to make a DDoS more complicated. If the list of possible destination server is long enough, the first will be back online when the last entry is under attack.

And if all named approaches are not sufficient, there is still a last resort option to throw more hardware against the attacker. Loadmasters like the LM-5300 Server Load Balancer are able to handle up to 8.8 Gbps with 9,300 SSL Transactions Per/Second (TPS), 110,000 HTTP Requests per second or 400,000 L7 concurrent connections. Each of them.


There also have been companies dedicated to the protection against DDoS attacks like CloudFlare, but we should always preserve the aspect of proportionality and economy in mind. In addition, this kind of service increases the danger of man-in-the-middle attacks which could be much more harmful in terms of long-term vision. Even CloudFare struggles with NTP-Reflection Attacks which easily generated 400 Gigabit/s.


Does it make sense to extract the heavy guns as in the initial example? Or isn't it smarter to go back to the smaller dedicated methods in order the solve our DDoS problem? That should everyone decide for themselves.


Jani Podlesny

Head of Engineering

I am focusing on Data Architecture and Analytics for Management Consulting across EMEA and the US. For my passion in Data Profiling & Privacy I am doing a PhD research at the Hasso- Plattner- Institute. 

Berlin Lab

Berlin, Germany
  032 229 340 927
  This email address is being protected from spambots. You need JavaScript enabled to view it.

Wuerzburg Lab

Würzburg, Germany
  032 229 340 927
  This email address is being protected from spambots. You need JavaScript enabled to view it.