A field where obfuscation is very common is commercial video games where they are now up to the point of using a virtual machine that generates an instruction set randomly at compile time to obfuscate some part of the code. These games are still cracked almost on release day.
Security by obscurity is underrated
311–320 of 530 posts
Re: Security by obscurity is underrated
#312Arguably, most security is security through obscurity. No password -> simple password -> complex password Plaintext -> Caesar cypher -> Vernier cypher -> modern cyphers 40-bit crypto -> 56-bit crypto -> 128-bit crypto -> 256-bit crypto 0.0.0.0 network allow-list -> /24 network allow-list -> /32 (per host) network allow-list allow by default -> deny by default standard port -> non-standard port We just add layers of o…
In fact, there may be obscurity in the encryption method. You won't find a decryption method for my encryption algorithm on the internet. You have to do crypto analysis.
My algorithm is reorganized caesar with block encryption
Re: Security by obscurity is underrated
#313Earlier quoted context omitted.
Here's a counter-example (I said else-where in this thread): Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. I'll also point out that we're generally talking about different threat vectors here, so it's good to lay them out. I don't think obscurity helps against a persistent threat probing your network, it helps aga…
>Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. Yep! And I should be clear: I am not saying just don't change the SSH port. I'm saying if you care about security, at a minimum disallow public access to SSH and set up a VPN at a minimum. >Unfortunately that's all too rare in most web-servers I see ( I'm a bit confus…
Protecting sshd behind a VPN just moves your 0day risk from sshd to the VPN server.
Choosing between exposing sshd or a VPN server is just a bet on which of these services is most at risk of a 0day.
If you need to defend against 0days then you need to do things like leveraging AppArmor/Selinux, complex port knocking, and/or restricting VPN/SSH access only to whitelisted IP blocks.
Re: Security by obscurity is underrated
#314While the article does have a point that obscurity can improve defences, I think security is not about defence. Security is about managing risk in a consistent and rational manner. This means that any defense mechanism need an appropriate level of defense against the threat.
Having a network share on the home network that only your household can access and use 2FA for that? Maybe a bit too much. Do you know your organization will be individually targeted by smart and tenacious actors? Changing the SSH port isn't gonna stop them.
I agree with the article that more discussion about what makes something secure is valuable security work. Disregarding defenses at first sight because they "sound obscure" isn't a good argument. But it also doesn't mean that "small things that might stop someone" is a good layer of defense.
And then there is also the cost of adding security layers...
Re: Security by obscurity is underrated
#315A field where obfuscation is very common is commercial video games where they are now up to the point of using a virtual machine that generates an instruction set randomly at compile time to obfuscate some part of the code. These games are still cracked almost on release day. https://en.wikipedia.org/wiki/Denuvo
It makes the barrier to entry MUCH, MUCH higher. First you have to unpack a binary, THEN you have to fixup any custom VM call that it makes. Basically only incredibly specialized people/groups will be able to do this.
Contrasting to games of the 2000s the barrier has been raised significantly for hackers
Re: Security by obscurity is underrated
#316There's something to the idea of rehabilitating "obscurity", or at least recognizing that "cost" is part of threat models, and you can raise costs for particular attack vectors by degrees instead of "to infinity". But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", o…
"But SSH is a terrible example, because the cost to the defender of simply not having SSH vulnerabilities is the same, or even less, than the cost of obfuscating it with nonstandard ports, "port knocking", or fail2ban, which are all silly ideas." I know who I am arguing with here but port knocking is not silly. It's fantastic . When I say fantastic, I don't mean it solves all of our problems and obviates any other pr…
> I believe there are sshd vulns extant that you and I don't know about and port knocking allows me to worry less about them.
That's interesting, that's the first time I've heard a justification for port knocking that actually makes sense to me.
I'm curious for others' thoughts here -- are non-public vulnerabilities something you consciously try to mitigate? So that, for example, using 2 different 8-character passwords that are implemented with different technologies, is therefore fundamentally more secure than a single 16-character password? Precisely so that a vulnerability in one is still protected by the other?
To me this feels like it's really only applicable if you need to protect your data from hostile governments targeting you specifically, who might actually have zero-days they have weaponized.
However, if you're just trying to protect yourself from everyday hackers or even targeted corporate espionage, is unknown vulnerabilities really something that's realistically worth protecting oneself from? (Assuming you're always installing all security patches.)
Re: Security by obscurity is underrated
#317Earlier quoted context omitted.
>Imagine a 0day for SSH drops tomorrow. Almost immediately script kiddies all over the world will be trying to take over everything running on port 22. Yep! And I should be clear: I am not saying just don't change the SSH port. I'm saying if you care about security, at a minimum disallow public access to SSH and set up a VPN at a minimum. >Unfortunately that's all too rare in most web-servers I see ( I'm a bit confus…
Protecting sshd behind a VPN just moves your 0day risk from sshd to the VPN server. Choosing between exposing sshd or a VPN server is just a bet on which of these services is most at risk of a 0day. If you need to defend against 0days then you need to do things like leveraging AppArmor/Selinux, complex port knocking, and/or restricting VPN/SSH access only to whitelisted IP blocks.
Except you don't assume that just because someone is on the VPN you're secure.
If the VPN server has a 0day, they now have... only as much access as they had before when things were public facing. You still need there to be a simultaneous sshd 0day.
I'll take my chances on there being a 0day for wireguard at the same time there's a 0day for sshd.
(I do also use selinux and think that you should for reasons far beyond just ssh security)
Re: Security by obscurity is underrated
#318A field where obfuscation is very common is commercial video games where they are now up to the point of using a virtual machine that generates an instruction set randomly at compile time to obfuscate some part of the code. These games are still cracked almost on release day. https://en.wikipedia.org/wiki/Denuvo
Most PC game sales occur in the first 30 days after release. Protecting even a few days adds significant value to the publisher.
Some protection methods do last a long time. StarForce 3.0 protected SplinterCell took 422 days to crack. Not long ago cracking Denuevo protected games took around 75 days [1,2]. I'm not aware what the current best protections are or how long such protected games take to crack.
[1] https://news.ycombinator.com/item?id=21953764
[2] http://web.archive.org/web/20200104093734/https://iscracked....
Re: Security by obscurity is underrated
#319Earlier quoted context omitted.
For production use cases in a business environment it's just not as good as the alternatives. Setting up VPNs and blocking SSH access to the internet is just as easy, less overhead, and more secure. Let's say you're a bank. You implement port knocking as your security measure of choice to keep SSH secure. I know from your job postings that your developers and IT department work at X location in Y city. I know the IP…
There's just not really any reason to use port knocking over a VPN when the difference in overhead and complexity is minimal and the benefits you get with a VPN vs. port knocking are so massive. But I would say in addition to a VPN, not instead of. Imagine the vpn client had it built in to do the knock, before connecting. So the VPN ports are not opened until the knock is performed and only for the source IP that did…
I mean, you could - it's not going to make things less secure to add port knocking - but I don't know that it makes things significantly more secure. The chances of there being public 0day exploits for a VPN and SSHD at the same time is pretty much zero, especially if you add in additional layers such as 2FA (which I would recommend doing)
If someone is burning multiple private 0day exploits to target you then they are attackers at the level where port knocking is not likely to foil them either.
(And to be clear, I just think that port knocking is a bit silly - not that it's totally ineffective, and it's not what I would call security through obscurity, since it is effectively another auth factor with a simple PIN)
Re: Security by obscurity is underrated
#320I think there's two different things we're talking about here, one is hiding things and the other is using obscure ways of doing things.
Changing your SSH port is the former.
Using NETRJS instead of SSH is the later.
Hiding things is just a good security practice in general (just understand hackers have access to port scanners) so that kind of "security through obscurity" isn't a bad idea. Using obscure protocols is something quite different, and really shouldn't be in the same category.