Firewall M1

Définition, principe de fonctionnement

Définition

Un pare-feu ou firewall en anglais est un équipement réseau (matériel ou logiciel) dont le but est de faire respecter les politiques d’accès et de sortie du réseau en utilisant un ensemble de règles définissant la politique de sécurité du réseau.

Un pare-feu fonctionne en général sur les couches 3 et 4 du modèle OSI (réseau et transport) et 2 et 3 du modèle TCP/IP (Internet protocol et transport).

Attention, un pare-feu classique ne fonctionnera pas sur les couches supérieures (et notamment applicative) de ces modèles et donc ne filtrera pas, par exemple, d’URLs: c’est le “job” de votre reverse-proxy et/ou de votre WAF (Web Application Firewall)

Principe de fonctionnement

Un pare-feu va filtrer le trafic en utilisant plusieurs critères:

• La source et/ou la destination d’un paquet IP, les entêtes du paquet.
• Le protocole de transport utilisé (ex: TCP, UDP, ICMP, etc)
  • le port utilisé
  • les entêtes du protocole de transport (segment, datagramme)
• des règles fines, par exemple de rate-limit

En règle générale, on voudra configurer notre pare-feu afin qu’il utilise un fonctionnement de type “ce qui n’est pas explicitement autorisé est implicitement interdit” et non pas en mode “ce qui n’est pas explicitement interdit est implicitement autorisé”.

Suivant sa complexité, un pare-feu peut aussi modifier à la volée le trafic réseau, par exemple en effectuant du NAT (SNAT ou DNAT).

Lorsqu’un paquet arrive sur l’une des interfaces réseau du pare-feu, il va devoir “passer” un ensemble de règles définis dans la table de filtrage (en entrée, en sortie ou en transmission), ligne par ligne, en commençant par la première. Lorsqu’une règle matche, le trafic est autorisé, ou au contraire refusé. Il est donc très important de bien définir l’ordre de ces règles de filtrage!

Types de pare-feux

On distingue deux grands type de pare-feux (hors WAF):

• Les pare-feux dits “stateless”, sans état, qui va comparer le trafic à une liste de règles préétablies, généralement uniquement sur la couche 3 du modèle OSI.
• Les pare-feux dits “stateful”, qui vont eux conserver en mémoire l’état des connexions réseau (flux TCP, datagrammes UDP) qui peuvent permettre de mieux détecter les comportements anormaux (syn flood, etc). C’est le cas de netfilter (iptables/nftables/ufw) notamment grâce au module kernel conntrack (Connection Tracking). Ils sont donc capables de travailler sur la couche 3 et la couche 4 du modèle OSI.

Si le filtrage en entrée du réseau d’un pare-feu peut sembler évident, un pare-feu est aussi capable de filtrer le trafic en sortie du réseau, voire en interne du réseau (entre VLANs par exemple).

Le but peut être, par exemple, de filtrer en sortie des protocoles de communication qui, mal utilisés, peuvent porter préjudice à l’entreprise, par exemple les protocoles de partage de fichiers en peer-to-peer tels que bittorrent.

Bonnes pratiques

Positionnement du pare-feu

Dans un petit SI, en général le pare-feu est “intégré” au routeur. Cependant, si le trafic est plus important ou si on désire des fonctionnalités plus avancées, il peut être pertinent d’utiliser du matériel dédié, qu’on placera alors derrière le routeur.

En règle générale, on voudra donc placer nos pare-feux près des points d’entrée et de sortie de nos réseaux.

Matrice de flux

Avant de configurer notre pare-feu, il faut d’abord identifier les flux entrants et sortants que nous autoriserons - les autres étant bien sûr filtrés par défaut.

Pour cela, on doit identifier, pour chaque flux entrant et sortant:

• La source (interne ou externe) du flux
• La destination de ce flux
• La description de ce flux (ex: flux de backup journalier, connexion à distance, accès VPN, site web vitrine, ERP entreprise, etc)
• Le protocole utilisé (ex: SSH, HTTP(S), etc, UDP, ICMP ou TCP)
• Le port utilisé (ex: 2222, 80, 443, 8443, 51820)
• Les mesures de sécurité en place: ACL, Authentification, chiffrement…
• Et enfin toutes les informations supplémentaires possibles.

