421–430 of 530 posts
"if you can reduce risk probabiloty with zero cost..." since when is obscurity zero cost? You've seen how much denuvo and vmprotect cost? Can you name any free free code obfuscator besides proguard that actually works? Can you name one that supports golang or rust? Security trough obscurity is considered bad because it's not zero-cost, and the investment you put into it might rather go into actual security
Changing the port number is quite cheap.
Earlier quoted context omitted.
> 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 passwor…
I agree. I think this comes down to the Mickens Security Threat Model. Your adversaries come in basically two forms: Mossad and Not-Mossad. If your adversary is Mossad, you've already lost; if a governmental actor wants your data badly enough, they'll get it. If your adversary is not-Mossad, they almost certainly don't have access to any secret zero-day exploits; stay up to date on patches and use good passwords and…
Earlier quoted context omitted.
But without the VPN, you're already the equivalent of on the LAN because all of these services are exposed to the public internet. In the discussion we're having, we're going from a setup where there is no equivalent to a private network because everything is public, to having a private network that only allows you access to the things that were previously public.
No because I have a firewall in front of the SSH, as mentioned. I would assume a firewall is in front of the VPN as well of course. So either only SSH is exposed to the public, or only VPN is exposed. Without an additional firewall after the VPN, how is my LAN more protected with the VPN vs SSH?
With your configuration, all that needs to exist is an SSH 0 day to gain access to the server. With a VPN, they need that AND a 0 day for the VPN software to gain access to the server.
You can have a more complex setup with a VPN, but that isn't the discussion here - the discussion is securing SSH. If you want to provide VPN access to an array of other services, or as access to a corporate LAN or similar, then that's another conversation that has to involve the specifics of those services and that configuration. It's not what is being recommended here.
Earlier quoted context omitted.
But new people in the industry shouldn't think that the things recommended in the article should be used as a primary defense and are accepted industry practices. Moving SSH to a new port to reduce false security alerts is one thing, having people read that article and walk away thinking this is how we do things is another. We don't.
I didn't take that away from the article at all. It said: > So let’s talk about security by obscurity. It’s a bad idea to use it as a single layer of defense. If the attacker passes it, there is nothing else to protect you. But it’s actually would be good to use it as an “additional” layer of defense. Because it has a low implementation cost and it usually works well. I think it's good to do those things in addition…
There is a reason the military doesn't paint their tanks bright pink... Armor is important, but if you don't get shot at in the first place, even better.
There'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 use SSH keys, and disabled passwords. However when I was running SSH on port 22, the number of attempts was slowing my machine to a crawl at times. Moving the port to some obscure random one divided the number of requests from several thousands per hour to a few per day. Definitely an improvement by any measure : suddenly you can analyze the attacks if necessary. I run fail2ban on top of it, because why not? In cas…
Earlier quoted context omitted.
My daily bread and butter is VPNs, but I must admit that I think there may be a truth here. While I fully agree that portknocking doesn’t provide the same layer of protection or flexibility a VPN does - but with the original article in mind: if your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution. Therefore portknocking is /…
I think get where you're coming from here, but I don't fully agree. >f your reason for deploying a VPN is because you fear to expose unknown bugs in sshd to the Internet the same could be said about every vpn solution. Yeah. You might have a VPN zero day - but then you still have to get into the other SSH servers. Two zero days simultaneously active for openssh and your VPN solution? Pretty unlikely, especially publi…
So yes, if we want to be fair we have to compare an in-host defense system like portknocking (which has one job: secure sshd) to a in-host vpn setup more alike to like the often mentioned wireguard.
And in this "configuration" I completely agree. I still think it may be more likely for a VPN to expose security critical bugs than a bug in knockd - but as you said this should only allow access to your next layer of defense (namely sshd) and maybe (if you're a really valuable target) a three-letter-agency might throw all their resources at you and are willing to throw every weaponized exploit they have at you - yeah than you're even more correct because than they would have a far easier time just intercepting your port knock sequence and throwing all their quantum computation power against your sshd keys.
> The rest of your argument, if I'm understanding it correctly, is that you think people will get more lax with securing SSH on a box only reachable via VPN
The argument I was trying to make is that while a VPN is in in every way a really good idea (the way we described it here - as an in-host security layer) but I have yet to see it being rolled out in that way.
I come from a more traditional sysadmin setting, and of most sysadmins I worked with would find implementing this "correctly" to tedious and would either
a) terminate the vpn connection at the rack or co-location "border" and shove a bunch of servers down a single VPN connection b) terminating every servers vpn connection at a single vpn concentration point
Regardless of which, in virtually all cases that I know of never was there any thought given about intra-VPN firewall rules or allowing only certain ports on the VPN. Most of the time you get the servers that are somewhat related, shove them in a subnet expose that subnet via VPN and you're golden.
And so from my practical experience, I would think that a compromised VPN in my reality would be worse than a exploited knockd, but only because it isn't scoped to the same level.
On a sidenote: I'll guess that modern orchestration tools make it pretty easy to roll out knockd and / or wireguard pretty easily in the discussed fashion - it's just I don't get to play with those.
That was a lot of text, just to say I agree with you - but hey, I guess agreeing on something on the internet is somewhat nice so have a great day.