Pare-feu informatique ou Firewall

Un pare-feu vise à créer un (sous-)réseau ou une 'zone' sur : une zone démilitarisée ( anglais demilitarized zone, abrévation DMZ).

Si vous êtes sous un routeur IPV4, avec un sous réseau, et sur un réseau sûr, vous n'aurez pas besoin de pare-feu.

Si vous êtes sur un modem IPV6, par exemple en cochant l'ipv6 sur une freebox en dégroupé, ou en modem Adsl directe, ou modem rtc vous avez besoin d'un pare feu, bien configuré.

De nos jours l'on met également en place des réseaux sécurisés, des vpn, et des connexions sécurisées : dans ces cas là l'utilité du pare-feu sur chaque machine est moindre, bien qu'il faille toujours un pare-feu pour sécuriser l'entrée/sortie du réseau.

Donc, tout dépendra de la politique informatique mise en place au sein du réseau de l'entreprise.

Un pare-feu est parfois appelé coupe-feu, garde-barrière, barrière de sécurité, ou encore firewall en anglais. Dans un contexte OTAN, un pare-feu est appelé Périphérique de protection en bordure (en anglais : Border Protection Device, ou BPD). Dans un environnement BSD, un pare-feu est aussi appelé packet filter.

L'usage du terme « pare-feu » en informatique est donc métaphorique : une porte empêchant les flammes de l'Internet de rentrer chez soi et/ou de « contaminer » un réseau informatique.

Le pare-feu était jusqu'il y a quelques années considéré comme une des pierres angulaires de la sécurité d'un réseau informatique , mais il perd en importance au fur et à mesure que les communications basculent vers des connexions sécurisé SSL SSH, VPN, ne nécessitant que du routage précis. Il permet d'appliquer une politique d'accès aux ressources réseau (serveurs).

Il a pour principale tâche de contrôler le trafic entre différentes zones de confiance, en filtrant les flux de données qui y transitent. Généralement, les zones de confiance incluent Internet (une zone dont la confiance est nulle), et au moins un réseau interne (une zone dont la confiance est plus importante.)

Le but ultime est de fournir une connectivité contrôlée et maîtrisée entre des zones de différents niveaux de confiance, grâce à l'application de la politique de sécurité et d'un modèle de connexion basé sur le principe du moindre privilège.

Le filtrage se fait selon divers critères. Les plus courants sont :

• l'origine ou la destination des paquets (adresse IP, ports TCP ou UDP, interface réseau, etc.) ;
• les options contenues dans les données (fragmentation, validité, etc.) ;
• les données elles-mêmes (taille, correspondance à un motif, etc.) ;
• les utilisateurs pour les plus récents.

Un pare-feu fait souvent office de routeur et permet ainsi d'isoler le réseau en plusieurs zones de sécurité appelées zones démilitarisées ou DMZ. Ces zones sont séparées suivant le niveau de confiance qu'on leur porte.

Enfin, le pare-feu est également souvent extrémité de tunnel IPsec ou SSL. L'intégration du filtrage de flux et de la gestion du tunnel est en effet nécessaire pour pouvoir à la fois protéger le trafic en confidentialité et intégrité et filtrer ce qui passe dans le tunnel. C'est le cas notamment de plusieurs produits du commerce nommés dans la liste ci-dessous.

Les pare-feu sont un des plus vieux équipements de sécurité informatique et, en tant que tel, ils ont été soumis à de nombreuses évolutions. Suivant la génération du pare-feu ou son rôle précis, on peut les classer en différentes catégories.

C'est le plus vieux dispositif de filtrage réseau, introduit sur les routeurs. Il regarde chaque paquet indépendamment des autres et le compare à une liste de règles préconfigurées. Ces règles peuvent avoir des noms très différents en fonction du pare-feu :

• « ACL » pour Access Control List (certains pare-feu Cisco),
• politique ou policy (pare-feu Juniper/Netscreen),
• filtres,
• Règles ou rules
• etc.

