7 ms·

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it c

by acoard 6y ago

>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is changing the default SSH port. Just by obscuring your port you can usually filter out the majority of break-in attempts. The only way security through obscurity signals to "predators" is if they've seen past your defence, and thus defeated the obscurity. Obscurity (once revealed) is not a deterrent. Likewise an authentication method (once exploited) is not a deterrent. >Of course in the age of automation, relying on obscurity alone is foolish because once someone has automated an attack that defeats the obscurity, then it is little or no effort for an attacker to bypass it. This is true of any exploit basically. Look no further than metasploit. Another example: a worm is a self-automating exploit.

Verdex 6y ago
> This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure. Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.
- acoard 6y ago
  Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here. Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised. >If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.
  - Retric 6y ago
    There is supposed to be a response when a port is closed telling you the machine is online but not listening to that port. https://en.wikipedia.org/wiki/Port_scanner https://en.wikipedia.org/wiki/Port_scanner
    - scarby2 6y ago
      most people have firewalls configured to simply drop traffic not destined for open ports, in which case there is no response as the traffic never makes it beyond the firewall.
      - efreak 6y ago
        If you'd like to be very visible in a different way, you could always waste resources: 1. Endlessh: https://news.ycombinator.com/item?id=19465967 https://news.ycombinator.com/item?id=19465967 2. Tarbit: https://github.com/nhh/tarbit https://github.com/nhh/tarbit
bleepblorp 6y ago
Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's trivial for anyone who knows the port sequence to defeat, but it's also very effective as anyone who doesn't know the port sequence has no indication of how to start probing for a solution.
- thinkharderdev 6y ago
  Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.
  - nordsieck 6y ago
    > Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Yes. But you also have to know that port knocking is enabled at all. That's the obscurity part.
    - thinkharderdev 6y ago
      Gotcha. Fair point.
    - smaudet 6y ago
      Eh, I think its how others have expressed in this thread. Security by obscurity is bad, not because it is bad to have well secured countermeasures, but because it encourages poor thinking with regards to methods you have in place, and additionally because it usually introduces extra, unintended attack vectors. You suffer from your own 'obscurity' - whether its because you forgot you had to port knock, use a different port, or because you somehow managed to leave a new exploit in some obscured code due a bug in the obscured code, or because you managed to open yourself up to an RCE with the port knocking, or some other obscure scenario you did not intend to create from whatever obscurity you created. I think this is different from Defense in Depth, which just says have more than one countermeasure in place, and to keep the counter measures 'separate', but well defined. Port knocking, but on a different box than your vpn box, on a different box than your ssh box. We aren't told to use 'well-defined' passwords, like 1234, obviously. If the point of 'obscurity' is 'secrets', that's all well and good, but that's not security, that's a password. Have a password, by all means, but tunnel it over TLS and use well defined security paths versus creating unnecessary risks.
dylan604 6y ago
In other words, changing the default SSH port number is similar to using camouflage. It just helps hide that something is there, but it does nothing to improve the defense once spotted. However, if the majority of predators don't see you, then the rest of your defenses are needed at that time.
- ballenf 6y ago
  It's also an indication that there are no default passwords in use. So even if you know what port SSH lives on, there's a lower ROI to attacking it than a default port.
Spooky23 6y ago
You can’t compromise what you can’t see. Calling an administrator account “9834753” obscures it’s purpose and may reduce the likelihood of a compromise attempt as opposed to “databasesuperadmin”. But that doesn’t mean that you don’t need a good security token.
voltagex_ 6y ago
I just turn off password authentication on SSH and moved to keys, then moved to IPv6. The automated scans haven't made it to v6 yet. The only better thing I could do is have an external v4 SSH honeypot that moves as slowly as possible to tie up a (tiny) resource.
- efreak 6y ago
  Endlessh and tarbit do this
- BlueTemplar 6y ago
  IPv6 seems to be a good example of security by obscurity, with up to 64 bits of random IP adresses per machine, making scanning impossible in practice ?
alexchamberlain 6y ago
I find the SSH example slightly odd, when all you need to do is disable password authentication and root access. Moving away from port 22 just seems a little excessive?

by acoard 6y ago

Verdex 6y ago

> This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). Most of the usages of "security through obscurity" that I've seen dissected and decried haven't been in the sense that something was being hidden, but rather that something was being confused. For example, using base 64 encoding instead of encrypting something. Or running a code obfuscator on source code instead of making the code actually secure. Either way the economic costs that I'm talking about are valid. If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. There are slightly different usages of the same word, but the effect looks to me to be the same. More investigation or automation can make the obscurity go away, but it does make things a bit harder.

