Quelle est la difficulté de percer un trou dans la DMZ sur un serveur Web?

Nous avons actuellement notre serveur Web dans une zone démilitarisée. Le serveur Web ne peut rien voir dans le réseau interne, mais le réseau interne peut voir le serveur Web. Serait-il sûr de percer un trou dans le pare-feu entre la DMZ et le réseau interne à un seul serveur Web dans l'intranet? Nous travaillons sur quelque chose qui interfacera avec plusieurs de nos applications de back-office (qui sont toutes sur un serveur) et il serait tellement plus facile de faire ce projet si nous pouvions communiquer directement avec le serveur IBM i contenant ces données ( via des services Web).

D'après ma compréhension (et je ne connais pas les marques), nous avons un pare-feu pour la DMZ avec une IP externe différente de notre IP principale avec un autre pare-feu. Un autre pare-feu se trouve entre le serveur Web et l'intranet.

Donc quelque chose comme:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

Il n'y a rien de mal à créer des mécanismes d'accès pour que les hôtes de la DMZ accèdent aux hôtes du réseau protégé lorsque cela est nécessaire pour atteindre le résultat souhaité. Ce n'est peut-être pas préférable de le faire, mais parfois c'est le seul moyen de faire le travail.

Les éléments clés à considérer sont:

• Limitez l'accès à la règle de pare-feu la plus spécifique possible. Si possible, nommez les hôtes spécifiques impliqués dans la règle ainsi que les protocoles spécifiques (ports TCP et / ou UDP) qui seront utilisés. Fondamentalement, n'ouvrez que le petit trou dont vous avez besoin.

• Assurez-vous que vous connectez l'accès de l'hôte DMZ à l'hôte sur le réseau protégé et, si possible, analysez ces journaux de manière automatisée pour détecter les anomalies. Vous voulez savoir quand quelque chose hors de l'ordinaire se produit.

• Reconnaissez que vous exposez un hôte interne, même indirectement, à Internet. Restez au courant des correctifs et des mises à jour pour le logiciel que vous exposez et le logiciel du système d'exploitation de l'hôte lui-même.

• Envisagez une authentification mutuelle entre l'hôte DMZ et l'hôte interne, si cela est possible avec l'architecture de votre application. Il serait bon de savoir que les demandes provenant de l'hôte interne proviennent en fait de l'hôte DMZ. Que vous puissiez le faire ou non dépendra fortement de l'architecture de votre application. Gardez également à l'esprit que quelqu'un qui "possède" l'hôte DMZ pourra faire des demandes à l'hôte interne même si l'authentification est en cours (car il s'agira en fait de l'hôte DMZ).

• En cas de problème avec les attaques DoS, envisagez d'utiliser une limitation de débit pour empêcher l'hôte DMZ d'épuiser les ressources de l'hôte interne.

• Vous voudrez peut-être envisager d'utiliser une approche de «pare-feu» de couche 7, où les demandes de l'hôte DMZ sont d'abord transmises à un hôte interne spécifique qui peut «désinfecter» les demandes, les vérifier et les transmettre ensuite à le "vrai" hôte principal. Puisque vous parlez d'interfaçage avec vos applications de back-office sur votre IBM iSeries, je suppose que vous avez une capacité limitée pour effectuer des vérifications d'intégrité contre les demandes entrantes sur l'iSeries lui-même.

Si vous abordez cela de manière méthodique et gardez un certain bon sens à ce sujet, il n'y a aucune raison pour que vous ne puissiez pas faire ce que vous décrivez tout en minimisant les risques en même temps.

Franchement, le fait que vous ayez une zone démilitarisée qui n'a pas un accès illimité au réseau protégé vous fait franchir de nombreux obstacles que j'ai vus. Pour certaines personnes, il semble que DMZ signifie simplement "une autre interface sur le pare-feu, éventuellement avec des adresses RFC 1918 différentes, et un accès sans entraves à Internet et au réseau protégé". Essayez de garder votre DMZ aussi verrouillée que possible tout en atteignant vos objectifs commerciaux et vous vous en sortirez bien.

Il y a évidemment des dangers, mais vous pouvez le faire. Fondamentalement, vous ouvrez un trou d'épingle que quelqu'un pourrait traverser, alors faites-le minuscule. Limitez-le uniquement aux serveurs à chaque extrémité et autorisez uniquement les données sur les ports choisis. Ce n'est pas une mauvaise idée d'utiliser la traduction d'adresse de port pour n'utiliser que des ports bizarres. Pourtant, la sécurité par l'obscurité n'est pas du tout une sécurité. Assurez-vous que quel que soit le serveur de l'autre côté, il existe une sorte de moyen de vérifier que les informations passant par cette connexion sont vraiment ce qu'elles semblent être ... ou au moins avoir une sorte de pare-feu contextuel en place. De plus, certains pare-feu sont conçus pour ce genre de choses ... Je sais que Microsoft ISA fait la même chose pour les serveurs OWA et Exchange.