La configuration de ces dispositifs est souvent complexe et l'absence de prise en compte des machines à états des protocoles réseaux ne permet pas d'obtenir une finesse du filtrage très évoluée. Ces pare-feu ont donc tendance à tomber en désuétude mais restent présents sur certains routeurs ou systèmes d'exploitation.

Certains protocoles dits « à états » comme TCP introduisent une notion de connexion. Les pare-feu à états vérifient la conformité des paquets à une connexion en cours. C’est-à-dire qu'ils vérifient que chaque paquet d'une connexion est bien la suite du précédent paquet et la réponse à un paquet dans l'autre sens. Ils savent aussi filtrer intelligemment les paquets ICMP qui servent à la signalisation des flux IP.

Enfin, si les ACL autorisent un paquet UDP caractérisé par un quadruplet (ip_src, port_src, ip_dst, port_dst) à passer, un tel pare-feu autorisera la réponse caractérisée par un quadruplet inversé, sans avoir à écrire une ACL inverse. C'est fondamental pour le bon fonctionnement de tous les protocoles fondés sur l'UDP, comme DNS par exemple. Ce mécanisme apporte en fiabilité puisqu'il est plus sélectif quant à la nature du trafic autorisé. Cependant dans le cas d'UDP, cette caractéristique peut être utilisée pour établir des connexions directes (P2P) entre deux machines (comme le fait Skype par exemple).

Dernière mouture de pare-feu, ils vérifient la complète conformité du paquet à un protocole attendu. Par exemple, ce type de pare-feu permet de vérifier que seul du HTTP passe par le port TCP 80. Ce traitement est très gourmand en temps de calcul dès que le débit devient très important; il est justifié par le fait que de plus en plus de protocoles réseaux utilisent un tunnel TCP pour contourner le filtrage par ports.

Une autre raison de l'inspection applicative est l'ouverture de ports dynamique. Certains protocoles comme le fameux FTP en mode actif échangent entre le client et le serveur des adresses IP ou des ports TCP/UDP. Ces protocoles sont dits « à contenu sale » ou « passant difficilement les pare-feu » car ils échangent au niveau applicatif (FTP) des informations du niveau IP (échange d'adresses) ou du niveau TCP (échange de ports). Ce qui transgresse le principe de la séparation des Couches réseaux. Pour cette raison, les protocoles « à contenu sale » passent difficilement voire pas du tout, les règles de NAT dynamiques, à moins qu'une inspection applicative ne soit faite sur ce protocole.

Chaque type de pare-feu sait inspecter un nombre limité d'applications. Chaque application est gérée par un module différent pour pouvoir les activer ou les désactiver. La terminologie pour le concept de module est différente pour chaque type pare-feu :

• l7 Filter (filtrage applicatif) sur Linux Netfilter

Un pare-feu identifiant réalise l’identification des connexions passant à travers le filtre IP. L'administrateur peut ainsi définir les règles de filtrage par utilisateur et non plus par adresse IP ou adresse MAC, et suivre l'activité réseau par utilisateur. Plusieurs méthodes différentes existent qui reposent sur des associations entre IP et utilisateurs réalisées par des moyens variés. On peut par exemple citer authpf (sous OpenBSD) qui utilise ssh pour faire l'association. Une autre méthode est l'identification connexion par connexion (sans avoir cette association IP=utilisateur et donc sans compromis sur la sécurité), réalisée par exemple par la suite NuFW, qui permet d'identifier également sur des machines multi-utilisateurs.

On pourra également citer Cyberoam qui fournit un Pare-feu entièrement basé sur l'identité (en réalité en réalisant des associations adresse MAC = utilisateur) ou Check Point avec l'option NAC Blade qui permet de créer des règles dynamiques basée sur l'authentification Kerberos d'un utilisateur, l'identité de son poste ainsi que son niveau de sécurité (présence d'antivirus, de patchs particuliers).

