Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #3040 > unrolled thread

Blocking IP addresses from specific countries

Back to article view | Back to comp.os.linux.networking

Contents

  Blocking IP addresses from specific countries Clark Smith <noaddress@nowhere.net> - 2014-07-27 20:14 +0000
    Re: Blocking IP addresses from specific countries Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-28 02:32 +0000
    Re: Blocking IP addresses from specific countries Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-07-28 07:13 +0000
    Re: Blocking IP addresses from specific countries Andrzej Adam Filip <anfi@onet.eu> - 2014-07-28 09:17 +0200
    Re: Blocking IP addresses from specific countries Joe Beanfish <joebeanfish@nospam.duh> - 2014-07-28 13:17 +0000
      Re: Blocking IP addresses from specific countries Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-28 17:51 +0000
        Re: Blocking IP addresses from specific countries Aleksandar Kuktin <akuktin@gmail.com> - 2014-07-28 19:36 +0000
          Re: Blocking IP addresses from specific countries Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-29 01:59 +0000
        Re: Blocking IP addresses from specific countries Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2014-07-28 14:23 -0700
          Re: Blocking IP addresses from specific countries Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-29 01:57 +0000
        Re: Blocking IP addresses from specific countries Joe Beanfish <joebeanfish@nospam.duh> - 2014-07-29 13:16 +0000
    Re: Blocking IP addresses from specific countries Roger Blake <rogblake@iname.invalid> - 2014-07-28 20:55 +0000
      Re: Blocking IP addresses from specific countries Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-29 02:00 +0000

#3040 — Blocking IP addresses from specific countries

	The problem: How to block packets from IP addresses controlled by 
specific countries.

	I guess that iptables could be used for the job, if one could get 
lists of such IP addresses. However, I suspect such lists are likely to 
be unwieldy.

	Suggestions, anyone?

[toc] | [next] | [standalone]

#3041

On Sun, 27 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <lr3mi8$21g$1@news.albasani.net>, Clark Smith wrote:

>       The problem: How to block packets from IP addresses controlled
>by specific countries.

"controlled by"...  doesn't exactly compute.  There are two sources of
country information.  The five Regional Internet Registries (AfriNIC,
APNIC, ARIN, LACNIC and RIPE) allocate or assign address blocks. These
may be assigned to "end users" or allocated to users or National
Internet Registries for further sub-allocation or assignment. The
records of the five RIRs include a "country code", but that code
is the ISO-3166 code of the country (or region) of the organization.
The README file from RIPE (among others) specifically warns

   This information also indicates the country where resources were
   first allocated or assigned. However it is not intended that the
   data be considered as an authoritative statement of the location
   where any specific resource may currently be in use.

   Therefore using this information for IP to country mapping may
   result in inaccuracies and, as a result, in user's confusion in
   many cases.

That's somewhat understated. The company I worked for is a "multi-
national", and the "whois" registration data says "New York" in the
USA. A traceroute would show the last identifiable location from the
world (before hitting the firewall) as Santa Clara, California - yet
the sub-net I was on is in Phoenix, Arizona, USA (about 360 miles/600
KM East of Los Angeles), and other sub-nets are in Switzerland, France,
Brazil, Japan, China, and Singapore.   Blocks may also be allocated to
ISPs who act as "Local Internet Registries" - meaning they can rent
the IPs to individuals or companies, but few are limited to only
providing service in their own country.

