8 ms·

Security through obscurity is underrated (2020)

105 points by metadat 4y ago

magicalhippo 4y ago
From 2020, previously discussed here, as mentioned in the article: https://news.ycombinator.com/item?id=24444497 https://news.ycombinator.com/item?id=24444497
woopwoop24 4y ago
Risk = Likelihood * Impact If someone is capable enough to combine things, he does not need to be told this advise. All the others we tell just to follow common advise and not live by obscurity because it is crap most of the time. Strong security does not need obscurity
- amelius 4y ago
  Yeah but it messes up your logs.
heinternets 4y ago
If security through obscurity wasn't somewhat effective, why would the army employ camouflage?
- b112 4y ago
  Camouflage is offensive, not defensive. You don't defend your country by hiding it, but you do sneak up when attacking...
  - bitxbitxbitcoin 4y ago
    Camouflage is absolutely at least as defensive as it is offensive. In the military context - You can defend your country by hiding ie with a nuclear submarine. Camo nets for covering anti aircraft guns, etc. outside of the military context, just look at how camouflage is actually deployed in nature.
- pixl97 4y ago
  Because at one time it was effective, then someone created IR optics and at least for heat generating/storing objects the effectiveness of camo dropped significantly. Now camo is still effectiveness, say against poor soldiers or one's who had their division leader sell that equipment off to make a little extra income. But you better understand your enemy well, or just putting up camo and then huddling together in a group with no further security will get you killed all at once.
  - bell-cot 4y ago
    Straw man. Nobody is arguing for ssh on 2222, with root:root for every server. Also - acquiring / maintaining / training / using good IR equipment consumes far more resources & attention than basic camouflage does. Good troops do something called "field training", where they become quite familiar with how effective cover & camouflage can be. And they've figured out that the stakes on a battlefield are "death", not "deal with server being hacked".
  - hoseja 4y ago
    Modern gear reduces your IR signature.
- 2OEH8eoCRo0 4y ago
  Or the entire classification system. Why should you give the enemy a freebie? Obscurity is just another hurdle/layer that wastes an adversaries precious time.
- adgjlsfhk1 4y ago
  obscurity is great when you have the ability to strike back. it's less good when you're a server that needs to withstand attacks and can't kill the attackers.
- protl 4y ago
  Isn't that because they don't have a more effective alternative? They're forced to rely on the security by obscurity of camo (ignoring the guns). If you had an indestructable soldier, you could paint them bright pink and have them live stream their position, it wouldn't matter they're indestructable.
  - dan_mctree 4y ago
    Isn't that true for software too though? You cannot ever rely 100% on any tool you use, so if you're serious about actually avoiding penetrations and not just about the academic discussion, you're better off using at least a bit of obscurity on top of your real security system.
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..
blincoln 4y ago
Security through making things harder in some unquantifiable way for an attacker to exploit[1] is usually a waste of time (IMO) because there is no way to measure or even estimate with any kind of accuracy how much value it adds versus the costs of implementing and maintaining it. Maybe it will deter attackers forever, because you'll get lucky and no one will ever care enough to put in the effort. Maybe someone becomes obsessed with the thing you're trying to protect, and just for fun figures out how to bypass all of your work in a week, and publishes the result to Full Disclosure. The author of the article cites a typical information security faux version of a real thing: calculating risk by multiplying impact by likelihood. Risk is a real field, with real data collected to make those estimations as accurate as possible. Insurance companies use complex actuarial tables, which is where the old saw about red cars having higher insurance premiums comes from. They really do collect massive volumes of data to make estimates of likelihood from. In my field (information security) people who talk about likelihood are generally just guessing, or trusting their knee to ache when the haxxors are about to pwn the Gibson. There is no data, just someone guessing and plugging the number into a formula so that the result has the appearance of objectivity and science. Implementing controls that "make things harder" is a variation on that same theme. If one wants a security control they can trust, they should pick the ones that have actual math behind them, like "using this random token[/key/whatever] means that an attacker would have to guess for literally one million years to make a successful request". [1] of which security through obscurity is a subset.
anjbe 4y ago
The thesis of the article, that security through obscurity is underrated, is “because it has a low implementation cost and it usually works well.” But I contest both of those things. Common obscurity methods provide low benefit for the amount of work put in, relative to methods with a better foundation. One of the best examples of this is port knocking, a resurging fad in self‐hosting circles, that is completely beaten both in simplicity and in actual protection by putting your SSH server behind WireGuard. Even the example in the article seems ridiculous. I always advocate disabling SSH passwords and using FIDO‐backed SSH keys instead, but of course people will complain that they lose the ability to log in from arbitrary machines (well worth it in my opinion, but fine). So rather than using SSH with a weak password on a non‐default port, why not use SSH with a strong password on a default port, which provides more entropy and also some protection against attacks by a local user, without having to remember weird port numbers?
- bogantech 4y ago
  Yep and Password auth can also be augmented with some additional PAM modules (like pam_oath and/or pam_yubico) as long as you don't configure them in a way that allows user enumeration. Really the only thing you get by changing the port is less log spam. If your system is so poorly configured that an automated drive-by attack by a bot would be successful then you're gonna get owned anyway if someone decides to target you.
  - hospadar 4y ago
    > if someone decides to target you I think reducing log spam is actually a great security outcome, if the only thing normally present in the log are my real logins, an attacker's attempt world stick out like a sore thumb.
