Iptables est l’utilitaire bien connu sous Linux pour gérer le pare-feu Netfilter. Il est très puissant, et possède des extensions pour augmenter ses possibilités. Dans le cadre de cet article le module xt_geoip va nous permettre de bannir des pays entiers sur un serveur Debian 9, à l’aide de la base de données GeoIP simplifiée.
Pourquoi bloquer un pays entier ?
Si vous analysez les logs de vos serveurs connectés en direct à internet, vous vous rendrez probablement compte que ceux-ci sont la cibles d’attaques diverses. En particulier, la Chine, la Russie et l’Ukraine sont des pays connus pour émettre du spam et commettre des tentatives d’intrusion dans les systèmes informatiques. Certains projets comme Kaspersky Cyberthreat real-time map ou Digital Attack Map tentent de cartographier ces attaques. Pour ma part je me fie en particulier à mes logs, et éventuellement à l’alphabet Cyrillique employé pour me spammer par email et formulaires !
Tous les administrateurs système ne peuvent pas se permettre de bloquer un pays entier, notamment si ceux-ci hébergent des services qui peuvent légitimement être accédés depuis ces pays là.
Installation des paquets sous Debian
Sous Debian les paquets sont déjà préparés pour ajouter les modules au noyau sans recompilation complète. Il faut donc installer les paquets suivants : xtables-addons-dkms xtables-addons-common libgeoip1 libtext-csv-xs-perl unzip . Le paquet geoip-database ne semble pas nécessaire car les fichiers CSV GeoIP seront téléchargés par un script du paquet xtables.
DKMS est un système permettant d’ajouter des modules au noyau dont les sources ne résident pas dans le noyau.
L’obtention des fichiers de données se fait ainsi. On convertit ensuite les données dans un format binaire facile à manipuler par le noyau dans /usr/lib/xt_geoip. Ici aucun script externe n’est requis, tout le nécessaire se trouve dans les paquets installés qui vont télécharger les données puis les convertir.
1 2 3 4 |
# cd /usr/lib/xtables-addons # ./xt_geoip_dl # mkdir /usr/share/xt_geoip # ./xt_geoip_build -D /usr/share/xt_geoip/ *.csv |
Il est normal d’obtenir un répertoire LE et BE dans /usr/share/xt_geoip, chacun contenant environ 500 fichiers .iv4 et .iv6.
On peut ensuite charger le module et s’assurer qu’il est utilisable par iptables.
1 2 3 4 5 6 7 8 9 |
# modprobe xt_geoip # lsmod |grep geoip # iptables -m geoip --help [...] geoip match options: [!] --src-cc, --source-country country[,country...] Match packet coming from (one of) the specified country(ies) [!] --dst-cc, --destination-country country[,country...] Match packet going to (one of) the specified country(ies) |
La commande suivante permet de vérifier que le module dkms est correctement pris en compte par le noyau.
1 2 |
# dkms status xtables-addons xtables-addons, 2.12, 4.9.0-3-amd64, x86_64: installed |
Règles iptables par pays
Règle basique de blocage
La syntaxe iptables pour utiliser le module geoip est expliquée avec la commande d’aide ci-dessus.
Voici un exemple simple où on bloque les connexions entrantes en provenance de pays bloqués. On peut spécifier plusieurs pays par commande, au maximum une dizaine.
1 |
# iptables -A INPUT -m geoip --src-cc RU,CN -j DROP |
La liste des codes ISO 3166-2 des pays sur deux lettres est visible sur Wikipedia.
On peut vérifier que la règle est bien dans la stack iptables comme ceci.
1 2 |
# iptables -L -n | grep geoip DROP all -- 0.0.0.0/0 0.0.0.0/0 -m geoip --source-country RU,CN |
Pour moi cette règle doit intervenir assez tôt dans la stack iptables afin de ne pas être désactivée par une autorisation visant un port d’entrée, ou un protocole comme icmp par exemple.
Règle de logging
Voici une application plus poussée du pare-feu iptables pour inscrire dans un fichier de log toutes les connexions qui correspondent à un motif. Ici dans un but de démonstration, on cible les connexions qui ne sont pas avec des adresses françaises.
1 2 3 |
# iptables -N LOGGING # iptables -A INPUT -m geoip ! --src-cc FR -j LOGGING # iptables -A LOGGING -j LOG --log-level 4 |
Ici le log-level vaut 4 (niveau warning) et on configure le fichier qui reçoit les warning dans /etc/rsyslog.conf avec une ligne kern.warning /chemin/vers/log .
Vérification du fonctionnement
Pour vérifier le fonctionnement d’une règle, je vous conseille de bloquer des pays et de vérifier l’accessibilité du serveur web avec un service comme locabrowser.com ou équivalent pour d’autres protocoles. Alternativement vous pouvez vous contenter de pings vers une adresse IP dans le pays visé.
Conclusion
Les règles iptables par pays ont un coté radical qui est assumé et ne pose pas de problème de neutralité du réseau tant que justement cela n’est pas appliqué sur un réseau public, mais bien sur un serveur privé. Un des avantages est que l’on peut cibler des hôtes avec lesquelles le serveur ne doit pas communiquer en fonctionnement normal, sans surcharger le pare-feu avec des milliers de règles IP par IP. De plus iptables se trouve assez bas dans la pile réseau, et peut donc apporter la fonctionnalité GeoIP à un service qui n’en serait pas doté comme par exemple un serveur FTP, SSH, NTP etc.
Je n’ai pas testé l’efficience de ces règles iptables sur le serveur, ni vérifier que le noyau ne s’en trouvait pas ralenti pour traiter les paquets. Sur un routeur chargé, je ne m’aventurerai pas à implémenter de telles règles sans vérifier que les performances suivent.
Pour finir, la base de données GeoIP n’est pas exhaustive, et donc il est évident que toutes les blocs IP d’un pays ne seront pas pris en compte. On ne peut donc pas se fier à 100% à ce type de règle.
Attention, néanmoins si vous avez configuré un serveur vpn sur cette machine…Vous risquez d’avoir des problèmes pour consulter certains sites…
En effet, mais un serveur web reçoit des connexions TCP d’un port supérieur à 1024 vers son port 80, tandis que lors du surf vous émettez une connexion TCP d’un port supérieur à 1024 vers le port 80 distant. Il y a donc moyen de restreindre le serveur web par pays avec iptables, mais pas le surf. Alternativement Apache2 supporte la configuration GeoIP sur ses VirtualHost.
Article très intéressante, mais une mise à jour est nécessaire car Résolution de geolite.maxmind.com (geolite.maxmind.com)… échec
J’ai l’impression que le domaine que vous citez est présent dans le script qui vient avec votre paquet Debian. C’est donc le mainteneur de ce paquet qu’il faudrait avertir.
En attendant voici une source alternative sur ce site.
Bonsour,
sur le site https://www.maxmind.com ont peux télécharger la base GeoipLite2 au format CSV
dans ce zip , il y a 10 fichiers CSV :
GeoLite2-Country-Blocks-IPv4.csv 10.5Mo
GeoLite2-Country-Blocks-IPv6.csv 4Mo
GeoLite2-Country-Locations-de.csv 10ko
GeoLite2-Country-Locations-en.csv 10ko
GeoLite2-Country-Locations-es.csv 10ko
GeoLite2-Country-Locations-fr.csv 11ko
GeoLite2-Country-Locations-ja.csv 15ko
GeoLite2-Country-Locations-pr-BR.csv 12ko
GeoLite2-Country-Locations-ru.csv 15ko
GeoLite2-Country-Locations-zh-CN.csv 12ko
je voudrais savoir si elle sont utilisable, et qu’est-ce que je dois garder et est-ce-que je peux utiliser la commande ./xt_geoip_build avec ?
Merci
Bonjour,
Le format des CSV téléchargés par xt_geoip_dl a six colonnes. Exemple :
« 1.0.0.0 », »1.0.0.255″, »16777216″, »16777471″, »AU », »Australia »
Il doit être possible de se référer à ce format pour utiliser des CSV externes.
Cordialement
Bonjour,
Maintenant il faut avoir un compte chez maxmind pour télécharger le zip contenant les csv mais le nouveau format n’est plus compatible avec xtables.
Je viens de tomber sur ce lien : https://legacy-geoip-csv.ufficyo.com/ qui permet de récupérer un fichier compatible.
Je viens de tester ça fonctionne correctement.
l’image docker du projet utilise ces scripts : https://github.com/sander1/GeoLite2xtables pour ceux qui sont allergiques a docker.
Cordialement.
Ah oui, cela me dit quelque chose en effet. Merci de relayer ce lien.