6 ms·

This is something that really needs to be said more in amateur circles (i.e. self-hosters and homelabbers). For these scenarios I think it's even worse, though,

by kayson 4y ago

This is something that really needs to be said more in amateur circles (i.e. self-hosters and homelabbers). For these scenarios I think it's even worse, though, because it's a case of insecurity through transparency. People don't realize that all ACME/Let's Encrypt certificates are published in transparency logs that get scanned constantly, giving attackers a shiny target. I saw a reddit post recently (which I won't link for the victims' sakes) where someone had searched for Heimdall (a popular dashboard) in a web-security-oriented search engine and found a bunch of insecure publicly facing instances, some of which contained credentials. Fixing this would be as simple as using wildcard certs, wildcard dns, and unique subdomains. Configure your web server to 404 any request without a valid subdomain (esp. www.domain.tld or domain.tld) and you've avoided nearly every web-based scan because the attacker doesn't know the host name. This is pure obscurity, but it definitely works. Yes, host name can get leaked through SNI, but if someone is monitoring your traffic, you probably need something more sophisticated anyways.

naasking 4y ago
> Configure your web server to 404 any request without a valid subdomain (esp. www.domain.tld or domain.tld) and you've avoided nearly every web-based scan because the attacker doesn't know the host name. But you haven't actually avoided it, you kicked the can down the road at best. Sometimes that's useful but it's not a sound general strategy.
- kayson 4y ago
  > you kicked the can down the road at best How so?
  - imtringued 4y ago
    Reverse DNS lookup.
    - kayson 4y ago
      You mean by PTR records? I'm pretty sure most people don't have those set up..
      - ggm 4y ago
        Which is security by obscurity?
      - tialaramex 4y ago
        You can actually buy "Passive DNS" records. Big DNS providers collect all the answers they learned while serving, deliberately without recording who asked and the answers are aggregated and available for purchase. So if Sarah in accounts once went to secret-webserver.internal.example.com from her laptop at home before turning on the VPN by mistake, her upstream DNS provider will tell any attackers with some $$$ that secret-webserver.internal.example.com existed, when it existed, what the A or AAAA records said and so on. Targeted attacks will know about secret-webserver.internal.example.com even though only *.internal.example.com is listed in the CT logs.
  - naasking 4y ago
    Because if a name is not crytopgraphically unguessable, then it's guessable and subject to dictionary, brute force, and other forms of attack.
    - kayson 4y ago
      If someone is doing that, you're in the realm of targeted attacks instead of scans, which is outside the scope of my original comment. It's similar to someone monitoring your traffic; as I already said, if that's the case you need more anyways.
      - naasking 4y ago
        Security is not choose your own buffet where you get to only think about scans but ignore other common attack vectors. Botnets are common enough that targeted attacks like I described are just as common as scans, so you always need more anyway. Configuring your host to return 404 on invalid subdomains is just not a general solution, at best it just buys you some time until attackers find the subdomain, ie. kicking the can down the road, like I originally said.
        kayson 4y ago
        So you're saying botnets will dictionary attack subdomains on every IP? Any sources?
        naasking 4y ago
        No, I'm saying that's one of many behaviours. They mine domains and URLs scraped from email addresses, email headers and bodies, online content, and more. Your site is not "secure" when that security can be circumvented by someone pasting a URL into an email.
_trampeltier 4y ago
They beauty with special ports are, much less bloated logs.
- anjbe 4y ago
  Do people using high ports actually check their logs enough for it to matter?
  - ggm 4y ago
    I do. I see no SSH attempts on the active high port. None. It may only be a matter of time of course. I continue to see French metric tonnes of attempts to subvert mysql and the Web. We've been on the shifted port for more than 5 years.
    - illiac786 4y ago
      I can confirm it makes a huge difference for SIP as well. Toll fraud attempts are not making the logs completely unreadable anymore when using a non-standard port.