- deleted 4y ago
  [deleted]
- marcosdumay 4y ago
  Exactly. "Security by obscurity" is a badly defined term that security people use to name the practices that bring too little benefit for their implementation cost. It's derogatory by definition, so it can not be underrated. One can disagree about the evaluation of some specific practice, but the people that insist on doing that usually have a horrible track record and even completely wrong mental models (like using the Swiss cheese model for security, when it's only useful against Nature, not humans).
slooonz 4y ago
Using a random port for SSH (or even "better", port knocking) is a "clever trick", until you forget the one you used for that server that quietly runs on which you log once every two years. Then it can range from minor annoyance to major PITA. Security by obfuscation has the potential to confuse some (mostly dumb) attackers, but it has also the potential to confuse your future self, for VERY minor benefits (since everyone agrees but most of your security should not come from security-through obfuscation anyway). Hence, avoid.
- smitty1e 4y ago
  One would think that if a list of services were going to be bound to non-standard ports, that would be an occasion to document very, very carefully.
- alerighi 4y ago
  You can maintain a .ssh/config file with all the port that you used (and backup it) or use always the same custom port. Anyway, it is useless but it can avoid all sort of bots trying out common login to your SSH server, that consumes resources (even if minimal) and fills your logs.
  - anjbe 4y ago
    > You can maintain a .ssh/config file with all the port that you used (and backup it) Once you start distributing config files to all your clients you might as well switch to keypair authentication, which so completely reduces risk of intrusion that leaving sshd on 22 simply does not matter. > that consumes resources (even if minimal) I suspect practically immeasurable.
  - amelius 4y ago
    How do you pick a good port number that doesn't clash now and in the future? Ps: it is a disgrace that the network/kernel still uses port numbers rather than names, which would be much more flexible.
- hotpotamus 4y ago
  I would say that every attacker I've ever encountered was dumb in the sense that it's a bot just scanning around. For ssh, I'm amazed by 2 things - 1, how quick a new server with 22 open on a public IP will be found and attempted to be compromised by brute force guessing, and 2, how changing the port (even to an obvious one like 2222) will eliminate all that noise. I suppose you could say that the attackers are filtering out anyone who has done some basic hardening, but I suspect the truth is mostly more mundane - the attackers just aren't that motivated/clever; at least the ones who mass scan the internet trying to compromise ssh.
PeterWhittaker 4y ago
Uh, no. While the basic risk formula is pretty much the standard one, the author fails to distinguish between the likelihood of a random or opportunistic attacker (the “most people” of the article) and a targeting/persistent attacker being deterred by a port number change. If you have high value assets and are being targeted, changing the SSH port number has virtually no effect on likelihood. Blocking port scans? Great, they will pay someone in your org $500 for an .ssh/config. Or $5000. Changing SSH port numbers and the other mechanisms in this article are so much bike shedding. Do the hard work first. Implement multiple layers, patching, monitoring, thresholds for automatic disconnect, etc. (Aside: why do you even think the president is in that convoy? They may well be elsewhere, moved into the third suburban at the last possible invisible moment.)
- hospadar 4y ago
  I don't think the author is discouraging anyone to do the "hard work", but rather encouraging them to do the easy work to further protect all that hard work at low added cost.
  - PeterWhittaker 4y ago
    My issue with that is since people have to choose how to spend their time, they may opt to do the easy work first, for very little value, then never get to the hard work, because busy/overloaded. The article oversells the value of this easy work and may lead some astray, lulling them into a false sense of security.
- iwillbenice 4y ago
  > (Aside: why do you even think the president is in that convoy? They may well be elsewhere, moved into the third suburban at the last possible invisible moment.) Unless they are actively repelling an attack, I can guarantee you that the President is absolutely not anywhere except the Beast. All of the other vehicles in the motorcade are less armored, and do not carry the critical items the President may need, namely his blood. The standard operating procedure if the President's motorcade is attacked is to exfil the President while the CAT (Counter Assault Team) lays down massive amounts of suppressing fire. To that goal, the Beast is the safest vehicle for the President to be riding in.
stoplying1 4y ago
Gonna get myself in trouble, but boy I don't really want to debate or collaborate with folks that want to argue this point. Or use things they're working on. Defense in depth, obscurity is not. It's not even interesting to consider beyond dismissing.
- heinternets 4y ago
  Why would camouflage be used by military, or even animals in nature if obscurity is not a useful tool?
  - anjbe 4y ago
    If animals in nature had a defense against predators as effective as “PasswordAuthentication no”, they wouldn’t need camouflage.
    - iwillbenice 4y ago
      I really wish people would stop conflating reducing the attack surface with safe software default configurations. They are not the same. There is value in hiding your listening sockets/ports from the world. Anyone who does not believe so frankly has never been responsible for security beyond their laptop and maybe some random VM in AWS they SSH into.
      - deleted 4y ago
        [deleted]
  - stoplying1 4y ago
