New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PSA Fedi/Masto admins, useragent allowlist, edit to deny.d conf regarding blocking hidden files also blocking .well-known. Also, .dump is a good contender to add for denied extensions #509
Comments
Another note to folks hosting fediverse instances such as Mastodon: A good contender to also deny is the api calls for your instance's instance blocks and known peers. This is exclusively used by blocklist scrapers which still attempt to access the peers and blocks regardless if you have disable these in the software directing attempts to 401s.
|
And if you are like me and want to block all at once outdated instance versions, such as like any version that's 2+ years old, which at time of writing goes are Pleroma v2.3.0 and older versions and Mastodon v3.3.3 and older, though personally at time of writing I've stopped at Mastodon v3.2.2, you can do the following in your bad useragents conf:
And if you want to also outright block Soapbox instances, and the fba blocklist scraper, you can do
There is ofc more than just Mastodon and Pleroma, but if you were to do this with Misskey too, it gets kind of complicated considering that certain old pre v12.x versions have been forked, aka before Misskey overhauled it's UI. Mastodon and Pleroma are pretty simple ones though. Though this would also block say a Pleroma 3.5.0 instance if someone forked and changed the useragent to say something like "Pleroma 1.0+3.5.0", as like there's Hometown fork of Mastodon which does like "Mastodon/1.1.1+4.0.2" to mean it's version 1.1.1 of Hometown on version 4.0.2 of Mastodon. Personally it should be the other way around so there's no risk of say Hometown some day reaching v2.1.0 and getting blocked because of the useragent is |
Oh and I just realised that some instances get blocked due to false flags from the global block list, such as .ninja instances for example. So you'll want to add to the useragent allow list Anarchy is another, so allowlist that as well:
Ok had another much deeper careful look and came to all these that can definitely cause false flags for fedi instances so allow listing them is recommended if running a fedi instance:
Definitely tbf wouldn't recommend as a fedi instance to have the auto updating for this. I planned to have it run the updater whenever I update packages, but as a fedi instance definitely want to check over the keywords whenever you update to ensure there's not something new added that happens to false flag a fedi instance. |
Did a fork including the changes https://github.com/jwbjnwolf/nginx-bad-bot-blocker, removing the hotlinking, adding the Far easier to manage than allowlisting them, with the rate each update to the global blocklist file adds & removes keywords, that I can see a changes/conflicts for each update.
|
Glad for this existence, and used this put on my proxy server I shield my upstream servers behind, one of which being a Mastodon server. (see important allow list below: #509 (comment))
Not necessarily a bug report or anything as you do disclaim big caution with the deny.d config, but few things as notes to others:
The location block for denying hidden file requests as it is:
location ~ /\. { return 444; }
, that also blocks .well-known requests (though excluding the acme challenge which has a location block setting the root to/tmp/letsencrypt
.Fediverse instances for federating purposes make strong use of the .well-known directory. Therefore excluding .well-known is a good idea, so change that location block to be like:
location ~ /\.(?!well-known).* { return 444; }
.Also, adding
dump
to the list of denied file extensions such as .sql, .conf etc, is something that should be good too, so if you dump your database as a .dump and have it stored in a web folder accidentally, then you're shielded from that being leaked out.. even though you should obviously NOT let that happen in the first place.Lastly, image hotlinking, denying that as is can cause your images with your setup to break (and personally I choose to not to deny this. (Years back on shared hosting the admin had to make me a new account because disabling hotlinking both in cpanel and cloudflare completely irreversibly bugged my account lol).
The text was updated successfully, but these errors were encountered: