Persistance des règles Iptables

De EjnTricks
Révision de 22 mars 2018 à 13:23 par Etienne (discussion | contributions)

(diff) ← Version précédente | Voir la version courante (diff) | Version suivante → (diff)

L'utilisation de Iptables permet de mettre en place des règles d'accès sur une machine. Ce firewall est très puissant et permet de mettre en place des règles sophistiquées. Cependant, lors de l'arrêt de la machine, celles-ci sont perdues et il est nécessaire de rejouer les configurations.

Cet article décrit la sauvegarde et la restauration automatique pour une installation sous Ubuntu.


Hand-icon.png Votre avis

Nobody voted on this yet

 You need to enable JavaScript to vote


Icon-memory.png Paquet iptables-persistent

Il existe le paquet iptables-persistent qui permet de gérer cette procédure de sauvegarde et chargement, comme décrit sur le site officiel: https://help.ubuntu.com/community/IptablesHowTo?action=show&redirect=Iptables#Configuration_on_startup. Ou une version française: https://doc.ubuntu-fr.org/iptables#appliquer_les_regles_au_demarrage.

Cependant ce paquet ne propose pas de configuration, comme un filtrage des règles asuvegardées. Fail2ban étant utilisé sur la machine, une implémentation personnalisée est mise en place comme expliqué dans la paragraphe suivant.


Study icon.png Analyse configuration réseau

La configuration réseau se situe au niveau du répertoire /etc/netword, dont le contenu est:

#sudo find /etc/network | sed 's/[^/]*\//|   /g;s/| *\([^| ]\)/+--- \1/'
|   +--- network
|   |   +--- interfaces
|   |   +--- if-up.d
|   |   |   +--- avahi-daemon
|   |   |   +--- ethtool
|   |   |   +--- wpasupplicant
|   |   |   +--- ntpdate
|   |   |   +--- openssh-server
|   |   |   +--- avahi-autoipd
|   |   |   +--- 000resolvconf
|   |   +--- if-down.d
|   |   |   +--- resolvconf
|   |   |   +--- wpasupplicant
|   |   |   +--- avahi-autoipd
|   |   +--- interfaces.d
|   |   +--- if-pre-up.d
|   |   |   +--- ethtool
|   |   |   +--- wpasupplicant
|   |   +--- run
|   |   +--- if-post-down.d
|   |   |   +--- avahi-daemon
|   |   |   +--- wpasupplicant

Les répertoires suivants attirent l'attention:

  • if-down.d
  • if-post-down.d
  • if-pre-up.d
  • if-up.d

Ceux-ci ressemblent étrangement aux actions possibles dans le fichier interface pour exécuter des scripts spécifiques. La consultation de la documentation confirme ceci. A noter que les répertoire if-pre-down et if-down-up ne sont pas mis à disposition par défaut avec Ubuntu. La documentation de interface est explicite sur ce point, étant des alias les scripts ne seront pas exécutés. Ces répertoires ne sont donc pas utiles.

L'utilisation de liens / scripts dans ces répertoires est grandement recommandée car cela évite la modification de fichier "système" et limite les risques d'erreurs.


Strategy-icon.png Stratégie de conservation

Backup-icon.png Backup

Les règles seront sauvegardées dans le répertoire /var/opt/backups/iptables:

#sudo mkdir -p /var/opt/backups/iptables
#sudo chmod -R 766 /var/opt/backups
#sudo chmod -R 700 /var/opt/backups/iptables

Le répertoire mis en place ne pourra être accédé que par le compte root afin de sécuriser l'accès aux sauvegardes.

Il faut ensuite créer le script, fichier /var/opt/backups/iptables/iptables-save.sh, qui va permettre de sauvegarde les règles mises en place à l'aide de l'outil iptables-save:

#!/bin/sh

[ "$IFACE" != "lo" ] || exit 0

iptables-save -c > /var/opt/backups/iptables/iptables.rules
chmod 600 /var/opt/backups/iptables/iptables.rules
exit 0

Warning-icon.png Attention, il est important de placer l'instruction de test sur l'interface. En effet, plusieurs interfaces sont chargées sur la machine dont celle de loopback. Ce test s'inspire de script fourni par Ubuntu, comme /etc/network/if-post-down.d/avahi-daemon.

#!/bin/sh

# Don't run the avahi-daemon unicast local check while bringing up
# the loopback device; it's not necessary until we bring up a real network
# device
[ "$IFACE" != "lo" ] || exit 0
case "$ADDRFAM" in
        inet|inet6) ;;
        *) exit 0 ;;
esac

# If we have an unicast .local domain, we immediately disable avahi to avoid
# conflicts with the multicast IP4LL .local domain
if [ -x /usr/lib/avahi/avahi-daemon-check-dns.sh ] ; then
        exec /usr/lib/avahi/avahi-daemon-check-dns.sh
fi

Ce script doit être exécutable et les permissions doivent également être restrictives:

#sudo chown root:root /var/opt/backups/iptables/iptables-save.sh
#sudo chmod 700 /var/opt/backups/iptables/iptables-save.sh

Dans le cadre d'une utilisation couplée avec Fail2ban, le résultat de la commande iptables-save -c exporte également les "chains" mises en place:

#sudo iptables-save -c
# Generated by iptables-save v1.4.20 on Mon Dec 30 16:00:51 2013
*filter
:INPUT ACCEPT [11508:1249240]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [9649:16781398]
:fail2ban-apache-scan - [0:0]
:fail2ban-ssh - [0:0]
:iptables-slapd - [0:0]
:iptables-tomcat - [0:0]
[0:0] -A INPUT -p tcp -m tcp --dport 389 -j iptables-slapd
[8591:729883] -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-scan
[1467:110128] -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
[0:0] -A INPUT -p tcp -m tcp --dport 8080 -j iptables-tomcat
[8591:729883] -A fail2ban-apache-scan -j RETURN
[1467:110128] -A fail2ban-ssh -j RETURN
[0:0] -A iptables-slapd -s 127.0.0.1/32 -j ACCEPT
[0:0] -A iptables-slapd -m iprange --src-range 192.168.1.2-192.168.1.9 -j ACCEPT
[0:0] -A iptables-slapd -j REJECT --reject-with icmp-port-unreachable
[0:0] -A iptables-tomcat -s 127.0.0.1/32 -j ACCEPT
[0:0] -A iptables-tomcat -m iprange --src-range 192.168.1.2-192.168.1.9 -j ACCEPT
[0:0] -A iptables-tomcat -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Mon Dec 30 16:00:51 2013

Or, ces "chains" sont créés automatiquement par Fail2ban lors de son démarrage. Il ne paraît donc pas nécessaire de les créer au démarrage de la machine. Qui plus est, si de nombreuses IPs ont été bannis, la table risque d'être conséquente et il n'est pas évident qu'il faille les conserver. En effet, ce sont essentiellement des tentatives de pirates et puisqu'ils ont été bannis lors de leur essai, il y a fort à parier qu'ils ne reviendront pas. Et au pire, ils seront à nouveau bannis.

En conclusion, il peut être utile de filtrer les règles générées par Fail2ban. L'outil étant particulièrement bien réalisé, il est facile de trouver une règle de filtrage se basant sur le mot fail2ban:

#!/bin/sh

[ "$IFACE" != "lo" ] || exit 0

iptables-save -c | sed '/fail2ban/d' > /var/opt/backups/iptables/iptables.rules
chmod 600 /var/opt/backups/iptables/iptables.rules
exit 0

Warning-icon.png Attention, le nom des bannissements peuvent évoluer. Dans les précédents exemples, fe filtre est réalisé sur des bannissements dont le nom contient fail2ban. Or les noms peuvent changés suite à des mises à jour, par exemple pour une version 0.9.7 les noms commencent par f2b. Dans ce cas, la commande de sauvegarde doit être la suivante.

#sudo iptables-save -c | sed '/f2b/d'


Le script étant opérationnel, il suffit de le référencer dans le répertoire /etc/network/if-post-down.d:

#sudo ln -s /var/opt/backups/iptables/iptables-save.sh /etc/network/if-post-down.d/iptables-save

Le contenu du répertoire /etc/network/if-post-down.d doit contenir le lien avec les droits d'exécution:

#sudo ll /etc/network/if-post-down.d
total 8
drwxr-xr-x 2 root root 4096 Dec 30 16:17 ./
drwxr-xr-x 7 root root 4096 Dec 30 15:33 ../
lrwxrwxrwx 1 root root   23 Dec 14 01:14 avahi-daemon -> ../if-up.d/avahi-daemon*
lrwxrwxrwx 1 root root   42 Dec 30 16:17 iptables-save -> /var/opt/backups/iptables/iptables-save.sh*
lrwxrwxrwx 1 root root   32 Nov 19 04:56 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh*