CM30 4y ago
This reminds me of how the best spam prevention methods involve making your site's registration system different enough from everyone else's that bots can't fill in the forms automatically. Yeah, it's useless against a dedicated attacker that can write a program specifically to attack your site, but it makes common automated systems useless, and (if done by enough people overall) makes the act of posting spam more expensive overall. You could probably say the same thing here. Yeah it won't work against an attacker who knows what they're doing, and no, it'll never work as your only or main line of security. But it'd probably slow down or stop attacks by random script kiddies using bots bought from dodgy internet forums or what not. And those are a decent percentage of attacks a site or service receives now.
throwawaaarrgh 4y ago
"Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports." Some attackers scan all ports for hosts that are known online through some other port/service/registration. They can also observe your traffic flows at each hop. Brute force scanning all ports on all IPs might take you a month. But after that you have all these easy targets that people don't patch because they think their server is invisible. Putting a painting in front of a safe does not make your safe safer. Every thief knows safes are hid behind paintings.
- dachryn 4y ago
  Whilst I agree philosophically with you, if you see a reduction on in your logs of this unwanted traffic, then it serves a purpose. And that's the point here. There is no claim that this is a good safety precaution, but the claim is that it is underrated, and at least that its worthwile to reduce some of the junk. Its not because something isn't perfect, that it's not worth doing
  - throwawaaarrgh 4y ago
    Turn off logging. It will have the same effect (you won't see brute force attacks on common ports) with the same security. You could also add 2 IPTables rules which would temporarily block all connection requests after hitting a threshold. But I guess actually stopping a brute force attack is less "cool" than changing a port number.
    - heinternets 4y ago
      On what planet is being blind to attempts the same effect as a massive reduction in hits or logon attempts?
      - bakugo 4y ago
        When those attempts are guaranteed to always fail because your server is properly secured, there's no reason to even care that they're happening.
charcircuit 4y ago
Making your username utka or changing the sshd port raises the cost to attack by a meaningful amount, but by simply requiring key based authentication you have raised the price of brute forcing your way in to practically $infinity. If the cost is already at $infinity it's pointless to take additional measures to raise it further as attackers will already have switched to trying to compromise your desktop instead to steal the key. There are some things like anticheat / antivirus / DRM where there is no simple way to make it cost $infinity to break your protection. These kinds cases are where obscurity comes in handy in raising the attacker's costs.
brontosaurusrex 4y ago
A wordpress example from some time ago: Don't have user named 'admin' + plugin that generated random 'login.php reroute' and some more that I can' remember now. Good example of obscurity on extremely popular software (at the time)? I'd imagine it would certainly bounce lots of hacking scripts.
badtension 4y ago
This is tangibly related to gov software being open or not. E.g. do you want your social security or medical system to be open source or not? Much more eyes can look at it and catch bugs. Many adversaries also have eyes and can do a passive analysis even before connecting. And they DO have budgets to do that very thoroughly. This is also a form of security by obscurity.
bell-cot 4y ago
A few simple obscurity tricks - 22 => 2222, /admin/ => /hq/, etc. - can save your ass if there's a remote zero-day, and the bad guys are busy scanning for low-hanging fruit while the good guys learn about it then scramble to patch.
- traceroute66 4y ago
  > 22 => 2222 With a well configured SSH server, 22=> 2222 is pointless, very much the definition of obscurity providing zero security. OpenSSH is impeccably written software, widely battle-tested and its been literally forever since there was any significant vulnerability in it despite being one of the most widely deployed servers on the planet. Enable key/cert only authentication and you are already effectively 100% secure. Then, to double-down: - Harden KexAlgorithms and Ciphers - PermitRootLogin no - Compression delayed - PerSourceMaxStartups - PerSourceNetBlockSize Job done.
  - goodpoint 4y ago
    > Job done. What part of "if there's a remote zero-day" you did not understand?
    - traceroute66 4y ago
      > What part of "if there's a remote zero-day" you did not understand? What part of how about you look at CVE and see its been YEARS/DECADES since the last severe vulnerability do you not understand ? OpenSSH zero-day my ass .... if there were any, they would have been found and exploited by now. OpenSSH is written by the same people as OpenBSD. Those guys are OBSESSIVE about writing secure and correct code and they have the track-record to prove it. Fact is there are millions (billions ?) of OpenSSH servers out there exposed to the internet. OpenSSH is not the way hackers are getting in my friend.
      - JohnJamesRambo 4y ago
        Have you ever heard of the Titanic?
afrcnc 4y ago
The guy who wrote this blog post also previously published an "educational" ransomware project that was widely-abused for half a decade. Just to add some context to this guy's "opinions" -- for those who didn't know. I wouldn't take my advice from someone who open-sourced a fully functional ransomware project for some klout.
- core-utility 4y ago
  Why? The author of Metasploit was widely seen as a "bad guy" by nearly everyone until security researchers realized it was a net-positive to the security community. If my system gets hit with a ransomware that's open source (and thereby likely very easy to create antivirus signatures for), I'd blame my system and the attacker, not the author.
deleted 4y ago
[deleted]
fedeb95 4y ago
While I generally agree, there are two problems with the scan example. First, a survey on twitter isn't exactly good data to base an opinion on. Second, even if the majority would scan the defaults, you still don't know the likelihood of someone doing a targeted attack and scanning the defaults. Such a survey is pretty impossible because you would need data of real attacks.
randyrand 4y ago
100% Have a stock Kia car? It’s trivially to steal because their key fob sucks and they can all be stolen in the same way. Now, take that shitty Kia and personally wire a little toggle in the center console that unplugs the Starter with a relay. All of a sudden no Kia theif will know how to steal it. Easily 100x less likely to be stolen than the fully standard car next to it. Having at least one layer of obscurity should be standard practice. It makes the theif need to put in custom effort. Most people are lazy.
- asimops 4y ago
  But that would be a 'real' security measure. Security by obscurity would be to park it 3 miles away where noone would think you parked it and relabel it as a Skoda.
  - jjav 4y ago
    No, it's a perfect example of security by obscurity. It's just a button, anyone can press it, no key or anything else needed. It's just different from the other cars, so it'll confuse a thief who is following a scripted runbook on "how to steal Kia". Hopefully enough that they move on to the next car.
  - randyrand 4y ago
    Having a toggle switch that unlocks the car is not 'real' security. If every car had that switch, it would offer no security at all. It's only secure because it's uncommon and not known. i.e. obscure
victor106 4y ago
> “Using Symmetric Encryption in the Database: ” Is this the same as encryption at rest? If not, how would you implement this?
- remram 4y ago
  Encryption at rest is actual security.
professorTuring 4y ago
I loved the “5 monkeys” comparison and I agree that everything depends on the real case scenario. My point here is that what the article propose it is no “security through obscurity” it’s just good configuration practices. Change username, port… Security through obscurity goes along in the line: “I have this algorithm in the js that obfuscate the password in the front end, and nobody is gonna guess it because it’s super complex”.
dhsysusbsjsi 4y ago
The more I learn, the more I find that “best practice” isn’t always best. It should be called good defaults. For example “Disable ssh password auth and use keys”. It depends on your threat model. A good password can be secure and may in some cases be more secure than a stolen laptop containing id_rsa. SSH keys are more convenient but rely on physical security. It should be discussed as a trade off.
- dima_vm 4y ago
  AFAIK, it's possible to require both ssh keys and password.
  - alias_neo 4y ago
    I've found the authentication options to be extremely flexible, thanks, I think to PAM[0]? With PAM, it's possible to configure any combination of authentication requirements, in any desired order, with optional steps etc. One can require password AND keys AND physical token, in that order, or password AND keys OR physical token, or any other combination they desire. With PAM, one could go as far as to write a module requiring them to whistle the scooby doo tune to unlock. [0]https://en.wikipedia.org/wiki/Linux_PAM https://en.wikipedia.org/wiki/Linux_PAM
- j-bos 4y ago
  best practice -> good defaults I really like your phrasing. Maybe "favorite defaults" to maintain both the original idea and the nuance.
- jeroenhd 4y ago
  But then you can protect against both keyloggers and stolen laptops by enabling TOTP 2FA. You can even require all three! I have a bastion setup somewhere in my network that's locked behind either an SSH key or a password + TOTP token for when I lose access to all devices with a signed SSH certificate. All devices are encrypted and I don't lose sight of them in public so my threat model would include "the police" and "people violently breaking in and stealing my stuff" but a password isn't going to protect me from that.
cersa8 4y ago
Security through obscurity is fine if it's an additional layer in a well thought out security implementation. I've build a bespoke Node.js site/service where I sometimes have to kick out clients due to various reasons. I sometimes fear reprisal and have to consider a targeted attack on my infrastructure. And indeed I do get the occasional hack attempt with for instance hand crafted sql injection attempts (I receive an instant notification when this happens). The best approach in hardening your infrastructure I think is trying to hack your own service by trying a plethora of methods like sql injection attacks or denial of service attacks on your public api's.
alexjplant 4y ago
It's only worth it when it has real value and doesn't introduce undue operational overhead. I've worked at multiple places where I was told by CISSPs (!) that we mustn't under any circumstances name the servers after what they do because then "the hackers would know what to attack" and that we must instead name them after superheroes or tequilas or some other such whimsy. I pointed out that getting LDAP bind credentials or the zone file from Active Directory is a tall order and that `nmap`ing the subnet for running services is ten times easier only to have the same tired rationale parroted back to me with an appeal to the authority of some 15-year-old security "best practices" document. I've also had similarly-futile discussions about disabling ICMP, browser development tools, RDP/SSH timeouts, and a dozen other things that I've forgotten by now and at no point did I ever get a good reply when asked about why we were introducing so much pain for so little tactical gain. To be clear I always make it a point to disable unused services, change account names, rename wp-admin, etc. because those aren't serious operational burdens and indeed reduce attack surface significantly, but at some point "defense in depth" becomes self-perpetuating box checkery designed to create security work streams. As somebody who cares about practical security _and_ delivering a good experience it's maddening.
aasasd 4y ago
A kind of a tipping point for me was when one commenter called port-knocking ‘security through obscurity’. Sure, let's see attackers pick one of 65535^x combinations of ports, and meanwhile let's hear this smartass wax about how that's categorically different from a password.
- hansvm 4y ago
  To be fair, any box in the middle can sniff that knock sequence, whereas a password can be transmitted securely.
  - aasasd 4y ago
    I think in fact that the sequence can be changing, based on some secret and e.g. current time. Haven't had a chance to implement anything like that, though, and not sure if there's software that supports such an arrangement. It's true however that above some effort it's more of a meaningless flex, and the proper aim of hiding the ports from most attackers would be achieved long before fancy combinations.

105 points by metadat 4y ago

From 2020, previously discussed here, as mentioned in the article: https://news.ycombinator.com/item?id=24444497 https://news.ycombinator.com/item?id=24444497

woopwoop24 4y ago

Risk = Likelihood * Impact If someone is capable enough to combine things, he does not need to be told this advise. All the others we tell just to follow common advise and not live by obscurity because it is crap most of the time. Strong security does not need obscurity

amelius 4y ago
Yeah but it messes up your logs.

heinternets 4y ago

If security through obscurity wasn't somewhat effective, why would the army employ camouflage?

b112 4y ago
Camouflage is offensive, not defensive. You don't defend your country by hiding it, but you do sneak up when attacking...
- bitxbitxbitcoin 4y ago
  Camouflage is absolutely at least as defensive as it is offensive. In the military context - You can defend your country by hiding ie with a nuclear submarine. Camo nets for covering anti aircraft guns, etc. outside of the military context, just look at how camouflage is actually deployed in nature.
pixl97 4y ago
Because at one time it was effective, then someone created IR optics and at least for heat generating/storing objects the effectiveness of camo dropped significantly. Now camo is still effectiveness, say against poor soldiers or one's who had their division leader sell that equipment off to make a little extra income. But you better understand your enemy well, or just putting up camo and then huddling together in a group with no further security will get you killed all at once.
- bell-cot 4y ago
  Straw man. Nobody is arguing for ssh on 2222, with root:root for every server. Also - acquiring / maintaining / training / using good IR equipment consumes far more resources & attention than basic camouflage does. Good troops do something called "field training", where they become quite familiar with how effective cover & camouflage can be. And they've figured out that the stakes on a battlefield are "death", not "deal with server being hacked".
- hoseja 4y ago
  Modern gear reduces your IR signature.
2OEH8eoCRo0 4y ago
Or the entire classification system. Why should you give the enemy a freebie? Obscurity is just another hurdle/layer that wastes an adversaries precious time.
adgjlsfhk1 4y ago
obscurity is great when you have the ability to strike back. it's less good when you're a server that needs to withstand attacks and can't kill the attackers.
protl 4y ago
Isn't that because they don't have a more effective alternative? They're forced to rely on the security by obscurity of camo (ignoring the guns). If you had an indestructable soldier, you could paint them bright pink and have them live stream their position, it wouldn't matter they're indestructable.
- dan_mctree 4y ago
  Isn't that true for software too though? You cannot ever rely 100% on any tool you use, so if you're serious about actually avoiding penetrations and not just about the academic discussion, you're better off using at least a bit of obscurity on top of your real security system.

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..

blincoln 4y ago

Security through making things harder in some unquantifiable way for an attacker to exploit[1] is usually a waste of time (IMO) because there is no way to measure or even estimate with any kind of accuracy how much value it adds versus the costs of implementing and maintaining it. Maybe it will deter attackers forever, because you'll get lucky and no one will ever care enough to put in the effort. Maybe someone becomes obsessed with the thing you're trying to protect, and just for fun figures out how to bypass all of your work in a week, and publishes the result to Full Disclosure. The author of the article cites a typical information security faux version of a real thing: calculating risk by multiplying impact by likelihood. Risk is a real field, with real data collected to make those estimations as accurate as possible. Insurance companies use complex actuarial tables, which is where the old saw about red cars having higher insurance premiums comes from. They really do collect massive volumes of data to make estimates of likelihood from. In my field (information security) people who talk about likelihood are generally just guessing, or trusting their knee to ache when the haxxors are about to pwn the Gibson. There is no data, just someone guessing and plugging the number into a formula so that the result has the appearance of objectivity and science. Implementing controls that "make things harder" is a variation on that same theme. If one wants a security control they can trust, they should pick the ones that have actual math behind them, like "using this random token[/key/whatever] means that an attacker would have to guess for literally one million years to make a successful request". [1] of which security through obscurity is a subset.

anjbe 4y ago

The thesis of the article, that security through obscurity is underrated, is “because it has a low implementation cost and it usually works well.” But I contest both of those things. Common obscurity methods provide low benefit for the amount of work put in, relative to methods with a better foundation. One of the best examples of this is port knocking, a resurging fad in self‐hosting circles, that is completely beaten both in simplicity and in actual protection by putting your SSH server behind WireGuard. Even the example in the article seems ridiculous. I always advocate disabling SSH passwords and using FIDO‐backed SSH keys instead, but of course people will complain that they lose the ability to log in from arbitrary machines (well worth it in my opinion, but fine). So rather than using SSH with a weak password on a non‐default port, why not use SSH with a strong password on a default port, which provides more entropy and also some protection against attacks by a local user, without having to remember weird port numbers?

bogantech 4y ago
Yep and Password auth can also be augmented with some additional PAM modules (like pam_oath and/or pam_yubico) as long as you don't configure them in a way that allows user enumeration. Really the only thing you get by changing the port is less log spam. If your system is so poorly configured that an automated drive-by attack by a bot would be successful then you're gonna get owned anyway if someone decides to target you.
- hospadar 4y ago
  > if someone decides to target you I think reducing log spam is actually a great security outcome, if the only thing normally present in the log are my real logins, an attacker's attempt world stick out like a sore thumb.
deleted 4y ago
[deleted]
marcosdumay 4y ago
Exactly. "Security by obscurity" is a badly defined term that security people use to name the practices that bring too little benefit for their implementation cost. It's derogatory by definition, so it can not be underrated. One can disagree about the evaluation of some specific practice, but the people that insist on doing that usually have a horrible track record and even completely wrong mental models (like using the Swiss cheese model for security, when it's only useful against Nature, not humans).

