4 ms·

Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the fir

by fedpost 2mo ago

Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the firewall rules.

simondotau 2mo ago
A sensible observation. In theory, the entire codebase for a simple HMAC knock knock ought to be tiny and easy to harden with multiple rounds of human and LLM review. The goal should be to have your complex layers sitting in front of simpler, easier-to-review lines of defence. Once you get to something like an open connection to ssh, the potential attack surface would be orders of magnitude larger, even though it’s more mature and closely scrutinised.
zsoltkacsandi 2mo ago
If you mean fail2ban by “battle hardened service”, it manipulates the firewall rules as well. And OpenSSH has the same functionality built-in, without any additional service (PerSourcePenalties).
mvkg 2mo ago
I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received. The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake. I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored. I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.
tptacek 2mo ago
No, it's not. The article itself is somewhat incoherent; for instance, if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys). The reality is that there are basically two ways to operate SSH: (1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, just disable passwords and let SSH run in 22/tcp exposed to the Internet. Probably stop logging people scanning you; there's nothing you're going to do about it, so it's not real information. (2) You can keep SSH behind WireGuard, an even simpler security protocol with an even better security story (though: OpenSSH is quite solid), which is designed to not to chat with counterparties that don't have keys, even to do negotiation. Everything else is performative. I'd incline towards option (2).
- BoingBoomTschak 2mo ago
  Note that fail2ban is built inside OpenSSH, these days.
- pak 2mo ago
  OpenSSH has the best track record, but even it had a zero-day RCE (regreSSHion) in 2024. There are bound to be many more discovered as LLMs capable of doing so proliferate among those who don't report such things responsibly. Keeping port 22 open puts you first in line for such exploits, while keeping it behind another layer (whether it's WireGuard or firewall tricks) would buy time, if not keep attackers away entirely. That seems useful, no?
  - ozim 2mo ago
    Keeping port 22 open puts you first in line for such exploits SSH RCE is a super expensive exploit - no one is firing that one while it still is a 0 day without having really important reason or juicy target.
- justsomehnguy 2mo ago
  > if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys). Why, fail2ban here still serve a very useful function: it bans the offending IP from talking to the machine. It's a simple and a very effective heuristic to block both non-offending port-scans and offending too. > basically two ways It's always amusing what people like you almost demand what ssh should be run on the port 22 but are fine with a random port for WireGuard. And for all of you to assume what both 22/tcp and WireGuard are always available and never blocked.

by fedpost 2mo ago

Is this actually practically reducing the attack surface? We're replacing a battle hardened service with a random one that has the ability to manipulate the firewall rules.

simondotau 2mo ago

A sensible observation. In theory, the entire codebase for a simple HMAC knock knock ought to be tiny and easy to harden with multiple rounds of human and LLM review. The goal should be to have your complex layers sitting in front of simpler, easier-to-review lines of defence. Once you get to something like an open connection to ssh, the potential attack surface would be orders of magnitude larger, even though it’s more mature and closely scrutinised.

zsoltkacsandi 2mo ago

If you mean fail2ban by “battle hardened service”, it manipulates the firewall rules as well. And OpenSSH has the same functionality built-in, without any additional service (PerSourcePenalties).

mvkg 2mo ago

I think the answer is yes. A response from a remote system (or lack of) is a signal. The conventional ssh protocol method when connecting to a server is to instantly send over the identification string. RFC 4253 requires "both sides MUST send an identification string". It doesn't necessarily decide an order, but most ssh implementations I've seen send their protocol string before any other data has been received. The broadcasting of the versioning information does constitute a potential leakage of information that could be useful to an attacker. Even if we contrast this to something like mTLS, the client certificate doesn't come until fairly late in the handshake, so there is still information that can be cleaned from the ServerHello from an unauthenticated inspector. This is also the case with QUIC since it piggybacks off the general TLS handshake. I think the issue is, for a known set of systems, can you create communications between them that are oblivious/non-discoverable to non-authorized systems. I think the answer is yes, but it requires an out-of-band key agreement protocol. Wireguard is an example. However, the problem of out-of-band key agreement can't really be ignored. I think the article's method is somewhat valid. I also think it is non-ideal for only doing source IP based rulesets, especially in the world of IPv4 and NAT being prevalent.

tptacek 2mo ago

No, it's not. The article itself is somewhat incoherent; for instance, if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys). The reality is that there are basically two ways to operate SSH: (1) You can, because OpenSSH is the significant remote service with the literal best track record of any remote service, just disable passwords and let SSH run in 22/tcp exposed to the Internet. Probably stop logging people scanning you; there's nothing you're going to do about it, so it's not real information. (2) You can keep SSH behind WireGuard, an even simpler security protocol with an even better security story (though: OpenSSH is quite solid), which is designed to not to chat with counterparties that don't have keys, even to do negotiation. Everything else is performative. I'd incline towards option (2).

BoingBoomTschak 2mo ago
Note that fail2ban is built inside OpenSSH, these days.
pak 2mo ago
OpenSSH has the best track record, but even it had a zero-day RCE (regreSSHion) in 2024. There are bound to be many more discovered as LLMs capable of doing so proliferate among those who don't report such things responsibly. Keeping port 22 open puts you first in line for such exploits, while keeping it behind another layer (whether it's WireGuard or firewall tricks) would buy time, if not keep attackers away entirely. That seems useful, no?
- ozim 2mo ago
  Keeping port 22 open puts you first in line for such exploits SSH RCE is a super expensive exploit - no one is firing that one while it still is a 0 day without having really important reason or juicy target.
justsomehnguy 2mo ago
> if you're using key-only authentication (which: of course you are) fail2ban has literally no function (unless you think attackers are brute-forcing ECDH keys). Why, fail2ban here still serve a very useful function: it bans the offending IP from talking to the machine. It's a simple and a very effective heuristic to block both non-offending port-scans and offending too. > basically two ways It's always amusing what people like you almost demand what ssh should be run on the port 22 but are fine with a random port for WireGuard. And for all of you to assume what both 22/tcp and WireGuard are always available and never blocked.