bastawhiz 4y ago
If you set up a wildcard cert and configure your server to reject invalid subdomains, you've already done more work than it takes to actually secure your site. If you've learned to do all that, you'd just secure your site. There is no time benefit to the obscurity approach.
- nine_k 4y ago
  How do you secure your site against a vulnerability which an attacker knows, and you still don't? And for which a fix is not available yet? No layer of defense is useless. Hiding the host name is a pretty noticeable layer. Running a private server only inside a VPN is, of course, even nicer, when you can afford it.
  - bastawhiz 4y ago
    If you're going to talk about vulnerabilities that you don't know about yet, then you should be looking at how you're running old kernel versions and unpatched software. Hiding your hostname doesn't protect you against anything other than insecure application code. Old httpd or openssl will still be exposed. There are plenty of ways that your secret hostname can leak. It's just a weak, low-entropy, guessable password that can't really be rotated. And moreover, if you're going to choose one thing to do (or time box your efforts around security), it's the highest complexity I can think of for almost no real return. I mean, if you're so concerned about leaking the hostname from your HTTPS cert because your site is that insecure, why are you even using HTTPS? What are you even protecting? Is that the best way to spend an hour securing your site? Even just slapping the six lines to put hard coded HTTP auth credentials on your nginx virtual host will do more than that.
  - ihattendorf 4y ago
    Require TLS Client Certificates at the load balancer level (or even just HTTP basic auth).
- friendzis 4y ago
  Why do people insist that "security" is binary, i.e. something is either secure or not? A residential building has way less security than a military base, yet can be consider secured while the base not. The article points to one of the core equations every business should embrace: `cost_of_risk = unit_probability * unit_impact`. If some measure can improve security metrics (time to discover, time to break, skill/power to break, etc.) then it can be considered a security measure. SSH server running on non-default port is not much more secure than otherwise equal server, but probability of random attack is lower. > you've already done more work than it takes to actually secure your site Finding and plugging RCE holes in every dependency you have deployed is way harder than making the host less discoverable. If running security-patched software, having non-default, hard to guess passwords are security measures that lead to lower chance of exploitation, why can't non-default, hard to discover hostnames/ports be considered security measures if they do reduce likelihood of exploitation? Relying solely on `apt upgrade` is similarly insecure as merely exposing software on non-default ports.
