What is a ddos attack. DDoS attack: what it is, how it works and whether it is possible to protect yourself

On a computing system in order to bring it to failure, that is, the creation of such conditions under which legal (lawful) users of the system cannot access the resources (servers) provided by the system, or this access is difficult. The failure of the “enemy” system can also be a step towards mastering the system (if in an emergency the software gives out any critical information - for example, version, part of the program code, etc.). But more often it is a measure of economic pressure: downtime of a revenue-generating service, bills from the provider, and measures to avoid an attack significantly hit the “target” in the pocket.

If an attack is carried out simultaneously from a large number of computers, one speaks of DDoS attack(from English. Distributed Denial of Service, distributed denial of service attack). In some cases, an unintended action leads to an actual DDoS attack, for example, placing a link on a popular Internet resource to a site hosted on a not very productive server (slash dot effect). A large influx of users leads to exceeding the allowable load on the server and, consequently, a denial of service for some of them.

Types of DoS attacks

There are various reasons why a DoS condition may occur:

Error in program code, resulting in access to an unused fragment of the address space, execution of an invalid instruction, or other unhandled exception when the server program crashes - the server program. A classic example is zero-based referencing. null) address.
Insufficient validation of user data, leading to an infinite or long cycle or increased long-term consumption of processor resources (up to the exhaustion of processor resources) or the allocation of a large amount random access memory(up to the exhaustion of available memory).
flood(English) flood- "flood", "overflow") - an attack associated with a large number of usually meaningless or incorrectly formatted requests to a computer system or network equipment, which has as its goal or led to a system failure due to the exhaustion of system resources - the processor, memory or communication channels.
Attack of the second kind- an attack that seeks to cause a false alarm of the protection system and thus lead to the unavailability of the resource.

If an attack (usually a flood) is carried out simultaneously from a large number of IP addresses - from several computers dispersed in the network - then in this case it is called distributed denial of service attack ( DDoS).

Exploitation of bugs

Exploit name a program, a piece of program code, or a sequence of program commands that exploits vulnerabilities in software and used to attack a cyber system. Of the exploits that lead to a DoS attack, but are unsuitable, for example, to seize control of an "enemy" system, the most famous are WinNuke and Ping of death (Ping of death).

flood

For flooding as a violation of netiquette, see flooding.

flood they call a huge stream of meaningless requests from different computers in order to take the "enemy" system (processor, RAM or communication channel) with work and thereby temporarily disable it. The concept of “DDoS attack” is almost equivalent to the concept of “flood”, and in everyday life both of them are often interchangeable (“flood the server” = “DDoS’it the server”).

To create a flood, both ordinary network utilities like ping (this is known, for example, the Internet community " Upyachka"), and special programs can be used. The possibility of DDoS is often "sewn up" in botnets. If a cross-site scripting vulnerability or the ability to include images from other resources is found on a site with high traffic, this site can also be used for a DDoS attack.

Communication channel and TCP subsystem flood

Any computer that communicates with the outside world via the TCP / IP protocol is subject to these types of floods:

SYN flood - with this type of flood attack, a large number of SYN packets are sent to the attacked node via the TCP protocol (requests to open a connection). At the same time, after a short time, the number of sockets available for opening (software network sockets, ports) is exhausted on the attacked computer, and the server stops responding.
UDP flood - this type of flood does not attack the target computer, but its communication channel. Providers reasonably assume that UDP packets should be delivered first, while TCP can wait. A large number of UDP packets of different sizes clog the communication channel, and the server running over the TCP protocol stops responding.
ICMP flood - the same thing, but with the help of ICMP packets.

Application layer flood

Many services are designed in such a way that a small request can cause a large consumption of computing power on the server. In this case, it is not the communication channel or the TCP subsystem that is attacked, but the service (service) itself - a flood of such "sick" requests. For example, web servers are vulnerable to HTTP flooding - either a simple GET / or a complex database query like GET /index.php?search= can be used to disable a web server<случайная строка> .

DoS attack detection

There is an opinion that special tools for detecting DoS attacks are not required, since the fact of a DoS attack cannot be overlooked. In many cases this is true. However, successful DoS attacks were observed quite often, which were noticed by the victims only after 2-3 days. It happened that the negative consequences of an attack ( flood-attacks) resulted in excessive costs for paying for excess Internet traffic, which was found out only when receiving an invoice from an Internet provider. In addition, many intrusion detection methods are ineffective near the target of attack, but are effective on network backbones. In this case, it is advisable to install detection systems exactly there, and not wait until the user who has been attacked notices it himself and seeks help. In addition, in order to effectively counteract DoS attacks, it is necessary to know the type, nature, and other characteristics of DoS attacks, and detection systems make it possible to quickly obtain this information.

DoS attack detection methods can be divided into several large groups:

signature - based on a qualitative analysis of traffic.
statistical - based on a quantitative analysis of traffic.
hybrid (combined) - combining the advantages of both of the above methods.

DoS protection

Measures to counter DoS attacks can be divided into passive and active, as well as preventive and reactive.

Below is a brief list of the main methods.

Prevention. Prevention of the reasons that prompt certain individuals to organize and undertake DoS attacks. (Very often, cyberattacks in general are the result of personal grievances, political, religious and other disagreements, provocative behavior of the victim, etc.)
Filtering and blackholing. Blocking traffic from attacking machines. The effectiveness of these methods decreases as you get closer to the object of attack and increases as you get closer to the attacking machine.
Reverse DDOS- redirecting the traffic used for the attack to the attacker.
Elimination of vulnerabilities. Doesn't work against flood-attacks for which "vulnerability" is the finiteness of certain system resources.
Increasing resources. Naturally, it does not provide absolute protection, but it is a good background for applying other types of protection against DoS attacks.
Dispersal. Building distributed and duplicating systems that will not stop serving users, even if some of their elements become unavailable due to a DoS attack.
Evasion. Moving the immediate target of the attack (domain name or IP address) away from other resources that are often also affected along with the immediate target of the attack.
Active response. Impact on the sources, the organizer or the control center of the attack, both by man-made and organizational and legal means.
Using equipment to repel DoS attacks. For example DefensePro® (Radware), Perimeter (MFI Soft), Arbor Peakflow® and other manufacturers.
Acquisition of a service to protect against DoS attacks. Actual in case of exceeding the bandwidth of the network channel by the flood.

