Modify /login endpoints to avoid DDOS and dictionary attacks
My forum is getting spammed on
/loginby more than 8000 computers. The normal daily traffic is about 500-600 unique computers.
The requests are only hitting /login. A GET request is first sent and then 10-15s later a POST request with some dictionary credentials. My instance is a t2.micro on AWS and it's suffering a lot in terms of CPU usage.
At this moment, I'm monitoring all requests in my plugin and then enabling a WAF rule that blocks all requests to /login. I'm also automatically banning the IPs in WAF that only send requests to /login because in theory there should be requests to other endpoints, like /assets, /categories, etc.
I'm mainly using WAF because it prevents the request from hitting the instance/nginx, therefore, it saves a lot of CPU. I've got 2 questions:
1 - Is it possible to "easily" change the /login endpoint to some other random string? The attacker could just look for the new endpoint and change the attack, but I believe this attack is coming from random bots that are simply checking if /login is valid, i.e., doesn't return 404. By changing the endpoint, I could just enable the WAF rule blocking /login and then the legit forum users wouldn't be affected.
2 - Is it normal for a password check with bcryptjs to be somewhat CPU intensive? I've noticed that whenever a regular user logins or the dictionary attack finds a valid username (but not the password), then the CPU usage increases considerably.
Not easily, as
/loginis hardcoded in a couple places in the codebase. To combat these types of attacks, we introduce a delay when logging in that somewhat matches the bcrypt runtime. You could always edit the codebase to increase the delay some more, but what I'd recommend is setting up spam-be-gone so these requests are curbed before it hits bcrypt.
Yes. bcrypt is processor intensive by design (that's what makes it so good as a password hashing algorithm, but I am no expert).