Ferm

Vous battez-vous toujours avec vos scripts shell pour configurer les firewall de vos serveurs ? Ne ramez plus, j'ai la solution : Ferm.

Pourquoi ferm ? Ben pourquoi pas ?

Je l'ai choisi car il ne fait qu'une chose (et le fait bien), il remplace vos scripts shell de lancement de firewall. Et c'est tout ! Pas d'interface graphique, pas d'assistance à création de règle, pas de gestion de votre serveur DHCP ...

Donc si votre machine de bureau sert de passerelle vers internet, ou si vous ne connaissez pas bien iptables, ce n'est probablement pas le meilleur outil. Par contre si vous avez l'habitude d'écrire des scripts shell pour gérer votre firewall, ferm est là pour vous simplifier la vie.

Configuration

Ferm génère des règles iptables à partir de son fichier de configuration. Il n'invente rien, il ne fait qu'écrire sous forme hiérarchique les règles iptables et vous permet d'utiliser des variable et des listes. Il faut donc les connaître un peu.

Petit exemple pour vous montrer comment gagner du temps (il se comprend tout seul) :

@def $SERVERS = (10.0.0.2 10.0.0.3);
table filter {
    chain FORWARD {
        policy DROP;
        proto tcp dport (80 443) daddr $SERVERS ACCEPT;
    }
}

On demande à ferm de générer les règles iptables mais sans les mettre dans le firewall (pas fou) :

$ ferm -n --lines firewall.conf

Et on obtient directement nos 4 règles auxquelles on s'attendait :

*filter
:FORWARD DROP [0:0]
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 80 --destination 10.0.0.3 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.2 --jump ACCEPT
-A FORWARD --protocol tcp --dport 443 --destination 10.0.0.3 --jump ACCEPT
COMMIT

On comprend bien qu'on va gagner du temps en scripting. Il faudra toujours écrire ses propres règles, mais elles seront "standardisées" et factorisées. Donc le transfert de compétence d'une personne à l'autre sera facilité. Le transfert de script aussi puisque ferm sait générer des scripts qui devront être poussés et lancés sur d'autres machines. Pratique pour ceux qui veulent une gestion centralisée des firewall de leurs serveurs/routeurs.

Mieux

Vous aurez remarqué que ferm génère des règles de type "sauvegarde iptables". Ce que je suis sur que vous ne faites pas dans vos script. Et pourtant c'est un gain de performance et de sécurité car l'ensemble des règles sera chargé en mémoire d'un coup.

De plus ferm gère lui-même le lancement du firewall au boot de la machine.

La cerise

Et si vous comptez passer à l'ipv6 ! Hé bien surtout ne faites rien ! Réutilisez le même firewall, entourez vos règles de

domain (ip ip6) {
 ....
}

Et voila votre firewall dualstack est prêt.

I'm back !
Désolé de vous avoir fait attendre, j'étais en quelque sorte en vacances.

Firewall

Cette fois nous allons parler de firewall. Comme vous le savez, netfilter, le firewall intégré à linux, est statefull par défaut. Ce qui veut dire que si on ne lui dit pas de ne pas le faire, il trace l'état de toutes les connexions qui le traversent. C'est grâce à cela qu'il sait filtrer les connexions avec des règles "simples" ou qu'il est capable de filtrer proprement le ftp.

Pour cela il garde en mémoire une table des connexions établies, qu'il peut communiquer au reste du monde, autrement appelé espace utilisateur. Il expose ces infos dans /proc/net/ip_conntrack* (entre autre, mais n'hésitez pas à regarder le contenu de ce répertoire pour plein de choses intéressantes).

La commande conntrack, du paquet éponyme sert à manipuler la table en question. Toute machine ayant un firewall, ou presque, on peut s'amuser à l'utiliser sur son PC. Mais c'est bien plus rigolo de faire ça sur un routeur ;->

D'ailleurs, si vous avez un serveur qui ne fait pas firewall et qui gère beaucoup de connexions (un serveur de twitter par exemple), vous pouvez désactiver le "connection tracking" pour soulager le noyau de cette tâche. Mais il faut entièrement désactiver le module, ce qui n'est pas des plus simple.

Conntrack

D'abord, commençons par lister les connexions connues :

$ conntrack -L

Pour une machine qui ne fait pas routeur, la liste est similaire à celle obtenue par netstat -atu. Notez les informations intéressantes : état de la connexion, détail de la connexion (remarquez la répétition nécessaire pour le NAT), et surtout nombre de paquets et d'octets passés par cette connexion. Ce compteur peut être réinitialisé avec l'option -z de conntrack :

$ conntrack -L -z

Pratique quand on veut détecter les changements.

Vous pouvez aussi regarder ce qui se passe en direct sur votre routeur :

$ conntrack -E

Mais lisez bien le manuel, pour limiter la sortie, car sur un vrai routeur, il faut filtrer. Man conntrack contient toutes les explications.

Et le plus rigolo sur un routeur partagé, on enlève l'entrée :

# Attention, il faut tout spécifier pour être sûr qu'on parle de la bonne connexion
$ conntrack -D -s 1.2.3.4 -d 4.3.2.1 -p tcp --orig-port-src 5678 --orig-port-dst 22

Cela devrait couper la connexion si le firewall est bien configuré (et probablement aussi s'il est mal configuré). C'est tout de même moins artisanal que l'ancienne technique.