Pare-feu

Firewall.

Besoin

Garantir la sécurité d'un domaine réseau, à savoir :

• les entrées dans ce domaine
• les sorties de ce domaine

Analyse

Un pare-feu (firewall) est une architecture réseau (et non forcément une seule machine comme on le pense souvent).

Il peut fournir divers services :

• filtrage de paquets : cette technique consiste à autoriser ou non le transit de paquets IP en fonction de :
  • leur adresse de source
  • leur adresse de destination
  • le port de destination
  • le protocole de niveau supérieur (TCP, UDP) utilisé.
  • Outre ces informations, les pare-feux sont généralement incapables (sauf Checkpoint Firewall 1) de prendre des décisions en fonction des données contenues dans ces paquets (d'où les techniques de tunnelling).
• filtrage d'applications
• serveur délégué/mandataire (proxy)
• NAT
• VPN : réseau privé permettant le cryptage

Conception

RMI

Les pare-feux situés entre deux parties communiquant via RMI (une applet et son serveur par exemple) interdisent généralement l'accès au port RMI par défaut (1099), ce qui amène automatiquement (si la propriété http.proxyHost est spécifiée, voir plus bas) le client RMI à tenter un tunneling HTTP. Si cette tentative de tunnelling n'est pas souhaitée, on fixera la propriété java.rmi.server.disableHttp=true.

Parce les requêtes HTTP ne peuvent être émises que dans une direction au travers d'un pare-feu, un client ne peut exporter ses propres objets au-delà du pare-feu, parce qu'une machine au-delà de ce pare-feu ne peut invoquer une méthode en retour vers le client (à vérifier si le pare-feu autorise les requêtes entrantes sur le port HTTP).

DNS

Il arrive également que le pare-feu d'un utilisateur empêche ce dernier de se connecter à un serveur DNS externe, et donc de résoudre des noms symboliques (www.javarome.org par exemple) en adresses physique (195.102.32.38 par exemple). Une applet sera par exemple incapable de charger une de ses ressources, parce qu'utilisant son codebase exprimé sous forme de nom symbolique pour récupérer cette ressource.

Il existe plusieurs solutions pour résoudre ce problème :

• Spécifiez l'adresse IP dans le codebase du tag <applet> et non pas le nom symbolique. Ceci impose de ne plus changer d'adresse IP.
• Spécifiez la résolution du nom symbolique dans le fichier de votre DNS local.
  • dans /etc/hosts pour les systèmes Unix
  • dans c:\windows\hosts pour les systèmes Windows 95 et Windows 3.x
  • dans c:\Winnt_version\system32\drivers\etc\hosts pour les systèmes Windows NT, où Winnt_version dépend de votre version de Windows NT (c:\winnt, c:\winnt4 par exemple)

HTTP

L'utilisation du protocole HTTP est donc une règle quasi-générale pour franchir les pare-feux. Ce protocole possède cependant de nombreux désavantages, qu'il peut être nécessaire de contourner afin que le support des pare-feux n'handicape pas fonctionnellement notre application.

HTTP n'est en effet pas un protocole dit "connecté", ce qui signifie que la connection établie par le client est censée être fermée une fois la réponse envoyée à ce premier.

Ce n'est heureusement pas toujours vrai.

Connexions Persistantes

De nombreuses implémentations de HTTP ont introduit une optimisation de ce principe, au travers des "connexions persistantes".

Le principe des Connexions Persistantes consiste à réutiliser une connexion établie au lieu de la fermer et d'en réouvrir une autre.

Ce mécanisme est fourni dans de nombreuses implémentations de HTTP, au travers de l'option Keep-Alive. Elle devait cependant être négotiée avec le serveur (qui devait la comprendre) et ne constituait pas le comportement par défaut de HTTP 1.0. Ceci pouvait en outre poser des problèmes lorsqu'un client souhaitait se connecter à un tel serveur via un proxy HTTP qui ne comprenait pas cette option, et se bornait à la transmettre au serveur final. Ce dernier, qui comprenait l'option, ne fermait pas sa connexion, ce qui bloquait le proxy qui, lui, attendait une fermeture.

HTTP 1.1 a apporté de nombreuses optimisations, dont l'utilisation par défaut des connexions persistantes, où l'exception consiste donc à fermer une connexion (la partie effectuant cette fermeture devant en informer l'autre via l'option Connection: close). L'utilisation de connexions persistantes par défaut permit par la suite diverses autres optimisations, comme l'envoi de plusieurs requêtes HTTPà la suite (les réponses sont renvoyées dans l'ordre).

Un client HTTP (navigateur Web typiquement), tentera donc d'envoyer des requêtes HTTP sur une connexion existante (pour peu que le même serveur soit visé) tant que cette connexion n'a pas été fermée. Le nombre de requêtes acceptées sur une même connexion peut être paramétrable côté serveur (dans la configuration d'un serveur Web par exemple), ainsi que le délai d'inactivité accepté avant la fermeture d'une connexion (timeout).

Connexions en Attente

Ou Pending Connections.

Certains besoins fonctionnels, tels qu'une connexion full-duplex peuvent être incompatibles avec un mode déconnecté ou déconnectable (un serveur désirant envoyer des événements à un client par exemple - le fameux server push ou push).

Une technique existe cependant pour contourner ce problème, consistant pour le client à se connecter au serveur en lui indiquant qu'il souhaite recevoir un événement. Le serveur enregistre le fait qu'il s'agit d'une connexion pour notification d'événement et ne déconnecte pas le client. Lorsque l'événement surviendra, le serveur utilisera cette connexion pour en avertir le client.

Ce procédé sous-entend cependant un accord de principe entre le client et le serveur.

Proxy

Un serveur mandataire (ou proxy, serveur de délégation) est une machine mandatée pour effectuer les requêtes réseau de machines du réseau interne à la place de celles-ci.

Ceci permet :

• d'empêcher les machines du réseau externe de voir les machines du réseau interne (pour elles les requêtes proviennent du serveur mandataire)
• de contrôler les requêtes provenant des machines internes (on pourra par exemple n'autoriser que les requêtes HTTP)
• de contrôler les réponses provenant des machines externes

Il existe deux grandes catégories de serveurs mandataires :

• les serveurs agissant au niveau application, qui attendent des requêtes dans un protocole applicatif donné (HTTP, S-HTTP, FTP, Gopher). Le contenu de ces requêtes n'a pas besoin d'être modifié. Il est reçu tel quel par le serveur mandataire qui les redirige après examen et validation vers la machine destinataire du réseau externe.
• les serveurs agissant au niveau transport, qui attendent des requêtes dans un protocole spécifique, notamment SOCKS. Ces serveurs dialoguent avec des clients spécifiques connaissant le protocole SOCKS. Le fait que nombre de logiciels clients (les navigateurs, le JPI...) supportent le protocole SOCKS permet, moyennant une configuration minime (l'adresse et le port du serveur SOCKSà utiliser), de rendre la traversée d'un tel proxy transparente pour l'utilisateur.

Exemples

• Une DMZ est une architecture de pare-feu qui utilise 2 routeurs pour filtrer et transférer l'information entre le réseau interne d'une organisation et l'Internet.

Voir

• Ecriture d'un firewall en Java par Paul Grégory.