Naive knocking isn't good as a primary security mechanism, but it lowers your attack surface and adds defense in depth.

It means that people who can't intercept traffic can't talk to the ssh server-- and that's most attackers at the beginning phases of an attack. And even someone who can intercept traffic needs to wait for actual administrative activity.

Defense in depth has value I agree, but I think it can also be counterproductive in some cases. Every layer can also be buggy and have vulnerabilities, which can often leak (e.g. into code execution) and compromise the whole system (bypassing layers). What happened in this case seems to be a case of maintained hijacking and introducing vulnerabilities. Adding an additional dependency (of say a port-knocking library) doesn't look great in that regard, if the dependency can be hijacked to add remote code execution capabilities. And that library is likely a lot less scrutinized than OpenSSH!

Also underrated I think is security by simplicity. OpenSSH should be extremely simple and easy to understand, such that every proposal and change could be easily scrutinized. Cryptographic constructions themselves are almost mathematically proven invulnerable, then a small codebase can go most of the way to mathematically provable security (bonus points for formal verification).

But for this kind of system there's usually some kind of human vulnerability (e.g. system updates for your distro) in the loop such that the community needs to remain watchful. (It's fun to consider an application that's proven correct and doesn't need updating every again, but usually that's not practical)

> Adding an additional dependency (of say a port-knocking library) doesn't look great in that regard, if the dependency can be hijacked to add remote code execution capabilities.

Port knocking infrastructure can be minimal, knowing nothing but addresses knocking. It can also be completely outside the protected service on a gateway.

Indeed, it can even be no-code, e.g. https://www.digitalocean.com/community/tutorials/how-to-conf...

> OpenSSH should be extremely simple and easy to understand, such that every proposal and change could be easily scrutinized.

But OpenSSH intrinsically is going to have a much larger attack surface.

> then a small codebase can go most of the way to mathematically provable security (bonus points for formal verification).

It's worth noting this would not have helped against this attack:

* It was against another dependency, not openssh

* The actual vulnerability didn't occur in the code you'd inspect as part of verification processes today. (I don't think anyone is formally verifying build process).

Good points, I would say that defense in depth is useful when the layers of defense need to all be broken (more or less) independently for a successful attack (this fails only if you add layers that expose vulnerabities compromising your system). E.g. usually a sandbox satisfies this criterion.

Also, whenever some layers may allow compromising everything, the supply chains of the layers should be minimal or correlated (same supplier), to avoid increasing such supply chain risks.

What if the knocking sequence was derived from a TOTP secret?

Don't have to do anything too complicated. Here's the knocker code in a short Bash script, produced by GPT4:

~ % gpt4 'write a very short bash script that takes the number stored in ~/.ssh/knock_seq, increments it by 1 and saves it to the file. It then takes the new number and concatenates it with the value stored in the file ~/.ssh/secret. It pipes the resulting string to sha1sum, spitting out binary. It then takes both the resulting sha1sum and the number used and pipes their concatenation to "nc -u $host $(cat ~/.ssh/knocking_port)". be brief'

  knock_seq=$(cat ~/.ssh/knock_seq)
  let knock_seq++
  echo $knock_seq > ~/.ssh/knock_seq
  concat_seq_secret=$(echo -n "${knock_seq}$(cat ~/.ssh/secret)")
  sha1_output=$(echo -n $concat_seq_secret | sha1sum -b | awk '{print $1}')
  final_output="${sha1_output}${knock_seq}"
  host=localhost
  knocking_port=$(cat ~/.ssh/knocking_port)
  echo -n $final_output | nc -u $host $knocking_port

The knockee PoC should also be straightforward, can use socat + udp-listen + fork with a script that checks that input matches `sha1sum(secret||num)||num` and `num>previously_seen_num`, and if so, adds an iptables rule.

This should prevent against replays. Throw in some rate limits somewhere maybe to not get DDoSed, especially if you let socat `fork`.

Definitely some fun project to try

Ooo, that's a fun idea

Not if you set it up such that each knocking sequence can only be used once. Port knocking is a flexible concept.

I wonder if one could combine port knocking and TOTP in some way, so the sequence is determined by the TOTP?

(Security is not my thing; don't judge me!)

Was just having the same thought reading this thread.

Yeah you could but wouldn’t it defeat the purpose of being basically a secret knock before you can give the password? The password should be the ssh password.

This would be just to allow you to connect to the server. If there was a vulnerable sshd on port 22, an adversary would have to know the port knocking sequence to connect to sshd and run the exploit.

This looks related to some other problem: - There is Alice's server which provide service X - There are clients like Bob who needs this service. - There is Mallory who thinks clients doesn't need such service. Mallory have significant resources (more than Alice or Bob). - Mallory thinks it's ok to block access to Alice' server IF it's known that it's Alice's server and not some random site. Mallory sometimes also thinks it's ok to block if protocol is unknown.

This problem solved by XRay in all of it's versions. It could be possible (if overkill) to use mostly same methods to authenticate correct user and provide eir access.