3 ms·

I guess my point is largely: I can set up a VPN in a roughly similar timeframe to setting up port knocking, and it has roughly similar overhead for end user, bu

I guess my point is largely: I can set up a VPN in a roughly similar timeframe to setting up port knocking, and it has roughly similar overhead for end user, but the VPN gives me significantly more security while also solving the same issue port knocking does. In that case, why not just set up a VPN instead of port knocking?

justinsaccount 6y ago
Which vpn though? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secure https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secur... VPN doesn't magically fix all problems. wireguard is good so far, but the kernel implementation is in C, so who knows.
- cthalupa 6y ago
  No, a VPN isn't magic in and of itself. And yes, I would suggest wireguard for the simplicity and performance these days. I do agree with the author of the original article that security should come in layers Once something is secured with SSH and a VPN, you've got that many more actual layers - you now need a CVE that allows access or credential leak for both the VPN and SSH. (And many of those CVEs don't necessarily allow a random attacker to arbitrarily gain access) https://news.ycombinator.com/item?id=24446919 https://news.ycombinator.com/item?id=24446919 has my list of what the bare minimum SSH protections should be for anything where you are storing customer/user data in my opinion, as well as additional best practices that I have employed.
rsync 6y ago
I will again agree with you that the VPN is a more robust and more complete protection. You are correct. I think the reason I continue to prefer (and evangelize) port knocking is that the intersection of (modest) security gain and simplicity/robustness hits a sweet spot for me. Again, 10+ years in production on many hosts, worldwide, and never so much as a blip. IF knockd were to fail, it would fail in a very boring way. VPNs, on the other hand, are far more complex and they fail in fascinating ways. I am a sysop turned sysadmin - this is my lifes work. I prefer simple, unixy tools that fail in boring ways :)
- Kalium 6y ago
  Not to be That Guy, but what I'm reading is that you have the wonderful opportunity before you to learn about VPNs until they fail in boring ways!
  - rsync 6y ago
    That's not how that works. Simple systems tend to fail in boring ways. Complex systems tend to fail in interesting ways. Learning more about a complex system, while rewarding in many ways, will not change that identity.
    - Kalium 6y ago
      It's been my experience that a system's complexity (basic or complex) is less an intrinsic trait and more a matter of subjective perception, familiarity, and experience. Your experience is clearly different.
foxtrottbravo 6y ago
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 / (would be*) indeed more elegant because - it makes no promises to be secure (as in as secure as a VPN) - one could argue: if you use it you know that portknocking is just an additional security layer - and maybe don’t get lazy as in a VPN - a misconfiguration or bug or an attacker might expose sshd on your hosts - a misconfigured VPN at least in a somewhat sizeable deployment can lead to countless attack surfaces Having said that, that only will work if the rest of the sshd security is in check and your password isn’t hunter2
- cthalupa 6y ago
  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 public ones. Someone burning two private zero days on you means you're an incredibly high value target and neither of these would suffice as your sole defense to begin with. 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 than if it was reachable by port knocking? It's possible, but I don't know that the evidence really shows that - lots of comments on this article are along the lines of "i set up port knocking and I've never even seen a malicious ssh connection attempt since then!" - no details of the rest of the security measures they've got in place. And yeah, going from 'I set up a VPN to connect to my web servers via ssh' to 'I have VPN access to a whole network with all sorts of things running on it' is a big step up, but I don't think it's really in the boundaries of this discussion. Port knocking was never going to be a replacement for a larger VPN deployment, and when you're opening up network access to a wider range of things then how you approach things definitely needs to change.

justinsaccount 6y ago

Which vpn though? https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secure https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=pulse+secur... VPN doesn't magically fix all problems. wireguard is good so far, but the kernel implementation is in C, so who knows.

cthalupa 6y ago
No, a VPN isn't magic in and of itself. And yes, I would suggest wireguard for the simplicity and performance these days. I do agree with the author of the original article that security should come in layers Once something is secured with SSH and a VPN, you've got that many more actual layers - you now need a CVE that allows access or credential leak for both the VPN and SSH. (And many of those CVEs don't necessarily allow a random attacker to arbitrarily gain access) https://news.ycombinator.com/item?id=24446919 https://news.ycombinator.com/item?id=24446919 has my list of what the bare minimum SSH protections should be for anything where you are storing customer/user data in my opinion, as well as additional best practices that I have employed.

rsync 6y ago

I will again agree with you that the VPN is a more robust and more complete protection. You are correct. I think the reason I continue to prefer (and evangelize) port knocking is that the intersection of (modest) security gain and simplicity/robustness hits a sweet spot for me. Again, 10+ years in production on many hosts, worldwide, and never so much as a blip. IF knockd were to fail, it would fail in a very boring way. VPNs, on the other hand, are far more complex and they fail in fascinating ways. I am a sysop turned sysadmin - this is my lifes work. I prefer simple, unixy tools that fail in boring ways :)

Kalium 6y ago
Not to be That Guy, but what I'm reading is that you have the wonderful opportunity before you to learn about VPNs until they fail in boring ways!
- rsync 6y ago
  That's not how that works. Simple systems tend to fail in boring ways. Complex systems tend to fail in interesting ways. Learning more about a complex system, while rewarding in many ways, will not change that identity.
  - Kalium 6y ago
    It's been my experience that a system's complexity (basic or complex) is less an intrinsic trait and more a matter of subjective perception, familiarity, and experience. Your experience is clearly different.

foxtrottbravo 6y ago

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 / (would be*) indeed more elegant because - it makes no promises to be secure (as in as secure as a VPN) - one could argue: if you use it you know that portknocking is just an additional security layer - and maybe don’t get lazy as in a VPN - a misconfiguration or bug or an attacker might expose sshd on your hosts - a misconfigured VPN at least in a somewhat sizeable deployment can lead to countless attack surfaces Having said that, that only will work if the rest of the sshd security is in check and your password isn’t hunter2

cthalupa 6y ago
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 public ones. Someone burning two private zero days on you means you're an incredibly high value target and neither of these would suffice as your sole defense to begin with. 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 than if it was reachable by port knocking? It's possible, but I don't know that the evidence really shows that - lots of comments on this article are along the lines of "i set up port knocking and I've never even seen a malicious ssh connection attempt since then!" - no details of the rest of the security measures they've got in place. And yeah, going from 'I set up a VPN to connect to my web servers via ssh' to 'I have VPN access to a whole network with all sorts of things running on it' is a big step up, but I don't think it's really in the boundaries of this discussion. Port knocking was never going to be a replacement for a larger VPN deployment, and when you're opening up network access to a wider range of things then how you approach things definitely needs to change.