Fiche technique DAIP Configuration du pare-feu du serveur pédagogique Kwartz Organisation de l infrastructure réseau On distingue différents réseaux au sein de l infrastructure d un établissement. Le schéma ci-dessous illustre cette organisation pour les collèges : E.N.T. Accès Internet pédagogique indépendant (optionnel ) Wan 1 Wan 2 Boîtier de sécurité Fortinet Port 1 Port 2 Dali+ Réseau administratif Ressources en DMZ (accessible depuis tous les réseauw) Port 3 Port 4 Ressources collectivité (Télérelève, etc.) Serveur Kwartz Réseau Pédagogique On distingue 4 zones interconnectées par l intermédiaire du boîtier de sécurité de marque Fortinet. 1) Le réseau administratif. Ce réseau est géré par le serveur Dali+. Il est relié au connecteur N 1 du boîtier de sécurité. Une liaison privée (VPN) permet aux postes de ce réseau de se connecter au réseau du rectorat. Ce réseau ne doit comprendre que des postes administratifs. 2) Le réseau pédagogique. Les postes des élèves et des professeurs sont connectés à ce réseau. L accès aux autres réseaux ne peut s effectuer que par l intermédiaire du serveur Kwartz. De ce fait, le serveur est équipé d une carte réseau pour se connecter au réseau local (LAN : Local Array Network ou réseau local) et d une autre lui permettant de communiquer avec les autres réseaux (WAN : Wide Array Network ou réseau étendu). Un composant de gestion des règles d accès (le pare-feu) permet de gérer les entrées et de sorties de ce réseau. 3) La zone démilitarisée (DMZ). Cette zone permet de proposer des ressources à l ensemble (ou partie) des autres réseaux. Les règles d accès sont fixées dans le boîtier de sécurité. On placera dans cette zone des ressources devant être accessibles à partir de plusieurs réseaux (serveur Pronotes par exemple). 4) La zone publique (Internet). Cette zone est directement connectée à l Internet. Elle permet la communication des réseaux internes avec le monde extérieur. Elle permet aussi aux postes externes de communiquer avec les postes et serveurs des réseaux locaux. 5) La zone collectivité. Elle fédère l ensemble des matériels que la collectivité prend de gestion (télé-relève, etc.). Pôle pédagogique du DAIP Page 1 sur 5 15/02/2016 jmd
Organisation du réseau pédagogique Nous allons maintenant nous occuper du réseau pédagogique, réseau qui comprendra : - Le serveur Kwartz qui est, pour l ensemble des postes du réseau pédagogique, la passerelle (gateway) de sortie vers les autres réseaux. - Les matériels connectés au réseau local (postes des élèves et des professeurs, imprimantes, etc.). - Le support d interconnexion physique des matériels : câblage réseau, matériels actifs (commutateurs), etc. Dans la suite de ce document, nous nous attarderons uniquement sur les échanges entre le serveur, les postes du réseau local et l accès vers les réseaux externes Les flux réseau mis en jeu Si l on reprend l organisation (simplifiée) du réseau local physique (colonne de gauche ci-dessous), on peut associer les différents flux possibles vers le serveur et/ou les postes du réseau (colonne de droite). Organisation physique Flux réseau Dans le schéma ci-dessus, on visualise donc que le pare-feu est l élément logiciel où va transiter l ensemble des flux entrant et sortant du serveur. Ces flux pourront être émis par le serveur et par les postes du réseau ou reçu d un réseau externe à destination du serveur ou des postes du réseau. On peut donc rapporter cela à l interface de gestion du pare-feu visible dans l interface Kwartz~Control. Pôle pédagogique du DAIP Page 2 sur 5 15/02/2016 jmd
Le tableau d affichage des règles du pare-feu se décompose ainsi : - Le nom du service concerné (Ping, Web, pages Internet (http, https), etc. - L état du flux entrant pour le serveur (Pour le serveur Kwartz / en entrée) : voir flux - L état du flux sortant pour le serveur Kwartz (Pour le serveur Kwartz / en sortie) : voir flux - L état du flux sortant pour les postes du réseau (Pour tous les postes / en sortie) : voir flux Analyse des règles par défaut La copie d écran ci-dessous reprend le paramétrage de base du pare-feu. On voit que certains flux ne sont pas autorisés. Par exemple si on analyse le service «web, pages internet (http/https)» on s aperçoit que l accès pour tous les postes est «non autorisé». Cela parait étrange car les postes peuvent pourtant consulter des pages Web internes ou externes. Cela s explique car l accès Internet des postes exploite un service du serveur Kwartz nommé proxy-cache (Squid). Quand un usager demande l affichage d une page web, il sollicite le serveur Proxy du serveur Kwartz (il faut impérativement que son navigateur web soit correctement configuré). Ce dernier va chercher (à la place du navigateur de l usager) les ressources demandées (c est la fonction proxy) puis les mémorise localement (c est la fonction cache qui permettra de fournir ces mêmes données à plusieurs postes sans effectuer un nouvel accès à l Internet). Il va ensuite fournir ces informations au navigateur de l usager. D autre part un système de filtrage (Squiguard) permettra d autoriser ou d interdire certaines ressources du web (filtrage d accès internet). Pour définir une règle, il faut pourvoir caractériser son flux, nous avons donc besoin de déterminer : - Son nom (Cette information est facultative mais elle facilitera la compréhension de la règle). - Le protocole qu il utilise (TCP, UDP, ). - Le port de connexion utilisé par ce flux. Pôle pédagogique du DAIP Page 3 sur 5 15/02/2016 jmd
- Le sens des échanges entre l émetteur et le récepteur. On prend pour exemple le flux http qui utilise un protocole TCP sur le port 80 (valeur standards). Une ouverture du port 80 pour tous les postes revient à supprimer le cache Proxy mais aussi le système de filtrage (ce n est donc pas une bonne idée d ouvrir ce flux ). De même pour le flux https (port 443). On voit donc qu il ne devrait pas exister de règle de pare-feu qui ouvre les ports 80 et/ou 443 pour tous les postes. Il faut aussi noter que certaines actions sur des services spécifiques (serveur web intranet/extranet, etc.) ont une incidence sur le pare-feu. Comment savoir si le pare-feu protège bien mon serveur et les postes de mon réseau? Il suffit d appliquer la règle suivante : Tous les accès entrant et sortant doivent être fermés sauf ceux indispensable au bon fonctionnement (voir la copie d écran page précédente). On peut maintenant justifier de l ouverture des flux pour les règles ci-dessous : - La maintenance IRIS devra être ouverte en entrée sur le serveur de manière à permettre une maintenance à distance (Iris technologies se connecte sur le serveur sur le port 22 en TCP pour assurer des maintenances). - La PRTICE accède à l interface Kwartz~Control à partir de chez lui. Le service Kwartz~control devra être ouvert en entrée sur le serveur. Ce service, fonctionnant sur le serveur, utilise le protocole HTTPS sur le port 9999 (port non standard). - On met à la disposition des usagers d Internet (les enseignants à partir de chez eux) un système de réservation de ressources qui est installé sur le serveur Kwartz. Comme ces usagers doivent s authentifiés, on utilisera un service web crypté (https) qui permettra cela. Il faut noter que ce service est aussi disponible sur le réseau local par l intermédiaire de l accès web (https) par le service proxy du serveur Kwartz. Remarque importante : tous les postes du réseau local ont accès à tous les ports du serveur Kwartz. On utilise donc le pare-feu pour gérer uniquement des flux qui transitent entre les 2 interfaces réseau du serveur. Comment faire si aucune règle par défaut ne convient au service que je veux mettre en place? Il faut donc créer une nouvelle règle en déterminant les caractéristiques du flux devant être ouvert. Par exemple, je désire donner accès au serveur Pronotes à l ensemble des postes de mon réseau. Ce serveur est installé sur le DMZ de mon établissement. Les postes utilisent un logiciel (client Pronotes) qui doit se connecter en TCP sur le port 49300 de mon serveur Pronotes (flux sortant pour tous les postes). Il faudra donc que le port 49300 (TCP) soit ouvert en sortie pour tous les postes. L ajout de cette règle permet donc aux postes de mon réseau pédagogique de se connecter sur le port 49300 de mon serveur Pronotes (externes à mon réseau). Pôle pédagogique du DAIP Page 4 sur 5 15/02/2016 jmd
Création d une translation de port La translation de ports va permettre à des postes du réseau externe de se connecter à un poste spécifique du réseau local. Flux entrant pour le serveur https://195.201.150.12:4444 Système d exploitation du serveur Kwartz Services offerts par le Serveur Kwartz Redirection de la requête Requête transmise https://172.16.253.254 Flux vers le serveur (requête entrante) Système d exploitation du poste Services du poste Applications Poste de pilotage du robot 172.16.253.254 Cette fonctionnalité ne doit être utilisée que dans des cas très spécifiques. Dans une configuration classique vous n aurez pas à utiliser cette fonctionnalité. Exemple : Mon établissement dispose d un robot pilotable depuis l internet au travers d une interface web classique en https (port 443) car l usager doit s authentifier pour piloter le robot). Sur le réseau local, l ordinateur qui pilote le robot possède l adresse IP locale 172.16.253.254. Il n y a aucun problème pour accéder à l interface de pilotage à partir du réseau local. Par contre, si je désire donner un accès à ce robot aux usagers depuis l Internet il me sera impossible d ouvrir en entrée le port 443 (car seul le serveur Kwartz est accessible sur ce port). Je dois donc mettre en place une règle de translation du port qui permet de dire que si j accède en TCP au serveur Kwartz sur le port 4444 alors il faut rediriger ce flux vers l adresse IP 172.16.253.254 sur le port 443 (port standards https). Il faut noter que le port 4444 du serveur est pris ici de façon totalement arbitraire mais qu il est indispensable : - De fixer cette valeur sur un port supérieur à 1024. - Que ce dernier ne soit pas en cours d utilisation (comme les ports 8888 : interface des responsables, 9999 : Kwartz~control, etc.). Pôle pédagogique du DAIP Page 5 sur 5 15/02/2016 jmd