Limit SSH based on certain State?

Using fine-grained geolocation-based limiting just to keep your log file cleaner is a really bad idea. Such things are a natural part of being on the internet.

Logins from SSH will only come ever from one state.

It's not to keep the log cleaned it's to protect my server since I never travel but have a dynamic ip at home.

Spring the extra $4/month with your ISP and get a Static IP.

-or-

IPTABLES to allow whatever IP Range your DHCP pool is (even a /16 will be smaller then allowing all IP's from NY).

-or-

Setup/Use OpenVPN and block all non-local SSH access.

@vonskippy:

Spring the extra $4/month with your ISP and get a Static IP.

IPTABLES to allow whatever IP Range your DHCP pool is (even a /16 will be smaller then allowing all IP's from NY).

Setup/Use OpenVPN and block all non-local SSH access.

thanks but it's an extra 100 dollars for my ISP since they consider it business type not residential.

I'll figure it out thanks again

@aot2002:

Logins from SSH will only come ever from one state.

It's not to keep the log cleaned it's to protect my server since I never travel but have a dynamic ip at home.

Right, except it doesn't offer you any worthwhile protection (hence why people will say the type of restriction you're asking for is just to keep the logfiles clean), and the simple fact is that it can't be done perfectly, and you can't even do it imperfectly for free.

IPs and ISPs change, so you can't rely on a static database (or you'll find yourself locked out, one day). That means you're going to have to pay for a service. The problem is that even these services are not perfectly accurate, and there are many cases where it's impossible for the service to geolocate an IP correctly.

For example, any ISP that spans more than one state and has any dynamic IP allocation zone that includes more than one state. In my case, my ISP's PoP is the next province over, so any geolocation service will tell you I'm in Toronto, when I'm actually in Montreal. A rather big difference.

If you want to properly restrict your server so that only you can log in, and that nobody else could ever guess your password, the correct approach is to use SSH keys, not geolocation. Then, only your specific computer will be able to connect.

What about blocking certain country ip ranges?

One more time,

What about blocking everything but your ISP's DHCP Pool Range.

Do you have any idea how fragmented the IPv4 space is? There isn't a single or simple handful of IP's to block any given geo space.

But better yet, setup OpenVPN, limit your SSH to local (i.e. traffic thru your VPN connection) and block everything else. Problem solved.

@vonskippy:

One more time,

What about blocking everything but your ISP's DHCP Pool Range.

Do you have any idea how fragmented the IPv4 space is? There isn't a single or simple handful of IP's to block any given geo space.

But better yet, setup OpenVPN, limit your SSH to local (i.e. traffic thru your VPN connection) and block everything else. Problem solved.

I cannot use VPN requirements because of contractual issues between a client.

Blocking everything but my ISP will affect my clients I was just thinking to isolate based on USA.

If it's not worth doing no biggie just wanted to confirm.

@aot2002:

I cannot use VPN requirements because of contractual issues between a client.
If they're all your direct clients, couldn't you could grant them their own VPN keys as part of any deliverable? I suppose there could be a platform issue, but OpenVPN connections are possible from all the major platforms. Though if you're building something for a client to then have their own clients, I can see where the final service needs to be generally accessible.

> Blocking everything but my ISP will affect my clients I was just thinking to isolate based on USA.

If it's not worth doing no biggie just wanted to confirm.
I agree with the others that it's probably not worth the effort as opposed to more traditional security measures, especially given the hassle it will be to try to keep it up to date and the general imprecision of any geo-location data in the first place or connections coming through proxies that have no geographic relation to the original location. Though at least at the country level the geo-data itself may be a bit more stable/accurate.

If you want a rough feel, take a peek at https://www.maxmind.com/app/geolitecountry which is a freely available geo-ip database aggregated to the country level. There's also a free version down to the city level though both free versions are less accurate than the paid versions. But at the country level that's not much difference (estimated 99.5% vs. 99.8%). Looks like there are 22545 individual network blocks to cover US assignments. (Though note the caveat about AOL users in the free country data)

That's too much for direct entry into iptables, though there's also a geoip iptables add-on that can reference the data (http://xtables-addons.sourceforge.net/geoip.php). The MaxMind resources page (https://www.maxmind.com/app/geoip_resources) has other wrappers and integrations.

– David

Well, are you trying to protect SSH, or everything else? If just SSH, use key-based auth, problem solved. If everything else, country-based IP blocking is much simpler and generally more accurate than narrower stuff, but it's still not perfect.

I seem to recall some sort of DNS-based geolocation service that worked on a country-level, but I can't remember the details. IIRC it was something like you looked up 1.2.3.4.us.foo.com and the nxdomain would let you know if it was in the US or not. I don't remember anymore, unfortunately.

@Guspaz:

Well, are you trying to protect SSH, or everything else? If just SSH, use key-based auth, problem solved. If everything else, country-based IP blocking is much simpler and generally more accurate than narrower stuff, but it's still not perfect.

I seem to recall some sort of DNS-based geolocation service that worked on a country-level, but I can't remember the details. IIRC it was something like you looked up 1.2.3.4.us.foo.com and the nxdomain would let you know if it was in the US or not. I don't remember anymore, unfortunately.

Thanks

For anyone looking for the lists of IP's

http://www.okean.com/sinokorea.txt

and

http://mark.koli.ch/2008/11/giving-up-o … dress.html">http://mark.koli.ch/2008/11/giving-up-on-asia-blocking-china-taiwan-etc-by-ip-address.html

Those are only China and Korea.

For a full list, use: http://www.countryipblocks.net/country- … ge-format/">http://www.countryipblocks.net/country-blocks/ip-range-format/

perfect thank you :)