• NuFW Pare-feu identifiant sous licence GPL pour la partie serveur et les clients Linux, FreeBSD et Mac OS. NuFW est basé sur Netfilter et en augmente les fonctionnalités.

Les pare-feu personnels, généralement installés sur une machine de travail, agissent comme un pare-feu à états. Bien souvent, ils vérifient aussi quel programme est à l'origine des données. Le but est de lutter contre les virus informatiques et les logiciels espions.

• ufw : Uncomplicated Firewall
  • Gufw (conseillé): Interface graphique de Uncomplicated Firewall (ufw)
• iptables - Netfilter & Iptables
  • FireStarter
  • KMyFirewall (kde)
  • Guarddog (site) développement stoppé.

• FirewallBuilder (site) : Firewall Builder est une interface graphique pour créer facilement des règles iptables - et administrer diffèrent firewall/machine du réseau.

Application console :

• shorewall - Configuration de Netfilter simplifiée
• Firetable (site)
• Arno's IPTABLES firewall script (site) : est un firewall pour des servuer à la fois mono ou multi-hébergement/service.
• ferm ("For Easy Rule Making") (site) : outil pour maintenir des pare-feu complexes. La configuration du pare-feu ressemble structuré comme un langage de programmation, qui peuvent contenir des niveaux et des listes.
• Firehol (site) : est un langage pour exprimer des règles de pare-feu, en plus d'être un script qui produit des règle pour le pare-feu.
• gShield (site) : 'Facile' à configurer, bloque tout ce qui n'est pas nécessaire (ou presque) par défaut. Contrôlée par un seul fichier de configuration.
• uruk (site)

Voir la page dédiée aux portails captifs

• Boîtiers pare-feu

Un système de détection d'intrusion (ou IDS : Intrusion Detection System) est un mécanisme destiné à repérer des activités anormales ou suspectes sur la cible analysée (un réseau ou un hôte). Il permet ainsi d'avoir une connaissance sur les tentatives réussies comme échouées des intrusions.

Les NIDS (Network Based Intrusion Detection System), surveillent l'état de la sécurité au niveau du réseau.

• Snort - libre
• Bro (site)

• Enterasys
• Checkpoint
• Tipping Point

Les HIDS (HostBased Intrusion Detection System), surveillent l'état de la sécurité au niveau des hôtes.

• Prelude LML
• OSSEC
• Samhain
• Tripwire (site) : en version open-source et commercial
• AIDE (ids) (site)
• Nabou (site)
• Osiris (site)

Anti rootkit :

• Chkrootkit
• Rkhunter
• lynis

Ces IDS servent, entre autres, à vérifier qu'un système n'a pas été compromis (par un rootkit par exemple). Ils utilisent des sommes de contrôle (MD5, SHA-1, …) des programmes exécutables pour s'assurer qu'ils n'ont pas été modifiés.

Les IDS hybrides, qui utilisent les NIDS et HIDS pour avoir des alertes plus pertinentes.

• Prelude
• OSSIM

Les avantages des IDS hybrides sont multiples :

• Moins de faux positifs
• Meilleure corrélation
• Possibilité de réaction sur les analyseurs (ips)

La corrélation est une connexion entre deux ou plusieurs éléments, dont un de ces éléments créée ou influence un autre. Elle se traduit plus généralement par la transformation d'une ou plusieurs alertes en attaque. Cela permet de faciliter la compréhension sur les attaques au lieu de s'éparpiller parmi les alertes.

Idéalement, elle nécessite un IDS Hybride car plus il y a d'informations hétérogènes sur un évènement, la corrélation se fait d'une façon plus pertinente. Les formats ayant été normalisés (IDMEF), il ne reste plus qu'à faire des associations afin de détecter des alertes qui n'auraient jamais eu lieu sur un analyseur seul.

Si l'on prend l'exemple d'une authentification échouée, cela génère une alerte de faible intensité. Mais s'il y a une série d'authentifications échouées avec des utilisateurs différents, on peut conclure à une attaque de force brute.

