Pourquoi le pare-feu bloque-t-il mes i applications ?

Vous avez décidé de passer à quelque chose de nouveau. Vous voulez profiter de toutes les superbes applications livrées avec les CD de votre système ou même d’autres, trouvées ailleurs. Vous avez l’intention de ne plus utiliser exclusivement l’écran vert et d’entrer dans l’univers des applications GUI qui tournent principalement sur votre PC et peuvent affecter ou contrôler votre système i (souvent de manière difficile ou impossible à réaliser à partir d’une ligne de commande 5250).

ligne de commande 5250

Vous vérifiez donc que votre PC est en état de marche. Vous procédez à l’installation en suivant la documentation. Vous lancez l’application et… rien. Peut-être qu’elle se plante ou se plaint de ne pas pouvoir communiquer avec votre système i. Très contrarié, vous appelez les gars du réseau. Ils font « quelque chose » et l’application fonctionne – jusqu’à ce que vous cliquiez sur une fonction différente et que l’application se plante à nouveau. Ou peut-être que vous essayez d’appeler de chez vous sur le VPN de l’entreprise et que l’application se replante. Mais que se passe-t-il donc ?

Vous avez peut-être buté sur un mur – un mur pare-feu, le superbe dispositif spécial mis en place pour protéger votre réseau d’entreprise contre les menaces internes et externes. Ne paniquez pas : avec un peu de travail, vous pouvez éviter les problèmes de pare-feu et utiliser tous ces superbes outils que vous brûlez d’essayer.

Applications GUI

Pour résoudre un problème de connectivité, la première étape consiste à isoler la cause de la communication défaillante. Malheureusement, de nombreuses applications GUI ne savent pas elles-mêmes quel est le problème. Elles savent simplement qu’elles appellent votre système i sans obtenir de réponse. Or, il se peut que le trafic provenant de l’application atteigne votre IBM i, mais que la réponse du serveur soit bloquée par un pare-feu.

Pour analyser de tels problèmes, il est important de comprendre le concept du numéro de port TCP/IP. Si vous êtes déjà rompu aux ports, aux en-têtes IP, etc., cet article (ou au moins cette section) ne vous concerne peut-être pas ! Mais, comme le concept de port est primordial pour diagnostiquer les défaillances de communications, il est utile de revoir les principes de base.

Quand une application veut parler à un serveur en utilisant TCP/IP (ce qui est le cas de la plupart des applications GUI), elle envoie une requête de connexion à l’adresse IP du serveur, en spécifiant un numéro de port « bien connu » unique à cette application. On peut comparer un numéro de port IP à un numéro d’appartement dans un immeuble résidentiel. Supposons que vous vouliez envoyer quelque chose à l’habitant de cet immeuble. Outre l’adresse de la rue, vous devez identifier le numéro de l’appartement pour assurer la bonne livraison. Et si vous habitez dans un immeuble résidentiel, le destinataire devra peut-être faire la même chose pour vous envoyer la réponse.

Dans cet exemple, l’adresse de rue de l’immeuble résidentiel est comme l’adresse IP. Le numéro d’appartement est comme un numéro de port. Les adresses IP et les numéros de ports sont juste des valeurs numériques dans l’en-tête d’un paquet, et la combinaison de l’adresse IP de source et de destination et des numéros de ports identifie une connexion unique entre client et serveur. Ces identificateurs sont codés dans chaque paquet échangé entre les deux unités.

Dans cette analogie, le pare-feu est comme votre facteur : pas le facteur sympa que vous aimez bien, mais plutôt un facteur soupçonneux dans un pays beaucoup moins libre ! Ce facteur regarde chaque lettre et l’adresse, puis décide de la livrer ou non. Bien qu’il stoppe rarement tout le courrier destiné à un certain immeuble, il pourrait garder celui de certains appartements plus suspects que d’autres. Ainsi, alors que certains résidents obtiendront chaque catalogue ou paquet qui leur est destiné, d’autres risquent de n’avoir pas de courrier ou de l’avoir sous étroite surveillance. Pis encore, avant de livrer le courrier, le facteur pourrait même l’ouvrir pour vérifier si son contenu est subversif. S’il juge qu’un courrier ne doit pas être délivré, il peut s’en débarrasser sans en informer l’expéditeur ou le destinataire. Par conséquent, l’expéditeur se demande si le courrier est parvenu à l’appartement visé, et la seule confirmation de cela est si le destinataire répond.

Mais n’accablons pas le facteur : il ne fait que son travail. Honnêtement, le coupable est le courrier qu’il examine – depuis des messages indésirables jusqu’à des lettres piégées. Et même des lettres innocentes adressées à des appartements non existants pourraient indiquer qu’un expéditeur essaie de trouver des adresses valides pour de prochains méfaits.

Quoiqu’imparfaite, cette analogie montre bien comment les unités et les pare-feu interagissent. Au minimum, un pare-feu supervise les numéros de ports (numéros d’appartements) sur chaque paquet adressé à un certain serveur (immeuble résidentiel), et abandonne les paquets que la stratégie dit de ne pas transmettre. Si votre application utilise l’un de ces ports bloqués, elle risque de se planter là dans l’attente d’une réponse qui ne viendra jamais. Quand les techniciens réseau parlent d’un port « ouvert », ils veulent dire que le trafic dont l’en-tête contient ce numéro de port peut passer librement au travers des pare-feu entre sa source et sa destination.

Un pare-feu bien configuré contrôle le trafic entrant et sortant. L’entrant provient de réseaux non approuvés vers le réseau protégé, et le sortant va de l’approuvé vers le non approuvé. Par défaut, un pare-feu bloque tout le trafic entrant. Les exceptions à cette règle doivent être spécifiquement configurées. La coutume voulait que le trafic sortant fût entièrement autorisé, mais aujourd’hui certaines bonnes pratiques incitent à contrôler également le trafic sortant.

Là où le trafic sortant est contrôlé, plusieurs ports sont presque toujours ouverts. Ils sont généralement destinés à des applications très courantes, comme HTTP (port 80) et HTTPS (port 443). Dans les réseaux les plus sécurisés, même ces ports apparemment inoffensifs peuvent être bloqués par le pare-feu, et les utilisateurs doivent alors faire leurs requêtes par l’intermédiaire d’un serveur « proxy » qui applique les restrictions spécifiques comme le filtrage de contenu.

Avant de résoudre les problèmes de connectivité, vous devez comprendre les pratiques de filtrage de pare-feu propres à votre organisation.

Par exemple, analyser une défaillance proxy n’a rien à voir avec isoler un simple blocage de règle de pare-feu.