Hacker News Reader

Comment by janosdebugs | Hacker News Reader

The provider doesn't care, the owner of the server who needs to log in from their home internet at 2AM in an emergency cares. Bad actors have access to botnets, the server admin doesn't.

View on HN

Unfortunately the only answer is "pay to play." If you're a server admin needing emergency access, you or your employer should pay for an ISP that isn't using cgnat (and has reliable connectivity). Same as how you probably have a real phone sim instead of a cheap voip number that's banned in tons of places.

Or better yet, a corp VPN with good security practices so you don't need this fail2ban-type setup. It's also weird to connect from home using password-based SSH in the first place.

> you or your employer should pay for an ISP that isn't using cgna

That may not be an option at all, especially with working from home or while traveling.

For example at my home all ISPs i have available use cgnat.

> That may not be an option at all, especially with working from home or while traveling.

Your work doesn't provide a VPN?

> For example at my home all ISPs i have available use cgnat.

Doubtful - you probably just need to pay for a business line. Somtimes you can also just ask nicely for a non-NATed IP but I imagine this will get rarer as IP prices increase.

The better answer is to just ignore dull password guessing attempts which will never get in because you're using strong passwords or public key authentication (right?).

Sometimes it's not a matter of price. If you're traveling your only option for a network connection could be whatever dreck the hotel deigns to provide.

Even with strong passwords, maybe you don't want someone attempting to authenticate so quickly. Could be DoS or trying to exploit sshd. If you're traveling, cellular and VPN are both options. VPN could have a similar auth dilemma, but there's defense in depth.

Also it's unlikely that your hotel's IP address is spamming the particular SSH server you need to connect to.

> Even with strong passwords, maybe you don't want someone attempting to authenticate so quickly. Could be DoS or trying to exploit sshd.

DoS in this context is generally pretty boring. Your CPU would end up at 100% and the service would be slower to respond but still would. Also, responding to a DoS attempt by blocking access is a DoS vector for anyone who can share or spoof your IP address, so that seems like a bad idea.

If someone is trying to exploit sshd, they'll typically do it on the first attempt and this does nothing.

> Also it's unlikely that your hotel's IP address is spamming the particular SSH server you need to connect to.

It is when the hotel is using the cheapest available ISP with CGNAT.

Good point on the DoS. Exploit on first attempt, maybe, I wouldn't count on that. Can't say how likely a timing exploit is.

If the hotel is using such a dirty shared IP that it's also being used to spam random SSH servers, that connection is probably impractical for several other reasons, e.g. flagged on Cloudflare. At that point I'd go straight to a VPN or hotspot.

Novel timing attacks like that are pretty unlikely, basically someone with a 0-day, because otherwise they quickly get patched. If the adversary is someone with access to 0-day vulnerabilities, you're pretty screwed in general and it isn't worth a lot of inconvenience to try to prevent something inevitable.

And there is no guarantee you can use another network connection. Hotspots only work if there's coverage.

Plus, "just use a hotspot or a VPN" assumes you were expecting the problem. This change is going to catch a lot of people out because the first time they realize it exists is during the emergency when they try to remote in.

I already expect unreliable internet, especially while traveling. I'm not going to have to explain why I missed a page while oncall.

Reply on news.ycombinator.com