Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When internal hostnames are leaked to the clown

rachelbythebay.com

Post reply on HN
Print view View original

131–140 of 265 posts

Re: When internal hostnames are leaked to the clown

#131

Post by nottorp »

ale42 wrote: post #76
fragmede wrote: post #10

This highlights a huge problem with LetsEncrypt and CT logs. Which is that the Internet is a bad place, with bad people looking to take advantage of you. If you use LetsEncrypt for ssl certs (which you should), that hostname gets published to the world, and that server immediately gets pummeled by requests for all sorts of fresh install pages, like wp-admin or phpmyadmin, from attackers.

It's not just Let's Encrypt, right? CT is a requirement for all Certificate Authorities nowadays. You can just look at the certificate of www.google.com and see that it has been published to two CT logs (Google's and Sectigo's)

Now I get why they want to reduce certificate validity to 20 minutes. The logs will become so spammy then that the bad guys won't be able to scan all hosts in them any more...

Re: When internal hostnames are leaked to the clown

#132

Post by seethishat »

b1temy wrote: post #15

Is "clown GCP Host" a technical term I am unaware of, or is the author just voicing their discontent? Seems to me that the problem is the NAS's web interface using sentry for logging/monitoring, and part of what was logged were internal hostnames (which might be named in a way that has sensitive info, e.g, the corp-and-other-corp-merger example they gave. So it wouldn't matter that it's inaccessible in a private netw…

Also, sometimes, we use the term 'weenie' rather than 'clown'. They are interchangeable.

Re: When internal hostnames are leaked to the clown

#133

Post by jraph »

flexagoon wrote: post #128
jraph wrote: post #22

Earlier quoted context omitted.

That hypothesis seems less likely and more complicated than the sentry one. Scanning wildcards for well-known subdomains seems both quite specific and rather costly for unclear benefits.

Bots regularly try to bruteforce domain paths to find things like /wp-admin, bruteforcing subdomains isn't any more complicated

> Bots regularly try to bruteforce domain paths to find things like /wp-admin

Sure, when WordPress powers 45% of all websites, your odds to reach something by hitting /wp-admin are high.

The space of all the possible unknown subdomains is way bigger than a few well known paths you can attack.

Re: When internal hostnames are leaked to the clown

#135

Post by wasmitnetzen »

TZubiri wrote: post #17

>Hope you didn't name it anything sensitive, like "mycorp-and-othercorp-planned-merger-storage", or something. So, no one competent is going to do this, domains are not encrypted by HTTPS, any sensitive info is pushed to the URL Path. I think being controlling of domain names is a sign of a good sysadmin, it's also a bit schizophrenic, but you gotta be a little schizophrenic to be the type of sysadmin that never gets…

I've blown fairly competent colleagues' minds multiple times by showing them the existence of certificate transparency logs. They were very much under the impression that hostnames can be kept secret as a protection against external infrastructure mapping.

Re: When internal hostnames are leaked to the clown

#136

Post by mike-cardwell »

Only way I can think of protecting against this is to put a reverse proxy in front of it, like Nginx, and inject CSP headers to prevent cross site requests. Wouldn't block the NAS server side from making external calls, but would prevent your browser doing it for them as is the case here. Also would prevent stuff like Google Analytics if they have it. If you set up a proxy, you could also give it a local hostname like nas.local or something with a cert signed by your private CA that Nginx knows about, and then point the real hostname at Nginx, which has the wildcard cert.

Bit of a pain to set this all up though. I run a number of services on my home network and I always stick Nginx in front with a restrictive CSP policy, and then open that policy up as needed. For example, I'm running Home Assistant, and I have the Steam plugin, which I assume is responsible for requests from my browser like for: https://avatars.steamstatic.com/HASH_medium.jpg, which are being blocked by my injected CSP policy

P.S. I might decide to let that steam request through so I can see avatars in the UI. I also inject "Referrer-Policy: no-referrer", so if I do decide to do that, at least they wont see my HA hostname in there logs by default.

Re: When internal hostnames are leaked to the clown

#137

Post by jraph »

ahoka wrote: post #123
jraph wrote: post #50

Earlier quoted context omitted.

> Can't even name the domains on my own damn server with an expectation of privacy now. You never could. A host name or a domain is bound to leave your box, it's meant to. It takes sending an email with a local email client. (Not saying, the NAS leak still sucks)

I have internal zones in my home network and requests to resolve them never leave the private network. So no, it's not meant to.

"Meant to" may indeed not be really accurate.

However, domains and host names were not designed to be particularly private and should not be considered secret, many things don't consider them private, so you should not put anything sensible in a host name, even in a network that's supposed private. Unless your private network is completely air-gapped.

Now, I wouldn't be surprised that hostnames were in fact originally expected to be explicitly public.

Re: When internal hostnames are leaked to the clown

#138

Post by wbobeirne »

jeroenhd wrote: post #78
nomercy400 wrote: post #67

Earlier quoted context omitted.

From what I understand, sentry.io is like a tracing and logging service, used by many organizations. This helps you (=NAS developer) to centralize logs and trace a request through all your application layers (client->server->db and back), so you can identify performance bottlenecks and measure usage patterns. This is what you can find behind the 'anonymized diagnostics' and 'telemetry' settings you are asked to enabl…

My employer uses Sentry for (backend) metrics collection so I had to unblock it to do my job. I wish Sentry would have separate infra for "operating on data collected by Sentry" and "submit every mouse click to Sentry" so I could block their mass surveillance and still do my job, but I suppose that would cut into their profit margins. My current solution is a massive hack that breaks down every now and then.

Most organizations I've set Sentry up for tunnel the traffic through their own domain, since many blocking extensions block sentry requeats by default. Their own docs recommend it as well. All that to say, it's not trivial to fully block it and you were probably sending telemetry anyway even with the domain blocked.

Re: When internal hostnames are leaked to the clown

#139

Post by Arrowmaster »

paffdragon wrote: post #94
atmosx wrote: post #53

I bought a SynologyNAS and I have regretted already 3-4 times. Apart from the software made available from the community, there is very little one can do with this thing. Using LE to apply SSL to services? Complicated. Non standard paths, custom distro, everything hidden (you can’t figure out where to place the ssl cert of how to restart the service, etc). Of course you will figure it out if you spent 50 hours… but w…

You can run a container on Synology and install your custom services, tools there. At least that is what I do. For custom kernel modules you still need a Synology package for something like Wireguard. If you have OPNSense, it has an ACME plugin with Synology action. I use that to automatically renew and push a cert to the NAS. That said, since I like to tinker, Synology feels a bit restricted, indeed. Although there…

The extremely old kernel on Synology makes it hard or impossible to run some containers.

Re: When internal hostnames are leaked to the clown

#140

Post by rini17 »

Fancy web interfaces are road to hell. Do simplest thing that works. Plain apache or nginx with webdav, basic auth(proven code, minimal attack surface). Maybe firewall with ip_hashlimit on new connections. I have it set to 2/minute and for browser it's actually fine, while moronic bots make new connection for every request. When they improve, there's always fail2ban.

That the nas server incl. hostname is public does not bother me then.

Post reply on HN