Sécurité des systèmes informatiques/Sécurité informatique/Protection réseau et firewall/Aspects architecturaux

Un livre de Wikilivres.
Sauter à la navigation Sauter à la recherche
Sécurité des systèmes informatiques
Ce modèle

Principes de fonctionnement[modifier | modifier le wikicode]

L'utilisation la plus simple d'un firewall consiste à le placer en coupure sur le lien de sortie vers Internet d'un réseau d'entreprise, en le configurant sur le principe d'une « diode ».

Dans cette architecture, présentée dans la figure suivante, le firewall interdit toutes les connexions entrantes en provenance d'Internet, et autorise seulement les connexions sortantes. Il s'agit dans ce cas des connexions TCP ou UDP. Les autres types de paquets IP sont généralement tous rejetés, quel que soit leur direction. Quelques exceptions sont parfois utiles, notamment pour permettre à certains types de paquets ICMP de fonctionner : il est généralement souhaitable d'autoriser certaines des machines du réseau interne à réaliser des « ping » (c'est-à-dire un échange d'un paquet ICMP echo request sortant et de la réponse ICMP echo reply entrante) afin de permettre un test commode de la connectivité avec le réseau Internet.

Filtrage mis en place par un firewall

Les flux réseaux à destination des interfaces du firewall lui-même font généralement l'objet de règles de filtrage plus précises, n'autorisant que les connexions d'administration provenant du réseau interne sur des ports TCP particuliers (comme SSH par exemple). Le firewall lui-même peut être soit extrêmement discret (ne répondant absolument pas aux demandes de connexion non autorisées1, invisible pour des ping de toute provenance) ce qui est parfois malcommode mais est de plus en plus recommandé du côté en contact avec Internet ; soit un peu plus visible (répondant aux demandes de ping2, répondant aux demandes de connexion non-autorisées par des rejets explicites3) ce qui est notamment utile du côté du réseau local pour limiter le temps d'attente d'une connexion refusée.

Les principaux besoins de sécurité auxquels répond cette configuration sont les suivants :

  • la protection du réseau local, contenant habituellement des postes de travail ou des serveurs n'offrant pas un niveau de sécurité suffisant pour être directement visibles sur Internet (présence de vulnérabilités connues, de services réseau peu protégés, etc.) ;
  • la mise à disposition d'un accès Internet (sortant) grâce à l'utilisation des fonctions de translation d'adresses du firewall, qui permettent à un nombre important de machines du réseau local (typiquement configuré avec un adressage IP privé, non routable) d'accéder à des serveurs publics en utilisant une seule adresse IP publique (généralement celle de l'interface Internet du firewall lui-même) ;
  • le contrôle d'accès en sortie, permettant de préciser les postes de travail ou les serveurs disposant d'un accès à Internet dans l'entreprise ;
  • et enfin, bien que ce ne soit généralement pas un objectif de sécurité explicite de l'organisation, la protection du réseau Internet lui-même contre des attaques provenant du réseau interne (en contrôlant les flux réseau disponibles pour les machines du réseau local, ce qui permet d'interdire un scan de ports sortant par exemple).

Dans cette architecture, tous les équipements connectés au réseau interne sont placés au même niveau de sécurité du point de vue du firewall. Notamment, les flux réseaux internes au LAN ne sont pas contrôlés.

« Niveaux » de sécurité et DMZ[modifier | modifier le wikicode]

Dès que l'on souhaite utiliser une connexion à Internet pour des applications plus avancées se fait ressentir le besoin de disposer de plus d'un niveau de sécurité. La connexion du réseau d'entreprise vers Internet peut impliquer également la mise en place d'un certain nombre de services réseaux visibles depuis Internet : serveur HTTP, serveur de messagerie par exemple. Dans ce cas, les besoins associés à ces serveurs se situent dans un niveau de sécurité nouveau : ils ne bénéficient pas du même niveau de protection que les machines du réseau interne (totalement masquées, mais inatteignables), mais il reste généralement souhaitable de ne pas les exposer directement sur Internet et d'assurer leur protection.

Pour répondre à cette problématique, en utilisant un matériel similaire à celui présenté au 3.1.3.1, on peut envisager d'utiliser deux équipements : un firewall interne et un firewall externe. Le firewall interne est configuré en diode et protège le réseau local tout en lui permettant d'accéder à Internet et aux serveurs publics de l'entreprise. Le firewall externe autorise les connexions entrantes à destination des serveurs publics pour que ceux-ci remplissent leur fonction.

