> Tech > Zones de sécurité et pare-feu (firewalls)

Zones de sécurité et pare-feu (firewalls)

Tech - Par iTPro - Publié le 24 juin 2010
email

Pour obtenir une infrastructure .NET sécurisée, il faut évaluer les zones de sécurité et les pare-feu déjà  présents dans l'entreprise. L'infrastructure .NET envisagée entraînera peut-être quelques modifications. Même si l'application que l'on construit n'a pas d'interaction avec des entités externes, il faudra néanmoins prévoir des pare-feu. Les pare-feu internes peuvent

Zones de sécurité et pare-feu (firewalls)

protéger les sites ou les départements ayant des critères de sécurité spéciaux et peuvent restreindre l’accès à  certaines parties du réseau interne (dans le cas où un intrus parviendrait à  franchir les pare-feu appartenant au périmètre de sécurité externe).

Pendant la conception de l’infrastructure, deux questions courantes liées aux zones de sécurité et au pare-feu peuvent se poser. Première question : où placer les données et les serveurs ? La zone de sécurité dans laquelle il faut les placer dépend de l’utilisation qui en est faite. Il faut d’abord évaluer la confidentialité des données que les serveurs vont traiter et stocker, puis stocker les données clients confidentielles dans la zone de sécurité de confiance (trusted).

Si l’entreprise utilise une zone démilitarisée (DMZ) dans sa topologie, comme dans la figure 1, les choses se compliquent. Bien entendu, il ne faut mettre que des données publiques dans une DMZ. Mais, même de telles données méritent protection. Lors des élections présidentielles de 2000, aucun candidat n’aurait voulu qu’un intrus modifiât le décompte des voix publié par CNN sur son site Web. (A bien réfléchir, cela n’aurait peut-être pas trop gêné Al Gore).

Deuxième question : Comment traiter les RPC (Remote Procedure Calls) et le trafic SSL (Secure Sockets Layer)/TLS (Transport Layer Security) qui se déplace entre les entités de part et d’autre d’un pare-feu ? De nombreux sites Web commerciaux utilisent SSL/TLS pour offrir un ensemble de services de sécurité de base aux clients. Cet ensemble de services de base comprend en principe l’authentification du serveur, celle du client, et la protection de l’intégrité et de la confidentialité des données transmises entre le client et le serveur SSL. Pour traiter le trafic SSL au niveau du pare-feu, deux des méthodes suivantes sont possibles : le SSL tunneling, illustré figure 2, ou le SSL bridging, illustré figure 3. La plupart des pare-feu du commerce supportent le SSL tunneling, qui utilise le message HTTP CONNECT pour demander au pare-feu d’ignorer le contenu d’une session SSL particulière et de retransmettre simplement les paquets SSL. Dans une configuration SSL bridging, le pare-feu tient compte du SSL et contient un certificat SSL approprié. Le pare-feu joue le rôle d’un point final de tunnel SSL. SSL bridging peut constituer une bonne solution non seulement pour traiter le trafic SSL au niveau du pare-feu, mais aussi pour qualifier SSL sur la portion publique (c’est-à -dire non garantie) du canal de communication conjointement aux applications non qualifiées SSL.

Les RPC permettent à  un client d’interagir avec une application distante. Tous les composants impliqués dans l’infrastructure .NET qu’illustre la figure 1, peuvent utiliser les RPC pour communiquer. On s’intéressera particulièrement ici à  l’utilisation des RPC pour la communication intercomposants dans les modèles de composants distribués de Microsoft (c’est-à -dire Distributed COM – DCOM – et COM+) et pour la réplique Active Directory (AD).

