1

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?

| improve this question | | | | |
  • Is it bandwidth as in bits-per-second? Or "bandwidth" as in a cloud provider only gives you so many bytes of traffic in/out per month before charging you extra? Or is this hardware so weak that it really can't handle many requests per second? A 404 or 403 response can be just a few bytes long. Other responses or timing out the client might be interpreted as "try again later". (Possibly. Maybe bots just give up after one attempt.) Have these requests and their responses really locked legitimate users out yet? – Future Security Apr 7 at 18:36
4

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 POST and 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.

  1. Enumerate users. There are several possibilities to get valid usernames from a WP installation:

    • /?author=1 will 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.
    • The /wp-json/wp/v2/users API gives JSON output of all users, username in slug:.
    • 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!
  2. Use password lists against these users. Usually leaked passwords.

    • Recently I've seen e.g. password from the rockyou.txt list (back from 2009).
    • Passwords today are amazingly similar to the 2019 findings from wpdevguides.com's honeypot.
  3. Once succeed, try and upload a malicious plugin or a theme.

    • POST /wp-admin/update.php?action=upload-plugin is used for uploading plugins.
    • POST /wp-admin/update.php?action=upload-theme is 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 GET to test the access and POST to upload the malware.
  4. 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.

| improve this answer | | | | |
  • Very great and detailed answer! – Heng Ye Apr 8 at 15:19
2

No.

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.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.