341–350 of 530 posts
Earlier quoted context omitted.
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?
Most distributions come with a 'portreserve' daemon for just this purpose.
Earlier quoted context omitted.
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…
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…
But how much of a threat is this? Who's going to drop a ssh 0day with PoC for script kiddies to use? If it's a bad guy he's going to sell it on the black market for $$$. If it's a bad guy he's going to responsibly disclose.
>You're right that these events could happen. But you have to ask yourself what's actions of yours will have a bigger impact:
>* Changing to non-standard SSH port, blocking out ~50% of all automated hacking attempts. Or port-knocking to get >90% (just a guess!).
But blocking 50% of the hacking attempts don't make you 50% more secure, or even 1% more secure. You're blocking 50% of the bottom of the barrel when it comes to effort, so having a reasonably secure password (ie. not on a wordlist) or using public key authentication would already stop them.
Earlier quoted context omitted.
The number of times I've seen people shitting all over port knocking is truly confusing. Since we added it several years ago, we've not had a single case of hackers trying to break into sshd. Before port knocking, 100's a day, even though it was on a very unusual port. I try to tell people this, when they poo poo port knocking, but they just don't get it. EDIT: s/the/they/
But serious question -- what exactly is the benefit? Before, it's not like they were getting in anyways if you were using keys. So I confess I still don't "get it". Unless you just want cleaner logs or something. I assume you're still getting the same number of initial connection attempts per day, but just not recording them? Is it something to do with network or CPU consumption related to failed subsequent attempts…
Earlier quoted context omitted.
In nature, prey animals will sometimes jump when they spot a predator[1]. One of the explanations is that this is the animal communicating to the predator that it is a healthy prey animal that would be hard to catch and therefore the predator should choose to chase someone else. I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give…
The only downside I see immediately is that there's a counterweighted risk to obscurity in your security layer: you can confuse your own users (or yourself). Many security tools I've used are downright user hostile in how little information they provide the end-user (or the admin!) regarding why an auth process failed. It incentivizes people to simplify or bypass the system entirely when they can't understand the sys…
Agree with the article. People have been misinterpreting "security by obscurity is bad" to mean any obscurity and obfuscation is bad. Instead it was originally meant as "if your only security is obscurity, it's bad". Many serious real-world scenarios do use obscurity as an additional layer. If only because sometimes, you know that a dedicated attacker will be able to breach, what you are looking for is to delay them…
Agreed. The maxim warning against "security from obscurity" is often reduced to an irrational comprehensive avoidance of obscurity. It's similar to the irrational avoidance of all performance optimization because Knuth warned of premature optimization. Both reductions lose practical utility by omitting nuance. * Avoid wasting your time doing performance optimization until tuning is necessary. But definitely take obvi…
Earlier quoted context omitted.
But serious question -- what exactly is the benefit? Before, it's not like they were getting in anyways if you were using keys. So I confess I still don't "get it". Unless you just want cleaner logs or something. I assume you're still getting the same number of initial connection attempts per day, but just not recording them? Is it something to do with network or CPU consumption related to failed subsequent attempts…
There have been bugs found in SSH server implementations that allowed limited remote code execution or even authentication bypasses. Missing an update or two isn't bad when nobody can figure out how to connect to your server. Of course you have to update at some point. However, if someone drops a zero day on your SSH server while you're asleep you're probably glad that you've got a secret sauce to protect your server…
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 they use it in addition to a VPN - people are saying it's their primary form of protection.
You can setup a wireguard VPN in as much time as it takes to set up port knocking. Now you have all of the benefits port knocking provides, and more. And you could even still set up port knocking in addition to the VPN if you really wanted to, but I would argue there's not much point.
All software security comes down to obscurity: it depends on the selection of specific numbers that are known to the authorized parties, but are extremely difficult to guess (i.e. very obscure) to the unauthorized parties. The extreme of this strategy is to make a successful guess cost more than anyone can possibly pay, for example by using numbers so obscure that all known algorithms for guessing them will take long…
Security can also be achieved by physical separation or identity based on physical human traits. Now we're getting philosophical, but if the security crew of the data center knows my face, and does not allow other people to enter, would you reduce my face to a value that is "extremely difficult to guess"?
Earlier quoted context omitted.
Security can also be achieved by physical separation or identity based on physical human traits. Now we're getting philosophical, but if the security crew of the data center knows my face, and does not allow other people to enter, would you reduce my face to a value that is "extremely difficult to guess"?
Right. There are three types of authentication factors: something you know, something you have, something you are. Obscurity and passwords fall under "something you know". Biometrics like what you describe would fall under "something you are". A physical key such as a yubikey or the sim card matching an SMS challenge would be "something you have". Multi-factor authentication is more secure but it doesn't negate the d…
Earlier quoted context omitted.
>I think we can kind of view obscurity in the same way. It's a way to signal to a predator that we're a hard target and that they should give up. This has it completely backwards. Security through obscurity's goal is not to signal predators, it's the opposite. The goal is to obscure, to hide. The "signal" is there is nothing here (or nothing here worth your time). One of the best examples (it's in the article!) is ch…
> 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…
Usually this is a poor choice vs. going with the published industry standard, because crypto is hard to get right, and people rolling their own implementations usually screw it up, making life much easier for dedicated attackers than trying to attack something that people have been trying and failing to breach for years or decades.
Software makers for example typically don’t publish the technical details of their anti-piracy code. But this usually doesn’t prevent software that people care about from being “cracked” quickly after release.
What’s missing here is the discussion of tradeoffs. I fail to see how e.g., requiring port knocking adds enough security to justify the annoyance. Changing the default port, maybe, but given how easily it’s detected anyway, the cons still outweigh the pros IMO.