Hacker News Reader

Comment by devwastaken | Hacker News Reader

Do not lock down to your IP address. Home IP's change all the time, and in proper security there should be no other way to access the server other than proper ssh authentication or physical access. There is no good reason to be doing it in this context. If SSH turns out to have a massive vulnerability that bypasses keyauth then every service on the net will be torn down.

View on HN

Some people recommend running a VPN server and then using SSH over VPN for "improved security", but pretty much every VPN apart from WireGuard has a pretty poor track record there.

SSH is in all likelihood the most secure server software that you can have on a Linux box. Everything else you put in front of it is likely to be a downgrade.

As you essentially say, WireGuard is great. I firewall off direct SSH and first use WireGuard to connect to the server instead.

One advantage is that if your firewall is setup right it's completely invisible, as unauthenticated UDP packets are dropped, as is the case with any other, unused, UDP port.

I still configure SSH to best practices just in case a configuration blunder inadvertently causes the firewall to accept connections.

Most people who tried hosting anything are aware whether they are or are not using a static IP address for their home or small business connection. It's usually a paid extra, even available on some ISPs that only give out IPv6 addresses with a CGNAT.

If the IP address doesn't change very often, it's not a bad idea to set up a dynamic DNS script and base your allow list on that subdomain rather than the raw IP address.

I lock down to my IPv6 prefix just to cut down on the log spam of all those failed attempts. Seconds after running up a server and it's full swing of brute force SSH login attempts. Maybe once journalctl gets some better exclusion filters I won't care so much so I can see what's actually going on in the logs.

> Do not lock down to your IP address.

> If SSH turns out to have a massive vulnerability that bypasses keyauth then every service on the net will be torn down

those seem to contradict each other.

i agree that black-/whitelisting should not be the center of you security architecture but it sure helps in the scenario of authentication bypass vuln.

If you have multiple systems anyway, then having a light-weight jump box (or 2 for redundancy) may be worth setting up. Then limit 'internal' hosts to only allow connections from the jump boxes / bastion hosts.

What about ip white-listing based on country origin?

Assuming you're not travelling ofc.

Ps. By reference, I'm from Belgium. Odds are slim that a scanning IP would come from here to my abroad server.

There's truly no fool-proof way to go from 1.2.3.4 to US, UK, CN, etc. IP addresses are constantly changing hands. I'm in the Southern US and yet a residential ISP I had showed up as coming from Montreal, Canada for years in many geo IP databases. A friend's house down the street sometimes gets mistaken as a Brazilian IP address.

Almost every time I've used a WAF's geo-IP blocking tool I've either personally experienced or had customers complain about being blocked incorrectly.

If you're dynamically getting IP addresses and you're allow-listing based on country of origin, expect to get locked out eventually even if you're sitting in the same place.

That's weird. My home ip address of broadband is linked to my provider, a dynamic IP fyi.

My ip with a reverse route can definitely be linked back to my country consistently according to past experience.

Providers mostly shift ip's between clients. Is your provider also active in Canada perhaps? ( Just a guess)

> My ip with a reverse route can definitely be linked back to my country consistently according to past experience.

What process do you do to verify the geographic location of the reverse route?

The provider at the time was Frontier Communications, I don't believe they have a large presence in Canada.

The hostname of my IP is actually also bound to my ISP. So it's ip-83-xxxxx.dsl.scarlet.be

Where .be would be a clear indicator of my country ( and the ISP i'm using). The other ones in Belgium had a similar flow ( I switch sometimes )

I used https://www.whatsmyip.org/ fyi

That's just a PTR record though. While scarlet.be implies the organization controlling it is in Belgium, that's not necessarily a guarantee the actual device using it is in Belgium. scarlet.be could deploy a box in Ghana or Chile and have its PTR record updated to something.dsl.scarlet.be. There's no actual enforcement that the device is in some physical location.

Loads of IP addresses for cloud providers ultimately resolve to things like amazon.com or google.com, does that mean those requests are from the US because it ends in .com?

I am not looking for a failproof way to ban all non-relevant ip's.

I'm looking for a method to exclude 99% of traffic based on IP ( if possible) and that i know how i can get in if the IP changes and it isn't updated automatically on the server ( as a failsafe).

I'd rather blacklist certain IP blocks for countries I'm sure won't get legitimate traffic and are cyberattack hotspots (China, Iran, Russia).

That usually doesn’t matter that much. You can get into the console of the node from whichever cloud company you’re renting it off and change it there.

I consider web console root access to be a security deficit in itself. Only thing I trust are keys.

Reply on news.ycombinator.com