All our servers are bombarded by a never ending wp-login.php brute force by hacked Amazon AWS instances - they are also unblockable because they fly on the edge of sane thresholds. We want to block the whole of Amazon AWS but it appears that LE is using some of its network ranges for HTTP validation. Is there any chance you can make it known which AWS ranges are being used (not specific IPs - just subnets), so that we can block all else?
No, there is no list of IPs or subnets published. (And if they were, it would probably just be all of AWS and perhaps other providers.) They need to verify that they can connect from multiple vantage points on the Internet in order to know you truly "own" a name, and they need to ensure that people can't spoof them. Your basic options that I can think of are:
- Configure your firewall to allow requests for
/.well-knownfrom everywhere, even if it's blocking other requests. - Script your firewall to open up during the time that you're doing renewals, and close the firewall back up when renewals are done.
- Switch to DNS-01 authentication, so that only your DNS server needs to be publicly accessible all the time instead of also needing your web server to be so.
4 Likes
In addition to what my fellow volunteer already stated, you can read the "official" statement about this here: FAQ - Let's Encrypt
3 Likes
Put your web server behind a proxy (which can run on same system).
And add a catch for stupid stuff like that:
location ~ /*/wp-login.php {
access_log /logs/wp-login-php.access.log combined_ssl;
return 414;
}#location
Unless you actually have your wp-login.php as wp-login.php.
2 Likes
Good idea. Could also become a "black hole" using
return 444;
nginx docs:
The non-standard code 444 closes a connection without sending a response header.
2 Likes
thanks for the info. will go with blocking AWS at the web server side.
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.