I practice security through obscurity every day. For example I don't flash large amounts of money when out in public. The notion that security through obscurity isn't security is and always has been monumentally stupid. In some sense sure cover is better than concealment, but in the real world 100% concealment is better than 100% cover since in the former case one won't be taking fire at all.
Security by obscurity is underrated
361–370 of 530 posts
Re: Security by obscurity is underrated
#362Earlier quoted context omitted.
> Using a non-standard SSH port is a bad example because nmap can see through that deception in a few seconds. Compared to milliseconds. Do yourself the favor and open one sshd on port 22 vs one on a port >10000, then compare logs after a month. The 22 one will have thousands of attempts; the other one hardly tens if even any. The 99% level we're defending against here is root:123456 or pi:raspberry on port 22. Which…
I know we've spoken in another thread, but I think it's important for people to understand that this sshd thing is a perfect example of why it isn't this easy: You reduce log spam moving to a non-privileged port, but also reduce overall security - a non-privileged user can bind to a port above 10k, but can't bind to 22. sshd restarts for an upgrade, or your iptables rules remapping a high port to 22 get flushed, that…
Yeah, I'm seeing a lot of nonsense in here. Why is SSH publicly accessible in the first place???
Security through obscurity is just some feel good bullshit.
Re: Security by obscurity is underrated
#363Earlier quoted context omitted.
If port knocking existing in a vacuum, sure. It'd be great. The issue is there are other options that are better - like VPN only access to SSH - that you can use instead of (or in addition to) If everyone advocating for port knocking was also saying set up VPN only access, sure. It's an additional authorization factor via where ports are used as a proxy for a PIN. But I haven't seen a single person in here saying the…
Curious, how does this work? I am not very familiar with VPN. Is the VPN connection setup for the SSH session only? What if someone needs to have multiple SSH session, going to different networks altogether? Im thinking it could be pretty impractical to go onto a whole other network to open an SSH session.
>Curious, how does this work?
It depends on the implementation. For a client server VPN, it creates an interface on your local machine that corresponds to the network address range for the VPN, and tunnels traffic to the remote end.
For a site to site VPN, two appliances create a tunnel between them, and traffic is routed over that tunnel via the same sort of routing rules you normally use.
> Is the VPN connection setup for the SSH session only?
It can be. It can also be configured for all traffic, or some other combination.
> What if someone needs to have multiple SSH session, going to different networks altogether?
You can have multiple VPN connections to multiple networks. It can get complicated if the VPNs are using overlapping IP space.
> Im thinking it could be pretty impractical to go onto a whole other network to open an SSH session.
I'm not entirely sure why. Millions of people use VPNs every day for a variety of reasons, including SSH. I currently have 8 saved VPN configurations in my wireguard client, and connecting to one is as simple clicking on the client and picking the one I need in the dropdown. Then I SSH as normal, except its to the server's private IP and not public.
Re: Security by obscurity is underrated
#364Earlier quoted context omitted.
> 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…
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…
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
Re: Security by obscurity is underrated
#365There'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…
> Just use SSH keys, and disable passwords. CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to con…
I think the fact that you had to list the 20-year-old SSH CRC compensator vulnerability to establish the untrustworthiness of SSH is telling; very few pieces of software have OpenSSH's current track record. I would cite the same 2 vulnerabilities to suggest that SSH is as trustworthy as almost any other piece of software you can run.
Having said that: I don't like exposing SSH services either! Which is why I try to keep them behind WireGuard, at least on prod networks that I care about.
In contrast to an actual VPN, port-knocking and (heh) nonstandard SSH ports shield you only from casual attackers; both give a middlebox attacker all the access they need to launch the attack.
Re: Security by obscurity is underrated
#366I practice security through obscurity every day. For example I don't flash large amounts of money when out in public. The notion that security through obscurity isn't security is and always has been monumentally stupid. In some sense sure cover is better than concealment, but in the real world 100% concealment is better than 100% cover since in the former case one won't be taking fire at all.
the problem with that (and security through obscurity in general) is that if your opponent attacks at random, they still have a chance of getting you. having lived in a bad neighborhood I can tell you that you don't have to flash money, or even look like you have any money to get into trouble (someone chooses you at random for a gang imitation, crackhead wants your shoes, or someone is just straight up crazy). it's always better to have as much cover is reasonable, and beyond that concealment doesn't hurt.
Re: Security by obscurity is underrated
#367There'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…
I think a lot of the people in this comment thread are missing the point when using the `sshd` example. There is no single infallible way to secure ssh, but there are a lot of things that can be done together to make it pretty darn hard to hack, and most of those countermeasures have some degree of 'obscurity' to them. Example: * Use RSA keys instead of passwords -> This will eliminate most risk, except for exploits…
Neither changing the SSH port nor using IP source address filters constitute serious countermeasures; they complicate systems and offer little return on the investment. Don't bother. If you're worried enough to change the SSH configuration, set up WireGuard.
Re: Security by obscurity is underrated
#368Earlier quoted context omitted.
This is significantly better than just changing the port the daemon listens on, for sure. There's still public access to SSH, so you're still at risk from a zero day, weak credentials, etc., so I don't think it's quite to ideal levels where you are employing a VPN, disallowing all public access, etc., but at least you're not introducing new potential attack vectors :)
What about VPN makes the VPN server software more secure than the SSH server software?
The level of security is cumulative. You do not trust a connection just because it's connected to the VPN. So if your VPN concentrator is compromised via 0day, the only access they get is the same as if things were listening on the public internet.
To gain access to the server via SSH they now need both a way in to the VPN and a way in to SSH, vs. just needing a way in via SSH.
It doesn't do much if someone just gives up the keys for the VPN and SSH, but it would mean that you would need two simultaneous exploits for the VPN and SSH to gain access.
Re: Security by obscurity is underrated
#369Earlier quoted context omitted.
Though it would be a tragicomic shame if you got caught by a nasty 0-day while the clown up at port 34015 narrowly escaped and earned enough time to patch before pre-mapped host scans begun.
Doesn't matter how much you vote me down. You know it's an entirely possible scenario, and having your sshd "off-port" as part of the security strategy can make the difference.
No, it's not, and it won't.
Re: Security by obscurity is underrated
#370Raising the cost of attacks is a good thing, particularly if the cost of doing so is not too great.
However, beware that obscurity is in the eye of the beholder, or more relevantly, in the eye of the attacker. For example, script kiddie attackers may be the ones who in the twitter example only scan the default ports. This is an important element to defend against.
But a seriously skilled attacker isn't going to use script kiddie methods. They will use more complete, likely stealthy attack patterns.
Bear in mind that what you think of obscure may be breakfast for a skilled attacker. If you are serious about defense, then you will be compelled to follow the ninja threat model, which, in part, says The attacker is going to sit on the same network segment as the application. There’s no firewall or filters. There’s a special place in hell reserved for products that require firewalls or filtering to protect themselves against attack.
Focus too much on obscurity and you will fall victim to the fallacy of "defense by presumed motive."