Notes

Literature

Chris Kaspersky Computer viruses inside and out. - Peter. - St. Petersburg. : Peter, 2006. - S. 527. - ISBN 5-469-00982-3
Stephen Northcutt, Mark Cooper, Matt Fearnow, Karen Frederik. Analysis of typical security breaches in networks = Intrusion Signatures and Analysis. - New Riders Publishing (English) St. Petersburg: Williams Publishing House (Russian), 2001. - P. 464. - ISBN 5-8459-0225-8 (Russian), 0-7357-1063-5 ( English)
Morris, R.T.= A Weakness in the 4.2BSD Unix TCP/IP Software. - Computing Science Technical Report No.117. - AT&T Bell Laboratories, Feb 1985.
Bellovin, S.M.= Security Problems in the TCP/IP protocol Suite. - Computer Communication Review, Vol. 19, No.2. - AT&T Bell Laboratories, April 1989.
= daemon9 / route / infinity "IP-spooling Demystified: Trust Realationship Exploitation". - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.
= daemon9 / route / infinity "Project Neptune". - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.

Links

DoS attack in the Open Directory Project Link Directory (

Increasingly, in the official messages of hosting providers, here and there, mentions of reflected DDoS attacks flicker. Increasingly, users, having discovered the unavailability of their site, immediately assume DDoS. Indeed, at the beginning of March, the Runet experienced a whole wave of such attacks. At the same time, experts assure that the fun is just beginning. It is simply impossible to ignore a phenomenon so relevant, formidable and intriguing. So today let's talk about the myths and facts about DDoS. From the point of view of the hosting provider, of course.

memorial day

On November 20, 2013, for the first time in the 8-year history of our company, the entire technical site was unavailable for several hours due to an unprecedented DDoS attack. Tens of thousands of our customers throughout Russia and the CIS have suffered, not to mention ourselves and our Internet provider. The last thing the provider managed to fix before the white light faded for everyone was that its input channels were tightly clogged with incoming traffic. To visualize this, imagine your bathtub with an ordinary sink, into which Niagara Falls rushed.

Even upstream providers have felt the echoes of this tsunami. The graphs below clearly illustrate what happened that day with Internet traffic in St. Petersburg and in Russia. Pay attention to the steep peaks at 15:00 and 18:00, just when we recorded the attacks. On these sudden plus 500-700 GB.

It took several hours to localize the attack. The server to which it was sent was calculated. Then the purpose of Internet terrorists was calculated. Do you know who all this enemy artillery hit? One very ordinary, modest client site each.

Myth number one: “The object of attack is always the hosting provider. These are the machinations of his competitors. Not mine." In fact, the most likely target for Internet terrorists is a regular client site. That is, the site of one of your hosting neighbors. And maybe yours too.

Not all DDoS...

After the events on our technical site on November 20, 2013 and their partial repetition on January 9, 2014, some users began to assume DDoS in any particular failure of their own site: “This is DDoS!” and “Are you having DDoS again?”

It is important to remember that if we suffer such a DDoS that even customers feel it, we immediately report it ourselves.

We want to reassure those who are in a hurry to panic: if something is wrong with your site, then the probability that this is DDoS is less than 1%. Simply due to the fact that a lot of things can happen to the site and this “lot of things” happens much more often. We will talk about methods of self-quick diagnostics of what exactly is happening with your site in one of the following posts.

In the meantime - for the sake of accuracy of word usage - let's clarify the terms.

About terms

DoS attack (from English Denial of Service) - this is an attack designed to cause a server to be denied service due to its overload.

DoS attacks are not related to equipment damage or information theft; their goal - make the server stop responding. The fundamental difference between DoS is that the attack occurs from one machine to another. There are exactly two participants.

But in reality, we practically do not observe DoS attacks. Why? Because the objects of attacks are most often industrial objects (for example, powerful productive servers of hosting companies). And in order to cause any noticeable harm to the operation of such a machine, much more power is needed than its own. This is first. And secondly, the initiator of a DoS attack is quite easy to calculate.

DDoS - essentially the same as DoS, only the attack is distributed nature. Not five, not ten, not twenty, but hundreds and thousands of computers access one server simultaneously from different places. Such an army of machines is called botnet. It is almost impossible to calculate the customer and the organizer.

accomplices

What kind of computers are included in the botnet?

You will be surprised, but often these are the most ordinary home machines. Who knows?.. - quite possibly your home computer drawn to the side of evil.

It takes a little for this. An attacker finds a vulnerability in a popular operating system or application and uses it to infect your computer with a Trojan that, on a certain day and hour, instructs your computer to start performing certain actions. For example, send requests to a specific IP. Without your knowledge and participation, of course.

Myth number two: « DDoS is being done somewhere far away from me, in a special underground bunker where bearded hackers with red eyes sit. In fact, without knowing it, you, your friends and neighbors - anyone can be an unwitting accomplice.

This is really happening. Even if you don't think about it. Even if you are terribly far from IT (especially if you are far from IT!).

Entertaining hacking or DDoS mechanics

The DDoS phenomenon is heterogeneous. This concept combines many options for actions that lead to one result (denial of service). Consider the options for the troubles that DDoSers can bring us.

Overconsumption of server computing resources

This is done by sending packets to a specific IP, the processing of which requires a large amount of resources. For example, to load a page, you need to execute a large number of SQL queries. All attackers will request this particular page, which will cause a server overload and a denial of service for normal, legitimate site visitors.
This is an attack of the level of a schoolboy who has devoted a couple of evenings to reading the Hacker magazine. She is not a problem. The same requested URL is calculated instantly, after which access to it is blocked at the web server level. And this is just one of the solutions.

Overload of communication channels to the server (to the exit)

The difficulty level of this attack is about the same as the previous one. The attacker calculates the heaviest page on the site, and the botnet under his control begins to request it en masse.

Imagine that the part of Winnie the Pooh invisible to us is infinitely large
In this case, it is also very easy to understand what exactly is clogging the outgoing channel, and prohibit access to this page. Requests of the same type are easy to see with the help of special utilities that allow you to look at the network interface and analyze traffic. Then a rule is written for the Firewall, which blocks such requests. All this is done regularly, automatically and so lightning fast that most users are not even aware of any attack.

Myth number three: "A However, they rarely visit my hosting often, and I always notice them.” In fact, 99.9% of attacks you don't see or feel. But the daily struggle with them - this is the everyday, routine work of a hosting company. This is our reality, in which the attack is cheap, the competition is off the charts, and not everyone demonstrates legibility in the methods of fighting for a place in the sun.

Overload of communication channels to the server (at the entrance)

This is already a puzzle for those who have been reading the Hacker magazine for more than one day.

Photo from the website of the radio "Echo of Moscow". They did not find anything more illustrative to represent DDoS with channel overload at the entrance.
To fill the channel with incoming traffic to capacity, you need to have a botnet, the power of which allows you to generate the required amount of traffic. But maybe there is a way to give away little traffic and get a lot?

There is, and not one. There are many options for enhancing the attack, but one of the most popular right now is attack through public DNS servers. Experts call this method of amplification DNS amplification(in case someone prefers expert terms). And if it's simpler, then imagine an avalanche: a small effort is enough to disrupt it, and inhuman resources to stop it.

You and I know that public DNS server on request, informs anyone who wants data about any domain name. For example, we ask such a server: tell me about the sprinthost.ru domain. And he, without hesitation, throws out everything he knows to us.

Querying a DNS server is a very simple operation. It costs almost nothing to contact him, the request will be microscopic. For example, like this:

It remains only to choose a domain name, information about which will be an impressive data package. So the original 35 bytes with a slight movement of the hand turn into almost 3700. There is an increase of more than 10 times.

But how to make sure that the response is directed to the correct IP? How to forge the source IP of the request so that the DNS server issues its answers in the direction of the victim, who did not request any data?

The fact is that DNS servers work on UDP communication protocol, which doesn't need confirmation of the origin of the request at all. Forging an outgoing IP in this case is not a big deal for a doser. That's why this type of attack is so popular right now.

Most importantly, a very small botnet is enough to implement such an attack. And several disparate public DNS, which will not see anything strange in the fact that different users from time to time request data from the address of one host. And only then all this traffic will merge into one stream and nail one “pipe” tightly.

What the doser cannot know is the capacity of the attacker's channels. And if he does not calculate the power of his attack correctly and does not immediately block the channel to the server by 100%, the attack can be quickly and easily repelled. Using utilities like TCPdump it is easy to find out that incoming traffic comes from DNS, and at the Firewall level to prohibit it from being accepted. This option - refusing to accept traffic from DNS - is associated with a certain inconvenience for everyone, however, both the servers and the sites on them will continue to work successfully.

This is just one of many options to enhance the attack. There are many other types of attacks, we can talk about them another time. In the meantime, I would like to summarize that all of the above is true for an attack whose power does not exceed the width of the channel to the server.

If the attack is strong

If the attack power exceeds the capacity of the channel to the server, the following happens. The Internet channel is instantly clogged to the server, then to the hosting site, to its Internet provider, to the upstream provider, and so on and up in ascending order (in the future - to the most absurd limits), as far as the attack power is enough.

And then it becomes a global problem for everyone. And in short, this is what we had to deal with on November 20, 2013. And when large-scale upheavals occur, it's time to turn on special magic!

This is what special magic looks like. With the help of this magic, it is possible to calculate the server to which the traffic is directed and block its IP at the ISP level. So that it stops accepting any calls to this IP through its communication channels with the outside world (uplinks). To lovers of terms: experts call this procedure "black out", from English blackhole.

At the same time, the attacked server with 500-1500 accounts remains without its IP. A new subnet of IP addresses is allocated for it, over which client accounts are randomly distributed evenly. Further, experts are waiting for a repetition of the attack. It almost always repeats itself.

And when it repeats, there are no longer 500-1000 accounts on the attacked IP, but some dozen or two.

The circle of suspects is narrowing. These 10-20 accounts are again distributed to different IP addresses. Once again, the engineers lie in wait for another attack. Again and again they spread the accounts remaining under suspicion to different IPs and so, by gradual approximation, they calculate the object of attack. All other accounts at this point return to normal operation on the same IP.

As you know, this is not an instant procedure, it takes time to implement.

Myth number four:“When a massive attack happens, my hoster doesn’t have a plan of action. He just waits with his eyes closed for the end of the bombardment and answers my letters with the same type of replies.This is not the case: in the event of an attack, the hosting provider acts according to a plan in order to localize it and eliminate the consequences as soon as possible. And the same type of letters allow you to convey the essence of what is happening and at the same time save the resources necessary for the fastest possible processing of an emergency situation..

Is there light at the end of the tunnel?

Now we see that DDoS activity is constantly increasing. To order an attack has become very accessible and ugly inexpensive. To avoid accusations of propaganda, there will be no prooflinks. But take our word for it, it is.

Myth number five: “A DDoS attack is a very expensive event, and only business bigwigs can afford to order one. As a last resort, these are the machinations of the secret services!” In fact, such events have become extremely accessible.

Therefore, it is not necessary to expect that malicious activity will disappear by itself. Rather, it will only intensify. It remains only to forge and sharpen weapons. What we are doing, improving the network infrastructure.

The legal side of the issue

This is a very unpopular aspect of discussing DDoS attacks, as we rarely hear about cases of capture and punishment of the instigators. However, remember: A DDoS attack is a criminal offense. In most countries of the world, including Russia.

Myth number six: « Now I know enough about DDoS, I'll order a holiday for a competitor - And I won't get anything for it!" It is not excluded that it will. And if it does, it won't seem like much.

The plot of history with DDoS payment system Assist
Exciting denouement

In general, we do not advise anyone to engage in the vicious practice of DDoS, so as not to incur the wrath of justice and not bend their own karma. And we, due to the specifics of our activity and a lively research interest, continue to study the problem, stand guard and improve defensive structures.

PS:we do not have enough kind words to express all our gratitude, so we just say"Thank you!" to our patient customers who have warmly supported us on a difficult day on November 20, 2013. You have said many words of encouragement in support of our

Fighting DDoS attacks is not only difficult, but also exciting work. It is not surprising that every system administrator first of all tries to organize defense on his own - especially since this is still possible.

We decided to help you in this difficult task and publish some short, trivial and non-universal tips for protecting your site from attacks. These recipes will not help you deal with any attack, but they will save you from most dangers.

The Right Ingredients

The harsh truth is that many sites can be taken down by anyone using the Slowloris attack, which kills Apache tightly, or by arranging a so-called SYN flood using a farm of virtual servers raised in a minute in the Amazon EC2 cloud. All of our further tips for protecting yourself from DDoS on your own are based on the following important conditions.

1. Get rid of Windows Server

Practice suggests that a site that runs on Windows (2003 or 2008 - it doesn't matter) is doomed in the event of DDoS. The reason for the failure lies in the Windows network stack: when there are a lot of connections, the server will certainly begin to respond poorly. We don't know why Windows Server performs so badly in such situations, but we've come across this more than once or twice. For this reason, this article will focus on the means of protection against DDoS attacks in the case when the server is running on Linux. If you are a happy owner of a relatively modern kernel (starting from 2.6), then the primary tools will be the iptables and ipset utilities (for quickly adding IP addresses), with which you can quickly ban bots. Another key to success is a well-prepared network stack, which we will also talk about next.

2. Part ways with Apache

The second important condition is the rejection of Apache. If you have Apache, then at least put a caching proxy in front of it - nginx or lighttpd. Apache "is extremely difficult to give files away, and, even worse, it is fundamentally (that is, incorrigibly) vulnerable to the most dangerous Slowloris attack, which allows you to fill up the server almost from mobile phone. To combat various types of Slowloris, Apache users first came up with the Anti-slowloris.diff patch, then mod_noloris, then mod_antiloris, mod_limitipconn, mod_reqtimeout... But if you want to sleep at night, it's easier to take an HTTP server that is invulnerable to Slowloris at the architecture level code. Therefore, all our further recipes are based on the assumption that nginx is used on the frontend.

Fighting off DDoS

What to do if DDoS comes? The traditional self-defense technique is to read the HTTP server log file, write a grep pattern (that catches bot requests), and ban anyone who falls under it. This technique will work... if you're lucky. There are two types of botnets, both dangerous, but in different ways. One completely comes to the site instantly, the other - gradually. The first one kills everything at once, but the whole thing appears in the logs, and if you grepaet them and ban all IP addresses, then you are the winner. The second botnet lays down the site gently and carefully, but you will probably have to ban it for a day. It is important for any administrator to understand: if you plan to fight with grep, then you need to be prepared to devote a couple of days to fighting the attack. The following are tips on where you can put straws in advance so that it is not so painful to fall.

3. Use the testcookie module

Perhaps the most important, effective and operational recipe of this article. If DDoS comes to your site, then the testcookie-nginx module, developed by @kyprizel, can become the most effective way to fight back. The idea is simple. Most often, bots that implement HTTP flooding are rather dumb and do not have HTTP cookie and redirect mechanisms. Sometimes more advanced ones come across - they can use cookies and process redirects, but almost never a DoS bot carries a full-fledged JavaScript engine (although this is becoming more and more common). Testcookie-nginx acts as a quick filter between bots and the backend during an L7 DDoS attack, allowing you to filter out junk requests. What is included in these checks? Does the client know how to perform HTTP Redirect, does it support JavaScript, is it the browser it claims to be (because JavaScript is different everywhere and if the client says that it is, say, Firefox, then we can check this). The verification is implemented using cookies using different methods:

"Set-Cookie" + redirect with 301 HTTP Location;
"Set-Cookie" + redirect using HTML meta refresh;
arbitrary template, and you can use JavaScript.

To avoid automatic parsing, the validation cookie can be encrypted with AES-128 and later decrypted on the JavaScript client side. IN new version module, it became possible to set a cookie through Flash, which also allows you to effectively weed out bots (which Flash, as a rule, does not support), but, however, also blocks access for many legitimate users (in fact, all mobile devices). It is noteworthy that it is extremely easy to start using testcookie-nginx. The developer, in particular, gives several clear examples of use (for different cases of attack) with config samples for nginx.

In addition to the advantages, testcookies also have disadvantages:

cuts all bots, including Googlebot. If you plan to leave the testcookie on a permanent basis, make sure that you do not disappear from the search results;
creates problems for users with browsers Links, w3m and the like;
does not save from bots equipped with a full-fledged browser engine with JavaScript.

In a word, testcookie_module is not universal. But from a number of things, such as, for example, primitive toolkits in Java and C #, it helps. Thus, you cut off part of the threat.

4. Code 444

DDoSers often target the most resource-intensive part of a site. A typical example is a search that performs complex database queries. Naturally, attackers can take advantage of this by loading several tens of thousands of requests to the search engine at once. What we can do? Temporarily disable search. While customers won't be able to search for the information they need with built-in tools, the entire main site will remain up and running until you find the root of all problems. Nginx supports the non-standard 444 code, which allows you to simply close the connection and return nothing in response:

Location /search ( return 444; )

Thus, it is possible, for example, to quickly implement filtering by URL. If you are sure that requests to location /search are only coming from bots (for example, your confidence is based on the fact that your site does not have a /search section at all), you can install the ipset package on the server and ban bots with a simple shell script:

Ipset -N ban iphash tail -f access.log | while read LINE; do echo "$LINE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "$(L%% *)"; done

If the format of the log files is non-standard (not combined) or you need to ban on other grounds than the status of the response, you may need to replace cut with a regular expression.

5. Geo-banim

The non-standard response code 444 can also be useful for quickly banning clients based on geo-reference. You can severely restrict individual countries that you feel uncomfortable from. For example, it is unlikely that an online camera store from Rostov-on-Don has many users in Egypt. This is not a very good way (to put it bluntly - disgusting), because the GeoIP data is inaccurate, and Rostovites sometimes fly to Egypt on vacation. But if you have nothing to lose, then follow the instructions:

Connect the GeoIP module to nginx (wiki.nginx.org/HttpGeoipModule).
Display georeference information in the access log.
Next, after modifying the above shell script, grep nginx's accesslog and add geographically kicked clients to the ban.

If, for example, the bots were mostly from China, then this might help.

6. Neural network (PoC)

Finally, you can repeat the experience of the user @SaveTheRbtz, who took the PyBrain neural network, stuffed the log into it and analyzed the requests (habrahabr.ru/post/136237). The method is working, although not universal :). But if you really know the insides of your site - and you, as a system administrator, should - then chances are that in the most tragic situations, such a tool based on neural networks, training and information gathered in advance will help you. In this case, it is very useful to have access.log before the start of DDoS, since it describes almost 100% of legitimate clients, and therefore, an excellent dataset for training a neural network. Moreover, bots are not always visible in the log.

Problem Diagnosis

The site is not working - why? Is it DDoSed or is it an engine bug not noticed by the programmer? Doesn't matter. Don't look for an answer to this question. If you think that your site may be attacked, contact companies that provide protection against attacks - a number of anti-DDoS services offer free first day after connection - and do not waste any more time looking for symptoms. Focus on the problem. If the site is running slowly or not opening at all, then something is wrong with its performance, and - regardless of whether there is a DDoS attack or not - you, as a professional, are obliged to understand what is causing this. We have repeatedly witnessed how a company experiencing difficulties with the operation of its site due to a DDoS attack, instead of looking for weaknesses in the site engine, tried to send applications to the Ministry of Internal Affairs in order to find and punish the attackers. Don't make such mistakes. The search for cybercriminals is a difficult and lengthy process, complicated by the very structure and principles of the Internet, and the problem with the operation of the site must be resolved promptly. Get the technicians to find out what is causing the site performance drop, and the lawyers can write the complaint.

7. Use a profiler and debugger

For the most common website building platform - PHP + MySQL - the bottleneck can be found using the following tools:

the Xdebug profiler will show which calls the application spends the most time on;
the built-in APD debugger and debug output to the error log will help you find out exactly which code makes these calls;
in most cases, the dog is buried in the complexity and heaviness of database queries. The explain SQL directive built into the database engine will help here.

If the site is lying on its back and you do not lose anything, disconnect from the network, look at the logs, try to play them. If it doesn't, then go through the pages, look at the base.

The example is for PHP, but the idea is valid for any platform. A developer writing software products in any programming language must be able to quickly use both the debugger and the profiler. Practice ahead of time!

8. Analyze mistakes

Analyze the amount of traffic, server response time, number of errors. See logs for this. In nginx, the server response time is recorded in the log by two variables: request_time and upstream_response_time. The first is the total execution time of the request, including network delays between the user and the server; the second tells how long the backend (Apache, php_fpm, uwsgi...) has been executing the request. The upstream_response_time value is extremely important for sites with a lot of dynamic content and active communication between the frontend and the database, and should not be neglected. You can use the following config as the log format:

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

This is a combined format with added timing fields.

9. Track requests per second

Also look at the number of requests per second. In the case of nginx, you can roughly estimate this value with the following shell command (the ACCESS_LOG variable contains the path to the nginx request log in combined format):

Echo $(($(fgrep -c "$(env LC_ALL=C date [email protected]$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

Compared to the normal level for this time of day, the number of requests per second can both fall and grow. They grow if a large botnet arrives, and fall if the incoming botnet crashes the site, making it completely inaccessible to legitimate users, and at the same time, the botnet does not request statics, but legitimate users do. The drop in the number of requests is observed precisely due to statics. But, one way or another, we are talking about serious changes in indicators. When this happens suddenly - while you are trying to solve the problem on your own and if you do not see it right away in the log, it is better to quickly check the engine and contact specialists in parallel.

10. Don't Forget About tcpdump

Many people forget that tcpdump is an awesome diagnostic tool. I will give a couple of examples. In December 2011, a bug was discovered in the Linux kernel when it opened a TCP connection when the SYN and RST TCP segment flags were set. The first bug report was sent by a system administrator from Russia, whose resource was attacked by this method - the attackers found out about the vulnerability earlier than the whole world. Obviously, such a diagnosis helped him. Another example: nginx has one not very nice property - it writes to the log only after the request has been completely processed. There are situations when the site is down, nothing works and there is nothing in the logs. This is because all the requests that are currently loading the server have not yet completed. Tcpdump will help here too.

It is so good that I advised people not to use binary protocols until they are sure that everything is in order, because text protocols are easy to debug with tcpdump, but binary protocols are not. However, the sniffer is good as a diagnostic tool - as a means of maintaining production"and he's scary. It can easily lose multiple packages at once and mess up your user history. It is convenient to watch its output, and it will be useful for manual diagnostics and a ban, but try not to base anything critical on it. Another favorite tool for "warming requests" - ngrep - generally by default tries to request around two gigabytes of non-swapable memory and only then begins to reduce its requirements.

11. Attack or not?

How to distinguish a DDoS attack, for example, from the effect of an advertising campaign? This question may seem ridiculous, but this topic is no less complex. There are some pretty funny cases. For some good guys, when they tensed up and thoroughly screwed up caching, the site fell ill for a couple of days. It turned out that for several months this site had been imperceptibly datamined by some Germans, and before optimizing the caching of the site page for these Germans, with all the pictures, it took quite a long time to load. When the page began to be issued from the cache instantly, the bot, which did not have any timeouts, also began to collect them instantly. It was hard. The case is especially difficult for the reason that if you yourself changed the setting (turned on caching) and the site stopped working after that, then who, in your opinion and the boss's opinion, is to blame? Exactly. If you see a sharp increase in the number of requests, then look, for example, in Google Analytics, who came to which pages.

Web server tuning

What are the other key points? Of course, you can set the "default" nginx and hope that everything will be fine for you. However, good things don't always happen. Therefore, the administrator of any server must devote a lot of time to fine-tuning and tuning nginx.

12. Limit resources (buffer sizes) in nginx

What should be remembered first of all? Each resource has a limit. First of all, it concerns RAM. Therefore, the sizes of headers and all used buffers should be limited to adequate values per client and per server as a whole. They must be registered in the nginx config.

client_header_buffer_size_ _ Sets the buffer size for reading the client request header. If the request string or request header field does not fit entirely into this buffer, then larger buffers are allocated, specified by the large_client_header_buffers directive.
large_client_header_buffers Specifies the maximum number and size of buffers to read the large client request header.
client_body_buffer_size Sets the buffer size for reading the client request body. If the request body is larger than the specified buffer, then the entire request body or only part of it is written to a temporary file.
client_max_body_size Sets the maximum size allowed for a client request body, specified in the Content-Length field of the request header. If the size is larger than the specified one, then the client returns error 413 (Request Entity Too Large).

13. Set up timeouts in nginx

Time is also a resource. Therefore, the next important step should be to set all the timeouts, which again, it is very important to carefully register in the nginx settings.

reset_timedout_connection on; Helps deal with sockets stuck in the FIN-WAIT phase.
client_header_timeout Specifies a timeout when reading a client request header.
client_body_timeout Specifies a timeout when reading the body of a client request.
keepalive_timeout Sets the timeout during which the keep-alive connection with the client will not be closed by the server. Many are afraid to set large values here, but we are not sure that this fear is justified. You can optionally set a timeout value in the Keep-Alive HTTP header, but Internet Explorer notorious for ignoring this value
send_timeout Specifies a timeout when sending a response to the client. If the client does not receive anything after this time, the connection will be closed.

Immediately the question is: what parameters of buffers and timeouts are correct? There is no universal recipe here, each situation has its own. But there is a proven approach. It is necessary to set the minimum values at which the site remains operational (in peacetime), that is, pages are returned and requests are processed. This is determined only by testing - both from desktops and from mobile devices. The algorithm for finding the values of each parameter (buffer size or timeout):

We set the mathematical minimum value of the parameter.
We start running site tests.
If all the functionality of the site works without problems, the parameter is defined. If not, increase the value of the parameter and go to step 2.
If the value of the parameter exceeded even the default value, this is a reason for discussion in the development team.

In some cases, the revision of these parameters should lead to refactoring / redesign of the site. For example, if the site does not work without three-minute AJAX long polling requests, then you do not need to increase the timeout, but replace long polling with something else - a botnet of 20 thousand machines, hanging on requests for three minutes, will easily kill an average cheap server.

14. Limit connections in nginx (limit_conn and limit_req)

Nginx also has the ability to limit connections, requests, and so on. If you're not sure how a certain part of your site will behave, then ideally you should test it, figure out how many requests it can handle, and write that into your nginx configuration. It's one thing when the site is down and you are able to come and pick it up. And it's a completely different matter - when it lay down to such an extent that the server went into swap. In this case, it is often easier to reboot than to wait for his triumphant return.

Let's assume that the site has sections with the telling names /download and /search. In doing so, we:

we don't want bots (or people with overzealous recursive download managers) to fill up our TCP connection table with their downloads;
we do not want bots (or stray search engine crawlers) to exhaust the computing resources of the DBMS with many search queries.

For these purposes, the following configuration will fit:

Http ( limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server ( location /download/ ( limit_conn download_c 1; # Other configuration location ) location /search/ ( limit_req zone= search_r burst=5; # Other configuration location ) ) )

It usually makes sense to set limits limit_conn and limit_req for locations where scripts that are expensive to execute are located (search is indicated in the example, and this is no accident). Constraints must be chosen based on the results of load and regression testing, as well as common sense.

Notice the 10m parameter in the example. It means that a dictionary with a buffer of 10 megabytes and not a megabyte more will be allocated for the calculation of this limit. In this configuration, this will allow 320,000 TCP sessions to be monitored. To optimize memory usage, the $binary_remote_addr variable is used as a key in the dictionary, which contains the user's IP address in binary form and takes up less memory than the regular $remote_addr string variable. It should be noted that the second parameter to the limit_req_zone directive can be not only IP, but also any other nginx variable available in this context - for example, in the case when you do not want to provide a more forgiving mode for the proxy, you can use $binary_remote_addr$http_user_agent or $binary_remote_addr$http_cookie_myc00kiez - but such constructions should be used with caution, because, unlike the 32-bit $binary_remote_addr, these variables can be much longer and the "10m" you declared may suddenly end.

Trends in DDoS

The power of network and transport layer attacks is constantly growing. The potential of an average SYN flood attack has already reached 10 million packets per second.
Attacks on the DNS have been in particular demand lately. UDP flooding with valid DNS requests with spoofed source IP addresses is one of the easiest attacks to implement and difficult to counter. Many large Russian companies (including hosting companies) have recently experienced problems as a result of attacks on their DNS servers. The further, the more such attacks will be, and their power will grow.
Judging by external signs, most botnets are not controlled centrally, but through a peer-to-peer network. This gives attackers the opportunity to synchronize the actions of the botnet in time - if earlier control commands were distributed over a botnet of 5,000 machines in tens of minutes, now seconds count, and your site may suddenly experience an instant hundredfold increase in the number of requests.
The share of bots equipped with a full-fledged browser engine with JavaScript is still small, but it is constantly growing. Such an attack is more difficult to repulse with built-in improvised means, so DIYers should watch this trend with caution.

preparing the OS

In addition to fine-tuning nginx, you need to take care of the settings for the network stack of the system. At the very least, immediately include net.ipv4.tcp_syncookies in sysctl to protect yourself from a small SYN flood attack at once.

15. Tune the core

Pay attention to the more advanced settings of the network part (kernel), again in terms of timeouts and memory. There are more important ones and less important ones. First of all, you need to pay attention to:

net.ipv4.tcp_fin_timeout The time the socket will spend in TCP phase FIN-WAIT-2 (waiting for a FIN/ACK segment).
net.ipv4.tcp_(,r,w)mem TCP socket receive buffer size. Three values: minimum, default value and maximum.
net.core.(r,w)mem_max Same for non-TCP buffers.

With a link of 100 Mbps, the default values are still somehow suitable; but if you have at least gigabits per second available, then it's better to use something like:

sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 838860 8" sysctl- w net.ipv4.tcp_fin_timeout=10

16. Revision /proc/sys/net/**

It is ideal to study all parameters /proc/sys/net/**. We need to see how they differ from the default ones, and understand how adequately they are exposed. A Linux developer (or system administrator) who understands the operation of the Internet service under his control and wants to optimize it should read with interest the documentation of all parameters of the kernel network stack. Perhaps he will find variables specific to his site there that will help not only protect the site from intruders, but also speed up its work.

Do not be afraid!

Successful DDoS attacks day by day extinguish e-commerce, shake the media, knock out the largest payment systems with one blow. Millions of Internet users are losing access to critical information. The threat is urgent, so you need to meet it fully armed. Do your homework, don't be afraid and keep your head cool. You are not the first nor the last to face a DDoS attack on your site, and it is up to you, guided by your knowledge and common sense, to minimize the consequences of the attack.

We talk a lot about attacks on the site, hacking, but we did not mention the subject of DDOS. Today we are correcting this situation and offer you a complete overview of the technologies for organizing DDoS attacks and well-known tools for performing hacker attacks.

You can view the list of available tools for DDOS attacks in KALI by running the command:

kali > /usr/share/exploitdb/platforms/windows/dos

This command shows the database of exploits for attacking Windows systems.

To view the available Linux DDoS attack tools, enter the command:

/usr/share/exploitdb/platforms/Linux/dos.

2.LOIC

The Low Orbit Ion Cannon (LOIC) Possibly the most popular DDOS program. It can send bulk requests via ICMP, UDP protocols, thereby blocking the channel to the victim's server. The most notorious LOIC attack was carried out by Anonymous in 2009 against PayPal, Visa, MasterCard in retaliation for WikiLeaks being cut off from the fundraising system.

Attacks organized using LOIC can be exploited by blocking UDP and ICMP packets on the network equipment of Internet providers. You can download the LOIC program itself for free on the website. This Windows-based tool is very easy to use, just point to the victim's websites and press just one button.

2.HOIC

HOIC was developed as part of Operation Payback by Praetox by the same team that created LOIC. The key difference is that HOIC uses the HTTP protocol and uses it to send a stream of randomized HTTP GET and POST requests. It is capable of simultaneously attacking 256 domains. You can download it from .

3.XOIC

XOIC is another very simple DDOS tool. The user just needs to set the victim's IP address, select the protocol (HTTP, UDP, ICMP, or TCP), and pull the trigger! You can download it from

5. HULK

6.UDP Flooder

UDP Flooder lives up to its name - a tool designed to send multiple UDP packets to a target. UDP Flooder is often used when DDOS attacks to game servers, to disconnect players from the server. The program is available for download at .

7. RUDY

8. ToR's Hammer

ToR's Hammer was designed to work through network, in order to achieve greater anonymity of the attacker. The problem with this tool is that the TOR network is quite slow and thus reduces the effectiveness of a DDoS attack. You can download this DDOS program from Packet Storm or .

9. Pyloris

Pyloris is another DDoS tool that takes a new approach. It allows an attacker to create their own unique HTTP request. The program will then try to keep the TCP connection open with such requests, thereby reducing the number of available connections on the server. When the server's connection limit is reached, the server can no longer serve connections and the site becomes unavailable. This tool is available for free download from the website.

10.OWASP Switchblade

Open Web Application Security Project (OWASP) and ProactiveRISK have developed a tool Switchblade DoS tool for testing WEB applications for resistance to DDoS attacks. It has three modes of operation: 1. SSL Half-Open, 2. HTTP Post, and 3. Slowloris. You can download it for review from the OWASP website.

11.DAVOSET

12. GoldenEye HTTP DoS Tool

13.THC-SSL-DOS

This DDOS tool (included with Kali) differs from most DDOS tools in that it does not use Internet bandwidth and can be used from a single computer. THC-SSL-DOS exploits the vulnerability of the SSL protocol and is able to "put down" the target server. Unless, of course, this vulnerability exists on it. You can download the program from the THC website, or use KALI Linux where this tool is already installed.

14. DDOSIM - Layer 7 DDoS emulator

This is where our review ends, but in the future we will return to the topic of DDoS attacks on the pages of our blog.

A DDoS attack (Distributed Denial of Service attack) is a set of actions that can completely or partially disable an Internet resource. Almost any Internet resource can act as a victim, such as a website, a game server, or a government resource. At the moment, it is practically impossible for a hacker to organize a DDoS attack alone. In most cases, an attacker uses a network of computers infected with a virus. The virus allows you to get the necessary and sufficient remote access to the infected computer. A network of such computers is called a botnet. As a rule, botnets have a coordinating server. Deciding to implement an attack, the attacker sends a command to the coordinating server, which in turn gives a signal to everyone to start executing malicious network requests.

Reasons for DDoS attacks

Personal animosity

This reason is quite common. Some time ago, independent research journalist Brian Krebs revealed the activities of the largest service for custom DDoS attacks - vDOS. The information was presented in full detail, which caused the arrest of the organizers of this service. In response, the hackers organized an attack on the journalist's blog, the power of which reached 1 Tbps. This attack became the most powerful in the world for all years.

Entertainment

Nowadays, it is becoming easier to organize a primitive DDoS attack on your own. Such an attack would be extremely imperfect and not anonymous. Unfortunately, most of those who decide to feel like a "hacker" are not aware of either the first or the second. However, many students often practice DDoS attacks. The outcome of such cases is very diverse.

Political protest (hacktivism)

One of the first social attacks was a DDoS attack implemented in 1996 by the Omega hacker. Omega was a member of the Cult of the Dead Crew (cDc) hacker coalition. The term hacktivism has become popular in the media due to the increasing frequency of cyber attacks that have a social basis. Typical representatives of hacktivists are Anonymous and LulzSec.

Unfair competition

Such motives often occur in the gaming server industry, but in the retail industry, such cases are quite common. A fairly effective way of unfair competition that can destroy the reputation of the trading platform if its owners do not turn to specialists for help in time. Such a motive can be distinguished from the others as the most common.

Extortion or blackmail

In this case, the attacker demands a sum of money from the potential victim for the failure to carry out the attack. Or to stop it. Large organizations often become victims of such attacks, for example, during 2014 Tinkoff Bank and the IT resource Habrahabr, the largest torrent tracker Rutracker.org were attacked (how was it?).

Consequences of DDoS attacks

The consequences of DDoS attacks can be very diverse, from shutting down your server by the data center to the complete loss of the reputation of the resource and client flow. Many organizations unknowingly choose unscrupulous security providers to save money, which often does not bring any benefit. To avoid such problems, we recommend contacting professionals in your industry.

Attacks that made Internet history

Technological progress is advancing by leaps and bounds, and attackers, in turn, are making every effort not to stand still and implement more and more complex and powerful attacks. We have collected short description the most interesting cases that went down in the history of DDoS attacks. Some of them may seem ordinary by today's standards, but at the time they took place, they were very large-scale attacks.

Ping Of Dead. An attack method based on the use of the ping command. This attack gained popularity in the 1990s due to the imperfection of network equipment. The essence of the attack is to send a single ping request to the network host, while the packet body includes not the standard 64 bytes of data, but 65535 bytes. Upon receiving such a packet, the equipment overflowed the network stack and that caused a denial of service.

An attack that affected the stability of the Internet. In 2013, Spamhaus was the victim of a 280Gbps attack. The most interesting thing is that for the attack, the hackers used DNS servers from the Internet, which in turn were very loaded with a large number of requests. On that day, millions of users complained about slow loading pages due to service congestion.

Record-breaking attack with traffic over 1 Tbps. In 2016, hackers tried to attack us with a burst attack at 360 Mpps and 1 Tbps. This figure has become a record for the existence of the Internet. But even under such an attack, we resisted and the load on the network only slightly limited the free resources of network equipment.

Characteristics of attacks today

Excluding peak attacks, we can say that the power of attacks is growing every year by more than 3-4 times. The geography of attackers changes only partially from year to year, because this is due to the maximum number of computers in a particular country. As can be seen from the quarterly report for 2016 prepared by our experts, Russia, the USA and China are the record-breaking countries in terms of the number of bots.

What are DDoS attacks?

At the moment, the types of attacks can be divided into 3 classes:

Channel flooding attacks

This type of attack includes , and ;

Attacks that exploit vulnerabilities in the network protocol stack

The most popular and interesting attacks of this type are , / attack,

Why choose us? Our equipment is located in the world's key data centers and is capable of repelling attacks up to 300 Gbps or 360 million packets per second. We also have a content delivery network () and a staff of engineers on duty in case of a non-standard attack or emergency situations. Therefore, having come under the protection of us, you can be sure that your resource is available 24/7. We are trusted by: REG.RU, Arguments and Facts, WebMoney, Russian radio holding GPM and other corporations.

Only against a small number of attacks you can implement protection yourself, using traffic analysis or setting up routing rules. Ways to protect against some attacks are given in.

What is a ddos ​​attack. DDoS attack: what it is, how it works and whether it is possible to protect yourself