Firewall/ Layer 7 DDoS

LowEndGuy

@jooja said:

@AlexJones said:
Captcha web hosts that usually host vuln WordPress pages e.g DO. also try out nginx I have been able to handle many more users since switching to it. Like 70 r/s to 200 r/s serving 4k images. Also try enabling CF edge cache on resources/pages getting hit hard, it'll also speed up your site quite a bit. Lastly try ignoring query string if that's an option.

I ended up doing this:

Added edge cache for images, enabled bypassing the query string as well.

Switched my backend was a VPS server 4 gb ram server for a dedicated (i7)quad core server, 32 GB of RAM,2 2x240 SSD.

Changed WebServer to nginx.

Rate-limited connections at nginx

I already have CloudFlare 5 secs up aswell.

Did Query Cache (since the DB-Server is located far-away from WebServer)

Result:

When the attack "kicks in", my use of ram and cpu goes to 100%.

And all pages with "PHP" don't work and many php processes are generated on the server.

If I disable php-fpm, WebServer it works even under-attack and ram goes for 50%.

Anyone have any other suggestions?

This is where a solid service can help you, but cheap services won't be able to do much in this case, CloudFlare is good, but there are situations where it won't help as well (and this is one of them).

AlexJones

@LowEndGuy said:

@jooja said:

@AlexJones said:
Captcha web hosts that usually host vuln WordPress pages e.g DO. also try out nginx I have been able to handle many more users since switching to it. Like 70 r/s to 200 r/s serving 4k images. Also try enabling CF edge cache on resources/pages getting hit hard, it'll also speed up your site quite a bit. Lastly try ignoring query string if that's an option.

I ended up doing this:

Added edge cache for images, enabled bypassing the query string as well.

Switched my backend was a VPS server 4 gb ram server for a dedicated (i7)quad core server, 32 GB of RAM,2 2x240 SSD.

Changed WebServer to nginx.

Rate-limited connections at nginx

I already have CloudFlare 5 secs up aswell.

Did Query Cache (since the DB-Server is located far-away from WebServer)

Result:

When the attack "kicks in", my use of ram and cpu goes to 100%.

And all pages with "PHP" don't work and many php processes are generated on the server.

If I disable php-fpm, WebServer it works even under-attack and ram goes for 50%.

Anyone have any other suggestions?

This is where a solid service can help you, but cheap services won't be able to do much in this case, CloudFlare is good, but there are situations where it won't help as well (and this is one of them).

Ah I didnt see yet. Try and switch over to openlitespeed it's LSAPI is faster than nginx's phpfpm.

YokedEgg

@AlexJones said:

@LowEndGuy said:

@jooja said:

@AlexJones said:
Captcha web hosts that usually host vuln WordPress pages e.g DO. also try out nginx I have been able to handle many more users since switching to it. Like 70 r/s to 200 r/s serving 4k images. Also try enabling CF edge cache on resources/pages getting hit hard, it'll also speed up your site quite a bit. Lastly try ignoring query string if that's an option.

I ended up doing this:

Added edge cache for images, enabled bypassing the query string as well.

Switched my backend was a VPS server 4 gb ram server for a dedicated (i7)quad core server, 32 GB of RAM,2 2x240 SSD.

Changed WebServer to nginx.

Rate-limited connections at nginx

I already have CloudFlare 5 secs up aswell.

Did Query Cache (since the DB-Server is located far-away from WebServer)

Result:

When the attack "kicks in", my use of ram and cpu goes to 100%.

And all pages with "PHP" don't work and many php processes are generated on the server.

If I disable php-fpm, WebServer it works even under-attack and ram goes for 50%.

Anyone have any other suggestions?

This is where a solid service can help you, but cheap services won't be able to do much in this case, CloudFlare is good, but there are situations where it won't help as well (and this is one of them).

Ah I didnt see yet. Try and switch over to openlitespeed it's LSAPI is faster than nginx's phpfpm.

Or better more why do you need php?

Could you just move your site to static based or is php an actual necessity?

FHR

Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

YokedEgg

@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.
@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

Redis plus opcache if php is a necessity

Eliminating apache for nginx is half the battle.

FHR

@YokedEgg said:

@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.
@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

Redis plus opcache if php is a necessity

Eliminating apache for nginx is half the battle.

FastCGI caching > opcache. If the requests don't have to hit the PHP daemon at all, it will be faster.

AlexJones

Track down what pages the flood is hitting. Odds are it's probably my a resource intensive one such as login/register. Captcha those intensive pages with an invisible captcha it's better than nothing. Try out CF's rate limiting and wildcard your php pages. Also lower the connection time outs to reasonable values and do basic web server sec- block blank requests, user agents, etc. Those likely won't be legitimate users anyway

jooja

@FHR said:

@YokedEgg said:

@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.
@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

Redis plus opcache if php is a necessity

Eliminating apache for nginx is half the battle.

FastCGI caching > opcache. If the requests don't have to hit the PHP daemon at all, it will be faster.

I made a cache for all GET requests,i also check if user is not logged into the system.

Website is online and Stable now.

Thanks for everyone !

YokedEgg

@jooja said:

@FHR said:

@YokedEgg said:

@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.
@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

Redis plus opcache if php is a necessity

Eliminating apache for nginx is half the battle.

FastCGI caching > opcache. If the requests don't have to hit the PHP daemon at all, it will be faster.

I made a cache for all GET requests,i also check if user is not logged into the system.

Website is online and Stable now.

Thanks for everyone !

You're welcome.

Thank you for coming to LET support desk, please come again.

LowEndGuy

@YokedEgg said:

@jooja said:

@FHR said:

@YokedEgg said:

@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.
@FHR said:
Cache, cache, cache. Cache all dynamic content. Since you confirmed tuning off PHP makes the attack bearable, try this: https://serversforhackers.com/c/nginx-caching (Scroll down to "Proxy Caching").

Just as a warning: You don't want to cache content for logged in users.

Redis plus opcache if php is a necessity

Eliminating apache for nginx is half the battle.

FastCGI caching > opcache. If the requests don't have to hit the PHP daemon at all, it will be faster.

I made a cache for all GET requests,i also check if user is not logged into the system.

Website is online and Stable now.

Thanks for everyone !

You're welcome.

Thank you for coming to LET support desk, please come again.

Ok, now I've just loled out. :P