Comment by justinsaccount | Hacker News Reader

Comment by justinsaccount | Hacker News Reader

Parent Full thread

> Just use SSH keys, and disable passwords.

CVE-2001-0144 - SSH1 CRC-32 compensation attack detector allows remote attackers to execute arbitrary commands on an SSH server or client via an integer overflow

CVE-2008-0166 - OpenSSL 0.9.8c-1 up to versions before 0.9.8g-9 on Debian-based operating systems uses a random number generator that generates predictable numbers, which makes it easier for remote attackers to conduct brute force guessing attacks against cryptographic keys.

I had a machine almost get compromised from the 1st vulnerability ( noexec on /tmp broke their script ). When the 2nd came out I was using non standard ports and or port knocking. Despite having vulnerable keys I was safe until I could upgrade.

If a SSH RCE 0day was released:

* every "Just use SSH keys, and disable passwords" box sitting on the internet with ssh on port 22 will get compromised within hours.

* The boxes using fail2ban will get compromised within hours.

* The majority of boxes on nonstandard ports would likely be ok, at least for some time.

* The boxes using port knocking would be safe.

I think the fact that you had to list the 20-year-old SSH CRC compensator vulnerability to establish the untrustworthiness of SSH is telling; very few pieces of software have OpenSSH's current track record. I would cite the same 2 vulnerabilities to suggest that SSH is as trustworthy as almost any other piece of software you can run.

Having said that: I don't like exposing SSH services either! Which is why I try to keep them behind WireGuard, at least on prod networks that I care about.

In contrast to an actual VPN, port-knocking and (heh) nonstandard SSH ports shield you only from casual attackers; both give a middlebox attacker all the access they need to launch the attack.

Only the 4th point is really true: if you run SSH on a non-standard port but it's otherwise accessible, you'll still see scans on a regular basis.

Port knocking isn't a terrible idea but I generally prefer locking down the networks (or, these days, using AWS SSM / GCP IAP to avoid listening publicly at all) since having something on the internet means you're just one mistake away from problems and need to staff monitoring accordingly.

The other thing to remember here is that we're talking about one general CVE in two decades. Almost any other running service has been much worse so while SSH is important to protect I don't know that I'd make the argument that further pushing that one service is really the best bang for your buck.

> Only the 4th point is really true: if you run SSH on a non-standard port but it's otherwise accessible, you'll still see scans on a regular basis.

Possibly.. It does depend on the port. 222 and 2222 often are scanned with 22. 2200-2299 is probably common now. I was using 2221 for a bit but after a few years that started seeing some auth attempts.

I mostly watched entire /16s, not single hosts.. the scan patterns for a large netblock are very interesting. It takes as much effort to scan the entire internet on port 22 as it does to scan all ports on a /16.. attackers simply do not do that.

The benefit of some of the port knocking systems is that the attack surface is almost nothing and they are easy to audit. I used it a few jobs ago on my management system/bastion host. I couldn't rely on the VPN since I was the one that managed the VPN, so I needed a way to securely login remotely that did not go through the VPN, and did not end up having sshd exposed to the world.

These days I run sshd at home behind https://www.tarsnap.com/spiped.html

Ubiquitous wireguard may change things.. we'll see.

What about entire /56s ? (Home user on IPv6.)

> you'll still see scans on a regular basis.

Not in my experience, I would even say that full range port scanning is extremely rare. Botnets (again, in my experience) seem to only be interested in vanilla installations and will test standard ports exclusively. But of course, if you are in charge of some very tempting target (eg a cryptocurrency exchange) your experience will be totally different than mine.

> * The boxes using port knocking would be safe.

No, safer. It is very well possible to brute-force port knocking or eavesdropping the ports since that information is not encrypted. Is it harder? Of course, a lot, but if you think scanning 65k ports on each host on the internet is reasonable, then evading a port knock is very much, too.

eavesdropping, maybe. There are tools like https://github.com/mrash/fwknop that are not vulnerable to that or brute-forcing.

But brute forcing in general? not a chance. There are 18446744073709551616 4 port sequences.

And there are roughly 1267650600228229401496703205376 port 22's in the IPv6 space - I've substracted a few for reserved and unassigned spaces, but at this scale a few orders of magnitude hardly matter.

Here, for comparison:

  281474976710656 - total ports in IPv4 space
  18446744073709551616 - 4 port combinations
  1267650600228229401496703205376 - my estimation for 22 in IPv6

And if you don't block the knocking when receiving traffic on another port, brute forcing gets quite a bit easier. I mean, it's still unreasonable. But my point is, when we accept 0,001% chance as possible, I don't think we can say that 0,000001% is impossible - just a lot less possible ;)

The actual chances for guessing the 4 port combination are closer to 0.000000000000000000001%, about as likely as winning the lottery three times in a row. If you're trying to brute-force me with those odds, I'll take my chances.

18446744073709551616 is 65 bits. Let’s simplify, you're trying to guess a number in 2^64 You can’t guess in parallel. Reasonable constraints on the server side (i.e. limit tries on the combination/per hour before suspending ssh for a while) may have been implemented.

I’d say cracking that is… Unfeasible.

That also assumes you know the existence of a server on which there is ssh under an unknown combination of port knocking of length 4.

> It is very well possible to brute-force port knocking

It's incredibly unlikely - there is probably more chance of the sun imploding tomorrow. And if you're the type to install port knocking, you've almost certainly also installed something like LFD, which will temporarily block IPs for port scanning.

Also, without inside information, how would you even know that a server was using port knocking?

> unlike

There is a vastly higher chance of there being exploitable bugs in port knocking tooling than there is of there being exploitable bugs in SSH. You are adding extra exposure and gaining nothing.

Reply on news.ycombinator.com