The other method is to look at the hostname, and see if the domain part
includes a (ISO-3166) country code - such as "bbc.uk"... but watch out
for the "vanity" domains like .fm, .ly. or .tv.  A number of radio
stations in the US use their call-signs within the .fm (the Federated
States of Micronesia) domain, and some TV stations do the same with the
.tv (Tuvalu) domain.  And of course, this also assumes that the network
support people managed to configure the DNS with appropriate PTR
records (many don't - and a DNS lookup returns "NXDOMAIN").

Someone recently suggested using a free lookup service at "ipinfo.io"
but my test lookups there have been less than satisfactory.  Also, it
works one IP address at a time - and excluding RFC6890 (Special-Purpose
IP Address Registries) address space, there are 3.702 x 10e9 IPv4
addresses available or in use.   Lots of lookups anyone?

>I guess that iptables could be used for the job, if one could get 
>lists of such IP addresses. 

Yes, but that's more a concept problem.  Do you have to offer service
to the entire world?  My home network allows incoming connections from
just three blocks (a /22 and two /24s or a total of 1530 addresses)
because I really don't expect authorized users to be connecting from
Kazakhstan, Kenya, Kiribati, Korea, Kuwait or Kyrgyzstan and a lot of
other places either. Lest someone from those countries object, I also
don't allow access from nearly all ISPs in the rest of the world   Not
expected == not allowed.  As I don't offer mail, web, or ftp service to
anyone - those ports are blocked at the firewall.

>However, I suspect such lists are likely to be unwieldy.

About ten days ago, data from the five RIRs listed 138890 IPv4 networks
with a total of 3578033640 (3.6 billion) addresses. There were also
20234 IPv6 networks with 1.13 x 10e30 addresses.  These assignments
and/or allocations are NOT made in a manner for easy filtering.
Everyone bitches about China, so let's take a quick look there (only
looking at IPv4).  China had 3992 networks as of 7/15/14 at 22:00 UTC,
from 1.0.1.0/24 to 223.255.252.0/23. Looking only at the first octet of
the IPv4 address, the blocks are in

[euclid RIR.stats]$ zgrep CN APNIC.gz | cut -d' ' -f2 | cut -d'.' -f1 |
 sort -n | uniq -c | column
     59 1            24 106          40 125          20 175
     17 14           42 110           1 134          36 180
     32 27           34 111          18 139          29 182
     25 36           21 112          13 140          17 183
     10 39           44 113           6 144           2 192
     90 42           37 114          41 150         557 202
     29 43           28 115           7 153         968 203
      1 45           56 116           7 157          78 210
     17 49           38 117           1 159          45 211
      1 54           48 118           1 161          73 218
     46 58           77 119           1 162          42 219
     35 59           31 120          39 163          17 220
     38 60           49 121           1 166          64 221
     89 61           37 122           2 167          64 222
     75 101          51 123           1 168          32 223
    503 103          72 124          12 171 
[euclid RIR.stats]$

So why not block all of 1.0.0.0/8 you ask?

[euclid RIR.stats]$ zgrep ' 1\.' APNIC.gz | cut -d' ' -f1 | sort | uniq
 -c | column
     12 AU            5 IN            2 MY            3 TW
     59 CN            9 JP            1 PH            1 VN
      3 HK            7 KR            8 TH
[euclid RIR.stats]$

It's called "collateral damage". Other /8s are just as bad:

[euclid RIR.stats]$ zgrep ' 202\.' APNIC.gz | cut -d' ' -f1 | sort |
 uniq -c | column
      2 AF          284 IN            5 MV          164 SG
      1 AS            1 IO           65 MY          138 TH
    685 AU          331 JP            6 NC            2 TO
     35 BD           11 KH           17 NP            1 TV
      9 BN            1 KI            1 NU           40 TW
      2 BT           41 KR          858 NZ            1 US
      1 CK            6 LA            2 PF           38 VN
    557 CN            5 LK            9 PG            2 VU
      8 FJ           15 MN           84 PH            2 WS
      8 GU           12 MO           50 PK
    330 HK            2 MP            1 PW
    273 ID            1 MU            2 SB
[euclid RIR.stats]$

and this also leaves the question about MO (Macau), HK (Hong Kong) and
TW (Taiwan) in the air.  Do you include them as "part of China"?  Oh,
and just for mind-boggling, there are 237 ISO-3166 country codes in use
by the 5 RIRs.

>       Suggestions, anyone?

Re-think the problem.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3042

On Sun, 2014-07-27, Clark Smith wrote:
> 	The problem: How to block packets from IP addresses controlled by 
> specific countries.

What's the use case?  Block a country you don't like, and mostly
innocent citizens will be hurt.  The policy makers (not to mention the
cyber warfare people) can easily get around it.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3043

Clark Smith <noaddress@nowhere.net> wrote:
> 	The problem: How to block packets from IP addresses controlled by 
> specific countries.
>
> 	I guess that iptables could be used for the job, if one could get 
> lists of such IP addresses. However, I suspect such lists are likely to 
> be unwieldy.
>
> 	Suggestions, anyone?

Which services would you like to block? 

-- 
[Andrew] Andrzej A. Filip  -  https://www.linkedin.com/in/andfil