slooonz 4y ago

Using a random port for SSH (or even "better", port knocking) is a "clever trick", until you forget the one you used for that server that quietly runs on which you log once every two years. Then it can range from minor annoyance to major PITA. Security by obfuscation has the potential to confuse some (mostly dumb) attackers, but it has also the potential to confuse your future self, for VERY minor benefits (since everyone agrees but most of your security should not come from security-through obfuscation anyway). Hence, avoid.

smitty1e 4y ago
One would think that if a list of services were going to be bound to non-standard ports, that would be an occasion to document very, very carefully.
alerighi 4y ago
You can maintain a .ssh/config file with all the port that you used (and backup it) or use always the same custom port. Anyway, it is useless but it can avoid all sort of bots trying out common login to your SSH server, that consumes resources (even if minimal) and fills your logs.
- anjbe 4y ago
  > You can maintain a .ssh/config file with all the port that you used (and backup it) Once you start distributing config files to all your clients you might as well switch to keypair authentication, which so completely reduces risk of intrusion that leaving sshd on 22 simply does not matter. > that consumes resources (even if minimal) I suspect practically immeasurable.
- amelius 4y ago
  How do you pick a good port number that doesn't clash now and in the future? Ps: it is a disgrace that the network/kernel still uses port numbers rather than names, which would be much more flexible.
