Blunt Banhammer Blocks Basic Bots Ballistically
18 points by soulcutter
18 points by soulcutter
Trusting XFF header blindly sounds like a bad idea to me.
If you have to use it (ie you are behind a proxy but don't control it or otherwise can't use PROXY protocol) you should generally validate that the connecting address (REMOTE_ADDR) is that proxy, before trusting XFF header - otherwise nothing stops someone from making requests to you with arbitrary XFF headers.
Checking for a valid non private IP also doesn't help you here, because you're checking the XFF headers first and exiting early so a bot spamming you with random public addresses in XFF will not be blocked and cause you to block other addresses.
It's not often I'd expect to see an easily achieved false positive and false negative concurrently.
i don’t know. it looks complicated. why not tail -f access.log | grep honey and firewall-ban the ips found!?
Basically what I do with fail2ban and an invisible link. Doesn't catch as many things as iocaine but it's non-zero.
And fail2ban can do expiring bans so you don't permaban some entire cgnat forever just because one person was inadvertently hosting a botnet on their temu tv
Is throwing {$UA} unquoted in .htaccess like that safe?
This entire script is insecure garbage.
🤷 I don't know enough PHP to judge.
But I'm surprised to see nothing arbitrating concurrent access to the .htaccess file. The code, as written, seems like it would result in file_get_contents returning nothing and .htaccess being all but cleared under any serious load?
Reading further, at least two commenters on the page itself have pointed out these issues and presented better solutions.
Probably. It’s in a line comment, so you’d need to inject a line break (with ␊ presumably the only candidate), and it’s derived from a field value and such control characters are not permitted in field values. HTTP/1 will be structurally immune. An HTTP/2 implementation could conceivably be vulnerable, but I’d be very surprised if Apache’s was.