[toc] | [prev] | [next] | [standalone]

#3044

On Sun, 27 Jul 2014 20:14:00 +0000, Clark Smith wrote:
> The problem: How to block packets from IP addresses controlled by
> specific countries.
> 
> 	I guess that iptables could be used for the job, if one could get
> lists of such IP addresses. However, I suspect such lists are likely to
> be unwieldy.
> 
> 	Suggestions, anyone?

By country would be interesting at best as others have described. If
you want to do gross blocking by continent (roughly) you could use the
list at
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
space.xhtml . Also available as csv or xml.

e.g.: for my personal use server I block all of APNIC, RIPE, AFRINIC,
LACNIC, etc. since I'm not a globetrotter.

[toc] | [prev] | [next] | [standalone]

#3045

On Mon, 28 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <lr5ih0$g6$1@dont-email.me>, Joe Beanfish wrote:

>If you want to do gross blocking by continent (roughly)

LARGE pinch of salt needed with that ;-)

>you could use the list at
>http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
>space.xhtml . Also available as csv or xml.

and even raw (readable) text

>e.g.: for my personal use server I block all of APNIC, RIPE, AFRINIC,
>LACNIC, etc. since I'm not a globetrotter.

Point your news-reader at the "comp.risks" newsgroup, and view the
issue of Friday 25 July 2014 (subject line "Risks Digest 28.10").
Read the items "How Hackers Hid a Money-Mining Botnet in Amazon's
Cloud".  Then tell me what country Amazon, Google, Heroku, Cloud
Foundry, CloudBees and other cloud server networks are "from".  I
suppose that also applies to 0wn3d windoze boxes on most cable/DSL
networks.

I prefer to set the firewall to ACCEPT connections from specific
network ranges for specific ports, and REJECT all other connection
attempts with the default rules.    If you really need to allow SSH
access from "the world", you can look at a log-reader tool such as
"BlockHosts", "Fail2Ban", "blocksshd" or "BruteForceBlocker", to
TEMPORARILY block (10 minutes is a good number) specific hosts that
tried and failed to connect.  These toy "tools" work by putting in a
host specific "block" rule in your firewall and/or hosts_access files.
I call them "self-denial-of-service" tools, because if you fail to
remove old host rules, you're going to be blowing a lot of CPU cycles.
Ten minutes is enough to dissuade a bot or common Skript Kiddie, but
shouldn't cost too many CPU cycles.   I think I've also mentioned using
a "port-knocking" technique to temporarily allow access if you're out
in the unknown world - sending a packet to a unrelated and closed port
on the firewall, and having a log-reader the allow access from that IP
for a short time (a minute) which would be long enough for you to "log
in".  The log reader then removes the temporary access, but the
ESTABLISHED rule in the firewall allows the connection to remain.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3046

Hi all!

I just waltzed in to say...

On Mon, 28 Jul 2014 17:51:35 +0000, Moe Trin wrote:

> I prefer to set the firewall to ACCEPT connections from specific network
> ranges for specific ports, and REJECT all other connection attempts with
> the default rules.    If you really need to allow SSH access from "the
> world", you can look at a log-reader tool such as "BlockHosts",
> "Fail2Ban", "blocksshd" or "BruteForceBlocker", to TEMPORARILY block (10
> minutes is a good number) specific hosts that tried and failed to
> connect.  These toy "tools" work by putting in a host specific "block"
> rule in your firewall and/or hosts_access files.
> I call them "self-denial-of-service" tools, because if you fail to
> remove old host rules, you're going to be blowing a lot of CPU cycles.
> Ten minutes is enough to dissuade a bot or common Skript Kiddie, but
> shouldn't cost too many CPU cycles.   I think I've also mentioned using
> a "port-knocking" technique to temporarily allow access if you're out in
> the unknown world - sending a packet to a unrelated and closed port on
> the firewall, and having a log-reader the allow access from that IP for
> a short time (a minute) which would be long enough for you to "log in". 
> The log reader then removes the temporary access, but the ESTABLISHED
> rule in the firewall allows the connection to remain.

...that I like these hacks.

[toc] | [prev] | [next] | [standalone]

#3050

On Mon, 28 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <lr68no$6jv$1@speranza.aioe.org>, Aleksandar Kuktin wrote:

>Moe Trin wrote:

