par ccnet » 04 Juin 2009 00:09
Je ferai presque comme vous le suggérez. Le problème c'est le "presque". Et c'est là que nous touchons aux limites d'ipcop. Votre idée correspond souvent sur le principe, presque, à l'architecture utilisée.
Pourquoi presque ?
Deux raisons me dissuade de mettre les données accéder de l'extérieur dans le réseau local interne.
1. Les risques sont, en gros aussi important avec les utilisateurs externes, qu'internes. Il faut protéger les données aussi vis à vis de l'intérieur.
2. Même indirectement les données sont accédés depuis l'extérieur et l'on ne peut exclure totalement la compromission d'un des frontaux. Ce serait suicidaire à mon avis. Si le risque se réalisait tout votre réseau interne serait compromis. Le risque est trop grand.
Une solution.
La solution à ce problème nécessite deux dmz. Appelons les interne et externe, on dit aussi parfois publique et privée, peu importe les noms. Or ipcop ne sait pas faire cela, du moins pas comme il est souhaitable de le faire. Ce type de solution requiert souvent l'usage de vlans pour augmenter le cloisonnement afin de limiter les risques d'intrusions en profondeur, notamment par rebond. Ipcop ne permet pas de faire tout cela. A titre d'exemple c'est pour des raisons de ce type que, récemment j'ai pu découvrir tout le réseau interne, sensé être invisible, en adressage privé, d'un site web. A la base un petit oubli dans un paramétrage. Je vous rassure, c'était le but de la mission que d'évaluer la résistance potentielle de l'architecture.
Il y a d'autres problèmes mais, dans un premier temps, celui de l'architecture est central.