Can I (practically) block access to the SSH port to my country only?

Question

I'm thinking that blocking access to the SSH port to allow for my country only is an obvious step, but I can't see a practical way to do this.

I'm in the UK if it matters. I have full access to the Ubuntu server. The server is a remote cloud-based server.

This seems too easy and I can't see how it can work: http://eminasif.wordpress.com/2014/01/14/how-to-restrict-server-ssh-access-or-any-port-only-for-specific-country-in-csf/

This shows a load of IPs but I can't see how I can transfer that to anything usable/practical: http://www.nirsoft.net/countryip/gb.html

In fact, only one office of people will ever need access (nobody is remote). I'm reluctant to set the current IP address we use when connecting though as it seems to change every 6 months.

I do have other good security practices in place - disable root login, high-bit encryption keys etc. but this seems an obvious extra step.

Is this worth the hassle? Is there a reliable way to do it?

Answer 1

That sounds like a subtle instance of security by obscurity. Anybody who is actually interested in hacking into a system like that can easily find an open proxy or rent a server within the UK, and attack from there.

At the same time you're making operations more difficult:

• You'd have to use heuristics since there's nothing like a "country" in TCP/IP. Heuristics fail, and when they do it will be at the worst possible moment.
• A non-standard setup is going to frustrate future maintainers.
• Critical backups should be replicated across the globe. You don't want to wait for production down-time time to discover a critical recovery path is blocked.

Answer 2

This doesn't seem completely necessary. Depending on your firewall, it might be able to do its own GeoIP blocking. Otherwise, you can use iptables to "allow" the block of IPs that you get within the office.

However, what you've done so far is enough for most servers. Key-only authentication makes brute-force unfeasible. You can further reduce attacks by changing the default SSH port. Note that this doesn't increase security, but it does reduce 90% of the bogus traffic from automated scanners that don't look for SSH on different ports.

Answer 3

I've found most IP-location lists to be unreliable. Some addresses are totally wrong.

It'd be easier to just make a VPN for each person that needs to SSH, so they can connect from anywhere... and block SSH access from the public.

Answer 4

To be honest, I don't think you can practically ensure ONLY people from the UK would be able to connect via SSH, as I'm not aware of a 100% method to truly identify a connection.

http://www.geoip.co.uk/ could be one way of doing this, but querying that each time and inspecting the result might trigger too many timeouts.

Answer 5

If you wanted to allow only certain locations based on IP, assuming you're using iptables, you would have to set the default INPUT policy to DROP then individually allow each address block that.

IMHO it would be much less overhead and still relatively secure to disable password authentication and allow only key based logins to the server.

Answer 6

You can download the list of RIPE allocations and create iptables rules based on that. You should be aware that the list may not be complete, I think there are some small amount of IP addresses allocated through slightly different channels, which will not show up on that list.

An attacker who knows what you have been doing would be able to bypass the filtering if they can find any proxy (or similar), which is on the permitted list of IP addresses.

Answer 7

I had a similar situation in the past. Everything that has already been said is quite valid, and I would agree that you can not effectively block by country without use of a suitable firewall applicance, and even that is fallible.

The point about you needing remote access, someday, at the worst possible moment" is the real clincher, here. as the saying goes, "Been there, Done that". It isn't pretty.

This is how I solved my problem.

I set up the office firewall to allow ibound ssh only our providers subnets and one other external IP address. That external server was configured with non-standard port, portsentry and a couple of other things to make sure that only I could get to it, and then would ssh from that, to the internal network.

Answer 8

Set up a Dynamic DNS on your server. Issue keys to your authorized clients so that each can only nsupdate their own Dynamic DNS IP address. This lets your server know what IP addresses your authorized clients are coming from.

Secure your SSH server with TCP Wrapper where you only allow your authorized clients to connect using the Dynamic DNS information. The relevant files being /etc/hosts.{allow,deny} for TCP Wrapper.

Given the complexity of the above, I only did this with a few Linux clients. Mobile clients present more of a challenge (primarily due to lack of nsupdate or lack of notification about IP address changing). I installed an OpenVPN server and issued keys to the non-Linux roaming clients. If a mobile client is lost/stolen, it's corresponding key can be revoked/removed at the OpenVPN server.

I started with IPSec but cheap wireless NAT routers wouldn't let the IPSec packets though. Perhaps newer/expensive routers will.