Backup-restore.png Activation

Une fois le script d'exportation mis en place, il reste à créer celui d'activation des règles, dans le fichier <code>/var/opt/backups/iptables/iptables-load.sh, avec le contenu:

#!/bin/sh

[ "$IFACE" != "lo" ] || exit 0

iptables-restore --noflush < /var/opt/backups/iptables/iptables.rules
exit 0

Warning-icon.png Attention, il est important de placer l'instruction de test sur l'interface. En effet, plusieurs interfaces sont chargées sur la machine dont celle de loopback. Ce test s'inspire de script fourni par Ubuntu, comme /etc/network/if-up.d/avahi-daemon.

#!/bin/sh

# Don't run the avahi-daemon unicast local check while bringing up
# the loopback device; it's not necessary until we bring up a real network
# device
[ "$IFACE" != "lo" ] || exit 0
case "$ADDRFAM" in
        inet|inet6) ;;
        *) exit 0 ;;
esac

# If we have an unicast .local domain, we immediately disable avahi to avoid
# conflicts with the multicast IP4LL .local domain
if [ -x /usr/lib/avahi/avahi-daemon-check-dns.sh ] ; then
        exec /usr/lib/avahi/avahi-daemon-check-dns.sh
fi

Warning-icon.png Attention, l'argument --noflush est important dans le cadre de cet article. En effet, Fail2ban est utilisé en complément, et des "chains" sont créées lors de son démarrage. Or, le script iptables-load.sh va être exécuté après. Sans l'argument --noflush, ces "chains" sont supprimés pouvant provoqués des effets de bords indésirables.

Si Fail2ban n'est pas utilisé, le contenu du script /var/opt/backups/iptables/iptables-load.sh peut s'affranchir du paramètre. Le contenu serait alors:

#!/bin/sh
iptables-restore < /var/opt/backups/iptables/iptables.rules
exit 0

Ce script doit être exécutable et les permissions doivent également être restrictives:

#sudo chown root:root /var/opt/backups/iptables/iptables-load.sh
#sudo chmod 700 /var/opt/backups/iptables/iptables-load.sh

Le script étant opérationnel, il suffit de le référencer dans le répertoire /etc/network/if-post-down.d:

#sudo ln -s /var/opt/backups/iptables/iptables-load.sh /etc/network/if-pre-up.d/iptables-load

Le contenu du répertoire /etc/network/if-pre-up.d doit contenir le lien avec les droits d'exécution:

#sudo ll /etc/network/if-pre-up.d
total 12
drwxr-xr-x 2 root root 4096 Dec 30 16:29 ./
drwxr-xr-x 7 root root 4096 Dec 30 15:33 ../
-rwxr-xr-x 1 root root  344 Apr 28  2012 ethtool*
lrwxrwxrwx 1 root root   42 Dec 30 16:29 iptables-load -> /var/opt/backups/iptables/iptables-load.sh*
lrwxrwxrwx 1 root root   32 Nov 19 04:56 wpasupplicant -> ../../wpa_supplicant/ifupdown.sh*


Warning-icon.png Attention

Une attention particulière doit être portée sur le nom des liens mis en place dans les sous répertoire de /etc/network. Si les scripts de sauvegarde et chargement ne sont pas pris en compte, il se peut que cela soit du au nom des liens.

En effet, ceux-ci sont exécutés à l'aide de la commande run-parts qui ne tient pas compte des fichiers contenant le caractère .. Il ne faut donc pas avoir d'extension dans les fichiers. Les premiers essais réalisés pour cet article donnait la création des liens ainsi:

#sudo ln -s /var/opt/backups/iptables/iptables-save.sh /etc/network/if-post-down.d/iptables-save.sh
#sudo ln -s /var/opt/backups/iptables/iptables-load.sh /etc/network/if-pre-up.d/iptables-load

Or, rien n'était réalisé. En supprimant les extension .sh, les scripts ont été exécutés comme attendu.


Viewer icon.png Voir aussi

Description de l'ensemble des solutions posibles. Documentation officielle: https://help.ubuntu.com/community/IptablesHowTo

Documentation de interfaces. Documentation officielle: http://manpages.ubuntu.com/manpages/trusty/en/man5/interfaces.5.html