La zone intermédiaire située entre les deux firewall a été baptisée « zone démilitarisée » ou DMZ (demilitarized zone), probablement par analogie avec les zones de terrain situées entre deux frontières. Cette dénomination est restée en usage, même si la mise en œuvre technique a largement évolué.

Niveaux de sécurité multiples

En effet, l'utilisation de deux matériels distincts dans les premières architectures avec DMZ, comme celle présentée figure 8, était tout simplement dûe à la difficulté de disposer de machines disposant de plus deux interfaces réseaux et capables d'exécuter un logiciel firewall. Les capacités techniques des matériels ont rapidement évolué en permettant de s'orienter vers des solutions avec un seul firewall pour la mise en œuvre d'une ou plusieurs DMZ (même si l'utilisation de plusieurs équipements différents a persisté, cette fois-ci pour des raisons de sécurité accrue grâce à la diversification des logiciels). La figure 9 présente une architecture réseau avec une DMZ réalisée en utilisant un seul firewall disposant de 3 interfaces réseau.

Avec une configuration judicieuse de la politique de sécurité du firewall, l'architecture de la figure 9 est équivalente à celle de la figure 8. Le nombre maximal d'interfaces utilisables sur un firewall particulier reste donc un paramètre important qui conditionne les architectures envisageables, et notamment le nombre maximal de DMZ (c'est à dire le nombre maximal de zones de sécurité distinctes utilisables).

Ajout d'une interface réseau pour mettre en place une DMZ

Dans la pratique, ce nombre peut varier couramment entre 2 et 10 environ ; mais ce nombre est parfois beaucoup plus contraint si on prend en considération la vitesse des interfaces (plus de 2 interfaces Gigabit est encore assez rare), le coût des licences logicielles (qui peuvent dépendre du nombre d'interfaces), ou encore la configuration matérielle des machines (la disponibilité ou non de cartes réseaux multi-adapteurs - cartes quad ou bi - peut changer radicalement ce paramètre).

Utilisations pratiques des DMZ[modifier | modifier le wikicode]

Diversification et haute-disponibilité[modifier | modifier le wikicode]

Translation d'adresses[modifier | modifier le wikicode]

Une autre fonctionnalité particulièrement importante des firewall est la translation d'adresses (ou NAT pour Network Address Translation) : c'est la capacité fréquemment associée à ces équipements de transformer les adresses des paquets qui transitent à travers eux, en multiplexant si besoin plusieurs adresses internes sur un ensemble plus réduit d'adresses externes.

Dans le cas d'une translation d'adresses simple impliquant uniquement les adresses IP source des paquets d'une communication, il est ainsi possible grâce au firewall de substituer à une adresse ip du réseau interne une autre adresse ip' appartenant à la plage d'adresses publiques officiellement affectée à l'organisation concernée, suivant le modèle suivant : formule à retranscrire.

Dans le cas où le réseau interne utilise (à juste titre) une plage d'adresse située dans un réseau non-routable (192.168.1.0/24 ou 10.0.0.0/8 par exemple [RFC 1918]), ceci est indispensable pour permettre aux machines du réseau interne de communiquer avec des machines situées sur Internet. Par ailleurs, la substitution étant dynamique, n'importe laquelle des N machines du réseau interne peut utiliser momentanément une adresse publique de manière transparente, le nombre maximal de machine pouvant communiquer simultanément avec l'extérieur étant toutefois limité par la taille de l'espace d'adresses public affecté à la translation d'adresses (P ci-dessus). Un avantage de cette translation basée seulement sur les adresses IP tient au fait que, pendant la période de communication durant laquelle l'adresse publique est affectée à une machine du réseau interne, celle-ci peut également être contactée depuis l'extérieur (si le firewall l'autorise). Toutefois, dans la pratique, ce mode de translation est assez peu utilisé pour les postes de travail du réseau interne, au profit de celui présenté ci-après. Par contre, c'est ce type de translation qui est couramment utilisé pour les serveurs accessibles depuis Internet, mais dans ce cas de manière statique, avec une affectation permanente de l'adresse IP publique à l'adresse IP interne du serveur, généralement en DMZ.

Les adresses IP source des paquets ne sont pas les seuls éléments utilisables pour réaliser une translation d'adresse : il est également possible de jouer sur les numéros de port source TCP ou UDP utilisés dans la mise en œuvre de communications avec ces protocoles. Dans ce cas, la translation d'adresses suit (pour TCP) le schéma suivant, où l'on voit que l'adresse source TCP/IP complète est substituée : formule à retranscrire

Ce multiplexage est surtout naturel vis à vis d'un protocole orienté connexion comme TCP (en se basant sur le port source). Il est également possible sur UDP, dans le cas des protocoles impliquant requête puis réponse (notamment le DNS). Il peut aussi être introduit pour ICMP (surtout pour le ping).

L'intérêt majeur de cette translation, parfois appelée PAT (pour Port Address Translation) est d'offrir des possibilités de multiplexage bien plus larges que dans le cas précédent. En utilisant une seule adresse IP publique (généralement celle de l'interface externe du firewall d'ailleurs) et en jouant sur la large plage de numéro de port source disponible (en théorie, de 1025 jusqu'à 65535 pour TCP ou UDP), il est parfaitement possible de permettre à plusieurs milliers de machines du réseau interne d'accéder simultanément à des serveurs sur Internet par TCP ou UDP. C'est un besoin désormais fréquent compte-tenu de la taille (relativement) réduite de l'espace d'adressage offert par IPv4 (32 bits). Par contre, du fait du mode de translation utilisé, ces machines internes doivent être elles-mêmes à l'origine de la demande de connexion et ne peuvent pas être contactées directement par leurs interlocuteurs depuis Internet, ceux-ci ne pouvant identifier que le firewall.

Ce type de translation d'adresses courant pose parfois des problèmes pour le fonctionnement de certaines applications. L'exemple type est FTP. Dans un échange FTP usuel, si la connexion de contrôle est bien établie à l'initiative du client, les connexions secondaires utilisées pour les transferts de fichiers peuvent être établies à l'initiative du client (mode passif) ou bien du serveur (mode actif), ce dernier mode étant fréquemment le mode par défaut. Dans le cas de la mise en œuvre d'une translation d'adresses, le mode FTP actif ne peut pas fonctionner sans une inspection plus détaillée du déroulement de la connexion par le firewall, ou l'utilisation d'un proxy transparent sur le firewall (ce qui revient un peu au même) pour effectuer un suivi de l'état de la connexion FTP et réagir correctement aux connexions TCP secondaires entrantes. Dans le cas de protocoles courants comme FTP ces fonctionnalités additionnelles sont généralement facilement disponibles, mais cet exemple illustre le fait que la présence du firewall et des fonctions de translation d'adresses ne sont pas anodines ; et les réactions des utilisateurs à ce type de situation sont difficiles à gérer.

Firewall : fonctionnement interne[modifier | modifier le wikicode]

Par rapport au fonctionnement interne d'un firewall, il est utile de préciser un certain nombre d'éléments qui participent au fonctionnement du logiciel et permettent de mieux comprendre et de mieux administrer ces équipements :

  • Tables : chaque firewall capable de réaliser un suivi d'état des connexions gère un certain nombre de tables internes, souvent accessibles à l'administrateur, qui reflètent, à un instant t, les différentes connexions connues gérées par l'équipement. On rencontre notamment :
    • Les tables d’état : pour chaque connexion TCP ou pseudo-connexion UDP autorisée, ces tables identifient l'état de la connexion (en cours d'établissement, établie, interrompue, etc.) et permettent : d'abord d'autoriser les paquets nécessaires, mais également de contrôler, voire d'imposer un déroulement « conforme ».
    • Les tables de translation : qui maintiennent la correspondance entre les adresses privées des machines du réseau interne initiant des connexions vers l'extérieur et les adresses ou les numéros de ports choisis par le firewall pour transformer les paquets avant de les acheminer.
  • Traces : chaque firewall offre des fonctions de surveillance des flux réseau qui le traversent, fréquemment en liaison avec les règles d'autorisation de sa configuration de filtrage qui permettent de tracer (logging) ou non un paquet autorisé ou rejeté. Ces flux peuvent être très volumineux, notamment dans les cas où l'on souhaite conserver le contenu des paquets réseaux ainsi repérés et générer une charge de traitement importante pour le firewall et les systèmes d'administration associés. Les modes de sélection et la voie d'accès, de transport et de traitement des traces sont des points assez important dans le fonctionnement interne du firewall. Les traces sont pourtant très utiles pour confirmer et identifier des attaques et leurs auteurs.
  • Fonctions de normalisation des paquets : outre l'application des règles de filtrage de la politique de sécurité réseau, les firewall réalisent en général également des traitements de normalisation visant à maintenir des flux réseau normaux dans le trafic qu'ils font transiter. Ceci peut parfois impliquer des règles de normalisation un peu brutales (comme le rejet des paquets fragmentés par exemple) dont il est utile de connaître l'existence. Dans la pratique, pour les logiciels les plus répandus, ces fonctions améliorent assez notablement la qualité du flux réseau en isolant en général du trafic réellement anormal.
  • Analyses et fonctions avancées : enfin la plupart des firewall vont désormais au-delà de la mise en œuvre du suivi d'état et de la translation d'adresses en permettant parfois de réaliser des fonctions sophistiqués (et plus ou moins utiles) dont nous mentionnons certaines ici.
    • Substitution des numéros de séquence : afin de limiter la prévisibilité des numéros de séquence TCP utilisés par certains systèmes d'exploitation, certains firewall sont en mesure de substituer ceux-ci sur les connexions qu'ils acheminent, ce qui est un exercice assez délicat.
    • Inspection protocolaire : pour répondre aux besoins spécifiques correspondant à des applications et des protocoles largement répandus (comme FTP bien entendu, mais aussi le DNS, H.323, etc.), un certain nombre de firewall sont en mesure d'aller au-delà de l'analyse des en-têtes IP et TCP/UDP des paquets pour examiner également les protocoles de plus haut niveau. Cette inspection protocolaire permet alors de mieux contrôler les flux et de simplifier la configuration du firewall en autorisant tous les flux nécessaires aux communications d'une application.
    • Redirection : une autre manière de répondre efficacement aux besoins des applications de communication complexes, c'est de permettre à des proxy applicatifs présents sur le firewall d'intervenir également sur la communication, et de manière transparente. Dans ce cas, le firewall doit pouvoir faire une redirection des flux autorisés vers des relais applicatifs, et permettre à ces relais de continuer la communication. L'objectif de ce mode de fonctionnement, relativement équivalent au précédent, est alors notamment d'éviter de polluer le logiciel de filtrage lui-même (habituellement étroitement associé aux couches réseau du noyau) avec des fonctions d'analyse plus avancées nécessitant des logiciels de type applicatif.
    • OS fingerprinting : certains travaux récents, notamment sur le firewall pf d'OpenBSD, ont introduit des éléments nouveaux dans les possibilités offertes par les firewall. En couplant la mise en œuvre des règles de filtrage avec des fonctions d'analyse réseau capables de reconnaître la signature de certains types de système d'exploitation, les dernières versions d'OpenBSD sont en mesure d'autoriser ou de limiter un flux de communication en fonction de certaines caractéristiques des machines impliquées dans la communication (et notamment le type de système d'exploitation). Ceci offre des possibilités assez nouvelles, notamment pour lutter contre les systèmes vieillissants.
    • Intégration avec la QoS : étant amené à suivre de la manière la plus précise possible les flux de communication qu'il achemine (au point parfois de nécessiter une analyse partielle des commandes utilisateurs inscrites dans la communication), le firewall est également très bien placé pour appliquer des règles de qualité de service réseau aux flux qu'il a identifié. Il est donc techniquement souhaitable d'associer des règles de QoS réseau aux règles de filtrage pour répartir la bande passante et accorder des priorités adéquates aux différents flux de communication. Toutefois, cette pertinence technique entre probablement en conflit avec les objectifs commerciaux de nombreux constructeurs (qui associent la sécurité et la qualité de service à des gammes de matériels et des offres différentes) et l'organisation courante de l'administration informatique (qui établit des frontières assez hermétiques et souvent une certaine concurrence entre l'administration de la sécurité et l'administration du réseau). Dans la pratique, les solutions techniques offrant une réelle intégration de la QoS et du firewall sont alors beaucoup plus homogènes dans le domaine du logiciel libre, avec Netfilter pour Linux, et pf avec ALTQ sous OpenBSD ; avec une exception notable : le module FloodGate-1 de CheckPoint (qui mériterait sans doute un intérêt supérieur à celui qu'il attire en général).