Use subdomain to obscure access?
Instead of using nginx basic authorization, would a lengthy subdomain work to keep people from discovering/accessing a directory? Something like send a 404 for everything but https://correct.horse.battery.staple.domain.com/. Is there a way to discover the long subdomain via DNS or auth headers? I think DNS wouldn't leak, as I would just have an A record for the domain.com and *.domain.com.
Obviously this isn't using it as I should, and I wouldn't protect sensitive data like this, but just curious if it would work.
Comments
absolutely not, bots just brute force ip addresses, so eventually it will be indexed by search engines
Security by obscurity doesn't really work, imho.
But yeah, I guess an obscure enough subdomain would be equally difficult to guess as a password. You could even mitigate bruteforce attacks by blacklisting clients with to many 404 etc. But still, I wouldn't do it.
Is there a reason why you would want to use such a solution instead of a basic auth mechanism?
Anyone can find any sub domain no matter how long or obscure it is by just using Maltego (and other similar tools). Community edition is available by default in Kali OS.
⚆ ͜ʖ ͡⚆ Thanked by (1281): verjin
As soon as you ask for a letsencrypt certificate it's gonna get indexed since certificates are public.
You could use a wildcard certificate, which would still be logged by Certificate Transparency, but not the specific hostname.
Website: thomassen.sh
Discord: Decicus#0001
Eh it doesn't hurt though. For example changing SSH default port should be one of the first things that's done. Of course they can do a full port scan but it'll knock off a number of bots. Additionally setting up a solution to block them after a certain amount of failed attempts is important, along with disabling for example default usernames like root.
These are basic things to be done but will knock out 99% of attempts unless it's highly targeted of course.
Changing ssh port doesn't really make it secure, it just makes it harder to find.
If you truly believed security by obscurity worked, you would change your ssh port and then have no passwords.
Hopefully, you don't do that.
Real security is filtering the ssh port and only allowing connections from trusted hosts, denying root logins, and only accepting ssh-keys, preferable with some kind of 2FA. Most of my hosts doesn't even run ssh on external interfaces, I have to be on internal networks and connect to loopback interfaces to be able to access it. If it runs on port 22 or something else really doesn't matter then, does it?
But you are right in that it does not hurt, but obscurity should never be a replacement for real security.
Sorta but not really... Serving media files to apps on the ipad, some don't work well with the username/password.
This was along the lines of the 'why not' I wanted to educate myself on.
Good point, I would have to use DNS challenge instead of HTTP.
I actually noticed this when I tested using Directadmin with a LE cert. I had a *.domain.com and firefox didn't like it with the really long name.
Agreed, I change port and disable root login, disable password login and run fail2ban. I think that would thwart many scripts/automated tools.
Very true. Security first, obscurity as a bonus.
In your case because other form of authentication wouldn't work well, I believe obscured path is a lot better than subdomain. Reason being domain is something that is not usually encrypted but the path is.
"Humanity is f*cked up" - Jay
You are alive! How are you fairing with your mid-life crisis?
♻ Amitz day is October 21.
♻ Join Nigh sect by adopting my avatar. Let us spread the joys of the end.
I should check logs. I thought they might just say domain.com, but if it's the whole name w/subdomain, that could be a leak. I could probably do both, https://correct.horse.battery.staple.domain.com/d0ntl00khere/ A pain to type in, it would need to be a bookmark/saved to be worthwhile.
https://xkcd.com/936/
all your queries are belong to 8.8.8.8
Wildcard only protects thd first level.
e.g. *.sub.domain.com covers 1st.sub.domain.com, but not 2nd.1st.domain.com