CentOS 6.X, Iptables 1.47 And GeoLite2 Country Database

Home » CentOS » CentOS 6.X, Iptables 1.47 And GeoLite2 Country Database
CentOS 6 Comments

Hi

Specs in subject line: CentOS 6.X all latest patches), iptables 1.47, Apache2.2

I use the Geolite legacy databases together with iptables 1.47 to filter traffic for a variety of ports and only allow .AU traffic to have access.

Maxmind (https://dev.maxmind.com/geoip/geoip2/geolite2/) changed the default DB to the latest version which is GeoLite2, this leaves all users in need of the old Geolite Legacy database in the dark, they cannot update.

If I download a later version of xtables it will complain that it requires iptable>1.6 which I do not think I can get going on CentOS 6.X.

Is there a way that I can convert Geolite2 CSV files to Geolite Legacy CSV Files and then compile those into BE/LE?

Are there any other ways I can use Geolite2 on a CentOS 6.X system?

Does anyone have other ideas how to tackle this?

(this made me really sleep well!)

thanks Jobst

6 thoughts on - CentOS 6.X, Iptables 1.47 And GeoLite2 Country Database

  • Do you create a separate table, then feed every IP address (via ipset) into this chain?
    Would you mind sharing this script?

    thx Jobst

  • –CentOS 7 uses firewalld which has direct support for ipsets in XML form. Hopefully the site will soon supply the data in that format. (But it’s not hard to generate the files from their format.)

    Note that a zip file of all the individual country files can be downloaded here:

    http://www.ipdeny.com/ipblocks/

  • Below is my script for creating/updating an ipset to block my top 10
    undesirable/abusive countries. It runs as a cron job up startup to initially populate it and again every X hours to update it on my EdgeRouter firewall device.

    It can be relatively slow process creating very large sets, so we create a temp set and then swap the contents of the live set with the temp set and finally delete the temp set. This is a more efficient way of updating an existing set.

    Once the ipset has been created, you can create rules in iptables to match against that set using -m set –match-set SETNAME.

    Hope that helps

    — Phil

    CountryList=”cn ru ua kp kr br ro tr vn in”
    if [ -e /tmp/countries.txt ]; then rm /tmp/countries.txt fi

    for country in $CountryList; do curl -o /tmp/$country.txt http://www.ipdeny.com/ipblocks/data/aggregated/$country-aggregated.zone cat /tmp/$country.txt >> /tmp/countries.txt done

    getnetblocks() {
    cat < /tmp/cnblock.txt sudo ipset -! -R < /tmp/cnblock.txt sudo ipset -W geotmp COUNTRIES-BLOCK sudo ipset -X geotmp rm /tmp/cnblock.txt

  • Thanks, it did, cleared up conflicting info I found on the Internet.

    I also wanted to go the “other way”: disallow everything but 2 countries (AU,NZ). There are even more conflicting ideas about how to do this, but I figured it out.

    Also I cannot see a difference in speed between using (maxmind)

    -A filter_countries -m geoip –src-cc AU,NZ -j ACCEPT

    and (ipdeny)

    -A filter_countries -m set –set au.geoblock src -j ACCEPT

    which is really good!

    Jobst

  • Great.

    How you handle that will depend on the default policy of the chain.

    I would use 2 rules – the first to accept connections from AU,NZ, and a second rule subsequently DROPing all other connections, as this will work regardless of the default policy of the chain and the intention of the rules is clear to anyone reading them.

    Yes, ipset is really efficient. My top 10 bad countries set above contains over 28,000 individual netblocks and runs on my EdgeRouter Lite, with a 500MHz embedded processor. The device is capable of Gigabit throughput, and I see no impact upon throughput with multiple iptables rules, many based on large ipsets.