acoard 6y ago
Fair point! Obscurity as confusion is not what I had in mind, but your points on confusion are totally valid. Your analogy with predators works better here. Using base64 encoding, or encrypting your database, are both examples in the article. While I agree base64 is super trivial, the point about either of these is defence in depth. In the language of the article, it's reducing likelihood of being compromised. >If an attacker sees that your SSH port isn't where it's supposed to be OR if an attacker sees that your SSH port ignores all packets sent to it (unless you first send a packet thats 25 0xFF bytes), then either way they're being signaled that you are more trouble than the computer that has an open telnet port. This is semantics. Personally I'd say if an attacker cannot sense anything to connect to, there is no "signal" you're sending. You're rather not sending a signal that you're a threat, as you're not sending a signal at all due to being functionally invisible. Otherwise, we could say literal nothingness is sending the same signal that your server is. We agree on the substance here, i.e. the obscurity increases the economic cost of hacking and works as a disincentive, so we may just agree to disagree on the semantics.
- Retric 6y ago
  There is supposed to be a response when a port is closed telling you the machine is online but not listening to that port. https://en.wikipedia.org/wiki/Port_scanner https://en.wikipedia.org/wiki/Port_scanner
  - scarby2 6y ago
    most people have firewalls configured to simply drop traffic not destined for open ports, in which case there is no response as the traffic never makes it beyond the firewall.
    - efreak 6y ago
      If you'd like to be very visible in a different way, you could always waste resources: 1. Endlessh: https://news.ycombinator.com/item?id=19465967 https://news.ycombinator.com/item?id=19465967 2. Tarbit: https://github.com/nhh/tarbit https://github.com/nhh/tarbit

bleepblorp 6y ago

Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Any attacker who is looking for more than just the lowest of low-hanging fruit will not be even slightly deterred. A better example would be a port-knocking arrangement that hides sshd except from systems that probe a sequence of ports in a specific way. This is very much security by obscurity, because it's trivial for anyone who knows the port sequence to defeat, but it's also very effective as anyone who doesn't know the port sequence has no indication of how to start probing for a solution.

thinkharderdev 6y ago
Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Since the number of ports is quite large, there is also a correspondingly large number of possible port sequences so you can't, in principle, brute force it without a lot of effort.
- nordsieck 6y ago
  > Maybe a bit nitpicky but I think port-knocking is in kind of a grey area. You can think of it as a kind of password where you have to know the correct series of ports. Yes. But you also have to know that port knocking is enabled at all. That's the obscurity part.
  - thinkharderdev 6y ago
    Gotcha. Fair point.
  - smaudet 6y ago
    Eh, I think its how others have expressed in this thread. Security by obscurity is bad, not because it is bad to have well secured countermeasures, but because it encourages poor thinking with regards to methods you have in place, and additionally because it usually introduces extra, unintended attack vectors. You suffer from your own 'obscurity' - whether its because you forgot you had to port knock, use a different port, or because you somehow managed to leave a new exploit in some obscured code due a bug in the obscured code, or because you managed to open yourself up to an RCE with the port knocking, or some other obscure scenario you did not intend to create from whatever obscurity you created. I think this is different from Defense in Depth, which just says have more than one countermeasure in place, and to keep the counter measures 'separate', but well defined. Port knocking, but on a different box than your vpn box, on a different box than your ssh box. We aren't told to use 'well-defined' passwords, like 1234, obviously. If the point of 'obscurity' is 'secrets', that's all well and good, but that's not security, that's a password. Have a password, by all means, but tunnel it over TLS and use well defined security paths versus creating unnecessary risks.

dylan604 6y ago

In other words, changing the default SSH port number is similar to using camouflage. It just helps hide that something is there, but it does nothing to improve the defense once spotted. However, if the majority of predators don't see you, then the rest of your defenses are needed at that time.

ballenf 6y ago
It's also an indication that there are no default passwords in use. So even if you know what port SSH lives on, there's a lower ROI to attacking it than a default port.

Spooky23 6y ago

You can’t compromise what you can’t see. Calling an administrator account “9834753” obscures it’s purpose and may reduce the likelihood of a compromise attempt as opposed to “databasesuperadmin”. But that doesn’t mean that you don’t need a good security token.

voltagex_ 6y ago

I just turn off password authentication on SSH and moved to keys, then moved to IPv6. The automated scans haven't made it to v6 yet. The only better thing I could do is have an external v4 SSH honeypot that moves as slowly as possible to tie up a (tiny) resource.

efreak 6y ago
Endlessh and tarbit do this
BlueTemplar 6y ago
IPv6 seems to be a good example of security by obscurity, with up to 64 bits of random IP adresses per machine, making scanning impossible in practice ?

alexchamberlain 6y ago

I find the SSH example slightly odd, when all you need to do is disable password authentication and root access. Moving away from port 22 just seems a little excessive?