hotpotamus 4y ago
I would say that every attacker I've ever encountered was dumb in the sense that it's a bot just scanning around. For ssh, I'm amazed by 2 things - 1, how quick a new server with 22 open on a public IP will be found and attempted to be compromised by brute force guessing, and 2, how changing the port (even to an obvious one like 2222) will eliminate all that noise. I suppose you could say that the attackers are filtering out anyone who has done some basic hardening, but I suspect the truth is mostly more mundane - the attackers just aren't that motivated/clever; at least the ones who mass scan the internet trying to compromise ssh.

PeterWhittaker 4y ago

Uh, no. While the basic risk formula is pretty much the standard one, the author fails to distinguish between the likelihood of a random or opportunistic attacker (the “most people” of the article) and a targeting/persistent attacker being deterred by a port number change. If you have high value assets and are being targeted, changing the SSH port number has virtually no effect on likelihood. Blocking port scans? Great, they will pay someone in your org $500 for an .ssh/config. Or $5000. Changing SSH port numbers and the other mechanisms in this article are so much bike shedding. Do the hard work first. Implement multiple layers, patching, monitoring, thresholds for automatic disconnect, etc. (Aside: why do you even think the president is in that convoy? They may well be elsewhere, moved into the third suburban at the last possible invisible moment.)

