Attack on Memory –
Consumers Out of Queue

As the result of an attack on the memory, the server becomes unavailable and hackers try to fill all the RAM, hard disk or critical memory spaces. 

To provide a direct analogy, consider a salesman who has a long queue in front of him. That salesman is overloaded, because too many people are trying to get to the cashier and buy something in the shop. But this is made even more difficult if somebody tries to skip the queue and buy their goods without waiting, thus providing extra load to a cashier. If this happens, the cashier will have a difficult time addressing those standing in the queue. With the cashier (memory in our case) overloaded, none of the legitimate buyers waiting in the queue will be able to check out. Thus, using the analogy, legitimate users would be unable to get to the website. 

A TCP SYN flood is a classic attack of this kind. It exhausts the connectivity limit to the server by creating a set of half-open connections. A similar TCP FIN flood attack creates a range of half-closed connections.

A bit different are "slow" attacks on HTTP protocol functions; the Web server, Apache, is most susceptible to these types of attacks. Thus, criminals connect to the server and start sending or receiving data very slowly. As a result, the server’s memory is overloaded because of the huge amount of generated protocols.

The best way to defend against this kind of attack is to ensure the correct setting on the server where the information about the new connection will not be stored in the server's memory, but rather in a so-called server response that will be received by the connection initiator.

Upon receiving the response from the client, the server checks the presence of this information in the package. Such technology is called syncookies. Vulnerability in TCP FIN flood is “treated” by manufacturer updates of software.

To protect against the "slow" attacks, you need to clearly define the minimum and maximum period of time during which sending the request or acceptance of an answer is available. If the customer exceeds the limit, the connection is dropped. There are special modules to set up such protection. For example, “mod_reqtimeout” allows you to control the number of slow queries through a directive RequestReadTimeout. If you are using Apache without Proxying, then switching to MPM Event regime will be a very good solution. But it can only run PHP in CGI / FastCGI mode, which is not always acceptable.

Foolproof – or as Foolproof as Possible

In addition to the special types of protection against DoS attacks, there are few rules, which help to protect sites from standard attacks.

Administrators need to start with the correct settings and software updates. This touches not only on server operating systems but also web applications software. These simple steps will allow the server to withstand attacks that use well-known vulnerabilities.

Also, you can create a distributed architecture for the application.With that approach, resource capacity grows horizontally. In this case, the attacker has no concrete goal, because the application is located "everywhere and nowhere" at the same time. In the event of the machines fails, a second one will come into operation. The attacker will need a lot more resources for a successful attack than in case of a single server.

Despite all the advanced methods of protection against hackers, unfortunately, attack technologies have historically been one step ahead of those who develop protection against the vulnerabilities. Therefore, owners of web applications need to be on alert because of the constant emergence of new threats.