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?

    Thanked by (1)FootKaput
  • 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. :bleep_bloop:

    Thanked by (1)FootKaput

    ⚆ ͜ʖ ͡⚆ Thanked by (1281): verjin

  • As soon as you ask for a letsencrypt certificate it's gonna get indexed since certificates are public.

  • @foxone said:
    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.

    Thanked by (1)FootKaput

    Website: thomassen.sh

    Discord: Decicus#0001

  • @rcy026 said:
    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?

    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.

    Thanked by (1)FootKaput
  • @sureiam said:

    @rcy026 said:
    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?

    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.

    Thanked by (1)FootKaput
  • edited May 2020

    @rcy026 said: Is there a reason why

    Sorta but not really... Serving media files to apps on the ipad, some don't work well with the username/password.


    @verjin said: Anyone can find any sub domain no matter how long or obscure it is by just using Maltego

    This was along the lines of the 'why not' I wanted to educate myself on.


    @foxone said: As soon as you ask for a letsencrypt certificate

    Good point, I would have to use DNS challenge instead of HTTP.


    @Decicus said:
    You could use a wildcard certificate, which would still be logged by Certificate Transparency, but not the specific hostname.

    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.


    @sureiam said: These are basic things to be done but will knock out 99% of attempts unless it's highly targeted of course.

    Agreed, I change port and disable root login, disable password login and run fail2ban. I think that would thwart many scripts/automated tools.


    @rcy026 said: obscurity should never be a replacement for real security.

    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?

    Thanked by (1)FAT32

    ♻ Amitz day is October 21.
    ♻ Join Nigh sect by adopting my avatar. Let us spread the joys of the end.

  • edited May 2020

    @FAT32 said: obscured path is a lot better than subdomain

    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/

  • @FootKaput said: Serving media files to apps on the ipad

    all your queries are belong to 8.8.8.8

  • @FootKaput said:

    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.

    Wildcard only protects thd first level.

    e.g. *.sub.domain.com covers 1st.sub.domain.com, but not 2nd.1st.domain.com

Sign In or Register to comment.