La corrélation permet de générer de nouvelles alertes à partir de celles existantes. C'est une étape préalable à une contre-mesure efficace.

Il y a diverses façons de faire de la corrélation. Cependant on peut définir deux catégories :

• La corrélation passive, correspondant à une génération d'alerte basée sur celles existantes. Nous pouvons prendre par exemple les scans de force brute ssh.
• La corrélation active, qui va chercher les informations correspondant à des alertes émises. Par exemple, lorsqu'une personne se connecte en dehors des heures de travail, cela a un impact élevé qui n'aurait pas été en temps normal d'activité.

Ips (Intrusion Prevention System) : on retrouve également des ips réseaux, et des ips hotes.

Le summum du système de détection d'intrusion est bien-sur d'appliquer des règles au pare-feu automatiquement par rapport à ce qui est détecté sur l'hôte et le réseau. Sinon c'est au responsable DSI de s'en charger en cas d'attaque : et il n'est pas h24 en train de surveiller son réseau heureusement pour lui, alors ce qu'il se passe c'est que les attaques sont toujours possibles, et les hackers s'y prennent généralement la nuit ¹⁾.

Cette boucle de retour (feedback) prend un terme spécifique : la contre mesure.

Liste des IPS libre :

• snort inline - IPS réseau
• OSSEC - IPS Hote

Les pare-feu récents embarquent de plus en plus de fonctionnalités, parmi lesquelles on peut citer :

• Filtrage sur adresses IP/Protocole,
• Inspection stateful[2] et applicative,
• Intelligence artificielle pour détecter le trafic anormal,
• Filtrage applicatif
  • HTTP (restriction des URL accessibles),
  • Courriel (Anti-pourriel)
  • Logiciel antivirus, anti-logiciel malveillant
• Traduction d'adresse réseau,
• Tunnels IPsec, PPTP, L2TP,
• Identification des connexions,
• Serveurs de protocoles de connexion (telnet, SSH), de protocoles de transfert de fichier (SCP),
• Clients de protocoles de transfert de fichier (TFTP),
• Serveur Web pour offrir une interface de configuration agréable,
• Serveur mandataire (« proxy » en anglais),
• Système de détection d'intrusion Système & Applicatif & Réseau (« IDS » - « HIDS » et « NIDS » en anglais)
• Système de prévention d'intrusion (« IPS » en anglais)

Lister les services sur la machine :

netstat -ta

Voir la page de openvas.

Voir la liste des outils dans nububunt (8.10).

• Top 100 Network Security Tools
• Network Monitoring Tools (stanford)

Autres Distributions en rapport :

• Backtrack
• Network Security Toolkit ( et ces applications )

Solution basique que l'on retrouve en entreprise, même avec des composants propriétaires.

Choix technologique possible : * Prélude + NUFW + OSSEC + Snort Inline

Le monitoring va ici de soi.

Cas d'utilisation : Serveur web, ou autre service devant utiliser un protocole non sécurisé.

La méthodologie sera de tester votre IPS / HIDS avec les divers outils de test intensif libre, mis à votre disposition.

Si une faille est détectée :

• Créer d'autres règles dans les diverses solutions ( SNort, …)
• Et reboucler.

Une fois votre pare-feu hautement configuré et testé, vous pourrez l'insérer dans votre réseau.

Choix technologique possible : Prelude + Nufw + VPN + SSH + HTTPS + Fail2ban

Cas d'utilisation : toutes les connections sont sécurisées et on autorise que celles là.

Dans l'absolue il est possible de faire accepter une transition du http au https (pour remplacer totalement l'http), pour par exemple des solutions d'erp, cms. La gène est nulle pour l'utilisateur ou le client.

Ce n'est bien sur pas la solution possible pour des serveurs web.

• (en) Comparison of firewalls

• Cf Article wikipedia., ( et version anglaise)

• Comment ça marche, un pare-feu ?
• Les Firewalls sur www.frameip.com
• Technologie Stateful Inspection

—-

Contributeurs : Psychederic.