2

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?

  • 1
    You can, but you'd better hope you never need to SSH in when you're travelling. – Tom O'Connor May 23 '14 at 11:35
  • 4
    I don't think it's worth the hassle. As is mentioned in some of the answers, it's easily bypassable and the geoip lists are inaccurate often enough to matter. Disabling password authentication and using reasonably large pubkey or gss/krb authentication is sufficient. – Andrew Domaszek May 23 '14 at 13:02
5

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.
| improve this answer | |
  • I've upvoted a few answers, but overall the answers on here have made me realise it's just not worth the hassle. Especially since my IP changes every 6 months. This answer helped me the most, closely followed by Nathan C's answer. – user2143356 May 23 '14 at 15:40
  • 1
    The link appears to be off topic. You surely were looking for a different definition of "demo effect". – kasperd May 23 '14 at 15:53
  • @kasperd Whoops, thanks! Wikipedia linking sometimes goes on auto-pilot :) – l0b0 May 23 '14 at 22:00
5

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.

| improve this answer | |
1

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.

| improve this answer | |
1

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.

| improve this answer | |
1

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.

| improve this answer | |
  • They aer not wrong so much as they likely fall back to wherever the company having them assigned is registered. – TomTom May 23 '14 at 12:36
1

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.

| improve this answer | |
0

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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.