It depends on what you define as unwanted traffic.
Personally I do not have an issue with bots as long as they behave and are not straight up malicious, so I rely on a combination of rate limiting, a fine-tuned OWASP CRS ruleset and an aggressive Fail2ban enforcement (hit 2 triggers and you get a 24 hour ban, 2 bans and you get banned for 30 days).
My sites also make extensive use of static elements and caching.
How do you deal with DDoS attacks on your infra / sites? Especially ones from residential proxies or vpn networks? These are the hardest to defend against as they often are relentless and no amount of proof-of-work, captchas or otherwise seems to stop them from coming. I don't think it's something you can easily block at any firewall level, the sheer volume of IP(s) and Subnets is too much.
Browsing is absolutely intolerable these days, with almost every website having a block screen, "we're checking your browser...", stuff like that. Lately I just close these websites immediately.
Cloudflare: "We reduced bot traffic by 80%"
Me: "Bro you reduced all traffic by 90%, my customers are pissed"
You can hide data in random static (for a novel captcha). Very obvious to most humans (if it becomes popular, the bots could probably be designed solve it; just requires diffing the images):
- https://fx.leftium.com/static
- https://www.youtube.com/shorts/tPfzNzy24to
---
I noticed most of the traffic to my hobby sites was bot traffic (probing for common vulnerabilities). So I added a robots.txt for well-behaved bots and rules for the bad ones. It works pretty well.
robots.txt: https://github.com/Leftium/robots-txt
Sample cloudflare rules:
(
http.request.uri.path contains "/wp-login"
or http.request.uri.path contains "/wp-admin"
or http.request.uri.path contains "/wp-content"
or http.request.uri.path contains "/wp-includes"
or http.request.uri.path contains "/xmlrpc.php"
or http.request.uri.path contains "/wordpress/"
or http.request.uri.path contains "/wp-json/"
or http.request.uri.path contains "/wp-config"
or http.request.uri.path contains "/wp/"
or http.request.uri.path.extension eq "php"
or http.request.uri.path.extension eq "aspx"
or http.request.uri.path.extension eq "asp"
or http.request.uri.path contains ".env"
or http.request.uri.path contains "sftp-config"
or http.request.uri.path contains ".vscode/"
or http.request.uri.path contains "credentials"
or http.request.uri.path contains "stripe"
or http.request.uri.path contains "secrets"
or http.request.uri.path contains "config.json"
or http.request.uri.path contains "config.yml"
or http.request.uri.path contains "config.yaml"
or http.request.uri.path contains "config.py"
or http.request.uri.path contains "config.inc"
or http.request.uri.path contains "config.rb"
or http.request.uri.path contains "settings.json"
or http.request.uri.path contains "settings.yml"
or http.request.uri.path contains "settings.py"
or http.request.uri.path contains "application.yml"
or http.request.uri.path contains "application.properties"
or http.request.uri.path contains "parameters.yml"
or http.request.uri.path contains "appsettings.json"
or http.request.uri.path contains "docker-compose"
or http.request.uri.path contains "/.git/"
or http.request.uri.path contains "/.circleci/"
or http.request.uri.path contains "/.aws/"
or http.request.uri.path contains "/.bitbucket/"
or http.request.uri.path contains "/.travis.yml"
or http.request.uri.path contains "serverless.yml"
or http.request.uri.path contains "debug.log"
or http.request.uri.path contains "error.log"
or http.request.uri.path contains "/storage/logs/"
or http.request.uri.path contains "_profiler"
or http.request.uri.path contains "phpinfo"
or http.request.uri.path contains "/debug/"
or http.request.uri.path contains "/horizon/"
or http.request.uri.path contains "/manage/"
or http.request.uri.path contains "fileman"
or http.request.uri.path contains "assetmanager"
)
I'm actually almost tempted to build a reverse proxy that detects this type of "scanning" behaviour and just drops it to the floor.