hospadar 4y ago
I don't think the author is discouraging anyone to do the "hard work", but rather encouraging them to do the easy work to further protect all that hard work at low added cost.
- PeterWhittaker 4y ago
  My issue with that is since people have to choose how to spend their time, they may opt to do the easy work first, for very little value, then never get to the hard work, because busy/overloaded. The article oversells the value of this easy work and may lead some astray, lulling them into a false sense of security.
iwillbenice 4y ago
> (Aside: why do you even think the president is in that convoy? They may well be elsewhere, moved into the third suburban at the last possible invisible moment.) Unless they are actively repelling an attack, I can guarantee you that the President is absolutely not anywhere except the Beast. All of the other vehicles in the motorcade are less armored, and do not carry the critical items the President may need, namely his blood. The standard operating procedure if the President's motorcade is attacked is to exfil the President while the CAT (Counter Assault Team) lays down massive amounts of suppressing fire. To that goal, the Beast is the safest vehicle for the President to be riding in.

stoplying1 4y ago

Gonna get myself in trouble, but boy I don't really want to debate or collaborate with folks that want to argue this point. Or use things they're working on. Defense in depth, obscurity is not. It's not even interesting to consider beyond dismissing.

heinternets 4y ago
Why would camouflage be used by military, or even animals in nature if obscurity is not a useful tool?
- anjbe 4y ago
  If animals in nature had a defense against predators as effective as “PasswordAuthentication no”, they wouldn’t need camouflage.
  - iwillbenice 4y ago
    I really wish people would stop conflating reducing the attack surface with safe software default configurations. They are not the same. There is value in hiding your listening sockets/ports from the world. Anyone who does not believe so frankly has never been responsible for security beyond their laptop and maybe some random VM in AWS they SSH into.
    - deleted 4y ago
      [deleted]
- stoplying1 4y ago

CM30 4y ago

This reminds me of how the best spam prevention methods involve making your site's registration system different enough from everyone else's that bots can't fill in the forms automatically. Yeah, it's useless against a dedicated attacker that can write a program specifically to attack your site, but it makes common automated systems useless, and (if done by enough people overall) makes the act of posting spam more expensive overall. You could probably say the same thing here. Yeah it won't work against an attacker who knows what they're doing, and no, it'll never work as your only or main line of security. But it'd probably slow down or stop attacks by random script kiddies using bots bought from dodgy internet forums or what not. And those are a decent percentage of attacks a site or service receives now.

