- Apr 25, 2015
- 1,845
- 2
- 2,199
- 327
When you decide to combat DDoS it is like disciplining a child. You have to yell "Go in the corner." without startling ALL other children (you cannot break everyone's connection, only the bad kids).
First, we have to find the "bad children", we want to know IoI (Indicators of Intelligence) including Indicators of Attack (IoA) and Indicators of Compromise (IoC).
Turn logging on and make sure if you are behind Cloudflare, you are passing along the appropriate visitor IP. A guide for various web server software is here. Know the problem? Cloudflare has too much "free stuff" they offer that eventually they stop supporting that... as is the case for mod_cloudflare. When things break, you sometimes have to stick your hands into configs with other modules. Otherwise you can build your own mod_cloudflare..
Now we have ~200 guests requesting to load our forum at the same second. Someone is obviously bored and feels like launching L7 (Layer 7) DDoS.
Let's scan our attackers (TCP ports)...
What is 212.22.93.69 running? 3306.. ahh a database and I did not check port 1337 but maybe lol.
188.40.70.2 is open on 80 and 22 (SSH), highly likely compromised and used for launching attacks.
49.254.0.190 is on with over 5 ports, in addition the above host and this one are both referencing Minecraft server install/setup scripts which leads me to believe at a surprisingly high rate, kids (and young adults) are trying to setup their own Minecraft servers with plentiful web-related systems with FTP (21), database (3306), SSH (22), and various other open ports. Since the majority of these systems are hosting some sort of Minecraft web-related control panels, this is probably the work of a "hack team" focused on targeting Minecraft sites. For example, they might find commonly used scripts/plugins: https://github.com/Tutorialwork/WebApply then find default configurations or see tutorials showing "Install WebApply today with username example1 and password stupidPassword1." Security is sometimes overlooked!
Lastly, http://62.210.130.186 is running w/ port 21 and 22 exposed.
The funny thing about these L7 attacks is typically the way attackers gain access to the systems, then shell them (backdoor to use for launching future attacks with either credentials into SSH or build out their own web API of sorts)....................... is all VERY fuckin' simple. Often, attackers throw some L7 attacks around, they get noisy and generate abuse reports.. the L7 attack options go down eventually. But of course with enough SHITTY and unreliable hosting companies that do not effectively handle L7 abuse reports, there are still 200+ shells the attackers have that continue to fake as being real web visitors. Obviously no forum is going to serve up 200+ visitors spamming 100 load requests (20,000+ requests/minute or 300+/second) without seeing some sort of spike in cache loads, depending on configs CPU/RAM, and of course when resource utilization gets top-heavy, loads begin to fail.
As there are hundreds (to say the least) of "booter" services.. this problem will not go away anytime soon! So I will be emphasizing focus on L7 blocking/countermeasure in the coming days. Blocking these attacks CAN be simple but this type o' sh*t is very much cat and mouse.
I block website loads unless you browser can calculate 1+1 with JavaScript, so the attacker just sends 2 every time. I generate random math problems to the client they solve before now connecting to the main server for example 137*2 or 100/2... the attacker now ties a JavaScript engine directly into their fake loader browser, or altogether just uses a whole fucking web browser automation engine to GENERATE _REAL_ browser loads, of which obviously all are fake and go on to solve all the bloody fuckin' JavaScript challenges/puzzles, but then ultimately have the childlike behavior of generating "more than normal" loads, but if someone holds F5 do we ban them? Fuck.
So at the end of the day, we are faced with some evident challenges of "squeak squeak" and *hiss*, back-n-forth-non-fuckin'-stop.
Thankfully companies like Cloudflare dedicated their entire business life to optimizing web caching and blocking common web-based attacks like this. I have heard people mention "Just enforce a cookie." trust me.. some of the newer floods carry cookies. As security advances, anti-security does too.
Not to be discouraging, but there are some very fun problems to solve regarding DDoS (and DoS-alike), and not just for web.. but all L7 attacks.
First, we have to find the "bad children", we want to know IoI (Indicators of Intelligence) including Indicators of Attack (IoA) and Indicators of Compromise (IoC).
Turn logging on and make sure if you are behind Cloudflare, you are passing along the appropriate visitor IP. A guide for various web server software is here. Know the problem? Cloudflare has too much "free stuff" they offer that eventually they stop supporting that... as is the case for mod_cloudflare. When things break, you sometimes have to stick your hands into configs with other modules. Otherwise you can build your own mod_cloudflare..
Now we have ~200 guests requesting to load our forum at the same second. Someone is obviously bored and feels like launching L7 (Layer 7) DDoS.
Let's scan our attackers (TCP ports)...
What is 212.22.93.69 running? 3306.. ahh a database and I did not check port 1337 but maybe lol.
188.40.70.2 is open on 80 and 22 (SSH), highly likely compromised and used for launching attacks.
49.254.0.190 is on with over 5 ports, in addition the above host and this one are both referencing Minecraft server install/setup scripts which leads me to believe at a surprisingly high rate, kids (and young adults) are trying to setup their own Minecraft servers with plentiful web-related systems with FTP (21), database (3306), SSH (22), and various other open ports. Since the majority of these systems are hosting some sort of Minecraft web-related control panels, this is probably the work of a "hack team" focused on targeting Minecraft sites. For example, they might find commonly used scripts/plugins: https://github.com/Tutorialwork/WebApply then find default configurations or see tutorials showing "Install WebApply today with username example1 and password stupidPassword1." Security is sometimes overlooked!
Lastly, http://62.210.130.186 is running w/ port 21 and 22 exposed.
The funny thing about these L7 attacks is typically the way attackers gain access to the systems, then shell them (backdoor to use for launching future attacks with either credentials into SSH or build out their own web API of sorts)....................... is all VERY fuckin' simple. Often, attackers throw some L7 attacks around, they get noisy and generate abuse reports.. the L7 attack options go down eventually. But of course with enough SHITTY and unreliable hosting companies that do not effectively handle L7 abuse reports, there are still 200+ shells the attackers have that continue to fake as being real web visitors. Obviously no forum is going to serve up 200+ visitors spamming 100 load requests (20,000+ requests/minute or 300+/second) without seeing some sort of spike in cache loads, depending on configs CPU/RAM, and of course when resource utilization gets top-heavy, loads begin to fail.
As there are hundreds (to say the least) of "booter" services.. this problem will not go away anytime soon! So I will be emphasizing focus on L7 blocking/countermeasure in the coming days. Blocking these attacks CAN be simple but this type o' sh*t is very much cat and mouse.
I block website loads unless you browser can calculate 1+1 with JavaScript, so the attacker just sends 2 every time. I generate random math problems to the client they solve before now connecting to the main server for example 137*2 or 100/2... the attacker now ties a JavaScript engine directly into their fake loader browser, or altogether just uses a whole fucking web browser automation engine to GENERATE _REAL_ browser loads, of which obviously all are fake and go on to solve all the bloody fuckin' JavaScript challenges/puzzles, but then ultimately have the childlike behavior of generating "more than normal" loads, but if someone holds F5 do we ban them? Fuck.
So at the end of the day, we are faced with some evident challenges of "squeak squeak" and *hiss*, back-n-forth-non-fuckin'-stop.
Thankfully companies like Cloudflare dedicated their entire business life to optimizing web caching and blocking common web-based attacks like this. I have heard people mention "Just enforce a cookie." trust me.. some of the newer floods carry cookies. As security advances, anti-security does too.
Not to be discouraging, but there are some very fun problems to solve regarding DDoS (and DoS-alike), and not just for web.. but all L7 attacks.
Last edited:
(if u r good at netfilter module (C programming.))