Like every other server revealing they use Apache or Nginx? Yeah, zero days in software are an issue so it's important to be vigilant for any public deployment, but it's also not something to count against unless the software is not being maintained or too slow to fix issues.
I've talked to devs who added PHP headers and fake server name headers to their servers. A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them.
This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads. It can also make for an easy source of blacklisted botnet IPs. This stuff takes maybe five minutes to set up and it weeds out a lot of the automated crap.
> A fake /wp-login/ also seems to greatly confuse the automated scanners, especially if you slowloris them.
You're just wasting a bit of your own resources for no gain here. If you want to "do something about it", throw that IP onto temporary blacklist (temporary because those IPs will inevitably rotate and might be actual dynamic ISP IPs that can be given to different user next time)
> This won't stop any kind of targeted attack, but it may confuse the low-effort automated scripts enough to send the wrong types of payloads.
Slowing down automated scripts barely takes any resources. Slowing them down would prevent their batch enumeration, spreading out the load of their attacks. It's not much, but it's probably taking fewer resources than ignoring them.
If you trap them in the wp-login stage, they probably won't get to the next part of their automated attack that you may actually be vulnerable to. Plus, with a bit of luck, criminals will ignore your server after finding out their bots keep getting stuck when they attack you.
If there's some kind of vulnerability in your software, you'd probably want to try to get bots to submit payloads for another type of software that won't do anything. An Apache 0day won't affect a Caddy server, and many PoCs will check if the target is vulnerable before attacking. Theoretically the attackers could patch that out, but many of them are too lazy to do that.
Imagine an automated scanner and attack tool. First it fingerprints your server, then it attacks with only payloads it thinks may work. If you trick it into thinking you run WordPress, for example, then it will attack you with WordPress payloads that won't affect you, even if it happens to know one that does.
Attackers have limited resources, so slowing them down with slowloris, or tricking them to use the wrong attacks provides protection. Dedicated attackers may notice the WordPress trick or may just run every payload against you, but automated scanners that are trying to be efficient will not. Hopefully a WAF can detect that much more noisy attack and deny-list their IP address(es), and other more traditional defences kick in.
