Ce post présente UFW un outil simplifié de configuration d’iptable sur son serveur dédié, il est disponible sur les distributions Ubuntu et Debian. Pour rappel, iptables, et ip6tables pour l’IPv6, sont deux outils d’administration du module netfilter au sein du noyau qui permettent la manipulation des paquets IP. Ces deux utilitaires sont extrêmement puissants et utilisés principalement pour

• mettre en place des règles de filtrage des paquets IP (firewall)
• partager une connexion internet (NAT)
• l’historisation du trafic réseau (log)

Toute bonne administration d’un serveur linux passe donc par la maîtrise d’iptables, et soyons honnêtes ce n’est pas un outil simple prendre en main. Comme souvent sur internet, on trouvera beaucoup trop de tuto qui sont soit mauvais soit simplistes, et dans tous les cas, on voit toujours trop de gens qui

• pensent qu’ils n’ont pas besoin d’iptables puisque leur serveur fonctionne… pour le moment
• débarquent sur les forum paniqués, leur serveur venant d’être hacké ou fermé car il a servi pour un DDoS

Pourtant, UFW propose une solution simple pour tous les débutants ou les plus flemmards qui n’ont pas envie de passer une journée à configurer/débuguer leur config iptables. Si la prise en main est aisée, UFW conserve la polyvalence d’iptables en permettant d’intégrer les règles les plus complexes.

Installation et Avertissement

UFW fonctionne très bien et sans problème sur les noyaux officiels de debian et ubuntu. Attention aux autres, notamment ceux d’OVH qui ne sont pas toujours compilés avec les modules nf_conntrack par exemple. Si vous utilisez la formule VPS Classic d’OVH, oubliez UFW, votre VPS est hébergé par OpenVZ et n’a donc pas son propre noyau.
Le piège classique, quand on manipule iptables ou UFW, est de s’interdir l’accès au shell SSH. Par défaut, UFW accepte le trafic icmp (ping, traceroutes, etc.) et ignore le reste. La première chose à faire est donc d’autoriser l’accès SSH avant d’activer UFW et de bien vérifier après, même si la connexion SSH active n’a pas sauté, que l’on peut toujours se connecter ! Une fois ces chausse-trapes contournés, UFW est fool-proof.
Pour installer UFW sur votre Debian ou Ubuntu, passez en root les commandes suivantes :

Si jamais vous vous êtes enfermés dehors, il vous faudra, via un accès console, KVM, OVH mode rescue ou n’importe quoi d’autre fourni par votre hébergeur, désactiver UFW soit avec un ufw disable ou en modifiant le paramètre ENABLE dans /etc/ufw/ufw.conf

Quelques Règles de Base

Si vous hébergez un serveur web avec SSL, il vous faut ouvrir les ports 80 et 443 en tcp pour permettre l’accès :

Attention, ces règles s’appliquent à toutes les interfaces en IPv4 et IPv6, pour ouvrir le trafic sur une seule interface, dans cette exemple celle d’un serveur TeamSpeak 3 :

Si l’on souhaite imposer un « rate limiting », UFW propose une règle qui, par défaut, limite le nombre de connexions depuis une même IP source à 6 sur les 30 dernières secondes. Cela peut être utile en cas de DDoS ou pour se protéger d’une attaque par force brute :

Listing des Règles et Suppression

Pour afficher toutes les règles utilisateurs mises en place :

Si la règle 5 n’a pas d’utilité, par exemple le daemon SSH n’écoute pas sur les adresses IPv6 :

N’oubliez pas que les règles sont interprétées dans l’ordre affiché, autrement dit, un DENY précédé d’un ALLOW sur les même conditions ne sera jamais pris en compte. Dans tous les cas, la politique par défaut étant « DENY », tout ce qui n’est pas autorisé sera rejeté. Pour insérer une règle au bon endroit, utiliser l’option insert

Les Logs

Si vous souhaitez garder une trace dans les logs de UFW des paquets refusés, acceptés etc. utilisez l’option logging. Par défaut, quand les logs sont activés, ils sont sur le niveau « low ». On peut augmenter ce niveau mais attention au remplissage des disques surtout sur un serveur très actif :

Un tour sur le man ufw fourni les différents niveaux de logs :

• low logs all blocked packets not matching the default policy (with rate limiting), as well as packets matching logged rules
• medium log level low, plus all allowed packets not matching the default policy, all INVALID packets, and all new connections. All logging is done with rate limiting.
• high log level medium (without rate limiting), plus all packets with rate limiting
• full log level high without rate limiting

Règles Avancées

Si vous avez suivi ce post jusque là, vous disposez maintenant grâce à UFW d’une configuration iptables assez solide pour un serveur basique. Mais comment gérer des configurations plus poussées ? Pas de soucis, UFW fournit un framework pour adapter son comportement par défaut et gérer les règles non supportées par l’interface utilisateur. Par exemple, UFW dispose de son propre fichier sysctl.conf qui vient remplacer les valeurs de celui du système. Par exemple, pour activer le routage, il suffit de dé-commenter les lignes suivantes dans /etc/ufw/sysctl.conf

Attention, la politique par défaut de UFW étant DROP pour ces chaînes, vous voudrez peut-être modifier ce comportement dans le fichier /etc/default/ufw :

Ou alors, vous préférerez rajouter des règles par protocole pour le routage. Rajoutez-les dans le fichier /etc/ufw/before.rules dans la chaîne ufw-before-forward.
Pour activer le NAT sur le subnet 192.168.1.0/24, il suffit de rajouter à la fin du fichier /etc/ufw/before.rules

Vous l’aurez remarqué, les syntaxes sont les mêmes que pour iptables-restore et ip6tables-restore. C’est normal, UFW s’en sert pour injecter ses règles dans le netfilter. Par contre, autant l’interface utilisateur de UFW est accessible à tous, autant il est fortement recommandé de comprendre iptables avant de jouer avec le framework. Je peux conseiller un bon tutoriel sur cette page.

Pour Conclure

On ne le répétera jamais assez. Un firewall est indispensable pour tout équipement connecté à Internet, que ce soit un serveur dédié ou son propre PC. UFW répond à ce besoin avec simplicité sans pour autant abandonner la souplesse qu’offre iptables. Il ne reste plus vraiment d’excuse pour ne pas s’y mettre.