Cet article est la première brique d’un dossier regroupant des articles existants et à venir qui constitueront un ensemble de pratiques permettant de sécuriser un serveur Debian/Ubuntu. Ce sont des techniques que j’utilise cela ne veut pas dire que ce sont les meilleures. Je suis preneur de critiques constructives et améliorations.

Quand on parle de sécurité sur un serveur on parle forcément du firewall, composant essentielle de la base d’une bonne sécurité. Netfilter est le pare feu le plus utilisé dans le monde des distributions Linux basées sur Debian et Ubuntu et on le manipule avec IPTables.

Règles par défaut et ordre

Avant de commencer à manipuler un firewall il faut réfléchir aux flux qui vont avoir lieu sur notre serveur et les politiques par défaut que l’on veut mener. Par défaut j’utilise toujours une politique par défaut où tout est bloqué que ce soit en entrée ou en sortie. On bloque tout et l’on ouvre ensuite uniquement ce dont on a besoin. Un autre élément essentiel est l’ordre dans lequel on va enchaîner nos règles car IPtables lit les règles de haut en bas comme tout le monde. Par exemple si sur la première ligne vous autorisez l’accès à google.com pour tout le monde et que sur la deuxième vous dites que telle IP ne doit pas accéder à google.com, c’est la première politique plus large qui sera appliquée puisque c’est la première qui correspond à la situation. Si je suis un firewall et que je reçois un paquet d’une adresse, si la première consigne que je lis c’est de tous les accepter alors j’accepte, si la ligne d’après me dit de ne pas accepter ceux de cette adresse en particulier c’est trop tard…

Tables, chaînes et directives

IPTables est constituée d’un certain nombre de tables appliquant des règles spécifiques. Celle qui va nous intéresser est la table filter qui va nous permettre de filtrer les paquets du réseau. Dans chaque table se trouve ce que l’on appelle des chaînes, à savoir: INPUT pour le trafic entrant, OUTPUT pour le trafic sortant et FORWARD pour le passage d’une interface réseau à une autre. Les chaînes PREROUTING et POSTROUTING existent aussi mais ne seront pas abordées ici. De même pour les autres tables qui sont: RAW pour « tagger » des paquets, MANGLE pour modifier les en têtes de paquets et NAT pour faire de la traduction de ports.
Les directives sont en gros l’action à mener si un schéma correspondant à la règle est détecté. Nous allons ici plus particulièrement nous intéresser à ACCEPT et DROP qui permettent respectivement d’accepter un paquet et le jeter.

Ligne de commande

Je l’ai dit au dessus IPTables nous permet de manipuler Netfilter et cela se fait de manière classique via la ligne de commande (des interfaces graphiques existent pour les environnement de bureau). Avec ce que l’on a vu dans les paragraphes précédents on imagine qu’il faut spécifier la table et la chaîne que l’on utilise. C’est exact mais il y’a bien sur beaucoup d’autres paramètres à prendre en compte comme par exemple le protocole, le port ou l’interface à utiliser. Par exemple pour interdire l’accès à mon serveur sur le port 21 (FTP) voici ce que j’obtiens:
iptables -t filter -A INPUT -p tcp --dport 21 -j DROP
J’appelle IPTables, puis la table filter et la chaîne INPUT, je spécifie que je travaille sur tcp sur le port 21 et enfin je donne la directive à appliquer. Quand on y réfléchit c’est assez logique non ?
Il est aussi possible de spécifier l’interface réseau concernée avec -i lemondelinterface
Moins la commande contient d’argument plus la règle sera stricte: si dans l’exemple je n’avais pas --dport 21 c’est tout le trafic entrant sur TCP qui serait bloqué. Il faut donc enchaîner ses règles avec précaution et dans le bon ordre. C’est d’ailleurs pour cela que l’on utilise normalement un script qui permet de bien visualiser nos règles dans l’ordre et de commenter leur effet. Je pense que je ferais d’ailleurs un article sur le script que j’utilise personnellement et qui permettra d’expliquer les commandes les plus utilisées.
On va donc s’arrêter là pour aujourd’hui après tout ce n’est qu’une introduction !
N’hésitez pas à commenter pour signaler des choses que vous n’auriez pas comprises ou des erreurs ou approximations que j’aurais commises !