Manu40 4y ago
I have an idea I want to pass by you, since you seem to understand the importance of this better than some others. (At least as far as my under educated opinion on network security goes) (I'm a hobbyist, self taught most things.) So lets say you are going to be running a home server to be setup as a read only server to the outside world, but write capable through a separate port connected only to a laptop that has no internet access (or very restricted) which also has the nicety of being so obsolete it doesn't have IME or any other intel idiocy backdoors attached to it. Would you still put a hardware firewall between each of these connections? And if so, would you also run it through a VPN on the read side of the server? I personally don't trust VPN's, since I see them as middlemen you pay to pretend they don't keep logs of anything. Of course there is always the whole argument of 'not having anything to hide, so no worries'; but I see it as false, since the whole point of using a VPN is to hide your bits from attackers and snoops. Even if it's legitimate/legal data. So, what would you do to avoid using a VPN, provided you can't own the VPN instance somehow somewhere due to being a bit of a cheapskate? Would some basic OpenWRT firewalled routers be enough for your purposes (and thus mine possibly) or would you go with some more complex setup where a person has to trust yet another company to not be trying to hijack data somehow? Server intended: Opteron build, DDR3 tech. 6 cores, hyperthreading (if any) disabled. All forms of speculation turned off. All that jazz. 1 nic port is to be setup to be downloaded data only, no upload allowed. Other nic port is access point for SSH via old laptop setup for security purposes. Everything running on linux, as much as possible. No windows allowed.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- asimops 4y ago
  What do you mean with the not trusting VPN to keep logs, etc.? It's your VPN, you host it, why would you care if you log youself or not?
  - Manu40 4y ago
asimops 4y ago
On a technical term, if I were to find a 404 for a domain, I know there is a webserver there. Is this really helping all that much?
- kayson 4y ago
  Yes, because you would still have to know a valid hostname to actually get anywhere. This of course assumes no bugs/vulnerabilities in the web server.
illiac786 4y ago
Is a non-public hostname “obscurity” or is it a form of password/credential? Or is a credential actually “obscurity”, only so vast an attacker can’t possibly have enough electricity to shine a light on even a remotely relevant part of it. It’s all about risk/probabilities in my view. How likely is it to find the hostname? How likely is it to find the password? The only real differences is that there are best practices ensuring passwords are never logged in clear text anywhere, whereas it’s not the case for a hostname.
castillar76 4y ago
> People don't realize that all ACME/Let's Encrypt certificates are published in transparency logs that get scanned constantly, giving attackers a shiny target. FWIW, this is true of all public certificates right now, regardless of issuance method (ACME, manual, etc.) or CA (ZeroSSL, LE, DigiCert, etc.). I don't point that out to be pedantic, just to emphasize that that information is going to be out there when someone grabs a cert, regardless of how they do it. :) > I saw a reddit post recently (which I won't link for the victims' sakes) where someone had searched for Heimdall (a popular dashboard) in a web-security-oriented search engine and found a bunch of insecure publicly facing instances, some of which contained credentials. There were some instances recently of the same thing happening with Wordpress installations, as the default Wordpress installer would go get itself a Let's Encrypt certificate before the user had completed setup and set an admin password on the install. No vulnerability necessary, just hop onto it and set the admin password. I suspect this is going to be a frequent vulnerability discovered as more things bundle "get me an LE/ZeroSSL/etc. cert" into their software/OS installers.

by kayson 4y ago

naasking 4y ago

> Configure your web server to 404 any request without a valid subdomain (esp. www.domain.tld or domain.tld) and you've avoided nearly every web-based scan because the attacker doesn't know the host name. But you haven't actually avoided it, you kicked the can down the road at best. Sometimes that's useful but it's not a sound general strategy.

kayson 4y ago
> you kicked the can down the road at best How so?
- imtringued 4y ago
  Reverse DNS lookup.
  - kayson 4y ago
    You mean by PTR records? I'm pretty sure most people don't have those set up..
    - ggm 4y ago
      Which is security by obscurity?
    - tialaramex 4y ago
      You can actually buy "Passive DNS" records. Big DNS providers collect all the answers they learned while serving, deliberately without recording who asked and the answers are aggregated and available for purchase. So if Sarah in accounts once went to secret-webserver.internal.example.com from her laptop at home before turning on the VPN by mistake, her upstream DNS provider will tell any attackers with some $$$ that secret-webserver.internal.example.com existed, when it existed, what the A or AAAA records said and so on. Targeted attacks will know about secret-webserver.internal.example.com even though only *.internal.example.com is listed in the CT logs.
- naasking 4y ago
  Because if a name is not crytopgraphically unguessable, then it's guessable and subject to dictionary, brute force, and other forms of attack.
  - kayson 4y ago
    If someone is doing that, you're in the realm of targeted attacks instead of scans, which is outside the scope of my original comment. It's similar to someone monitoring your traffic; as I already said, if that's the case you need more anyways.
    - naasking 4y ago
      Security is not choose your own buffet where you get to only think about scans but ignore other common attack vectors. Botnets are common enough that targeted attacks like I described are just as common as scans, so you always need more anyway. Configuring your host to return 404 on invalid subdomains is just not a general solution, at best it just buys you some time until attackers find the subdomain, ie. kicking the can down the road, like I originally said.
      - kayson 4y ago
        So you're saying botnets will dictionary attack subdomains on every IP? Any sources?
        naasking 4y ago
        No, I'm saying that's one of many behaviours. They mine domains and URLs scraped from email addresses, email headers and bodies, online content, and more. Your site is not "secure" when that security can be circumvented by someone pasting a URL into an email.

_trampeltier 4y ago

They beauty with special ports are, much less bloated logs.

anjbe 4y ago
Do people using high ports actually check their logs enough for it to matter?
- ggm 4y ago
  I do. I see no SSH attempts on the active high port. None. It may only be a matter of time of course. I continue to see French metric tonnes of attempts to subvert mysql and the Web. We've been on the shifted port for more than 5 years.
  - illiac786 4y ago
    I can confirm it makes a huge difference for SIP as well. Toll fraud attempts are not making the logs completely unreadable anymore when using a non-standard port.

bastawhiz 4y ago

If you set up a wildcard cert and configure your server to reject invalid subdomains, you've already done more work than it takes to actually secure your site. If you've learned to do all that, you'd just secure your site. There is no time benefit to the obscurity approach.

nine_k 4y ago
How do you secure your site against a vulnerability which an attacker knows, and you still don't? And for which a fix is not available yet? No layer of defense is useless. Hiding the host name is a pretty noticeable layer. Running a private server only inside a VPN is, of course, even nicer, when you can afford it.
- bastawhiz 4y ago
  If you're going to talk about vulnerabilities that you don't know about yet, then you should be looking at how you're running old kernel versions and unpatched software. Hiding your hostname doesn't protect you against anything other than insecure application code. Old httpd or openssl will still be exposed. There are plenty of ways that your secret hostname can leak. It's just a weak, low-entropy, guessable password that can't really be rotated. And moreover, if you're going to choose one thing to do (or time box your efforts around security), it's the highest complexity I can think of for almost no real return. I mean, if you're so concerned about leaking the hostname from your HTTPS cert because your site is that insecure, why are you even using HTTPS? What are you even protecting? Is that the best way to spend an hour securing your site? Even just slapping the six lines to put hard coded HTTP auth credentials on your nginx virtual host will do more than that.
- ihattendorf 4y ago
  Require TLS Client Certificates at the load balancer level (or even just HTTP basic auth).
friendzis 4y ago
Why do people insist that "security" is binary, i.e. something is either secure or not? A residential building has way less security than a military base, yet can be consider secured while the base not. The article points to one of the core equations every business should embrace: `cost_of_risk = unit_probability * unit_impact`. If some measure can improve security metrics (time to discover, time to break, skill/power to break, etc.) then it can be considered a security measure. SSH server running on non-default port is not much more secure than otherwise equal server, but probability of random attack is lower. > you've already done more work than it takes to actually secure your site Finding and plugging RCE holes in every dependency you have deployed is way harder than making the host less discoverable. If running security-patched software, having non-default, hard to guess passwords are security measures that lead to lower chance of exploitation, why can't non-default, hard to discover hostnames/ports be considered security measures if they do reduce likelihood of exploitation? Relying solely on `apt upgrade` is similarly insecure as merely exposing software on non-default ports.

Manu40 4y ago

I have an idea I want to pass by you, since you seem to understand the importance of this better than some others. (At least as far as my under educated opinion on network security goes) (I'm a hobbyist, self taught most things.) So lets say you are going to be running a home server to be setup as a read only server to the outside world, but write capable through a separate port connected only to a laptop that has no internet access (or very restricted) which also has the nicety of being so obsolete it doesn't have IME or any other intel idiocy backdoors attached to it. Would you still put a hardware firewall between each of these connections? And if so, would you also run it through a VPN on the read side of the server? I personally don't trust VPN's, since I see them as middlemen you pay to pretend they don't keep logs of anything. Of course there is always the whole argument of 'not having anything to hide, so no worries'; but I see it as false, since the whole point of using a VPN is to hide your bits from attackers and snoops. Even if it's legitimate/legal data. So, what would you do to avoid using a VPN, provided you can't own the VPN instance somehow somewhere due to being a bit of a cheapskate? Would some basic OpenWRT firewalled routers be enough for your purposes (and thus mine possibly) or would you go with some more complex setup where a person has to trust yet another company to not be trying to hijack data somehow? Server intended: Opteron build, DDR3 tech. 6 cores, hyperthreading (if any) disabled. All forms of speculation turned off. All that jazz. 1 nic port is to be setup to be downloaded data only, no upload allowed. Other nic port is access point for SSH via old laptop setup for security purposes. Everything running on linux, as much as possible. No windows allowed.

deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
asimops 4y ago
What do you mean with the not trusting VPN to keep logs, etc.? It's your VPN, you host it, why would you care if you log youself or not?
- Manu40 4y ago

asimops 4y ago

On a technical term, if I were to find a 404 for a domain, I know there is a webserver there. Is this really helping all that much?

kayson 4y ago
Yes, because you would still have to know a valid hostname to actually get anywhere. This of course assumes no bugs/vulnerabilities in the web server.

illiac786 4y ago

Is a non-public hostname “obscurity” or is it a form of password/credential? Or is a credential actually “obscurity”, only so vast an attacker can’t possibly have enough electricity to shine a light on even a remotely relevant part of it. It’s all about risk/probabilities in my view. How likely is it to find the hostname? How likely is it to find the password? The only real differences is that there are best practices ensuring passwords are never logged in clear text anywhere, whereas it’s not the case for a hostname.

castillar76 4y ago

> People don't realize that all ACME/Let's Encrypt certificates are published in transparency logs that get scanned constantly, giving attackers a shiny target. FWIW, this is true of all public certificates right now, regardless of issuance method (ACME, manual, etc.) or CA (ZeroSSL, LE, DigiCert, etc.). I don't point that out to be pedantic, just to emphasize that that information is going to be out there when someone grabs a cert, regardless of how they do it. :) > I saw a reddit post recently (which I won't link for the victims' sakes) where someone had searched for Heimdall (a popular dashboard) in a web-security-oriented search engine and found a bunch of insecure publicly facing instances, some of which contained credentials. There were some instances recently of the same thing happening with Wordpress installations, as the default Wordpress installer would go get itself a Let's Encrypt certificate before the user had completed setup and set an admin password on the install. No vulnerability necessary, just hop onto it and set the admin password. I suspect this is going to be a frequent vulnerability discovered as more things bundle "get me an LE/ZeroSSL/etc. cert" into their software/OS installers.