I love that this write-up is hosted both on HTTP and HTTPS. I cannot access the HTTPS version but the HTTP display just fine. Now that's reliability.
> I cannot access the HTTPS version
Curiosity begs: why not?
When internal hostnames are leaked to the clown
211–220 of 265 posts
Re: When internal hostnames are leaked to the clown
#212I have investigated similar situation on Heroku. Heroku assigns a random subdomain suffix for each new app, so URLs of apps are hard to guess and look like this: test-app-28a8490db018.herokuapp.com. I have noticed that as soon as a new Heroku app is created, without making any requests to the app that could leak the URL via a DNS lookup, the app is hit by requests from automatic vulnerability scanning tools. Heroku c…
> certificate authority logs, which are actively monitored by vulnerability scanners
That sounds like a large kick-me sign taped to every new service. Reading how certificate transparency (CT) works leads me to think that there was a missed opportunity to publish hashes to the logs instead of the actual certificate data. That way a browser performing a certificate check can verify in CT, but a spammer can't monitor CT for new domains.
Re: When internal hostnames are leaked to the clown
#213Isn't the article over emphasising a little bit on leakage of internal urls ? Internal hostnames leaking is real, but in practice it’s just one tiny slice of a much larger problem: names and metadata leak everywhere - logs, traces, code, monitoring tools etc etc.
Is it a real problem? My internal hostnames resolve to RFC-1918 addresses and I have a firewall. If I wasn't so lazy, I'd use split DNS.
Re: When internal hostnames are leaked to the clown
#214The Clown is my master
I've been chosen!
Eeeeeeeeeah!
Re: When internal hostnames are leaked to the clown
#215Earlier quoted context omitted.
NAS is the primary function. But yes, I want full linux server that I can decide what to install and which protocol to use to upload and/or download files.
Why not just leave the NAS to be a NAS and get a separate server? You're probably better off not trying to overload the NAS to be everything.
Why do I want two things when I can have one? Newer nases with n100 or similar are pretty powerful for the cost/package.
Re: When internal hostnames are leaked to the clown
#216Earlier quoted context omitted.
A bunch of out-of-the-box NAS manufacturers provide a web-based OS-like shell with file managers, document editors, as well as an "app store" for containers and services. I see the traditional "RAID with a SMB share" NAS devices less and less in stores. If only storage target mode[1] had some form of authentication, it'd make setting up a barebones NAS an absolute breeze. [1]: https://www.freedesktop.org/software/sys…
Storage target mode is block-level, not filesystem-level, meaning it won't support concurrent access and any network hiccup or dropped connection will leave the filesystem in an unclean state.
> ...any network hiccup or dropped connection will leave the filesystem in an unclean state.
Given that the docs claim that this is an implementation of an official NVMe thing, I'd be very surprised if it had absolutely no facility for recovering from intermittent network failure. "The network is unreliable" [0] is axiom #1 for anyone who's building something that needs to go over a network.
If what you report is true, then is the suckage because of SystemD's poor implementation, or because the thing it's implementing is totally defective?
[0] Yes, datacenter (and even home) networks can be very reliable. They cannot be 100% reliable and -in my professional experience- are substantially less than 100% reliable. "Your disks get turbofucked if the network ever so much as burps" is unacceptable for something you expect people to actually use for real.
Re: When internal hostnames are leaked to the clown
#217>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.
Can't it? If you get a wildcard certificate?
Otherwise if you are getting a domain specific certificate, you are obviously giving your cert provider the domains, and why would you assume it would be secret?
Re: When internal hostnames are leaked to the clown
#218Is "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…
I remember the term "clown computing" to describe "cloud computing" from IRC earlier than 2016
I use a localhost TLS forward proxy for all TCP and HTTP over the LAN
There is no access to remote DNS, only local DNS. I use stored DNS data periodically gathered in bulk from various sources. As such, HTTP and other traffic over TCP that use hostnames cannot reach hosts on the internet unless I allow it in local DNS or the proxy config
For me, "WebPKI" has proven useful for blocking attempts to phone home. Attempts to phone home that try to use TLS will fail
I also like adding CSP response header that effectively blocks certain Javascript
It sounds like the blog author gave the NAS direct access to the internet
Every user is different, not everyone has the same preferences
Re: When internal hostnames are leaked to the clown
#219>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…
TLS 1.3 has encrypted client hello which encrypts the domain name during an HTTPS connection.
That's one of those features that's not quite standard, but risks getting into paranoid threat models , like DNS over HTTP, residential proxies, Tor.
Re: When internal hostnames are leaked to the clown
#220Earlier quoted context omitted.
> any sensitive info is pushed to the URL Path This too is not ideal. It gets saved in the browser history, and if the url is sent by message (email or IM), the provider may visit it. > Definitely uninstall whatever junk leaked your domain though, but it's really nothing. We are used to the tracking being everywhere but it is scandalous and should be considered as such. Not the subdomain leak part, that's just how Ra…
>This too is not ideal. It gets saved in the browser history, and if the url is sent by message (email or IM), the provider may visit it. Sure. POST for extra security. > Not the subdomain leak part, that's just how Rachel noticed, but the non advertised tracking from an appliance chosen to be connected privately. If this were a completely local product, like say a USB stick. Sure. but this is a Network Attached Stor…
> Sure. but this is a Network Attached Storage product, and the user explicitly chose to use network functions (domains, http), it's not the same category of issue.
Is it fair to say that you're saying that it should be considered normal to expect that network-attached devices (designed and sold by reliable, aboveboard companies) connected to (V)LANs with no Internet access will be configured to use computers that use their management interfaces (whether GUI, CLI, or API) as "jumpboxes" to attempt to phone home with information about their configuration and other such "telemetry"?
Do carefully note what I'm asking: whether it should be considered normal to do this, rather than considering it to be somewhat outrageous. It's obviously possible to do this in the same way that it's obviously possible to do things like scratch the paint on a line of cars parked on the street, or adulterate food and medicine.