Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Ahh so bots are finding subdomains by scraping SSL certificates?
Yes, and also by trying common subdomains under the main domain (like
jellyfin.,home.etc.) (They also scan the entire IPv4 address space, all TCP ports, over and over, but that's a different discussion.)If you're using DDNS you have to also be careful where you put the
AandAAAArecords. Some people put them on the main domain and then do a wildcardCNAMEpointing to it for all the subdomains, or individual subdomainCNAMEs. But since the main domain is known from TLS cert logs it's trivial for bots to also check to see if there'sA/AAAArecords on it.It's better to put the
A/AAAAon a dedicated subdomain, obfuscate the name beyond trivial guesses (eg. maybe don't useip.), and make an individualCNAMEfor each services that points to the IP subdomain, and obfuscate those service subdomains similarly.For those who aren't familiar with DNS, the information in it is publicly available to anybody who can name a [sub]domain and record type explicitly, but they refuse to do "list all the records for all the subdomains of this domain". So bots are limited to asking for the most commonly used record types on the main domain but can't get to records on subdomain names unless they can name the subdomain. (For completion, asking for a list of all records is possible, but nowadays due to abuse that function is restricted on all the public servers to just the known IPs of their fellow redundant servers.)
A similar limitation applies to reverse proxies, bots can't get to a service behind it unless they can correctly name the FQDN that the proxy uses for that service. (But please note that a reverse proxy works independently of DNS. If the proxy has
foo.example.comdefined to reach a service, it will work even if that domain isn't in DNS or doesn't exist.)Even after taking these measures you have to keep in mind that this is not security, it's obscurity. It cuts down on bot scans which is great but don't assume it means nobody knows your service domains. Your ISP probably knows them, there are DNS servers out there that know them, your mobile carrier can see them, and if you ever connect to WiFi when away from home the owners of those WiFi can see them (think hotels, airports, coffee shops etc.) It's not out of the question for a coffee shop WiFi to have been compromised and to collect URLs and attempt attacks against them. Use VPN or a SSH tunnel to connect to services whenever possible, rather than exposing them publicly, and if you must expose them publicly then use mTLS or at the very least a custom header key.
That was my experience also. Within minutes of spinning up any new subdomain with a dedicated A DNS record, I had bots that scraped it from https://crt.sh/ knocking on the door.
With wildcard subdomains and relatively obscure URLs, it's pretty quiet.