If you do a GET / request against the IP (typically http too) does it yield a redirect to your proper fqdn? It shouldn't return anything and remain stealthy as you likely dont want to expose anything directly on IP connections and rely solely on your vhosts.
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: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
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!
I can't say I know the answer but a few ideas:
- did you access it with a browser? Maybe it snitches on you or some extension does?
- did you try to resolve it with a public DNS server at any point (are you sure nothing forwarded the request to one)?
You could try it again, create the domain in the config and then do absolutely nothing. Don't try to confirm it works in any way. If you don't see the same behaviour you can do one of the above and then the other and see when it kicks in. If it gets picked up without you doing anything..then pass!
When a CA issues an SSL/TLS certificate, they're required to submit it to public CT logs (append-only, cryptographically verifiable ledgers). This was designed to detect misissued or malicious certificates.
Red and Blue team alike use this resource (crt.sh) to enumerate subdomains.
Chrome: Sees new website domain
Google: 👀
You need to look at the DNS server used by whatever client is resolving that name. If it's going to an external recursive resolver instead of using your own internal DNS server then you could be leaking lookups to the wider internet.
My guess would be NSEC zone walking if your DNS provider supports DNSSEC. But that shouldn't work with unregistered or wildcard domains
The next guess would be during setup, someone somewhere got ahold of your SNI (and/or outgoing DNS requests). Maybe your ISP/VPN service actually logs them and announce it to the world
I suggest next time, try setting up without any over-the-internet traffic at all. E.g. always use curl with the --resolve flag on the same VM as Apache to check if it's working
if you use Let’s Encrypt (ACME protocol) AFAIK you can find all domains registered in a directory that even has a search, no matter if it’s wildcard or not.
It was something like this https://crt.sh/ but can’t find the site exactly anymore
LE: you can also find some here https://search.censys.io/
This.
That's why temping obscurity for security is not a good idea. Doesn't take much to be "safe", at least reasonably safe. But that not much its good practice to be done :)
Holy shit, this has every cert I’ve ever generated or renewed since 2015.
Certificate Transparency makes public all issued certificates in the form of a distributed ledger, giving website owners and auditors the ability to detect and expose inappropriately issued certificates.
If you have browser with search suggestions enabled, everything you type in URL bar gets sent to a search engine like Google to give you URL suggestions. I would not be surprised if Google uses this data to check what it knows about the domain you entered, and if it sees that it doesn't know anything, it sends the bot to scan it to get more information.
But in general, you can't access a domain without using a browser which might send that what you type to some company's backend and voila, you leaked your data.
Easily verified by creating another bunch of domains and using a browser that doesn't do tracking - like waterfox
What you can do is segregate networks.
If the browser runs in, say, a VM with only access to the intranet and no internet access at all, this risk is greatly reduced.
Maybe that particular subdomain is getting treated as the default virtual host by Apache? Are the other subdomains receiving scans too?
I don't use Apache much, but NGINX sometimes surprises on what it uses if the default is not specifically defined.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| CA | (SSL) Certificate Authority |
| DNS | Domain Name Service/System |
| IP | Internet Protocol |
| SSL | Secure Sockets Layer, for transparent encryption |
| TLS | Transport Layer Security, supersedes SSL |
| VPN | Virtual Private Network |
| VPS | Virtual Private Server (opposed to shared hosting) |
[Thread #990 for this comm, first seen 11th Jan 2026, 01:25] [FAQ] [Full list] [Contact] [Source code]
Good bot
Kudos to the bot.
For anyone who needs to read it: At the end of the day this is obscurity, not security; however obscurity is a good secondary defense because it buys time.
I too would be interested to learn how this leaked
A long time ago, I turned a PC in my basement into a web server. No DNS. Just a static IP address. Within 15 minutes, the logs showed it was getting scanned.
SSL encrypts traffic in-transit. You need to set up auth/access control. Even better, stick it behind a Web Application Firewall.
Or set up a tunnel. Cloudflare offers a free one: https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/
Do post again if you figure it out!
Will do!
You say you have a wildcard cert but just to make sure: I don't suppose you've used ACME for Letsencrypt or some other publicly trusted CA to issue a cert including the affected name? If so it will be public in Certificate Transparency Logs.
If not I'd do it again and closely log and monitor every packet leaving the box.
The random name is not in the public log. Someone else suggested that earlier. I checked CRT.sh and while my primary domain is there, the random one isn't.
My next suspicion from what you've shared so far apart from what others suggested would be something out of the http server loop.
Have you used some free public DNS server and inadvertently queried it with the name from a container or something? Developer tooling building some app with analytics not disabled? Any locally connected AI agents having access to it?
We're always watching.
I run my webservers behind a pfsense firewall with ssl offloading(using a wildcard cert) with a static IP and use Haproxy to have sub-domain's go to individual servers. Even though I've seen my fair share of scans, I only ever expose port 443 and keep things updated.
Recently though someone on here mentioned routing everything over Tailscale via a VPS. I didn't want to pay for a VPS and frankly can't even find one that is reasonably priced in the US(bandwidth limits mainly), so I threw Tailscale onto my pfsense, setup split-dns on Tailscale's admin panel with my domain name, and then reconfigured Haproxy to listen on my Tailscale interface. Even got IPv6 working(huge pain due to a bug it seems). Oh and setup pfblocker.
My current plan is I'm going to run my webservers behind Tailscale and keep my game servers public and probably segment those servers to a different vlan/subnet/dmz/whatever. And maybe just have a www/blog landing page that is read only on 443 and have it's config/admin panel accessible via my tailscale only.
Anyway, back on topic. I run my game servers and I don't advertise them out anywhere(wildcard cert) and do whitelist only, yet I still see my minecraft servers get hit constantly on port 25565.
So not much you can do except minimize exposure as much as possible.
Are you sure they're hitting the hostname and not just the IP directly?
Shows up by name in the apache other_hosts...log, so yes
Going to IP directly could redirect to your first domain. This would trigger another request to your domain and could result in your logs.
Reverse DNS? Or vuln scans just hitting IPs. Don't need DNS for that.
Yeah, this is interesting, I'll dig more into this direction.
But the randomly generated subdomain has never seen a DNS registrar.
I do have *.mydomain.com registered though...hmmm
All the obvious things have been mentioned.
The only way to identify the problem is to share the exact steps youve followed and then others can reproduce.
Based on what youve told us, no one knows how the subdomain is leaked. Without meaning to be derisive, that suggests that something youve told us isn't quite correct.
Well, the good news is that I at least think I'm doing all the right things.
I'll spin up a new VM tomorrow and start from scratch.
Did you yourself make a request to it or just set it up and not check it? My horrifying guess it that if you use SNI in a request every server in the middle could read the subdomain and some system in the internet routing is untrustworthy.
You need better logging. Try doing a packet capture with tcpdump then decrypt the HTTPS traffic. Because what you've described so far, especially before the edit makes no sense.
If you don't have a DNS record pointing the subdomain to the IP address of the server, it shouldn't be possible to resolve the IP for random Internet users. If this VHOST only exists in your Apache config file and nowhere else, it is private.
Scans from where? Is it exposed to the internet? What does the scan traffic look like?
Mostly from AWS or the like, with occasional Chinese and Russian origins.
The scans look like requests to various WordPress endpoints, JavaScript files associated with known vulnerabilities etc
@BonkTheAnnoyed@lemmy.blahaj.zone are you generating certificates for each of the random subdomains?
Fitting that someone from an instance on a random subdomain commented on this lol
I don't think so? I have a letsencrypt wildcard cert, and reference that in the relevant .conf
Inb4 some lucky dude just ran sublist3r or wfuzz on your subdomain and got a hit
I mean, it could be... I'll try it with a 128 char base 52 name and see what happens
Have you also tried making a subdomain and not making any requests to it yourself? So no browser access or other DNS resolution requests for the new subdomain. That should rule out some of the other possible causes suggested in the other comments.
Dang, it could be the upstream DNS server passing along client queries. Maybe the ISP?
In that case not even curl would be safe unless you could ensure all queries only resolve on your gear. Either use a host file entry or local DNS server.
Have you sent the URL across any messaging services? Lots of them look up links you share to see if it's malware (and maybe also to shovel into their AI). Even email services do this.
Nope, but that's a good suggestion. I set this one up brand new for the experiment.
Following this thread!
Stupid question, but are you somehow publicly exposing your vhost config (or a bak file of it)? Or do you see logs of someone bruteforcing the subdomain?