Pare-feu et iptables

Par ce salop de FanfanlaTulipe

Nous aborderons ici le sujet des pare-feu, point cruciale dans la sécurité des serveurs et des réseaux.

Pare-feu

Un pare-feu permet de filtrer les flux réseaux sur une machine et de faire respecter la politique de sécurité du réseau. Nous distinguerons deux définitions du pare-feu :

• Pare-feu matériel : il s'agit d'un matériel réseau dont le but est de filtrer les flux réseaux le traversant. On peut par exemple citer les pare-feu Fortinet ou Palo Alto.
• Pare-feu logiciel : il s'agit d'une couche réseau qui va filtrer les flux réseaux déstinés à ou transitant par la machine. Là, on peut citer Windows Defender (pare-feu de Microsoft), iptables (pare-feu Linux) ou pf (pare-feu BDS).

La suite de ce guide parle des pare-feu logiciels. Nous désignemerons par "pare-feu" les pare-feu logiciels.

Le filtrage se fait selon plusieurs critères, par exemple :

• La source et la destination d'un paquet (IP, port, interface réseau)
• Les données transportées (taille, correspondance avec un motif)

On distingue deux types de pare-feu :

• Sans état (Stateless): un pare-feu sans état ne va pas faire la distinction entre un nouveau paquet et un paquet présent suite à une connexion. Par exemple, dans le cas d'un pare-feu sans état sur un serveur web, il faut autoriser les flux entrants à destination du port 80 ET les flux sortants à l'origine du port 80.
• A état (stateful): à l'inverse, un pare-feu avec état va pouvoir déterminer si un paquet est neuf ou s'il provient d'une connexion déjà établie. Dans notre exemple, il suffit d'autoriser les flux entrants à destination du port 80 et le pare-feu autorisera les paquets en réponse à la requète à sortir.

Les pare-feu sans état sont donc bien plus stricts et permettent un meilleur contrôle des flux, mais sont plus compliqués à maintenir et la probabilité de faire des erreurs est plus grande. A l'inverse, les pare-feu à état sont plus simples d'utilisation et plus adaptés aux protocoles dit 'connectés' comme TCP.

Iptables

Wiki Arch Linux
Wiki sur les pare-feu à état et exemple de configuration
Guide concernant les pare-feu de l'ANSSI

iptables est un outil en ligne de commande pour configurer le pare-feu du noyau Linux (le terme "iptables" est aussi utilisé pour désigner ce pare-feu). Ce pare-feu est configurable directement avec iptables ou avec des outils graphiques (nous y reviendrons plus bas).

Il faut noter qu'iptables est utilisé pour la pile IPv4, et ip6tables pour la pile IPv6.

ATTENTION, si vous travaillez sur une machine distante, faire une erreur lors de la configuration du pare-feu peut couper votre connexion et rendre la machine injoignable !

Par défaut, iptables est un pare-feu sans état. Il est cependant possible de le transformer en pare-feu à état avec le module noyau conntrack. Nous utiliserons conntrack pour la suite de ce guide. De plus, il est important de savoir qu'iptables fonctionne selon le principe du first-match. Cela signifie que la première règle qui correspond au paquet sera la règle appliquée.

Rendre iptables stateful

On accepte tous les paquets provenant de connexions déjà établies :

iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Il est donc nécessaire d'appliquer ses règles en premier, pour appliquer la règle du first-match.

Ne pas couper la connexion actuel dans le cas d'une machine distante

iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Règles par défaut

Sous Linux, il est conseillé de mettre par défaut les règles suivantes :

• DROP sur le traffic entrant (INPUT)
• DROP sur le traffic transité (FORWARD)
• ACCEPT sur le traffic sortant (OUTPUT)

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Dans la logique du first-match, ces règles doivent être appliqué en dernières.

Règles persistentes

Les règles iptables ne survivent pas à un redémarrage. Il est donc nécessaire de faire quelques manipulations pour leurs permettre d'être persistentes. Nous utiliserons 2 binaires :

• iptables-save pour sauvegarder les règles iptables.
• iptables-restore pour rétablir les règles iptalbes.

Pour sauvegarder les règles actuellement en place :

sudo iptables-save -f /etc/iptables/iptables.rules

De plus il faut un service qui se lancera un démarrage pour rétablir les règles :

sudo vim /usr/lib/systemd/system/iptables.service

[Unit]
Description=IPv4 Packet Filtering Framework
Before=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables-restore /etc/iptables/iptables.rules
ExecReload=/usr/sbin/iptables-restore /etc/iptables/iptables.rules
ExecStop=/usr/sbin/iptables -F
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Outils graphiques

• firewalld
• Gufw
• PeerGuardian

Le tocage à la porte

Le port knocking (normalement je préfère les termes français mais là...) est une méthode pour mettre d'ouvrir un port sur un pare-feu normalement fermé. Le pare-feu va attendre des connexions à des endroits bien spécifiques, dans un ordre précis. L'intéret du port knocking est de rendre un service invisible à un scan de port.

Nous verrons ici comment l'implémenter avec iptables.

Je vous jure je vais le faire.

Source du wiki Arch Linux

Sécurité par l'obscurité

Le principe de la sécurité par l'obscurité repose sur la non-divulgation d'information pour assurer la sécurité d'une structure (dans le cas de la sécurité informatique). On peut par exemple citer le rot n dans la cryptographie.

La sécurité par l'obscurité est dangereuse car elle donne un faux sentiment de sécurité. En effet, si le secret est découvert, toutes les messages passés, présentes et futures sont vulnérables (dans le cas de la cryptographie).

La question est donc : "Est ce que le tocage à la porte est une sécurité par l'obscurité ?"

Le tocage à la porte ne remplace pas une authentification classique. Cela doit être une mesure complémentaire uniquement pour contrer les scans de port ou les attaques par force brute. Le tocage à la porte ne doit en aucun cas donner accès à des ressources sensibles sans une autre forme d'authentification. Enfin, pour répondre à la question, le tocage à la porte peut être vu comme une forme de mot de passe supplémentaire, mais qui est récupérable avec une attaque de l'homme du milieu (man-in-the-middle) par exemple.