Rate limit and URL per virtualhost, not per IP

wanah

Well-Known Member
#1
Hello,

Bruteforce attacks can happend from entire botnets, with sometimes 2000 IP's each trying to login with 1 try per minute. In such a case traditional modsecurity anti brute force rules wouldn't work (unless I haven't found out how).

What I want to do is limit per domain and not per IP.

On a nginx VPS that hosts a single site, I setup a ratelimit of 5 simultanious calls to URLS with wp-login.php and for URLs with xmlrpc.php.

No matter what IP's are used (10 different IP's or only 1 IP) when wp-login.php is called more that 5 times in one second all the following calls to these files give an error "503 ressource unavailable".

Is there an existing way to to say that for URL's that contain a specific regex, each URL can only be called X times per second (or X times simultaniously).

I already limit each IP to X times per second, but I now want to limit each URL to X times per second.

I can't do this on an URI basis, it needs to be on a comlete URL basis and block per URL as this is a shared hosting server and one account under attack shouldn't affect other accounts.

In our case this would completly resolve the whole WordPress brute force issue.
 

NiteWave

Administrator
#2
so during attack, this URL is not accessible to normal user as well

in theory implementing this feature in web server level looks possible, and looks possible implemented in a wordpress plugin ( or maybe one is there already ? )
 

wanah

Well-Known Member
#3
Yes, exactly.

It's better that the attack just stops the login URL from working then stopping the whole site from working.

A WordPress plugin still calls PHP and often the whole of WordPress and often also does database calls.

When a customer's website gets attacked on xmlrpc.php or wp-login.php, we currently disable access to xmlrpc.php in the htaccess file and restrict wp-login.php either by password or to the user's IP address and tell them to try removing the disabeling lines in a day or so. If this could be done automaticaly it would significanly reduce the server load and prevent users sites from becomming slow.
 

NiteWave

Administrator
#4
we currently disable access to xmlrpc.php in the htaccess file and restrict wp-login.php either by password or to the user's IP address
this looks a good approach. when "restrict wp-login.php either by password or to the user's IP address", normal user still can log in wordpress while bots can't so php process won't start to process the illegal login. just wonder why need disable access to xmlrpc.php at the same time. is "restrict wp-login.php either by password or to the user's IP address" not enough to prevent bots attack ?
 
Top