Malicious DDOS and protection
An interesting story happened with one of my projects, I want to share with you, maybe it will seem interesting to someone.
Since my project was often tortured by DDOS, it was decided to translate it under the HighLoad Lab, which provide protection against DDOS attacks for free.
Everything was super, they proxied the traffic through themselves to our server. We have blocked all incoming IP addresses on the server, except for HighLoad.
')
But on the night of November 13-14, the server began to be terribly slow, I could not understand why: there was no load, iptables did not accept anything, but the brakes were noticeable even when working in ssh.
In the afternoon, the server fell. I did not yet know the reasons, and the first thing that occurred to me was the old core of slackwar, which had not been updated for a long time. It was decided to go to Krasnogorsk, to the office of Rednet and rearrange the system to fresh Debian, but everything turned out to be far from what I had planned ...
As I went through the possible reasons in my mind, the telephone rang. On the wire was the main administrator krasnogorsk.ru . He said that an accident occurred due to a DDOS attack, which occurred at the time of equipment replacement, when the protection and cleaning systems were disabled.
Since our server was at the home provider, the client traffic (ordinary Internet users) suffered first of all
An attack was noticed on the COMCOR trunk site and our IP-address was chopped off. At the peak of the attack reached 300 Mbps.
The attackers knew our old IP-address and the attack was carried out specifically on it, bypassing the traffic cleaning systems, and naturally, no iptables in the block all mode will not help.
Now the server is transferred to an IP unknown to anyone, the traffic goes through HighLoad Lab, we configured the web server's mail via Gmail, and all outgoing connections to download avatars via links were disabled, since the attacker could download the image from his server and find out our new IP.
User request -> external ip antidos server -> traffic clearing system -> their nginx -> cleared traffic goes to our server -> nginx -> apache -> and back to the user in the same chain. The most important thing is not to attack the attacker with the real IP address of the web server.
Help in design and editing: as3k
Since my project was often tortured by DDOS, it was decided to translate it under the HighLoad Lab, which provide protection against DDOS attacks for free.
Everything was super, they proxied the traffic through themselves to our server. We have blocked all incoming IP addresses on the server, except for HighLoad.
')
Problem
But on the night of November 13-14, the server began to be terribly slow, I could not understand why: there was no load, iptables did not accept anything, but the brakes were noticeable even when working in ssh.
In the afternoon, the server fell. I did not yet know the reasons, and the first thing that occurred to me was the old core of slackwar, which had not been updated for a long time. It was decided to go to Krasnogorsk, to the office of Rednet and rearrange the system to fresh Debian, but everything turned out to be far from what I had planned ...
Cause
As I went through the possible reasons in my mind, the telephone rang. On the wire was the main administrator krasnogorsk.ru . He said that an accident occurred due to a DDOS attack, which occurred at the time of equipment replacement, when the protection and cleaning systems were disabled.
Since our server was at the home provider, the client traffic (ordinary Internet users) suffered first of all
An attack was noticed on the COMCOR trunk site and our IP-address was chopped off. At the peak of the attack reached 300 Mbps.
Why not save the filters HighLoad'a?
The attackers knew our old IP-address and the attack was carried out specifically on it, bypassing the traffic cleaning systems, and naturally, no iptables in the block all mode will not help.
Total
Now the server is transferred to an IP unknown to anyone, the traffic goes through HighLoad Lab, we configured the web server's mail via Gmail, and all outgoing connections to download avatars via links were disabled, since the attacker could download the image from his server and find out our new IP.
Now the scheme is approximately as follows:
User request -> external ip antidos server -> traffic clearing system -> their nginx -> cleared traffic goes to our server -> nginx -> apache -> and back to the user in the same chain. The most important thing is not to attack the attacker with the real IP address of the web server.
Help in design and editing: as3k
Source: https://habr.com/ru/post/76130/
All Articles