It solves none of your problems and adds complexity and cost to your defense without corresponding increases to attacker costs.

If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.

Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all. I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.

>It solves none of your problems

Wrong, it solves tons of them.

>adds complexity and cost

Almost zero complexity and cost. Maybe if you're a bad at sysadmin work it adds cost and complexity.

>defense without corresponding increases to attacker costs.

It adds a _huge_, almost incalculable cost increase to attackers.

>If you believe there are unknown OpenSSH attacks, you can't coherently believe that port knocking is a real defense, since port knocking doesn't do anything to protect the SSH channel that attacks will be carried out in.

Looks like you don't understand the concept of 0-days. Several CVEs we're listed elsewhere. I suggest researching 0-day exploits so you understand how port knocking mitigates them.

Port knocking mitigates 0-days.

>Instead, if you're actually worried about OpenSSH vulnerabilities, you shouldn't be exposing SSH to the public Internet at all.

I don't disagree here, VPN is a great solution. Nonetheless, for some shops simple port-knocking on a bastion host solves, a lot of these issues, and removed the complexity that VPNs add.

>I'm not super worried about OpenSSH server vulnerabilities, but I would never recommend that teams leave SSH exposed; they should just hide that stuff behind WireGuard.

No one is super worried about things like shellshock, heart bleed, etc. until they happen.

Port knocking solved a lot of problems, protects you from zero-days, and makes SSH noise a non-issue (huge signal-to-noise gains).

Used in production for years. It's fantastic.

Port knocking adds a huge, almost incalculable cost increase to attackers. I'm going to remember that one, thanks!

Why not just block SSH access from the public internet and use a VPN? Trivially easy to setup and more secure than knocking.

All it takes is me somehow being able to listen in on your traffic - not even decrypt it - and now I know the knock sequence. I know that you have SSH listening on that server. I know you are actively doing something on it.

vs. a VPN where... all I know is you are communicating over a VPN. With DPI I might be able to determine what type of traffic you're sending, but not where it is ultimately going.

Again, this is where all port knocking debates devolve to ...

Port knocking is not the christ child that will wash away all of our sins ... and therefore is not worth implementing.

You're right!

It doesn't add that much. But it's non-zero and has almost zero cost. It's very elegant, in my mind, and it makes me very happy.

It doesn't add enough to compensate for its costs, which are commensurate with those of VPNs, which provide drastically more return on the investment. But VPNs don't have a cheering section, because they're so obviously useful that nobody has any incentive to make that banal observation. "Port knocking" is idiosyncratic and widely looked down on by security engineering teams, so there's a contrarian impulse that makes them seem worth discussing.

I'm struggling to walk away with a crystallized view of why port-knocking is bad, though.

I do agree, nobody should be going to sleep at night, relying solely on obscurity as their source of protection. But these commenters are offering it as an additional layer of indirection. They're not touting it as _the_ solution, full stop.

At the most basic level, would you refute the claim that port knocking or alternate ports are adding additional friction for an attacker, or no?

Myself, I would prefer to run a simple, (hopefully) set-and-forget daemon on my server if it really did add an extra layer of obscurity to my secured SSH service.

I guess I just fail to see why it's one against the other.

There's several components to this.

Foremost, there is an opportunity cost to setting it up. The time you spend setting up port knocking could be spent setting up another form of security. I believe it is a sound argument to say that a VPN provides more security at a similar level effort. No public SSH means an attack cannot know SSH is running on the server from a port scan because it simply isn't listening. It allows you to reduce the attack surface - you can add more and more servers that you need to SSH into, but you are only allowing public access via your VPN - so you have fewer potential ingress points, and can ratchet up your security and auditing commensurately. And if your VPN concentrator is owned, you should have been setting things up so that they did not implicitly trust someone just because they were on the VPN, so you still have all of your usual measures of security in place.

In that case, there's just not much point. You could also enable port knocking, but I don't think it provides much benefit.

That brings us to the next part. Port knocking is a "weird" thing. It's idiosyncratic and not standardly used. Documenting it and understanding it is additional overhead, and it's something you have to manage and worry about on every server that's using it. Additionally, both standard and SPA implementations are vulnerable to man in the middle attacks, though most SPA based implementations will require an active MITM in that blocks the initial packet rather than just replaying a knock sequence. So extra complexity, less secure, and an oddity on the network that you have to have documented and explain to new team members, etc.

If you're a single person managing a single server, well, honestly you're probably fine just turning off password auth. And you can feel free to do port knocking and whatever else. It probably doesn't matter.

Thanks, I appreciate the thoughtful response.

It sounds like port knocking and VPNs, while starkly different in approach, have some overlap in their approach to threat mitigation.

Wireguard et al are much better equipped to handle the needs of an organization, while port knocking's value trends to smaller teams, or even individuals.

I wouldn't want to manage knock rotations for 600 employees, for example.

A tangent: are VPNs other than WireGuard less likely to have vulns compared to SSH? Seems the same to me (or worse for OpenVPN a few years ago)

You're asking for my opinion, and that's all I can relate, but here's my ranked ordering of things likely to have RCE vulnerabilities, from least to most secure:

* A Java, Python, or Ruby app server

* OpenVPN

* Stock nginx

    ----- starts to get really unlikely right here ----

* OpenSSH

* The Linux IP stack

* WireGuard

One crude first-order comparison is to look at the relative size of the code. More code is more likely to have more vulnerabilities, to a first-order BOEC metric.

""Port knocking" is idiosyncratic and widely looked down on by security engineering teams"

I can't comment on that.

I'm not a UNIX sysadmin because it's a rewarding career path with excellent opportunities for advancement.

I'm a UNIX sysadmin because I truly love doing it and always have. I would do it for free.

That's why I do software security!

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?

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 :)

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!

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.

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.

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

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.

First of all I agree with you, that we should compare solutions in a comparable manner and I went overboard.

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.

Which vpn though?

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn

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.

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 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.

Like you said.. "worry less"

Can a theoretical attacker intercept a port knocking sequence? maybe. Would a script kiddie running a new ssh 0day against the entire internet be able to do this? no.

> almost zero cost

If it's your private pet server - sure. In larger networks you have to document the access, manage the allowed ports on the network, configure security groups or equivalent on instances, provide alternative steps for people with unusual clients (for example database UI app proxying over SSH), etc. The cost suddenly becomes very non-trivial.

> 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.)

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 you'll be fine. Port knocking will almost certainly protect you from not-Mossad, assuming your adversary doesn't know that you're using it.

Sure, a small percentage of adversaries are in neither category, and a random hacker dedicated to hitting your specific server may suspect port knocking and could try to circumvent it, but most companies don't have an adversary like that, and even if they do, you've made it harder for them for a small cost.

I love that article, but this comment beautifully illustrates the problem with it, because unless you believe "19 year old with better-than-normal tooling" counts as "Mossad", it has totally screwed up your perception of the threat model.

I understand how port knocking can throw off nmap and reduce brute force traffic.

Does it solve anything else?

> 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.

Wouldn't you need to worry about vulnerabilities in knockd?

Agreed: adding port-knocking and fail2ban in addition to passwordless should not be and are not silly ideas.