Hacker News Reader

Comment by unraveller | Hacker News Reader

If you're lucky enough to have a big ISP with a single big block of IP addresses that never changes you can disallow all other ranges on your VPS admin ports and only have to worry about VPNing through that ISP.

I guess you could block the main country offenders but you'd have to pay an API to keep up with the IP allocations to be sure.

View on HN

I just use IPv6 and only allow my ISPs single /32 block. Its neat that IPv6 has cleaned the mess of IPv4 having different IP blocks all over.

My prefix is dynamic, If it was static it would be more secure.

And also I have fail2ban for good measure.

Another advantage of IPv6, if implemented well by the hosting provider (i.e. they assign you a /64 or larger), is that you can pick a random IP address from a pool of billions to host your SSH server on. There's a tiny chance of accidentally conflicting with another service if you're provisioning your addressing using SLAAC, but that chance is low enough that I'm willing to risk it. Scanning the entire IPv6 internet isn't very feasible for automated tools because of how large the IP space is.

This approach does require some client side hacking, though either in the form of SSH config, or in the form of a split horizon DNS so you can easily access your server, but that's no different from alternatives such as port knocking or simply altering the SSH port.

Or alternatively, block port 22 entirely on your firewall and use something like Tailscale to access the machine.

Of course, now your attack surface includes Tailscale, which has had it's own vulns in the past, but I think blocking all public traffic ends up being much stronger than any weaknesses Tailscale may introduce.

Isn't that just the same thing in different clothes? Just a different protocol offering the same features of authentication and encryption - often using exactly the same primitives?

Is it "Security through obscurity" assuming fewer people are attacking vpn protocols that than ssh? And I'm not sure that's even true

Plus a centralized identity provider, which is a plus or minus depending on your threat model, https://tailscale.com/kb/1013/sso-providers

Introducing obscurity to the process doesn't make it insecure. Criticism of "security through obscurity" is that security shouldn't rely on obscurity. The system should remain secure even if the attacker knows every detail of your system. Here the point of the "obscurity" (if you can call it that) is to avoid blowing up your logs and wasting compute cycles and energy on attempts that will fail anyway.

It allow SSH on another port. There are considerations when deciding to allow SSH on unprivileged ports.

Also, it's a bit tricky to set up but port knocking is a very effective solution, and you can keep the SSH on port 22 if you like.

Reply on news.ycombinator.com