Confused about bot scanning my domain

https://lemmy.world/post/13289360

Confused about bot scanning my domain - Lemmy.World

So i have a domain that I have been using solely for homelab and VPS services (domain.example). I have my A and AAAA record for my VPS proxying through cloudflare (proxy.domain.example) and a DNS A record pointing towards my homelab for my home Wireguard (wg.domain.example) with no other records pointing home or anywhere. I have a couple of services at home with certificates for example (proxmox.domain.example, nas.domain.example, router.domain.example) that are using cloudflares API token but they do not have records listed at cloudflare Now my issue is I specifically setup a Cloudflare WAF to block every continent/country except my own and this is now showing in the events that a crawler is attempting to access router.domain.example, nas.domain.example, homeassistant.domain.example. Do I have any reason to be concerned and also how would this web crawler only be searching for my home lab domains. None of these services are public facing.

Probably not. Itโ€™s most likely automated scanning and the subdomains seem common enough to be included in wordlists. Another possibility is that the subdomains have leaked somehow, do you use LetsEncrypt? If so, the existence of your subdomains is public knowledge and can easily be picked up by bots.
Ahhhh thank you. Yes I use LetsEncrypt for all the homelab services which explains it then.
Its one reason i use DNS challenge wildcard domains.
I know security through obscurity is not security, and that a leaked wildcard cert is more damagingโ€ฆ However the likelihood of a leaked cert is slim, the convenience is huge, the attack window isnโ€™t huge (well, 90 days) and less published information about internals feels more secure.
maybe you issued one certificate with multiple domains, mixing internet facing ones with purely internal. It is very easy to discover hidden subdomains inspecting the certificate you get from a public service

If anyone is interested in mitigation, the only way around this AFAIK is to start with a brand new domain, only use wildcard certs (with DNS validation), and donโ€™t bundle multiple renewals into a single cert.

Also, donโ€™t enter your domain or related IP address into dns reverse engineering tools (like dnsdumpster), and check certificate transparency logs (crt.sh) to see what information related to your cert renewals has been published.

This wonโ€™t stop automated bots from scanning your ip for domains, but should significantly reduce the amount of bots that discover them

crt.sh | Certificate Search

Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)

I think it is generally okay to bundle the root domain certificate and the wildcard for its subdomains into a single renewal.

So for example:

example.com *.example.com

Yepp sorry - what I meant was bundling multiple different root domains, e.g. example.com & example1234567.org in the same cert.

I currently do as you mentioned above, renewing with just one root and its accompanying subdomain wildcard.

Itโ€™s not just letโ€™s encrypt - the common names of any SSL cert issued by a public CA have to be recorded in a public certificate transparency log. You can use tools like crt.sh to search the logs
crt.sh | Certificate Search

Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)

This is my thought as well.

Those services are running on some ports and someone was able to see that there are services running on those ports. Now they (or more likely, their script) is trying to find out what those services are to see if there are exploits.

So to OPs question should they be worried? No. This is par for the course today. But is a great example of why you need to be vigilant in updating your services and platforms, use strong passwords, MFA, etc.