• Blocking IP addresses from specific countries

    From Clark Smith@110:110/2002 to All on Sun Jul 27 20:14:00 2014
    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?

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: albasani.net (110:110/2002@linuxnet)
  • From Moe Trin@1:0/0 to All on Mon Jul 28 02:32:46 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: International League of Cat Herders, Local 3
  • From Jorgen Grahn@1:0/0 to All on Mon Jul 28 07:13:03 2014
    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 .

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: The Kofo System II BBS telnet://fido2.kofobb
  • From Andrzej Adam Filip@1:0/0 to All on Mon Jul 28 07:17:16 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: It is for me to know and for you to find out
  • From Joe Beanfish@110:110/2002 to All on Mon Jul 28 13:17:21 2014
    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Moe Trin@1:0/0 to All on Mon Jul 28 17:51:35 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: International League of Cat Herders, Local 3
  • From Aleksandar Kuktin@110:110/2002 to All on Mon Jul 28 19:36:24 2014
    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Aioe.org NNTP Server (110:110/2002@linuxnet)
  • From Roger Blake@110:110/2002 to All on Mon Jul 28 20:55:22 2014
    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 -----------------------------------------------------------------------------

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: Ministry of Silly Walks (110:110/2002@linuxnet)
  • From Keith Keller@110:110/2002 to All on Mon Jul 28 21:23:20 2014
    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


    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)
  • From Moe Trin@1:0/0 to All on Tue Jul 29 01:57:34 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: International League of Cat Herders, Local 3
  • From Moe Trin@1:0/0 to All on Tue Jul 29 01:59:44 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: International League of Cat Herders, Local 3
  • From Moe Trin@1:0/0 to All on Tue Jul 29 02:00:56 2014
    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

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: International League of Cat Herders, Local 3
  • From Joe Beanfish@110:110/2002 to All on Tue Jul 29 13:16:54 2014
    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.

    --- MBSE BBS v1.0.1 (GNU/Linux-i386)
    * Origin: A noiseless patient Spider (110:110/2002@linuxnet)