Exemple:

La matrice de flux va donc nous permettre d’identifier correctement les flux nécessaires au bon fonctionnement de notre système d’information ainsi que les mesures de sécurité en place ou à mettre en place, le but étant toujours de respecter la règle du moindre privilège: par exemple, les postes de travail du vlan compta doivent accéder à l’ERP de l’entreprise dans le VLAN IT, mais ne doivent pas avoir accès par exemple à l’IPAM dans ce même VLAN.

De la même façon, il est important de réfléchir à la défense en profondeur de notre système d’information: chaque équipement doit avoir son pare-feu configuré correctement, jusqu’au poste de travail des utilisateur⋅ices du SI.

Planifier l’organisation de nos tables de filtrage

Une fois notre matrice de flux déterminée, nous allons pouvoir mettre en place les différentes règles. Pour ce faire, il est important de bien déterminer l’ordre de nos différentes règles d’accès.

Par exemple, regardons les règles suivantes en entrée de notre réseau:

À votre avis, à quoi a accès 154.123.214.23?

En règle générale, lorsqu’on établit des règles d’interdiction d’accès (par exemple, pour un pays non-ami), il est important de les placer avant toutes les autres règles et notamment celles qui acceptent le trafic!

Dès lors, il est nécessaire de bien réfléchir en amont, avant d’implémenter les règles de notre pare-feu, à leur organisation et leur répartition sous forme de table.

Réviser et documenter régulièrement les règles en place

Les règles d’un pare-feu sont amenées à être modifiées à intervalles plus ou moins réguliers. En effet, on peut vouloir temporairement bloquer l’accès à une ressource en fonction de certains critères (par exemple, à un subnet appartenant à un cloud public). Cet ajout doit être documenté, car il est possible que dans le futur, on veuille lever cette restriction car un service que l’on utilise (ex: Let’s Encrypt) va utiliser ce subnet, hors s’il est filtré, le service risque de ne pas fonctionner correctement.

À l’inverse, on peut se rendre compte que certaines règles en place ne reflètent plus la production, voire, ne sont plus utilisées du tout, et il est donc important de “faire le ménage” régulièrement.

Surveiller, agréger, alerter

Comme tout équipement dans notre infrastructure, notre, ou plutôt nos pare-feux (haute disponibilité oblige) doivent être monitorés correctement.

Supervision

Bien évidemment, on voudra récupérer les métriques “habituelles”: CPU, RAM, entrées/sorties réseau, QoS, etc.

Il peut être intéressant aussi de vérifier l’efficacité de nos règles de filtrage:

11G  650G DROP  0 --  * *  0.0.0.0/0    0.0.0.0/0   match-set singapore src

Comme on peut le voir ci-dessus, le filtrage en entrée des utilisateurs (enfin, des bots...) en provenance de Singapour a bloqué 11 milliards de paquets depuis le dernier reboot de cette machine, totalisant 650Go de trafic (il s’agit de simples requêtes HTTP). On voit ici (surtout que des machines similaires, il y en a 4) que ce blocage - ainsi que plusieurs autres - est efficace dans notre cas (plateforme web à destination de l’Europe), bloquant à l’arrivée le trafic à 99.999% illégitime en provenance de ce pays.

Ce genre de métrique peut permettre de vérifier le bon fonctionnement de nos règles, mais aussi nous indiquer de potentiels comportements anormaux (par exemple un fort trafic à destination d’un service à usage interne de l’entreprise).

Agrégation de logs

De la même manière, l’agrégation des journaux de connexion de nos pare-feux peut là aussi permettre de nous alerter d’un comportement anormal voire d’une tentative d’intrusion. Plusieurs solutions existent afin d’extraire et visualiser au mieux ces informations.

Par exemple ci-dessous, nous agrégeons les journaux de connexion en entrée de notre réseau et nous trions par AS (Autonomous System):

