How to deal with DDos attack?
-
@pichalite I've only ever seen 502 'bad gateway' in a restart scenario. Can you think of a reason why your system would show a 503?
-
@jongarrison Not sure why. I have a test installation running on c9. Some times after a
./nodebb restart, when I refresh the page I get 503. -
@jongarrison You should get 502 if you turn off NodeBB completely during restart (kill process, restart then) and nginx points to closed port in the meantime. If you however use NodeBB internal functions of restart/reload you're supposed to get a neat 503 page instead
-
@frissdiegurke It's a neat 503 page but don't think the "Excessive Load" message is appropriate during restart/reload.
-
Would it be possible for NodeBB to just wait before sending a response? NodeBB startup doesn't take that long.
-
@frissdiegurke Interesting
-
@pichalite said:
@frissdiegurke It's a neat 503 page but don't think the "Excessive Load" message is appropriate during restart/reload.
Sure it is! When NodeBB reloads or restarts, it uses the entirety of the system's resources to compile CSS/templates/js, and thus doesn't have any spare cycles to dedicate to NodeBB.
All this is handled on a lower level than NodeBB itself, so it's really out of our hands. The toobusy middleware checks for a lag in the Node.js event loop, and when system resources are tied up, this loop lag goes up, hence a 503... perhaps it's not excessive load, per se, but the system is running low on spare cycles
-
@julian According to https://www.npmjs.com/package/toobusy you have the capability to change the text thought. 503 is absolutely correct, only the text is too specific.
Wikipedia says:
503 Service Unavailable
The server is currently unavailable (because it is overloaded or down for maintenance). Generally, this is a temporary state.It's not about differentiating those cases
-
for changing the text -
To be honest I wonder very often how DDoS attacks can even occur.
It is not like I do not understand that there are some "bad guys" out there, but in the last year my site was not DDoSed any time.
No, I do not use CloudFlare to protect my site (got all settings disabled at it - except anycast DNS).The only reason which comes into my mind is that the providers are simply inexperienced or lack the proper ressources to block such attacks.
-
@AOKP said:
The only reason which comes into my mind is that the providers are simply inexperienced or lack the proper ressources to block such attacks.
Careful, @AOKP, such words could be to your disadvantage
Denial of service attacks can be mitigated by rules like fail2ban, firewall rules, etc.
Distributed denial of service attacks are very different, and it is difficult to determine when traffic is legitimate vs what is a garbage request.
When you control all of the resources from server to pipe, then sure, you can spend time figuring out who is doing what and taking steps to block bad requests, but when you're using a hosting provider, you've got a bit of pressure to resolve the situation immediately, otherwise you're looking at hefty fines (AWS), or service suspension/termination (DigitalOcean).
We make it a policy to not accept high risk customers without a significant investment in a DNS level DDoS protection service, typically CloudFlare (or actually, Incapsula, since they allow WebSockets at a lower pricing tier).
In @AlexFung's case, investigating the nginx access log showed repeated requests from a single IP, with the user agent
ApacheBench/2.3. -
@julian I bet every single penny I have that DDoS attacks will have no effect on my site, unless you use a really big botnet.
My provider uses Arbor and Tilera systems against these sort of attacks and is well known for its strong anti-ddos capabilites.
-
Try running your URL through Cloudpiercer.org... if your origin IP is exposed, cloud-based mitigation is largely useless when DNS attacks are still such an effective threat. Not all the bad guys are only toting Low Orbit Ion Cannons.