>> I think I've also mentioned using a "port-knocking" technique to
>> temporarily allow access if you're out in the unknown world -
>> sending a packet to a unrelated and closed port on the firewall,
>> and having a log-reader the allow access from that IP for a short
>> time (a minute) which would be long enough for you to "log in".  The
>> log reader then removes the temporary access, but the ESTABLISHED
>> rule in the firewall allows the connection to remain.

>...that I like these hacks.

If you're referring to port knocking summarized above, some people have
complained that it's "security by obscurity"  - failing to understand
that after you've successfully knocked, you _STILL_ have to log in with
what ever credentials you've set the server to require.   Port knocking
is not meant to be a replacement for authentication.

Oh, and word of experience - don't choose a totally off the wall port
number for the knocking port.  Many ISPs block external access to
common server ports (such as 25/tcp), while some remote sites may
have outbound firewall rules preventing access to what the local
administrator considers "normal" ports.

Some have extended the technique to require multiple knocks to several
different ports in a pre-determined sequence - an effort to increase
security.   What that actually does in increase the chance that you'll
fumble-finger something, and shoot yourself in the tender bits.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3048

On 2014-07-28, Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:
>
> If you really need to allow SSH
> access from "the world", you can look at a log-reader tool such as
> "BlockHosts", "Fail2Ban", "blocksshd" or "BruteForceBlocker", to
> TEMPORARILY block (10 minutes is a good number) specific hosts that
> tried and failed to connect.  These toy "tools" work by putting in a
> host specific "block" rule in your firewall and/or hosts_access files.

A newish tool in this area is sshguard, which adds appropriate iptables
rules, and also has options for automatically expiring these new
iptables rules (which is the default configuration).  It can also
remember previous attackers and increase the amount of time their
firewall rules are kept in place, so if Skript Kiddie comes back in 11
minutes, he may have to wait 30 next time (I forget the exact
escalation intervals).

--keith


-- 
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

[toc] | [prev] | [next] | [standalone]

#3049

On Mon, 28 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <8jriabxq6f.ln2@goaway.wombat.san-francisco.ca.us>, Keith Keller wrote:

>Moe Trin <ibuprofin@painkiller.example.tld.invalid> wrote:

>> If you really need to allow SSH access from "the world", you can
>> look at a log-reader tool such as "BlockHosts", "Fail2Ban",
>> "blocksshd" or "BruteForceBlocker", to TEMPORARILY block (10 minutes
>> is a good number) specific hosts that tried and failed to connect.

>A newish tool in this area is sshguard, which adds appropriate
>iptables rules, and also has options for automatically expiring these
>new iptables rules (which is the default configuration).

========================
sshguard     http://www.sshguard.net/    (still at 1.5 6/13/12, 1/19/13,
7/11/13, 1/16/14 and 7/28/14)
log reader for Linux, *BSD, AIX, MacOS, Solaris, etc.  Uses firewall
rules if possible, tcp_wrappers if not.   Available in .rpms and .debs
as well as a tarball.
1.5       Feb 2011       1.4       Aug 2009       1.3       Oct 2008
1.2       Sep 2008       1.1       Jul 2008       1.0       May 2007
0.91      Mar 2007       0.9       Feb 2007  - first public release
First block defaults to 7 minutes - doubles per repeated blocks. Can be
permanent, has whitelist.  Doesn't block if attempts are slow enough (20
minutes default).
========================

The reason I didn't mention it was the lack of revision activity.

Mentioned, I avoid most of the problems because the firewall only
allows connections to 22/tcp from ~1500 addresses.  I used to modify
the rules when I went on travel, but for the past ten years have used
the port-knocking to open a temporary hole in the firewall. I make it
harder because the username is intentionally obscure, never mind not
being one of the mail names I use.

        Old guy

[toc] | [prev] | [next] | [standalone]

#3052

