The enlightened trick is to run ssh on port 443.
And https on 22? Why didn't I think of that?
You could run both on 443: https://github.com/yrutschle/sslh
I close SSH port 22 (and what I use instead)
41–50 of 106 posts
Re: I close SSH port 22 (and what I use instead)
#42Why not just use ssh as the knock protocol too? To a bespoke ssh server. Ssh to 7000, type "mellon", and ssh 22 opens up. No other software required, and you clearly already have ssh.
It's easier as in using already known tools. It's potentially less secure because sshd is vastly more complex, and allows literal (authorized) remote code execution, unlike fwknop.
You would absolutely not use openssh server for this. That's a terrible idea.
Pick a library. https://github.com/Eugeny/russh
Re: I close SSH port 22 (and what I use instead)
#43Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates a…
I think you are missing the point. It isn't about increasing the bits of security, it's about avoiding the flood of port scanners and the logs that produces.
IPsec is way more complicated to set up than this (or other VPN solutions like Wireguard or OpenVPN for that matter), and doesn't even completely solve that problem, because your ipsec port is open. Although, admittedly, there are probably less bots looking for ipsec than ssh.
Re: I close SSH port 22 (and what I use instead)
#44I don’t know why this wasn’t mentioned before but why not use a Firewall. If you’re using a virtual box like Hetzner or Scaleway you can specify an ip or range at the router level. For all intents and purposes this removes public exposure. Scaleway also has a cheap VPN bridge. So you never need to connect via the public internet if you don’t want to… hardly gets more secure than that
If you are connecting from a residence or a mobile device (like a laptop), your ip address isn't fixed, so a firewall won't help.
Re: I close SSH port 22 (and what I use instead)
#45Earlier quoted context omitted.
This is a bad idea™. You should never have more than one UID 0 on a Unix system. This will violate most corporate security guidelines (STIG and CIS) * . And for good reason. A much better idea is to set up a non-root user and configure sudo correctly. * https://www.stigviewer.com/stigs/red_hat_enterprise_linux_9/...
I am not a corporation, so I don't need corporate guidelines. There isn't more than one UID 0. Only more than one password/shadow database entry pointing to it. (It might not be necessary; perhaps there is a way for OpenSSH to remap names, so that our example rotorooter is mapped to root by sshd itself.) > A much better idea is to set up a non-root user and configure sudo correctly. Even if so, the same principle app…
> Whoever wrote that does not know WTF they are talking about
... or they know something you don't.
Re: I close SSH port 22 (and what I use instead)
#46Port knocking, and other bespoke middle layers in front of internet services, is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes (or “noise”) manageable, adjust your logging levels. Anything added in front of your normal service also complicates a…
Agreed.
And for logging in particular: Just switch the logging over to a temp file that lives in RAM (what disk thrash/write-amplification/SSD wear?), or even disable it altogether for failed login attempts.
We already know that there are great hordes of zombies outside of the castle, banging on the doors and the blocked-off spaces where the windows once were, picking away tirelessly. That's been a constant for many years. Documenting their continued persistence is pretty meaningless. None of it is actionable, or stoppable. It's just going to keep happening. Recording attempts from valid users is also largely without merit; it also just looks like noise, and we've got other ways to troubleshoot stuff that breaks without maintaining a long list of zombie attacks to peruse.
If a zombie actually manages to get in, then that's pretty important to keep track of; log that. But the attempts don't mean anything and have not meant anything for a very long time.
(When the word comes forth that the zombies are gone and the noise has ceased, it will be broadcast so far and wide that even the most noise-deafened sysadmins will find it impossible to ignore. In that seemingly-impossible unlikelihood, we can then resume recording attempts to log in with ssh.)
Re: I close SSH port 22 (and what I use instead)
#47Just wrap it in wireguard. WG won't respond to any incoming handshake without a valid and authorized client key, it's essentially invisible.
Re: I close SSH port 22 (and what I use instead)
#48> If a zero-day drops in OpenSSH... Realistically, fwknop is more likely to have a vuln than OpenSHH. Last release was two years ago and the readme dates back twelve :/ Time will tell.
fwknop is a bit lower risk though. If all an attacker can do is open a port, they’ll still have to exploit OpenSSH.
fwknop's default is to run as root, so there's that. Support for separation of privileges is still pending since 2013 (https://github.com/mrash/fwknop/issues/32)
Re: I close SSH port 22 (and what I use instead)
#49The enlightened trick is to run ssh on port 443.
I had to do this once. SSH server needed to run on port 443 because the clients had a locked down network firewall and could only make connections to particular port numbers.
Re: I close SSH port 22 (and what I use instead)
#50I made my ssh server to listen ipv6-only, and it has been super silent in the logs ever since. In the first iteration the IPv6 got polled by a handful of attackers as soon as the letsencrypt certificate was published. In the second iteration I just picked another IPv6 address from the /64 and made ssh.example.com to point to it. This should work until the attackers start guessing subdomain s...
This is an interesting piece that is often overlooked by folks in the "but NAT is security" camp; Having a sparse address space that is 64-bits makes it impossible to iteratively scan over a range. If you don't reverse resolve or you disallow zone transfers then you also have no real discoverability for that /64.