Les RPC sont faciles à  établir – si aucun pare-feu n’est impliqué. Une caractéristique déplaisante des RPC réside dans leur mode d’utilisation de ports entrants (inbound) dynamiques, qui ne permet absolument pas de prévoir quels ports seront utilisés. Pour des raisons de sécurité évidentes, peu d’administrateurs de pare-feu sont disposés à  ouvrir tous les ports possibles. Pour plus d’informations sur ce problème, voir l’article Microsoft « HOW TO : Configure RPC Dynamic Port Allocation to Work with Firewall » (http://support.microsoft.com/support/kb/articles/ql54/5/96.asp).

Comment traiter avec les RPC et les pare-feu pour des communications DCOM et COM+ ? Tout d’abord, il ne faut jamais utiliser des RPC pour connecter un client Internet à  l’infrastructure .NET. Il faut dans ce cas choisir une solution de type HTTP. Tant que HTTP ne pénètre pas par un tunnel à  l’intérieur de SSL ou d’IP Security (IPSec), il est plus facile à  contrôler et utilise un port entrant fixe (le port 80 par défaut). Mais, on sera parfois amené à  établir des RPC au travers des pare-feu pour des communications DCOM et COM+. Supposons, dans l’infrastructure illustrée figure 1, qu’il faille initier une communication COM+ entre un serveur Web dans la DMZ et un serveur d’objets de gestion COM+ dans la zone de confiance (trusted). Dans un tel scénario, on peut utiliser des RPC pour permettre la communication inter-composant au travers de Tunneling TCP ou de SOAP (Simple Object Access Protocol).

Tunneling TCP ajoute un passage de témoin (handshake) de type HTTP au début de la séquence de communication DCOM. Après ce handshake, Tunneling TCP envoie des paquets DCOM ordinaires sur TCP sans l’intervention de HTTP. Tunneling TCP s’appuie sur le message RPC_CONNECT et nécessite la présence d’un proxy RPC. Pour installer un proxy RPC sur Win2K, ouvrez l’applet Control Panel Add/Remove Programs et ajoutez le COM Internet Services Proxy (CIS Proxy) Networking Services. Pour configurer Tunneling TCP du côté client Win2K ou Windows NT 4.0, utilisez l’utilitaire de configuration dcomcnfg.exe. Pour plus d’informations sur la configuration de Tunneling TCP et de CIS Proxy, lire l’article MSDN (Microsoft Developer Network) de Marc Levy, « COM Internet Services » (http://msdn.microsoft.com/library/backgrnd/html/cls.htm). Bien que Tunneling TCP et le CIS Proxy résolvent le problème du pare-feu, ils dépendent de la plate-forme Microsoft.

SOAP, l’un des mots du jargon du .NET framework, est une technologie assez nouvelle. D’après la définition des spécialistes Microsoft, Lotus et IBM, SOAP est un protocole indépendant des plates-formes. L’un des principaux avantages de SOAP est le fait qu’il offre une méthode de transport du trafic RPC en utilisant des messages de protocole HTTP. Autrement dit, SOAP permet à  un client d’utiliser le protocole HTTP pour communiquer avec une application à  base de composants distante.

Pour intégrer l’information RPC dans HTTP, SOAP utilise le codage XML. Contrairement à  Tunneling TCP, SOAP compte sur HTTP pour bien plus qu’un handshake initial. Pour plus d’informations sur SOAP, voir l’article MSDN d’Aaron Skonnard, « SOAP : The Simple Object Access Protocol » (http://msdn.microsoft.com/library/periodic/period00/soap.htm).

Une autre application de type RPC particulièrement intéressante dans le contexte de la sécurité de l’infrastructure .NET, est la réplique AD entre des contrôleurs de domaines (DC, domain controllers) du même domaine qui sont membres de différentes zones de sécurité. A ce jour, Microsoft n’a pas supporté le protocole SMTP pour la réplique des informations contextuelles des noms de domaines. On peut contourner cela en établissant une solution de tunneling à  base d’IPSec. IPSec permet de mettre en oeuvre le tunneling sur la couche réseau. Pour faire passer IPSec par un tunnel au travers d’un pare-feu, il faut ouvrir les ports suivants :
· 53/TCP et 53/UDP pour le trafic DNS
· 500/UDP pour le trafic IKE (Internet Key Exchange)
· 88/TCP et 88/UDP pour le trafic Kerberos V5 (dans le cas où l’on n’utilise pas les méthodes d’authentification par clé partagée ou par certificat).

Il faut également ouvrir le pare-feu pour prendre en compte le trafic des protocoles suivants : IPSec (Encapsulating Security Protocol (ESP) – protocole 50 – et IPSec Authentication Header (AH) – protocole 51.

Téléchargez cette ressource

SD-WAN de confiance : guide de mise en œuvre

SD-WAN de confiance : guide de mise en œuvre

Ce livre blanc décrit les différents aspects indispensables pour la mise en place d’une approche SD-WAN sécurisée et de confiance. Ce document s’adresse aux consultants et responsables sécurité des systèmes d’information pour bien comprendre les enjeux du Trusted SD-WAN à l’heure de la transformation numérique des entreprises.

Tech - Par iTPro - Publié le 24 juin 2010