5 ms·

It seems to me that the article is missing a few of points on what "security by obscurity" means. From Wikipedia: "reliance [...] on design or implementation s

by n0on3 6y ago

It seems to me that the article is missing a few of points on what "security by obscurity" means. From Wikipedia: "reliance [...] on design or implementation secrecy as _the main method_ of providing security [...]" So, to use the model mentioned in the article, a single slice of cheese. It's not "an additional layer of defense", it's the main one (so you have other... weaker layers? ¯\_(ツ)_/¯) Second, "reliance on secrecy of design and implementation" is different from "reliance on secrecy of _whatever-else_", because design and implementation are most often either easily discoverable (sure, occasional skids might not scan port 64323 but what about someone who can observe your traffic?) or pretty much guaranteed to be discovered by adveraries with (not even as much as one might think) time and motivation. Third, some of the examples mentioned (e.g., the decoy cars) are not even security by obscurity, that's called deception. So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense. Security by obscurity is not underrated, by definition it's just bad.

jjeaff 6y ago
I agree with your understanding of security by obscurity. But I think the popular understanding has started to be more along the lines that the author counters. That if any security measure is "obscurity" then don't do it, it's bad.
- wintermute_ 6y ago
  This is the problem with "sound bite" bits of conventional wisdom. The more it's used and misused, the less it's actually understood. People hear "Security through obscurity is bad" and just interpret those words however they want without listening to the rest of the actual advice being given. It's not to never use obscurity to your advantage. It's that you need to be aware (and far too many weren't at one time) that you cannot rely on obscurity as a form of defense. If I have an old, buggy unpatched version of an admin page sitting on an obscure random URL, but I decide I don't need to bother patching it because eh, it works and it's too much effort to patch and what are the odds someone will guess my super secret random URL, then I need to think about why "security through obscurity" is bad. And that false sense of security is why they say security through obscurity can be worse than no security at all. They key is to promote vigilance and actual hardening of systems and not expend precious time devising ever more elaborate obscurity hoops that cost you more than they cost an attacker in time and effort to defeat, and are in the end ineffective. That's not to say you should leave ssh listening on port 22, you really shouldn't. It's like the difference between leaving your front door unlocked and leaving it unlocked and putting up a big neon "Open 24 Hours!" sign in the window.
coding123 6y ago
We have a few technologies in play in the world that operate on obscurity. Shared industry passwords like the DVD encryption key: https://en.wikipedia.org/wiki/AACS_encryption_key_controversy https://en.wikipedia.org/wiki/AACS_encryption_key_controvers... Even if it was technically a password, it's really obscurity because the password was literally available in billions of devices worldwide - it's just hard to read. Then someone figured it out (specifically in WinDVD). So, when someone says obscurity is fine, it's fun to remind them that all DVDs are cracked because someone thought so. (Not that I think that's a bad thing)
PragmaticPulp 6y ago
This is actually the misunderstanding that the author is talking about: People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. Slowing down your adversaries and weeding out the low-effort attacks is still valuable. > So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said. I would go one step further and say that engineers commonly underestimate the volume of low-effort attacks that will pour in at scale. Some of these, such as brute-forcing or DDoS, can be disruptive to users unless you have perfect rate limiting (which you won't at first). Adding layers of obscurity before attackers can authenticate with and interact with core services can dramatically reduce the volume of these low-effort attacks. The skilled attackers tend to be more surgical.
- n0on3 6y ago
  > This is actually the misunderstanding that the author is talking about I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it. > People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure. > Slowing down your adversaries and weeding out the low-effort attacks is still valuable. Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers. > That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said. The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this. I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.
cthalupa 6y ago
>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, or iptables rules getting reloaded if they're being used to forward traffic from a high port to 1024 and an attacker can have their own credential collecting service running where you think sshd is, and all it takes is someone ignoring the host key mismatch error to give up your good creds to an attacker, and now they have more access into your infrastructure.
- unethical_ban 6y ago
  Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?
  - cthalupa 6y ago
    I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd. It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel? That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about. Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA. Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports. Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.
moomin 6y ago
Indeed, the "real-world" examples suffer from two problems: 1) The former is not security by obscurity, the car the president is in is a secret. Any attack on the president is rendered much harder because of the process even if you know what the process is. Just like regular cryptography. 2) This isn't security through obscurity because the attacker learning your system wouldn't help them. Because the attacker is, literally, a bird-brain.
tetha 6y ago
This is one of the reasons why I've started to call a good layer of concealment and deception on top of a hard system OPSEC rather than obscurity. It's a less ambiguous term and probably more accurate. For example, I have no trouble revealing that all our SSHDs at work are ssh-keys only with a strong key policy and periodic reviews, whitelisted accounts, most are firewalled to be VPN only, configs are hardened periodically, some are 2FA secured. All in all, those are good or best practices to follow in order to harden an sshd, so I'm losing little info there. A pentester under NDA would get more info to be effective, like the whitelists, might get IP whitelisted even. Security audits during pre-sales might some other additional info. However some details and measures don't need to be known outside our operations team. But they can and have been a royal pain to visitors.

