Correct. In my case no data is leaked. But it’s a paid domain. Not sure how this whould be with dyn-dns solutions.
That’s why I have the honeypot / dummy-site responding when it’s not the correct domain. Works flawlessly. As mentioned above, not a single unwanted request to Home Assistant since I have this setup.
As for obscuring the login page I totally agree. Doesn’t make sense.
Well, I’ve also got it accessable with an .onion domain, hopefully thats oscure enough for you guys.
And what’s important is in the eye of the beholder. All too often its the not invented here attitude that reigns OSS forums. Besides the ‘look how much I know’ posture, of course.
To be clear: I refer to the admin pages.
What do you mean by that? The domain is whatever you want it to be.
Fine, I am interested in the method. And I use ‘*’ in the dnszone, so you can’t get it from there.
STO is not targetting to protect from somebody who has enough motivation to enter your network. The most simple solution being probably to break in your house. It’s happened when computers were stolen at their home from high profile people in a company I worked at.
STO is protecting from bots that do basic stuff.
I see much more attemps to break into a system on domain names (no prefix) and www. than on non-standard sub-domains.
For instance, I see 0 attempts in my server logs on a subdomain I use at least once a week, and plenty on the root domain. And that’s true as well for other domains I manage.
The would actually do the opposite.
Now everything, like whatever you type, will point to that.
That is sadly yesterday’s world.
Hackers today have often more computer power than most countries due to botnets.
Will point to that IP address, not to that service. If you do not have the correct subdomain, the proxy will not transparently directly you to the service.
Not what I observe.
And sure malicious hackers have more computing power than in the past, and there are the store/record now-decrypt later (in +10 years) techniques.
Still they need to decide to throw that computing power at your “doorstep”.
That being said, these are no good reason to not apply techniques.
We still use locks for our houses which are fairly easy to circumvent and we can make things harder to find for those that do not “have” the time to search.
If the login page would be /login then this helps prevent bruteforce login attacks, for lower usability.
That is all a domain does.
A domain have nothing to do with ports or services.
It points to an IP address and that is it.
They can throw it at all the public IPv4 addresses that exist in the world.
It is easy for them with a botnet and the botnet prevents you from blocking their attempts because the botnet will try three times and then hand over the next attempts to another bot in the network.
And you have something valuable to them and you are flashing it wildly.
An always on machine and probably on a good line. It even runs an Unix variant and the hardware might also be quite powerful.
Such a machine is perfect for a botnet and also more sinister things.
Ah, what I meant there was In that whatever subdomain you pick the base URL for HA MUST still be at ‘/’
HA doesn’t support being run from a virtual directory. (without massive adreess rewriting - but at that point you’re behind a proxy doing better work anyway)
As to the okta article when I was a field engineer, we used to use the term: Best CURRENT practice. Instead of best practice. What I recommended for domain controllers in 2013 was WAAAY different than my recommendation in 2023 
Specifically because of cases like your 2013 Okta article. 10 years ago is an eternity in ITsec unfortunately.
That is like renaming the root user to administrator.
Well I think I wrote <instance>/login<random> but without the backticks so Discuss removed it.
The article is not from 2013 but refers to one from 2013. A decade ago does not imply obsolete - even with computing power.
I manage several servers, so I get an idea how much comes “knocking” at the ports. There are bots that try 3 times and others that try just until they’re blocked and some then try again later.
So sure, there are bots trying to enter “all the time”. That works on well known urls, but not on non-standard urls. And those bots do not try on the not publicly known adresses.
Sure SOT is not protecting from everything, but it helps and it’s easily accessible to home assistant users. Look at the discussion on Wireguard to get an idea on how simple that really is for users.
I do not think that anyone is saying that VPN is not better than SOT, we’re just saying that this is a good thing to have. Same as a having a 2FA HW key separate from your computer - I have one and I started securing SSH sessions with it.
We are not saying that STO is not a step in the right direction, but it has to be done on all surfaces of an installation to have effect, even error pages like 404 and HA have to many surfaces for it to make sense and some of these surfaces are even out of HA control due to third-party additions.
And yes hackers try ALL ports too when they have access to the botnets, but your server might not see them, because you have no services answering those ports.
Having a honey pot server or a firewall with superior logging capability makes it possible to see these patterns, which often means building your own Linux firewall/router.
Just for my own enlightenment:
I own a domain, and I’m managing it’s root DNS myself (VPS + bind).
I see in this thread mention of hackers being able to “list” the subdomain. I saw the “subfinder” project above, but it seems to only aggregate lists of known subdomains, unless I misunderstood.
Is there, to the best of your knowledge, a way to actually list subdomains of a self-hosted domain (not counting “brute” attempts, ofc)?
I tend to think that semi-random subdomains + reverse proxy virtual hosts is a decent STO, but I might be delusional 
The DNS service have request that list the entire domain with all settings.
I think it is called an AX transfer request and that needs to be limited to only authorized servers.
It is the request used by slave servers to keep the domains in sync.
Cool, thanks (for ref, it’s AXFR / Zone transfers).
You can deny that protocol easily when you manage your own DNS, but indeed you have to be careful.
By instance, I noticed that I properly protected my master DNS, but not my slave 
Okta? They probably sticked to security through obscurity…
That has nothing to do with hardening for internet exposure.
That is a general security audit for security by design principles, which all software should adhere to.