You can also (almost) get it down to the group-of-continents level by /8… there's a lot of slop (the "LEGACY" blocks will hurt a lot), but here it is: IPv4, IPv6.

This is mostly an artifact of the IP allocation process. IANA allocates big blocks (typically /12 for IPv6 (*)) to the five regional registries (see the map here). From there, assignments are made to network providers and large end users fairly haphazardly. Within those assignments, things become even more haphazard.

It's also not guaranteed that addresses allocated from a regional registry will only be used within that region, nor that all traffic originating from an IP address will be from the same geographic area, or anything at all, really. Some really good guesses can be made for fixed locations, though.

Rest assured that whitelisting by geographic location will not stop automated ssh brute-force attacks. Keep your eyes peeled and you'll eventually see one from a Linode in your same datacenter. Also, you will eventually block yourself: I am clearly in New York State, but I had this IP address when I camped out at the Tim Hortons across from my mechanic a few months ago.

(*) Back when they had IPv4 blocks to allocate, they would allocate /8 at a time.

@hoopycat:

You can also (almost) get it down to the group-of-continents level by /8… there's a lot of slop (the "LEGACY" blocks will hurt a lot), but here it is: IPv4, IPv6.

This is mostly an artifact of the IP allocation process. IANA allocates big blocks (typically /12 for IPv6 (*)) to the five regional registries (see the map here). From there, assignments are made to network providers and large end users fairly haphazardly. Within those assignments, things become even more haphazard.

It's also not guaranteed that addresses allocated from a regional registry will only be used within that region, nor that all traffic originating from an IP address will be from the same geographic area, or anything at all, really. Some really good guesses can be made for fixed locations, though.

Rest assured that whitelisting by geographic location will not stop automated ssh brute-force attacks. Keep your eyes peeled and you'll eventually see one from a Linode in your same datacenter. Also, you will eventually block yourself: I am clearly in New York State, but I had this IP address when I camped out at the Tim Hortons across from my mechanic a few months ago.

(*) Back when they had IPv4 blocks to allocate, they would allocate /8 at a time.

> Rest assured that whitelisting by geographic location will not stop automated ssh brute-force attacks. Keep your eyes peeled and you'll eventually see one from a Linode in your same datacenter. Also, you will eventually block yourself: I am clearly in New York State, but I had this IP address when I camped out at the Tim Hortons across from my mechanic a few months ago.

Okay then it's not the best solution to implement because ip's cannot be relied upon for location.

SSH Keys might be the solution I'll have to see, thanks again.

@hoopycat:

I am clearly in New York State, but I had this IP address when I camped out at the Tim Hortons across from my mechanic a few months ago.

A bizarre result. First of all because that's clearly a Toronto IP (look at the RDNS, tor.radiant.net). They're just using the company HQ location for the IP, which is strange, because geolocation databases tend to be rather more accurate than that. Second of all, because Tim Hortons doesn't offer wifi, so if you were getting it from a shop it's either a franchisee-specific thing, or a US-only thing, which makes the Canadian IP stranger still.

I was behind a NAT, for what it's worth. Here's the location if you're collecting Tim Hortons metadata.

No, it's probably just another of those differences between Canadian and American stores. Like how beverage size names are all offset by one in the US; a traditional medium is an American small, a traditional large is an American medium, etc. That surprised me when I was visiting a Tim Hortons in Massachusetts. Apparently wifi is another one of those things, but it's odd that if they only offer it in the US, they use a Canadian supplier.

Maybe American Tim Hortons needs to take over Canadian Tim Hortons.

~~http://drop.hoopycat.com/IMG_20111214_170614.jpg" />

… just as soon as we enjoy some more delicious coffee and high-speed Internet, paid for by a credit or debit card.

wait what was the original topic again~~

![](" />

@hoopycat:

Maybe American Tim Hortons needs to take over Canadian Tim Hortons.

… just as soon as we enjoy some more delicious coffee and high-speed Internet, paid for by a credit or debit card.

wait what was the original topic again

Our cups: ~~http://dl.dropbox.com/u/48490966/tim-ho … offee2.jpg">http://dl.dropbox.com/u/48490966/tim-hortons-coffee2.jpg" />

Well, there are 600 US stores, and 3000 Canadian stores (1:10000 people!), so it's not going quite that way yet :P I suspect the prices match the different sizes, though, it's just a naming thing. Except that the US has no equivalent to our "small" size, and we have no equivalent to the US "extra large" size. 8/10/14/20 oz. versus 10/14/20/24 oz.

Original topic? What original topic? This thread seems to be about coffee and trains.~~

@Guspaz:

the US has no equivalent to our "small" size, and we have no equivalent to the US "extra large" size. 8/10/14/20 oz. versus 10/14/20/24 oz.
Some Canadian locations are currently testing US-equivalent cup sizes, including the even larger "extra large".

@Guspaz:

Original topic? What original topic? This thread seems to be about coffee and trains.
The train will get back on track as soon as one of OP's clients gets a taste of Tim Horton's coffee. Brace for all those confused e-mails telling the OP he can't log in to his site so it must have been hax0red, etc.

Just require 2048-bit public keys on all accounts. Problem solved.

@Guspaz:

any geolocation service will tell you I'm in Toronto, when I'm actually in Montreal.

aren't those fighting words to a Quebecois? ;)