DDoS attack bypassing Qrator. How to protect yourself?
There are services that protect us from DDoS attacks. They work on the proxy principle: their IP is registered in the DNS, they filter traffic and proxy to your server. All of them strongly recommend hiding your IP and in public access give only the IP proxy defender. It is a sound approach, sufficient for successful protection. And I will tell on what you can pierce and how to protect against this.
Let's register in such a service and get a registration letter from him in the mail. Open the source of the letter and see:
Well, we found the car in the subnet of this server in real DC, and not a proxy. Here it is: srv1.example.com, xxx.xx.xx.xxx. Most likely this machine is in the same DC and on the same subnet as the www server. Typically, such projects do not have large networks, no more than / 24. Let's scan the mesh and find all the machines with an open 80 / tcp port. Noob is great, there is a list of machines - let's go to each browser. On a machine with the address xxx.xx.xx.xxy, a redirect to www.example.com happened to us - this is the same machine, they redirected us to the proxy of the defender.
Now we can safely attack this car. The channel on the machine is unlikely to be more than 1GB, but there are motherboards where network cards with 4 interfaces are built in at once. So the attack will be with a margin of - 4GB. We will not make an attack on the application, or an attack on nginx - you can simply fill the channel with traffic. Moreover, the fact that we fill only the incoming direction to the server is not terrible. Requests from users are also inbound. Is it a lot of 4 GB for DDoS attacks? Let's count. In Moscow, many people have a good Internet connection at home - 40 MB minimum. 4 GB / 40 MB = 100 machines. These are only 100 machines with a bot - such a botnet can be organized fairly quickly (if there is an appropriate skill), and for a person who is constantly engaged in DDoS, this is not a problem at all. Modern botnets are thousands of infected machines.
')
A simple solution is to have a mail machine outside the DC and outside the combat subnet, which will work as a mail relay and cut off all the “Received” that it has. This is not difficult to do, in the same postfix there is a content_filter option where you can specify an SMTP proxy for content filtering. In any language, you can easily write smtp-proxy, which will cut off all the excess in the letter. I don’t know the finished tools, to be honest, but for me the task to write smtp-proxy in python or ruby ​​is a task for several hours.
Less accessible, but also a real way. Having dragged off the DNS zone, we will find in it the names of the machines and IP addresses - usually the technical names of the machines are kept right in the same zone. Something like srv1.example.com IN A xxx.xx.xx.xxx.
It is quite simple to protect - all technical DNS s are placed in a separate subdomain and are protected more carefully. srv1.servers.example.com - something like this.
It is not difficult to conclude that a site without statics does not work. Usually services for protection against DDoS take money for traffic, so static from the main domain is transferred to the CDN. Covering up with CDN traffic is a very difficult task, because of its distribution. But you can see what kind of static is still on the site. ABOUT! Banners are shown from the left service and he is not sitting behind a proxy defender - this is just luck. You can fill the channel to the banner system: js will not load, DOM Ready will not happen - if there are a lot of js on the site - it is almost impossible to use it.
This is not a universal way, but it can roll where the site without js does not work in principle. Protection against this is also the most stupid - asynchronous js to banners. I could not - well, okay.
Here we found an interesting file on the CDN: cdn-1.example.com/static/video/hardporn.flv . It weighs as much as 140 MB. We remember that proxy defenders take money for traffic. And from where CDN will take this file? In the simple case of www.example.com/static/video/hardporn.flv . Check and make sure that it is given. So that's great. In the simple case, we need a very small botnet, which will simply download this file for a couple of days - without much of a burden, without attracting the attention of the proxy defender. Of course, this will be an excess of prepaid traffic and the site owner’s company will have to be very sad.
You can tweak such an attack a bit - find the XSS and plug in an html5 video with autoplay and display: none. Outwardly, nothing changes, but each user pulls a lot of traffic to him. Each user, unlike a botnet, is not filtered.
In general, financial attacks are the most dangerous for binz. Either the business pays for the huge traffic so that the site works (and pulls even more traffic), or it does not pay and the service lays down.
Protection from such is simple to stupidity - return 403 from statics to everyone except the CDN.
If the site also has a mobile application - it is now fashionable, it means a modern site. Having a mobile application, usually the site still has a mobile API. By installing the application and gathering tcpdump traffic (well, it's not difficult to raise wifi point-to-point on your PC), you can find api-mobile.example.com. Perhaps because of the desire to save, he, too, will not be for a proxy defender, but look directly at the server. Well, the IP we needed was burned.
Protection, as you understand, is simple - API traffic must go through a proxy defender.
All the above methods are simple. They do not require deep research of the site - just poke into it, do not even require to get a shell on it. Not all methods are real on all sites, but on most sites, at least one way will work.
Protection against DDoS attacks through service defenders is good, it justifies itself financially and technically. There remains a task for the site admins - but do not sleep your IP!
Outgoing mail
Let's register in such a service and get a registration letter from him in the mail. Open the source of the letter and see:
Received: from mxfront8j.mail.yandex.net ([127.0.0.1]) by mxfront8j.mail.yandex.net with LMTP id c0MIOzBI for <mymail@yandex.ru>; Sun, 10 May 2015 15:58:47 +0300 Received: from srv1.example.com (srv1.example.com [xxx.xx.xx.xxx]) by mxfront8j.mail.yandex.net (nwsmtp/Yandex) with ESMTPS id FpRuMcFeJH-wksakWfe; Sun, 10 May 2015 15:58:46 +0300 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) Received: from srv1.example.com (localhost [127.0.0.1]) by srv1.example.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id t4ACvd6T026304 for <mymail@yandex.ru>; Sun, 10 May 2015 15:57:39 +0300 Received: (from www-data@localhost) by srv1.example.com (8.14.3/8.14.3/Submit) id t4ACvdQX026302; Sun, 10 May 2015 15:57:39 +0300 Well, we found the car in the subnet of this server in real DC, and not a proxy. Here it is: srv1.example.com, xxx.xx.xx.xxx. Most likely this machine is in the same DC and on the same subnet as the www server. Typically, such projects do not have large networks, no more than / 24. Let's scan the mesh and find all the machines with an open 80 / tcp port. Noob is great, there is a list of machines - let's go to each browser. On a machine with the address xxx.xx.xx.xxy, a redirect to www.example.com happened to us - this is the same machine, they redirected us to the proxy of the defender.
Now we can safely attack this car. The channel on the machine is unlikely to be more than 1GB, but there are motherboards where network cards with 4 interfaces are built in at once. So the attack will be with a margin of - 4GB. We will not make an attack on the application, or an attack on nginx - you can simply fill the channel with traffic. Moreover, the fact that we fill only the incoming direction to the server is not terrible. Requests from users are also inbound. Is it a lot of 4 GB for DDoS attacks? Let's count. In Moscow, many people have a good Internet connection at home - 40 MB minimum. 4 GB / 40 MB = 100 machines. These are only 100 machines with a bot - such a botnet can be organized fairly quickly (if there is an appropriate skill), and for a person who is constantly engaged in DDoS, this is not a problem at all. Modern botnets are thousands of infected machines.
')
How to protect?
A simple solution is to have a mail machine outside the DC and outside the combat subnet, which will work as a mail relay and cut off all the “Received” that it has. This is not difficult to do, in the same postfix there is a content_filter option where you can specify an SMTP proxy for content filtering. In any language, you can easily write smtp-proxy, which will cut off all the excess in the letter. I don’t know the finished tools, to be honest, but for me the task to write smtp-proxy in python or ruby ​​is a task for several hours.
Steal DNS zone
Less accessible, but also a real way. Having dragged off the DNS zone, we will find in it the names of the machines and IP addresses - usually the technical names of the machines are kept right in the same zone. Something like srv1.example.com IN A xxx.xx.xx.xxx.
It is quite simple to protect - all technical DNS s are placed in a separate subdomain and are protected more carefully. srv1.servers.example.com - something like this.
Indirect attack
It is not difficult to conclude that a site without statics does not work. Usually services for protection against DDoS take money for traffic, so static from the main domain is transferred to the CDN. Covering up with CDN traffic is a very difficult task, because of its distribution. But you can see what kind of static is still on the site. ABOUT! Banners are shown from the left service and he is not sitting behind a proxy defender - this is just luck. You can fill the channel to the banner system: js will not load, DOM Ready will not happen - if there are a lot of js on the site - it is almost impossible to use it.
This is not a universal way, but it can roll where the site without js does not work in principle. Protection against this is also the most stupid - asynchronous js to banners. I could not - well, okay.
Financial attack
Here we found an interesting file on the CDN: cdn-1.example.com/static/video/hardporn.flv . It weighs as much as 140 MB. We remember that proxy defenders take money for traffic. And from where CDN will take this file? In the simple case of www.example.com/static/video/hardporn.flv . Check and make sure that it is given. So that's great. In the simple case, we need a very small botnet, which will simply download this file for a couple of days - without much of a burden, without attracting the attention of the proxy defender. Of course, this will be an excess of prepaid traffic and the site owner’s company will have to be very sad.
You can tweak such an attack a bit - find the XSS and plug in an html5 video with autoplay and display: none. Outwardly, nothing changes, but each user pulls a lot of traffic to him. Each user, unlike a botnet, is not filtered.
In general, financial attacks are the most dangerous for binz. Either the business pays for the huge traffic so that the site works (and pulls even more traffic), or it does not pay and the service lays down.
Protection from such is simple to stupidity - return 403 from statics to everyone except the CDN.
Mobile API Attack
If the site also has a mobile application - it is now fashionable, it means a modern site. Having a mobile application, usually the site still has a mobile API. By installing the application and gathering tcpdump traffic (well, it's not difficult to raise wifi point-to-point on your PC), you can find api-mobile.example.com. Perhaps because of the desire to save, he, too, will not be for a proxy defender, but look directly at the server. Well, the IP we needed was burned.
Protection, as you understand, is simple - API traffic must go through a proxy defender.
Conclusion
All the above methods are simple. They do not require deep research of the site - just poke into it, do not even require to get a shell on it. Not all methods are real on all sites, but on most sites, at least one way will work.
Protection against DDoS attacks through service defenders is good, it justifies itself financially and technically. There remains a task for the site admins - but do not sleep your IP!
Source: https://habr.com/ru/post/260393/
All Articles