Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I close SSH port 22 (and what I use instead)

michelebologna.net

Post reply on HN
Print view View original

71–80 of 106 posts

Re: I close SSH port 22 (and what I use instead)

#71

Post by kstrauser »

mmh0000 wrote: post #27
kazinator wrote: post #20

What I do is laughably simple. 1. Disable all logging about break-in attempts. 2. Do not have any common user names like "root". Say you want to be able to log in as root from anywhere, just with a password. This is a wise idea; what if you need access, but are in a situation where you are not able to use a certificate? Make up an alternative name like roto-rooter or whatever pops into your head. Install it into the…

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

Ah, yes, those BSD idiots with their root and toor accounts, clearly clueless about security concerns.

I don’t recall ever seeing a security requirement not to have 2 root accounts. What you can’t have is multiple users sharing the same account. This is different.

Re: I close SSH port 22 (and what I use instead)

#72

Post by cyh555 »

usernametaken29 wrote: post #19

I 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

They could be hosting on their own homelab network (without tailscale etc magic)

Re: I close SSH port 22 (and what I use instead)

#73

Post by pak »

tptacek wrote: post #55
fedpost wrote: post #4

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.

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, jus…

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?

Re: I close SSH port 22 (and what I use instead)

#75

Post by dostick »

So the best solution according to the article is to use UDP’s feature of not being sent to any port in particular. In ideal hypothetical it should work, but on any public WIFI, and remote networks would not deliver UDP.

UDP was designed as no-guarantee of delivery. Why would you rely on it for this important feature?

Re: I close SSH port 22 (and what I use instead)

#76

Post by adrian_b »

thayne wrote: post #43
teddyh wrote: post #28

Port 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…

If you enable IPsec, the IPsec protocol becomes open, but there is absolutely no difference in comparison with the configuration proposed in TFA, because any IPsec packet that will be received, but which will fail authentication, will be dropped without any other action, i.e. without any reply, so a remote system cannot determine whether IPsec is open or not.

Like for any other packets, you can choose to log such failures, or not. In the parent article the logs are simplified not by the decision of using special authentication packets for opening the SSH port, but by the decision to not log these packets, which is a completely independent decision.

What a remote system could try to determine is not whether IPsec is open, but whether it is possible to initiate a key exchange for IPsec keys. You can easily run IPsec without using a key exchange protocol, by using pre-shared keys. I am not sure whether the last official version of IKE (Internet Key Exchange protocol) provides any reply packet to an initial connection packet that was not authenticated, but in any case it would be easy to customize the key exchange protocol, to not provide any reply.

While TLS is the necessary solution for the communication between computers that have different owners, for the communication between computers that are owned by the same entity IPsec would have been the correct solution (e.g. for connecting your laptop with your home server when you are away), except that the original variant of IPsec had too many completely unnecessary complications, which deterred potential users. Later it was simplified, but it had already acquired a bad reputation of being too difficult to use.

Today the main problem with IPsec remains that there are many stupid firewalls that block without good reasons most protocols and ports. So one may have to run IPsec over some UDP port, instead of running it as an alternative protocol. If even UDP is blocked, one may have to run IPsec over some TCP port, or just over the http or https port (just masquerading it as TCP, not actually running it over TCP, which would mess with flow control).

Re: I close SSH port 22 (and what I use instead)

#77

Post by lormayna »

My checklist to secure a VPS, enforced by an Ansible playbook.

* Disable SSH root login

* Disable password login and use only certificates

* Enable fail2ban

This have been worked for more than ten years and never been hacked.

I never understand the need for port knocking.

Re: I close SSH port 22 (and what I use instead)

#78

Post by swinglock »

teddyh wrote: post #28

Port 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…

No, it doesn't. You're arguing against a straw man. The primary motivation was in second paragraph.

Re: I close SSH port 22 (and what I use instead)

#79

Post by justsomehnguy »

tptacek wrote: post #55
fedpost wrote: post #4

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.

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, jus…

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

Re: I close SSH port 22 (and what I use instead)

#80

Post by z3ratul163071 »

teddyh wrote: post #28

Port 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…

It is not stupid. Your stated principle assumes the exposed OpenSSH server does not have pre-auth 0-days. Having open 22 exposes a lot of information about the machine already, not to mention possible banners. The mentioned method is an elegant solution to both risks.
Post reply on HN