On voit tout de suite qu’Amazon AWS fait quasiment autant de trafic qu’Orange. Il est donc fort probable que cet AS soit utilisé par des bots de scraping IA et que ce trafic est au mieux gênant (il utilise des ressources dont les utilisateurs légitimes sont dès lors privés) voire potentiellement nuisible.

Il existe de nombreuses solutions d’agrégation de logs, parmi lesquelles:

• ELK
• Graylog
• Loki + Grafana

NIDS : Network Intrusion Detection System

Il peut aussi être pertinent de coupler nos pare-feux à une solution de détection d’intrusion réseau comme Suricata, Snort, etc. Le but étant là encore d’être alerté le plus rapidement possible de tout comportement anormal afin de pouvoir y remédier en un minimum de temps.

Alertes

Bien évidemment, si nos différents systèmes de supervision ne nous alertent pas lorsqu’un incident survient… ils ne vont pas nous servir à grand chose! Il est donc primordial de mettre en palce un système d’alerte (SMS, “chat” type Slack, etc) afin d’être avertis dès qu’une anomalie est détectée par nos systèmes. Notre réactivité peut faire la différence entre une simple correction et une compromission du système d’information!

Backup!

Comme pour tout élément de notre système d’information, il est essentiel d’avoir une politique de sauvegarde des éléments de configuration et des règles de nos pare-feux.

Suivant l’outil utilisé, cette procédure peut varier. Concernant iptables et ipset par exemple, quelques commandes exécutées quotidiennement via cron peuvent “faire le job”:

iptables-save > iptables.$(date +%s).rules
ip6tables-save > ip6tables.$(date +%s).rules
ipset save > ipset.$(date +%s).conf

Concernant des appliances dédiées type stormshield ou autres, consultez la documentation fournisseur.

Exemples de Pare-feux

Linux

Netfilter

(source: Wikipedia, Jan Engelhardt)

Netfilter est le pare-feu intégré au noyau Linux depuis la version 2.4 du kernel. C’est la base sur laquelle sont construites les différentes solutions de pare-feu disponibles sous Linux. Il fonctionne sur les couches 2, 3 et 4 du modèle OSI (Liaison, Réseau et Transport, donc) et 1,2 et 3 du modèle TCP/IP.

Il utilise les modules suivants du noyau:

iptables

iptables (et ip6tables pour IPv6) est un utilitaire permettant de manipuler les tables ip_tables du kernel. C’est un composant legacy qui doit à terme être remplacé par nftables. Cependant, des années d’utilisation d’iptables ont bien ancré la syntaxe de cet utilitaire dans le cerveau de pas mal d’administrateurs systèmes et réseaux (dont votre humble serviteur) au point qu’il existe iptables-nft, une surcouche de nftables utliisant la syntaxe d’origine d’iptables et produisant les règles nftables correspondantes.

iptables utilise plusieurs tables (filter - par défaut -, nat et mangle) contenant plusieurs chaînes (INPUT, FORWARD, OUTPUT par exemple) qui elles-mêmes vont contenir les règles à appliquer au trafice entrant, sortant ou transféré.

Note: ipset

ipset permet de résoudre un problème de taille. Imaginons que nous voulions bannir un grand nombre de sous-réseaux (par exemple, les sous-réseaux d’un Système Autonome (AS) utilisé pour des tentatives d’attaques par déni de service). Si nous utlisons les mécanismes de base de nos pare-feux, nous risquons donc de remplir les tables de nos pare-feux de dizaine de milliers de lignes. Ce qui veut dire que chaque paquet légitime traité devra passer plusieurs dizaines de milliers de conditions avant d’arriver à une condition le validant et le laissant donc “passer”. Multiplions ça par quelques centaines de milliers de paquets par seconde, et nous avons une belle recette d’auto-déni de service.

ipset permet de construire des tables de hashage (appelées listes) contenant un grand nombre d’éléments (65536 par liste, sachant qu’on peut utiliser plusieurs listes) qu’il est capable de parcourir extrêmement rapidement. Il fournit un module iptables permettant, en une règle iptables, de vérifier si une IP n’appartient pas à une liste ipset. Ainsi, on peut facilement appliquer une règle iptables à tout un AS, voire, à tout un pays, sans créer des dizaines de milliers de lignes dans nos chaînes iptables.

