I have a non-wordpress website running on a not-so-powerful server. Bots often try to find admin pages (such as wp-login/wp-admin), which increases the bandwidth that is used. Here, in a comment, MSalters mentions that I could return a non-standard error code to mess with the bots. Will this help stop the bots from preventing legitimate users from accessing the website by consuming all of the bandwidth?
Bandwidth? Preventing legitimate users? Unlikely!
This is not a denial-of-service (DoS) attack in nature.
These are brute-force login attempts. They are short
GET requests with short replies – not downloading huge files. Replying
200 OK vs.
403 Forbidden or
404 Not Found consumes relatively same amount of bandwidth, which is next to nothing. Configuring the server to reply with
403 might save you from an extra file system access, though, which means a little less system resources is spent.
Also, it's not like the bots are flooding requests; e.g. in the last 24 hours my honeypot has got 248
POST request, which is approximately 10 attempts in an hour. Most certainly any web server can handle this background noise of the Internet.
These attacks have opposite goal than DoS attacks
The currect approach for typical WP attacks seems to be using botnets for broad scans (many sites), moving slowly to the next phase. Proceeding slowly from a wide set of IP addresses they can avoid being Fail2Banned. The attack is not targeted against your server, but it's about finding the weakest link i.e. the one with the weakest (administrative) password.
Enumerate users. There are several possibilities to get valid usernames from a WP installation:
/?author=1will give you articles from the first user by redirecting to
/author/username/, etc. The attack could enumerate all users, but it's likely the first user is an administrator.
/wp-json/wp/v2/usersAPI gives JSON output of all users, username in
- The login form itself gives different response when the user exists.
- XML-RPC. Disable XML-RPC and REST API from your WP if you don't use them!
Use password lists against these users. Usually leaked passwords.
- Recently I've seen e.g. password from the
rockyou.txtlist (back from 2009).
- Passwords today are amazingly similar to the 2019 findings from wpdevguides.com's honeypot.
- Recently I've seen e.g. password from the
Once succeed, try and upload a malicious plugin or a theme.
POST /wp-admin/update.php?action=upload-pluginis used for uploading plugins.
POST /wp-admin/update.php?action=upload-themeis used for uploading themes.
- It's all automated: you don't see someone downloading all the JS/CSS/images that accessing the admin page would produce. It's just a single
GETto test the access and
POSTto upload the malware.
Hide the tracks.
- Typically, the uploaded plugin or theme is just for giving one-time access to the installation files. If the malware was a plugin or a theme, you'd be able to uninstall it.
- Instead, you could see a direct access to the script that does some other modification, maybe to the core installation or another theme or plugin. This could be anywhere. Once the payload is hidden, the plugin/theme launches a self-destruction. Everything seems to be just fine, and once the logs have rotated and removed, all tracks are gone.
Even if you had a WordPress installation, the goal is not to make the site unresponsive to the legitimate users. That would reveal the malicious actions. The real goal could be e.g. stealing information like credit card numbers or PII, or making the installation part of the botnet for infecting more sites.
If a bot never probed your website before, it doesn't know that this specific page does not exist. It must make a request to find out. If it gets a 404, it can either remember this fact and avoid requesting this site again, or it simply forgets about it and might request the same resource in vain again later. The latter approach is probably used more often, because it is simpler to implement and doesn't require the overhead of tracking failed requests.
What would change if the server returns another status code or a redirect or some other gimmick? Nothing. The bot would realize that it does not reach the real admin page and either stores this information or not. Why should it behave differently than before? In both cases it is clear that there is no admin login page there.
If your server is the bottleneck, I recommend a change in your architecture. You can use a proxy or application level firewall in front of the web server, which handles requests to resources that do not exist on your web server. That way, the web server will not even see the requests and can focus on handling the requests directed at existing functionality.
If the bandwidth is the bottleneck, you must address the problem at provider level. Many providers offer a service to filter DDoS attacks before they can reach you. If simple bot activity already consumes your bandwidth, you might have an entirely different problem though.
You should investigate further, what's actually causing the problem. Initially you mentioned that your server is not powerful enough, in the end you mentioned a lack of bandwidth. Pinpointing the problem will help you decide on the next steps.