Protéger un réseau d'entreprise
14/04/2006
Résumé
Le Firewall permet de protéger un réseau des attaques extérieures, si il n'est pas suffisant en lui-même, il est un des éléments indispensable pour protéger l'accès au réseau de l'entreprise.
Table des matières
Un firewall est un dispositif de protection qui permet de filtrer (accepter, rejeter, modifier) les paquets IP à destination d'un hôte ou d'un réseau. Les firewalls traditionnels s'appuient exclusivement sur les éléments de l'en-tête IP, presque toujours uniquement les adresses, pour prendre leurs décisions de routage. Quel que soit le type de firewall, les décisions de filtrage sont rédigées sous forme de liste de contrôle d'accès. Au bout du processus de filtrage il ne peut y avoir qu'une alternative : le paquet est autorisé à passer ou il n'est pas autorisé à passer.
Mais pourquoi donc se fatiguer à implémenter un firewall le plus efficace possible ? Y a-t-il des données si importantes et secrètes que ça à dissimuler ? Qu'est ce qui vaut vraiment la peine d'être protégé au prix d'un effort non négligeable ? Les réponses sont multiples, mais il y a quelques pistes que nous pouvons évoquer :
Le dysfonctionnement du réseau interne sans parler de l'accès à l'extérieur : un acte d'intrusion sur les machines du réseau local peut se traduire par une incapacité partielle ou totale du réseau à bien fonctionner. Ces perturbations peuvent nuire au bon fonctionnement de l'organisation, voire bloquer des fonctions qui ne sont pas, a priori, en rapport direct avec le système d'information comme la gestion des accès à des salles protégées ou la possibilité de faire des photocopies.
La perte de données est toujours un des risques lié à l'intrusion : en plus de perturber le bon fonctionnement du réseau, qu'est-ce qui empêche un intrus d'effacer les données auxquelles il pourra avoir accès ? Il peut s'agir de données importantes pour la survie de l'organisation, comme les données comptables ou les fichiers clients, mais ce peut être plus insidieux. Un certain nombre de fichiers sont importants pour la sécurité ou le bon fonctionnement du réseau et de ses applications : une altération de la base DNS peut conduire à des résultats catastrophiques.
Le vol de données est aussi un risque non négligeable, même si au sein d'une organisation il peut ne pas y avoir d'informations vraiment confidentielles, la divulgation d'informations liées à des projets en cours ou à la santé financière de l'organisation peut donner un avantage concurrentiel non négligeable à une société du même secteur.
La responsabilité civile ou pénale des responsables de l'organisation peut être engagée en cas d'utilisation des ressources du réseau par un pirate pour attaquer d'autres réseaux. Les responsables du réseau attaquant peuvent être poursuivis pénalement si il est prouvé qu'ils n'ont pas pris les précautions élémentaires pour enpêcher ce type de prise de contrôle. Ce genre de situation se retrouve dans les attaque de type Distributed Denial of Service (DDoS).
La liste des types de firewalls présentés ici n'est pas exhaustive, elle permet simplement d'avoir une vue d'ensemble des opérations qu'un firewall peut effectuer. Nous n'envisagerons également que les types de firewalls qui agissent au niveau des couches 3 et 4 du modèle OSI. Les firewalls applicatifs sont trop liés à un type de service donné pour faire l'objet d'un cours générique.
Si ils sont efficaces pour protéger la plupart des ressourcese d'un réseau, les firewalls présentés ici ne permettent pas de prendre en compte les données applicatives utilisées, ils n'agissent pas sur :
Les adresses URL vers des sites non autorisés
Les virus qui peuvent transiter sur les protocoles applicatifs
Les courriels non sollicités (spam, junk mail,...)
...
C'est le rôle d'autres applicatifs dans la chaîne de sécurité d'assurer ces fonctions, comme un scanner anti-virus associé à un serveur de messagerie ou à un proxy HTTP.
Des points de communication sont nécessaires entre le réseau de l'organisation et l'extérieur, que ce soit pour accéder à des services ou pour en fournir. La plupart du temps les services standards demandant une haute disponibilité et de forts volumes de transactions sont hébergés par des sociétés spécialisées dans ce type de prestation, mais il reste toujours un certain nombre de services qui peuvent être hébergés localement, que ce soit pour des raisons de confidentialité, de commodité ou autres. La DMZ est la partie du réseau qui est ouverte vers l'extérieur elle n'héberge que les machines et les services qui doivent être exposés au public pour des raisons de communication externes. Typiquement on trouve dans la DMZ :
Le serveur DNS
Les serveurs de messagerie
Les serveurs WEB pour les applications ouvertes à l'extérieur
Les serveurs FTP pour les documents à communiquer à l'extérieur
Les serveurs d'annuaire qui contiennent des informations publiques
Et plus généralement tous les serveurs qui contiennent des informations à diffuser ou des services à offrir au public.
On n'y trouve surtout pas :
Les serveurs de fichiers.
Les serveurs de base de données.
Les serveurs de sécurité (Kerberos, annuaires LDAP complets).
Les serveurs DNS qui révèlent la strucure interne du réseau.
Et plus généralement tous les serveurs qui contiennent des informations confidentielles.
Dans le contexte d'une DMZ, le firewall a pour rôle de réguler les flux entre :
Le réseau externe et la DMZ
Le réseau interne et le réseau externe
La DMZ et le réseau interne
Depuis la version de noyau 2.4, Linux utilise les mécanismes NetFilter, ils permettent de réaliser un filtrage sophistiqué au niveau IP, mais aussi sur les protocoles de couche 4 (TCP, UDP), voire sur les en-têtes de couche 2 (MAC Address). En dehors des opérations de filtrage netfilter est capable, de base, d'effectuer des opérations assez sophistiquées en matière de NAT ou de PAT, voire de marquage de paquets pour gérer la QOS ou contrôler l'usage de la bande passante.
Le processus netfilter analyse les paquets entrant ou sortants et prend ses décisions en fonction des informations contenues dans les paquets : adresses IP, protocoles encapsulés, ports TCP ou UDP, type ICMP, état de la connexion... Dans le cas du filtrage de paquet, netfilter utilise trois chaînes de règles différentes selon l'origine et/ou la destination des paquets IP :
La machine reçoit une paquet IP et l'adresse de destination est une des adresses allouée aux interfaces de la machine : le paquet est transmis à la chaîne INPUT qui va l'analyser et appliquer les règles qui décideront de son sort.
Le paquet est émis par un processus interne de la machine (client ou serveur), il est analysé par la chaîne OUTPUT qui décidera de son sort.
La machine reçoit un paquet IP, l'adresse de destination du paquet n'est pas une des adresses des interfaces de la machine et le routage (ip forwarding) n'est pas activé : le paquet est détruit.
La machine reçoit un paquet IP, l'adresse de destination du paquet n'est pas une des adresses des interfaces de la machine et le routage (ip forwarding) est activé : le paquet est transmis à la chaîne FORWARD qui va l'analyser et décider de son sort.
Le processus netfilter analyse aussi le paquets émis par un processus interne de la machine, ces paquets sont systématiquement analysés par la chaîne OUTPUT. Le graphique ci-dessous montre le positionnement des différents filtres, sur ce schéma l'entrée et la sortie désignent une interface physique ou logique, peu importe leur nombre en réalité.
Netfilter utilise trois tables de règles différentes pour selon le type d'opération :
filter est la table par défaut qui contient toutes les opérations relatives à l'analyse et à l'acceptation ou au rejet de paquets en fonction de leurs caractéristiques. filter utilise les chaînes de règles
INPUT,OUTPUTetFORWARDprésentées ci-dessus.nat est la table qui permet de modifier l'adresse source et/ou l'adresse de destination de paquets, ainsi qu'éventuellement les ports des protocoles de niveau 4. Les règles de la table nat ne permettent pas d'accepter ou de rejeter un paquet.
mangle est la table utilisée pour altérer les caractéristiques d'un paquet IP comme le champ TOS pour gérer la QOS et/ou prioritiser les flux. Comme pour la table nat les règles de la table mangle ne permettent pas de prendre de décision sur l'acceptation ou le rejet de paquets.
Les interactions entre les différentes tables et la façon de les utiliser seront décrite plus tard. Pour l'instant seules sont envisagées les règles liées à la table filter.
Pour le reste de l'introduction à netfilter, nous utiliserons le schéma de réseau suivant :
Le firewall Linux est placé entre la "DMZ" et le réseau LAN proprement dit. On considère comme interface interne celle qui est reliée au réseau LAN et comme interface externe celle qui est reliée à la DMZ.
L'outil iptables permet d'effectuer l'ensemble des opérations nécessaires à la gestion d'un firewall netfilter. Pour l'instant on n'utilisera iptables que pour agir sur la table filter qui contient les règles de filtrage des paquets, c'est la table par défaut. iptables permet également d'agir sur les tables nat pour modifier l'adresse source ou destination ainsi qu'éventuellement les ports. La table mangle permet quand à elle d'altérer l'état du paquet et d'introduire des notions de QOS.
Quelques commandes de base permettent de régler les paramètres de comportement de netfilter, de lister les règles ou de les effacer. Voici les paramètres de configuration :
-Ncrée une nouvelle chaîne-Xeffacer une chaîne vide-Pchanger la règle par défaut d'une chaîne-Fvider les règles d'une chaîne (pas la règle par défaut)-Lafficher les règles d'une chaîne-Zremettre à zéro les compteurs d'une chaîne
Voici un exemple d'utilisation des commandes de base :
durin:~# iptables -LChain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination durin:~# iptables -P FORWARD DROP
durin:~# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP)
target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
| | Liste des chaînes de règles |
| | La règle par défaut de la chaîne |
| | Le résultat de la modification de la règle par défaut est visible dans la liste des règles |
Les filtres simples ne permettent de prendre de décision que sur les adresses IP. Par principe on interdit d'abord tous les flux, puis on n'autorise que ceux qui sont considérés comme licites. L'interdiction a priori a une conséquence : il faut ouvrir les flux dans les deux sens (cette pratique est valable pour l'ensemble des règles de filtrage).
L'exemple suivant décrit des règles de filtrage fondées uniquement sur les adresses IP et/ou sur les interfaces. Un filtre qui ne se base que sur les adresses ip est relativement facile à écrire, mais il faut d'abord définir les objectifs à atteindre :
Le firewall n'est pas autorisé à dialoguer sur son interface externe
Le serveur SGBD ne peut discuter qu'avec les machines du réseau interne et le serveur web
Les machines du réseau LAN ne sont autorisées à dialoguer qu'avec les machines de la DMZ
Pour atteindre ces objectifs, bien modestes, il faut sur le firewall :
Activer le routage
Construire la table de routage
Tout interdire par défaut
Modifier la chaîne INPUT
Modifier la chaîne OUTPUT
Modifier la chaîne FORWARD
Ce qui donne le script suivant :
#!/bin/bash echo -n 1 > /proc/sys/net/ipv4/ip_forwardiptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -i $LOOPBACK -j ACCEPT
iptables -A OUTPUT -o $LOOPBACK -j ACCEPT iptables -A INPUT -i $INTERNAL -j ACCEPT
iptables -A OUTPUT -o $INTERNAL -j ACCEPT iptables -A FORWARD -s 192.168.1.2 -d 192.168.2.4 -j ACCEPT
iptables -A FORWARD -s 192.168.2.4 -d 192.168.1.2 -j ACCEPT iptables -A FORWARD -s 192.168.2.4 -j DROP
iptables -A FORWARD -d 192.168.2.4 -j DROP iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -d 192.168.1.0/24 -j ACCEPT
| | Activation des fonctionnalités de routage dans le noyau Linux. |
| | Avant toute chose il faut vider toutes les listes de règles pour annuler d'éventuelles configuration pré-existantes. |
| | Définir les interfaces internes et externes de façon générique permet de rendre le script plus adaptable. |
| | Tout interdire par défaut permet de s'assurer que seuls les flux autorisés passeront (la règle par défaut est de tout accepter). |
| | On accepte tous les flux sur les interfaces de loopback : la machine se fait confiance à elle-même, sinon un grand nombre de communications inter-processus locales risquent d'être mises à mal. |
| | Le firewall est autorisé à dialoguer uniquement avec les machines du réseau LAN. |
| | Le firewall accepte les flux en provenance du serveur web et à destination du serveur de bases de données. La ligne du dessous réalise l'opération inverse. |
| | Tout autre flux entre le serveur SGBD et la DMZ est interdit, cette règle est nécessaire à cause de la règle suivante qui ouvre tous les flux entre le réseau local et la DMZ. |
| | Ouverture de tous les flux entre la DMZ et le réseau local. |
On aperçoit vite les limites d'un filtrage basé uniquement sur les adresses : dans le cas du serveur SGBD qui supporte également des services de fichiers, on laisse également passer les flux NFS et SMB vers la DMZ ce qui n'est en aucun cas souhaitable.
A partir de cet exemple, on peut déduire quelques règles de syntaxe liées à iptables :
-A <chaîne>permet d'ajouter une règle à la fin dechaîne.-i [!] <interface>désigne le nom de l'interface utilisée en entrée par la règle, ce paramètre n'est valable que pour les chaînes INPUT, FORWARD et PREROUTING (chaîne liée à la table nat).-o [!] <interface>désigne le nom de l'interface utilisée en sortie par la règle, ce paramètre n'est valable que pour les chaînes OUTPUT, FORWARD et POSTROUTING (chaîne liée à la table nat).-s [!] adresse[/masque]spécifie l'adresse source de la machine visée par la règle, si le masque (notation CIDR ou décimale pointée au choix) est présent la source désigne un réseau.-d [!] adresse[/masque]spécifie l'adresse de destination de la machine ou du réseau visé par la règle.-j <cible>spécifie le sort du paquet, si ce paramètre n'est pas spécifié les compteurs liés à la règle sont incrémentés, mais aucune action n'est entreprise et le sort du paquet dépendra des règles suivantes. La cible peut être terminale, une décision est prise et le traitement s'arrête là, effectuer une action particulière ou renvoyer vers une autre chaîne. De base il y a deux cibles, terminales toutes les deux :DROPqui abandonne le paquet ouACCEPTqui accepte le paquet.
![[Important]](images/important.png) | À retenir |
|---|---|
Même si il existe des commandes pour supprimer( Dans les paramètres, lorsqu'il est autorisé le Si on a utilisé la règle par défaut qui consiste à refuser a priori tout trafic, il ne faut pas oublier d'ouvrir les flux dans les deux sens : il ne sert pas à grand chose de pouvoir en envoyer des paquets à un hôte si on n'accepte pas les paquets de réponse en retour. D'autre part il ne faut pas oublier d'ouvrir les flux sur l'interface de loopback sous peine de voir certaines applications locales cesser de fonctionner correctement. |
D'après l'exemple ci dessus, un filtre plus efficace consisterait à ajouter quelques précisions aux règles présentées plus haut :
On sait que les serveur de Bases de Données utilise MySQL qui attend les clients sur le port tcp 3306.
Les autres machines du réseau LAN ne peuvent que se connecter à des services dans la DMZ, les machines de la DMZ n'ont pas le droit de se connecter sur des services offerts par les machines du LAN : les machines du lan peuvent envoyer un trafic vers tous les ports tcp et udp des machines de la DMZ (0 à 65535), les machines de la DMZ n'ont le droit d'envoyer une trafic vers le LAN uniquement sur les ports tcp et udp éphémères du LAN (1024 à 65535).
Ces contraintes supplémentaires donnent le script suivant :
#!/bin/bash echo -n 1 > /proc/sys/net/ipv4/ip_forward iptables -F INTERNAL=eth0 EXTERNAL=eth1 LOOPBACK=lo iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP iptables -A INPUT -i $LOOPBACK -j ACCEPT iptables -A OUTPUT -o $LOOPBACK -j ACCEPT iptables -A INPUT -i $INTERNAL -j ACCEPT iptables -A OUTPUT -o $INTERNAL -j ACCEPT iptables -A FORWARD -s 192.168.1.2 -d 192.168.2.4 -p tcp --dport 3306 -j ACCEPT
| | Au niveau du serveur de bases de données, seuls les flux depuis et vers le service MySQL (port tcp 3306) sont autorisés en entrée et en sortie du réseau local pour le serveur de bases de données. |
| | Pour les autres machines du réseau local seules sont autorisées les sorties à destination de la DMZ vers des services bien connus (ports compris entre 0 et 1023). On remarquera qu'il a fallu doubler les règles : un couple de règles pour tcp et un groupe de règele pour udp. Il faut noter qu'avec ces nouvelles règles, les flux icmp sont stictement interdits. |
Éléments complémentaires sur la syntaxe de l'outil iptables :
-p [!] <protocole>spécifie le protocole encapsulé dans le paquet IP, protocole peut prendre ses valeurs danstcp,udp,icmpouall--sport [!] port[:port]spécifie un port ou une plage de ports (port1:port2) à la source d'un segment tcp ou udp--dport [!] port[:port]spécifie un port ou une plage de ports (port1:port2) de destination d'un segment tcp ou udp
| À retenir |
|---|---|
Dès lors que l'on spécifie un protocole encapsulé dans le paquet IP, la règle ne s'applique qu'à ce seul protocole, si on veut que tous les protocoles passent, il faut une règle par protocole encapsulé. |
Pour mieux comprendre la suite, voici un petit rappel sur les en-têtes TCP :
Les différents bits d'état sont organisés de la façon suivante :
Le processus netfilter est capable de travailler sur l'état des segments transportés : soit en analysant les bits d'état des segments, soit en utilisant un mécanisme de suivi des connections (conntrack). L'analyse des bits d'état des segments permet de diagnostiquer si il s'agit d'un paquet valide et dans le cas de TCP si il s'agit des suites d'une connexion ou d'une demande d'établissement de connexion. Dans le cas de la demande de connexion, netfilter s'appuie sur la connexion en trois phase de TCP dont le schéma ci-dessous rappelle le principe :
Lors de la demande de connexion seul le bit syn est positionné pour mémoire
Un routeur filtrant transparent permet d'intercaler un dispositif de filtrage au sein d'un réseau sans que les clients en aient conscience. Ce dispositif permet de filtrer le trafic et de protéger plus particulièrement certains équipements du réseau