Note: nftables

nftables est le remplaçant d’iptables. Il est disponible depuis la version 3.14 du kernel (2014). Sa syntaxe plus verbeuse que celle d’iptables permet néanmoins plus de flexibilité: nftables incorpore des structures avancées telles que des dictionnaires, des mappings et autres n’existant pas avec l’utilitaire iptables seul.

UFW

Uncomplicated FireWall est là aussi une surcouche de netfilter, utilisée notamment par la distribution Ubuntu, simplifiant l’utilisation de netfilter notamment grâce à une syntaxe plus simple que celle d’iptables.

BSD

Sous les UNIX de la branche BSD (Berkeley Software Distribution), on retrouve plusieurs pare-feux, notamment:

• OpenBSD PF (Packet Filter), une référence
• IPF (IP Filter)
• IPFW (IP FireWall)

Windows

Microsoft Windows implémente lui aussi un pare-feu, Windows Firewall, depuis Windows XP SP2. Il fonctionne sur le même concept que les pare-feux des autres systèmes d’exploitation en ajoutant une notion de profils:

• Le profil public, le plus restrictif
• Le profil privé, plus permissif car il part du principe que l’on se trouve dans un LAN raisonnablement sécurisé
• Le profil de domaine, lorsque le poste est joint à un domaine et qu’il se trouve sur un réseau de confiance lié à ce domaine

Appliances logicielles (semi-)propriétaires et open-source

Les routeurs logiciels bien connus:

• PFSense (pas libre)
• OPNSense (libre)

disposent d’un pare-feu - de mémoire OpenBSD PF - ainsi que d’une interface graphique de gestion permettant de créer, modifier et supprimer les différentes règles de contrôle d’accès aux réseaux auxquels ces appliances sont connectées.

Appliances propriétaires

Il s’agit de matériels dédiés, offrant une couche logicielle généralement propriétaire.

• Stormshield
• Palo-Alto Networks
• Fortinet

TP 1: Découverte d’iptables et ipset

Normalement, nous avons créé trois VMs:

• Une VM de routage (probablement OPNSense)
• Une VM pour nos conteneurs
• Une VM Base de données.

Nous allons nous concentrer sur notre VM de base de données.

En effet, une stratégie de pare-feu ne s’arrête pas à l’entrée et à la sortie de nos réseaux: on voudra mettre en place une défense en profondeur et donc configurer correctement les pare-feux intégrés à tous les hôtes de nos réseaux, le but étant de s’assurer que seuls les communications autorisées sont permises entre les hôtes de nos réseaux.

Par exemple, dans le cas de notre base de données, notre routeur doit-il pouvoir communiquer directement avec le port de notre base de données?

Nous allons donc établir une première matrice de flux, puis ensuite configurer correctement le pare-feu de cette VM via iptables.

De la même façon, lorsqu’on utilise des charges de travail conteneurisées et notamment dans l’environnement Kubernetes, on voudra mettre en place des stratégies réseau (Network Policies) définissant quelles connexions sont autorisées entre conteneurs (et pods dans le cas de kubernetes). Par exemple, je ne voudrais pas que les charges de travail du namespace “client1” de mon cluster kubernetes puissent dialoguer avec les charges de travail du namespace “client2” pour des raisons évidentes de sécurité et de confidentialité.

Pour la configuration d’iptables, je vous invite à suivre ce lien: https://wiki.lidstah.info/en/linux/shell-basics#netfilteriptables

TP 2: Mise en place d’une stratégie de pare-feu à l’échelle de notre petite infrastructure

Matrice de flux et planification

• Identifiez correctement tous les flux internes et externes de notre petite infrastructure
• définissez la matrice de flux correspondante
• définissez les règles à mettre en place (routeur, hôtes) pour correspondre à la matrice de flux.

Mise en place

Mettez en place sur le routeur et les hôtes de votre petite infrastructure les règles définies précédemment.

Vérification

Vérifions la bonne application de nos règles de filtrage.