throwawaaarrgh 4y ago

"Firstly, we’ve eliminated the global brute forcers again since they scan only the common ports." Some attackers scan all ports for hosts that are known online through some other port/service/registration. They can also observe your traffic flows at each hop. Brute force scanning all ports on all IPs might take you a month. But after that you have all these easy targets that people don't patch because they think their server is invisible. Putting a painting in front of a safe does not make your safe safer. Every thief knows safes are hid behind paintings.

dachryn 4y ago
Whilst I agree philosophically with you, if you see a reduction on in your logs of this unwanted traffic, then it serves a purpose. And that's the point here. There is no claim that this is a good safety precaution, but the claim is that it is underrated, and at least that its worthwile to reduce some of the junk. Its not because something isn't perfect, that it's not worth doing
- throwawaaarrgh 4y ago
  Turn off logging. It will have the same effect (you won't see brute force attacks on common ports) with the same security. You could also add 2 IPTables rules which would temporarily block all connection requests after hitting a threshold. But I guess actually stopping a brute force attack is less "cool" than changing a port number.
  - heinternets 4y ago
    On what planet is being blind to attempts the same effect as a massive reduction in hits or logon attempts?
    - bakugo 4y ago
      When those attempts are guaranteed to always fail because your server is properly secured, there's no reason to even care that they're happening.

charcircuit 4y ago

Making your username utka or changing the sshd port raises the cost to attack by a meaningful amount, but by simply requiring key based authentication you have raised the price of brute forcing your way in to practically $infinity. If the cost is already at $infinity it's pointless to take additional measures to raise it further as attackers will already have switched to trying to compromise your desktop instead to steal the key. There are some things like anticheat / antivirus / DRM where there is no simple way to make it cost $infinity to break your protection. These kinds cases are where obscurity comes in handy in raising the attacker's costs.

brontosaurusrex 4y ago

A wordpress example from some time ago: Don't have user named 'admin' + plugin that generated random 'login.php reroute' and some more that I can' remember now. Good example of obscurity on extremely popular software (at the time)? I'd imagine it would certainly bounce lots of hacking scripts.

badtension 4y ago

This is tangibly related to gov software being open or not. E.g. do you want your social security or medical system to be open source or not? Much more eyes can look at it and catch bugs. Many adversaries also have eyes and can do a passive analysis even before connecting. And they DO have budgets to do that very thoroughly. This is also a form of security by obscurity.

bell-cot 4y ago

A few simple obscurity tricks - 22 => 2222, /admin/ => /hq/, etc. - can save your ass if there's a remote zero-day, and the bad guys are busy scanning for low-hanging fruit while the good guys learn about it then scramble to patch.

traceroute66 4y ago
> 22 => 2222 With a well configured SSH server, 22=> 2222 is pointless, very much the definition of obscurity providing zero security. OpenSSH is impeccably written software, widely battle-tested and its been literally forever since there was any significant vulnerability in it despite being one of the most widely deployed servers on the planet. Enable key/cert only authentication and you are already effectively 100% secure. Then, to double-down: - Harden KexAlgorithms and Ciphers - PermitRootLogin no - Compression delayed - PerSourceMaxStartups - PerSourceNetBlockSize Job done.
- goodpoint 4y ago
  > Job done. What part of "if there's a remote zero-day" you did not understand?
  - traceroute66 4y ago
    > What part of "if there's a remote zero-day" you did not understand? What part of how about you look at CVE and see its been YEARS/DECADES since the last severe vulnerability do you not understand ? OpenSSH zero-day my ass .... if there were any, they would have been found and exploited by now. OpenSSH is written by the same people as OpenBSD. Those guys are OBSESSIVE about writing secure and correct code and they have the track-record to prove it. Fact is there are millions (billions ?) of OpenSSH servers out there exposed to the internet. OpenSSH is not the way hackers are getting in my friend.
    - JohnJamesRambo 4y ago
      Have you ever heard of the Titanic?

afrcnc 4y ago

The guy who wrote this blog post also previously published an "educational" ransomware project that was widely-abused for half a decade. Just to add some context to this guy's "opinions" -- for those who didn't know. I wouldn't take my advice from someone who open-sourced a fully functional ransomware project for some klout.

core-utility 4y ago
Why? The author of Metasploit was widely seen as a "bad guy" by nearly everyone until security researchers realized it was a net-positive to the security community. If my system gets hit with a ransomware that's open source (and thereby likely very easy to create antivirus signatures for), I'd blame my system and the attacker, not the author.

deleted 4y ago

[deleted]

fedeb95 4y ago

While I generally agree, there are two problems with the scan example. First, a survey on twitter isn't exactly good data to base an opinion on. Second, even if the majority would scan the defaults, you still don't know the likelihood of someone doing a targeted attack and scanning the defaults. Such a survey is pretty impossible because you would need data of real attacks.

randyrand 4y ago

100% Have a stock Kia car? It’s trivially to steal because their key fob sucks and they can all be stolen in the same way. Now, take that shitty Kia and personally wire a little toggle in the center console that unplugs the Starter with a relay. All of a sudden no Kia theif will know how to steal it. Easily 100x less likely to be stolen than the fully standard car next to it. Having at least one layer of obscurity should be standard practice. It makes the theif need to put in custom effort. Most people are lazy.

asimops 4y ago
But that would be a 'real' security measure. Security by obscurity would be to park it 3 miles away where noone would think you parked it and relabel it as a Skoda.
- jjav 4y ago
  No, it's a perfect example of security by obscurity. It's just a button, anyone can press it, no key or anything else needed. It's just different from the other cars, so it'll confuse a thief who is following a scripted runbook on "how to steal Kia". Hopefully enough that they move on to the next car.
- randyrand 4y ago
  Having a toggle switch that unlocks the car is not 'real' security. If every car had that switch, it would offer no security at all. It's only secure because it's uncommon and not known. i.e. obscure

victor106 4y ago

> “Using Symmetric Encryption in the Database: ” Is this the same as encryption at rest? If not, how would you implement this?

remram 4y ago
Encryption at rest is actual security.

professorTuring 4y ago

I loved the “5 monkeys” comparison and I agree that everything depends on the real case scenario. My point here is that what the article propose it is no “security through obscurity” it’s just good configuration practices. Change username, port… Security through obscurity goes along in the line: “I have this algorithm in the js that obfuscate the password in the front end, and nobody is gonna guess it because it’s super complex”.

dhsysusbsjsi 4y ago

The more I learn, the more I find that “best practice” isn’t always best. It should be called good defaults. For example “Disable ssh password auth and use keys”. It depends on your threat model. A good password can be secure and may in some cases be more secure than a stolen laptop containing id_rsa. SSH keys are more convenient but rely on physical security. It should be discussed as a trade off.

dima_vm 4y ago
AFAIK, it's possible to require both ssh keys and password.
- alias_neo 4y ago
  I've found the authentication options to be extremely flexible, thanks, I think to PAM[0]? With PAM, it's possible to configure any combination of authentication requirements, in any desired order, with optional steps etc. One can require password AND keys AND physical token, in that order, or password AND keys OR physical token, or any other combination they desire. With PAM, one could go as far as to write a module requiring them to whistle the scooby doo tune to unlock. [0]https://en.wikipedia.org/wiki/Linux_PAM https://en.wikipedia.org/wiki/Linux_PAM
j-bos 4y ago
best practice -> good defaults I really like your phrasing. Maybe "favorite defaults" to maintain both the original idea and the nuance.
jeroenhd 4y ago
But then you can protect against both keyloggers and stolen laptops by enabling TOTP 2FA. You can even require all three! I have a bastion setup somewhere in my network that's locked behind either an SSH key or a password + TOTP token for when I lose access to all devices with a signed SSH certificate. All devices are encrypted and I don't lose sight of them in public so my threat model would include "the police" and "people violently breaking in and stealing my stuff" but a password isn't going to protect me from that.

cersa8 4y ago

Security through obscurity is fine if it's an additional layer in a well thought out security implementation. I've build a bespoke Node.js site/service where I sometimes have to kick out clients due to various reasons. I sometimes fear reprisal and have to consider a targeted attack on my infrastructure. And indeed I do get the occasional hack attempt with for instance hand crafted sql injection attempts (I receive an instant notification when this happens). The best approach in hardening your infrastructure I think is trying to hack your own service by trying a plethora of methods like sql injection attacks or denial of service attacks on your public api's.

alexjplant 4y ago

It's only worth it when it has real value and doesn't introduce undue operational overhead. I've worked at multiple places where I was told by CISSPs (!) that we mustn't under any circumstances name the servers after what they do because then "the hackers would know what to attack" and that we must instead name them after superheroes or tequilas or some other such whimsy. I pointed out that getting LDAP bind credentials or the zone file from Active Directory is a tall order and that `nmap`ing the subnet for running services is ten times easier only to have the same tired rationale parroted back to me with an appeal to the authority of some 15-year-old security "best practices" document. I've also had similarly-futile discussions about disabling ICMP, browser development tools, RDP/SSH timeouts, and a dozen other things that I've forgotten by now and at no point did I ever get a good reply when asked about why we were introducing so much pain for so little tactical gain. To be clear I always make it a point to disable unused services, change account names, rename wp-admin, etc. because those aren't serious operational burdens and indeed reduce attack surface significantly, but at some point "defense in depth" becomes self-perpetuating box checkery designed to create security work streams. As somebody who cares about practical security _and_ delivering a good experience it's maddening.

aasasd 4y ago

A kind of a tipping point for me was when one commenter called port-knocking ‘security through obscurity’. Sure, let's see attackers pick one of 65535^x combinations of ports, and meanwhile let's hear this smartass wax about how that's categorically different from a password.

hansvm 4y ago
To be fair, any box in the middle can sniff that knock sequence, whereas a password can be transmitted securely.
- aasasd 4y ago
  I think in fact that the sequence can be changing, based on some secret and e.g. current time. Haven't had a chance to implement anything like that, though, and not sure if there's software that supports such an arrangement. It's true however that above some effort it's more of a meaningless flex, and the proper aim of hiding the ports from most attackers would be achieved long before fancy combinations.