by n0on3 6y ago

jjeaff 6y ago

I agree with your understanding of security by obscurity. But I think the popular understanding has started to be more along the lines that the author counters. That if any security measure is "obscurity" then don't do it, it's bad.

wintermute_ 6y ago
This is the problem with "sound bite" bits of conventional wisdom. The more it's used and misused, the less it's actually understood. People hear "Security through obscurity is bad" and just interpret those words however they want without listening to the rest of the actual advice being given. It's not to never use obscurity to your advantage. It's that you need to be aware (and far too many weren't at one time) that you cannot rely on obscurity as a form of defense. If I have an old, buggy unpatched version of an admin page sitting on an obscure random URL, but I decide I don't need to bother patching it because eh, it works and it's too much effort to patch and what are the odds someone will guess my super secret random URL, then I need to think about why "security through obscurity" is bad. And that false sense of security is why they say security through obscurity can be worse than no security at all. They key is to promote vigilance and actual hardening of systems and not expend precious time devising ever more elaborate obscurity hoops that cost you more than they cost an attacker in time and effort to defeat, and are in the end ineffective. That's not to say you should leave ssh listening on port 22, you really shouldn't. It's like the difference between leaving your front door unlocked and leaving it unlocked and putting up a big neon "Open 24 Hours!" sign in the window.

coding123 6y ago

We have a few technologies in play in the world that operate on obscurity. Shared industry passwords like the DVD encryption key: https://en.wikipedia.org/wiki/AACS_encryption_key_controversy https://en.wikipedia.org/wiki/AACS_encryption_key_controvers... Even if it was technically a password, it's really obscurity because the password was literally available in billions of devices worldwide - it's just hard to read. Then someone figured it out (specifically in WinDVD). So, when someone says obscurity is fine, it's fun to remind them that all DVDs are cracked because someone thought so. (Not that I think that's a bad thing)

PragmaticPulp 6y ago

This is actually the misunderstanding that the author is talking about: People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. Slowing down your adversaries and weeding out the low-effort attacks is still valuable. > So, sure, you can do non-standard stuff to make it harder for _some_ not discover your vulnerabilities (ssh non-standard port is actually a good thing given the massive amounts of bots around), but that should never be your only (or your main) layer of defense That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said. I would go one step further and say that engineers commonly underestimate the volume of low-effort attacks that will pour in at scale. Some of these, such as brute-forcing or DDoS, can be disruptive to users unless you have perfect rate limiting (which you won't at first). Adding layers of obscurity before attackers can authenticate with and interact with core services can dramatically reduce the volume of these low-effort attacks. The skilled attackers tend to be more surgical.

n0on3 6y ago
> This is actually the misunderstanding that the author is talking about I don't think so. It's like when someone confuses encoding and encryption because both "hide the plain text", they're just not the same thing no matter how you choose to view it. > People commonly misunderstand the concept and assume that obscurity is a bad practice in general, even when used as a secondary layer. It's not uncommon for junior engineers to object to any level of obfuscation or security because they can imagine a scenario where a sufficiently skilled attacker can defeat it, but that's missing the point. So how about teching these people instead of accomodating the misunderstanding and its unforseen consequences? I say this because the point of spreading "security by obscurity is bad" directly relates indeed to people, who use to think of security as a binary thing (it's either secure or not secure) with the consequent misconception that if there is something in place than it's secure. > Slowing down your adversaries and weeding out the low-effort attacks is still valuable. Definitely yes. But that is not security by obscurity. I always liked the safe analogy: it's good if you still need the key to open it even if you have its blueprints, a huge number of models both open and close with their own keys to play with and the time to take all of them apart. I think most people who dealt with math and cryptography get this more among security professionals and engineers. > That's exactly what the author says in the article. I don't see where the author is disagreeing with what you said. The part when he based the article ignoring the definition of the subject. If one reads his article with the definition in mind, then the whole article disagrees with this. I don't mean to be pedantic on definitions but I think there are good reasons for this one that are just being ignored.

cthalupa 6y ago

>ssh non-standard port is actually a good thing given the massive amounts of bots around Except that if you use a port above 1024 (like the author does) you no longer have assurances that it is a privileged user that launched the process. Any non-privileged user on a Linux system can bind to a port higher than 1024, so all it takes is sshd restarting after an update if it's directly listening on a high number port, or iptables rules getting reloaded if they're being used to forward traffic from a high port to 1024 and an attacker can have their own credential collecting service running where you think sshd is, and all it takes is someone ignoring the host key mismatch error to give up your good creds to an attacker, and now they have more access into your infrastructure.

unethical_ban 6y ago
Never thought about this before, but is this a tunable thing in the kernel config? Some way to signal to the OS "only use port ranges above 16382 for unpriv" and move the boundary up?
- cthalupa 6y ago
  I don't believe it's an easily changeable tunable with a config flag or sysctl setting, no. You could of course modify the kernel source code, but there's probably lots of unintended side effects to this - your setting is alright for most Linux distros, but what if someone picked one that overlapped with ephemeral port ranges? Or if you're running software that the commonly used port binds to something under 16382 but above 1024 - now you have to reconfigure it, or set up temporary privilege escalation so it can bind to it before going back down, a la httpd. It's also a bit of a contract with the client - on Linux something below 1024 is ALWAYS privileged so you know you're not connecting to a fake sshd and giving away your password or current 2FA token unless that system has been totally owned. If you modify the kernel you're modifying that contract - are you sure that this system has modified kernel? That's really my issue with this whole idea (and one of my top level comments goes into this in more depth) - but there's a lot of unintended side effects from these obscurity changes that people don't know about or think about. Meanwhile there's lots of well understood practices that provide real security that solve both the issue of noisy low effort attacks while also providing real security against determined attackers. VPNs and jumphosts - why should SSH be internet accessible in the first place? Use key based auth, as well as 2FA. Port knocking is... interesting... in theory, but it increases complexity for the users at a similar level of requiring them to use a VPN or jumphost (or both), but has additional flaws that they don't have - if they have access to sniff your traffic via some means, they can figure out the sequence and now they have completely removed it as a layer of security. They don't even need to be able to decrypt the traffic - just see the destination ports. Is this level of attack something most of us have to worry about? No. But if for similar levels of effort we can get better security, why would we go for the weaker form, even if it's unlikely we need more? If for some reason you do have a dedicated attacker, you're better prepared. You can also extend it to provide even more security - lock down SSH to all of your production hosts to only the jumpbox(es). Alarm on any attempt production host to production host SSH attempts. Easily audit ingress SSH access on a subset of hosts. etc.

moomin 6y ago

Indeed, the "real-world" examples suffer from two problems: 1) The former is not security by obscurity, the car the president is in is a secret. Any attack on the president is rendered much harder because of the process even if you know what the process is. Just like regular cryptography. 2) This isn't security through obscurity because the attacker learning your system wouldn't help them. Because the attacker is, literally, a bird-brain.

tetha 6y ago

This is one of the reasons why I've started to call a good layer of concealment and deception on top of a hard system OPSEC rather than obscurity. It's a less ambiguous term and probably more accurate. For example, I have no trouble revealing that all our SSHDs at work are ssh-keys only with a strong key policy and periodic reviews, whitelisted accounts, most are firewalled to be VPN only, configs are hardened periodically, some are 2FA secured. All in all, those are good or best practices to follow in order to harden an sshd, so I'm losing little info there. A pentester under NDA would get more info to be effective, like the whitelists, might get IP whitelisted even. Security audits during pre-sales might some other additional info. However some details and measures don't need to be known outside our operations team. But they can and have been a royal pain to visitors.