On Mon, 28 Jul 2014 17:51:35 +0000, Moe Trin wrote:
> On Mon, 28 Jul 2014, in the Usenet newsgroup comp.os.linux.networking,
> in article <lr5ih0$g6$1@dont-email.me>, Joe Beanfish wrote:
> 
>>If you want to do gross blocking by continent (roughly)
> 
> LARGE pinch of salt needed with that ;-)
> 
>>you could use the list at
>>http://www.iana.org/assignments/ipv4-address-space/ipv4-address-
>>space.xhtml . Also available as csv or xml.
> 
> and even raw (readable) text
> 
>>e.g.: for my personal use server I block all of APNIC, RIPE, AFRINIC,
>>LACNIC, etc. since I'm not a globetrotter.
> 
> Point your news-reader at the "comp.risks" newsgroup, and view the issue
> of Friday 25 July 2014 (subject line "Risks Digest 28.10").
> Read the items "How Hackers Hid a Money-Mining Botnet in Amazon's
> Cloud".  Then tell me what country Amazon, Google, Heroku, Cloud
> Foundry, CloudBees and other cloud server networks are "from".  I
> suppose that also applies to 0wn3d windoze boxes on most cable/DSL
> networks.
> 
> I prefer to set the firewall to ACCEPT connections from specific network
> ranges for specific ports, and REJECT all other connection attempts with
> the default rules.    If you really need to allow SSH access from "the
> world", you can look at a log-reader tool such as "BlockHosts",
> "Fail2Ban", "blocksshd" or "BruteForceBlocker", to TEMPORARILY block (10
...

Certainly. Good security is a multi-faceted and layered system. Blocking
huge swaths of the net you know you won't use greatly diminishes your
vulnerability footprint. Doing so dramatically reduced attack attempts
seen by other tools down the line. But, as you say, this is only one
facet. Anyone that claims that "this one thing", whatever it is, is "the
way to be secure" doesn't know what they're talking about.

[toc] | [prev] | [next] | [standalone]

#3047

On 2014-07-27, Clark Smith <noaddress@nowhere.net> wrote:
> 	The problem: How to block packets from IP addresses controlled by 
> specific countries.

I guess you could try something like this, no idea how well it really
works. Not only is it probably impossible to amass a really comprehensive
list of IP addresses for a specific country, there's nothing to stop
someone in one of those countries from coming in through a proxy located
elsewhere:

 http://infodepot.wikia.com/wiki/Asiablock

-- 
-----------------------------------------------------------------------------
  Roger Blake (Change "invalid" to "com" for email. Google Groups killfiled.)

  NSA sedition and treason -- http://www.DeathToNSAthugs.com
-----------------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#3051

On Mon, 28 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <20140728165238@news.eternal-september.org>, Roger Blake wrote:

>I guess you could try something like this, no idea how well it really
>works.

If you look at the data files, it's a bit dated.  The source looks
like it's the RIR delegation files, with all of the problems that
entails.

>Not only is it probably impossible to amass a really comprehensive
>list of IP addresses for a specific country, there's nothing to stop
>someone in one of those countries from coming in through a proxy
>located elsewhere:

a proxy, or 0wn3d home systems on any number of domestic networks, or
a "cloud" server or...    Lessee, most of the data was apparently from
13 March of this year, and some from last year .  I grab/process the
zone files on the 15th, and I saw

  3/15/13  3492673464 IPv4 hosts  94.23223%   125459 IPv4 networks
  3/15/14  3549161880  "     "    95.86307%   135875   "     "
  4/15/14  3557457008  "     "    96.08712%   136490   "     "
  5/15/14  3567884232  "     "    96.36876%   137168   "     "
  6/15/14  3575970184  "     "    96.58716%   137905   "     "
  7/15/14  3578033640  "     "    96.64290%   138890   "     "

As you can see, they're running out of IPv4 address space.  I have
noticed allocations/assignments being pulled back, and reassigned
elsewhere.  Merck Pharmaceuticals used to have 54.0.0.0/8 - and as of
ten days ago, they've only got two /11s and Spamazon has the rest in
eight chunks for their cloud servers,  This has happened to other
blocks in other countries, so "year old" data has increased errors.

One other symptom I've noticed - the RIRs are handing out smaller sized
chunks of IP space.  Lately, it seems that the common size is a /20 or
/21 (255.255.240.0 or 255.255.248.0) rather than /16s (255.255.0.0)
and larger.   Well, they're still handing out enormous chunks of IPv6
space as if there's an endless supply.  Ah, shades of RFC1606

1606 A Historical Perspective On The Usage Of IP Version 9. J. Onions.
     April 1 1994. (Format: TXT=8398 bytes) (Status: INFORMATIONAL)

        Old guy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web