Principes de fonctionnement.
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.
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 :
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.
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é.
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).
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).
Translation d'adresses.
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.
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 :