DMZ privée - Réseaux - Systèmes & Réseaux Pro
Marsh Posté le 12-10-2009 à 11:35:07
par exemple des serveurs que tu veux proteger. Tu peux y trouver des serveurs de TOIP par exemple (oui je suis plus réseau donc mes réponses en découlent), ou plus généralement des serveurs qui nécessite plus de sécurité.
En théorie tu peux mettre tout ce que tu veux dans une DMZ.
Marsh Posté le 23-10-2009 à 23:46:21
Salut,
A la base, tu peux effectivement placer tout ce que tu veux en DMZ. Par contre, il y a, à mon sens, quelques règles qu'il peut s'avérer utile de respecter. La première, et pas la moindre, est qu'il est préférable de proscrire tout flux direct provenant de ton réseau externe à destination d'un réseau interne. Pour cela, il est utile de se reposer sur les DMZ pour faire transiter ces flux par les équipements de sécurité qui vont bien.
En théorie, je dirais que les services doivent être placés au plus près de l'utilisateur qui doit les accéder. Concrètement, si tu prends un serveur web, tu pourrais avoir une architecture de ce style :
1. Le client arrive d'Internet pour accéder à un site publié depuis ton réseau
2. Tu possèdes un reverse proxy installé en DMZ publique qui va te permet de contrôler les requêtes HTTP/HTTPS fournies
3. Ce reverse proxy va effectuer une requête sur ton serveur web potentiellement installé en DMZ privée.
4. SI nécessaire, ce serveur web effectue des requêtes avec un serveur SQL situé sur ton LAN par exemple.
Donc voilà un exemple (que je ne considère pas non plus comme une référence) mais qui peut t'illustrer un peu ce concept.
Marsh Posté le 29-10-2009 à 17:57:16
Bonsoir et merci nono61984 et Pandinus2k4 pour ces compléments d'infos.
Pandinus2k4 a écrit : |
Justement, dans le cas d'une DMZ privée, le traffic de la DMZ privée vers le réseau interne est interdit et le traffic du réseau interne vers la DMZ privée est autorisé.
Or si le serveur web initie des requêtes SQL vers un serveur de BD, elles essuyeront un reset. Dans ce contexte, on est obligé de corriger les règles de pare-feu pour autoriser ce flux.
Je me posais donc la question, en pratique qu'est-ce que l'on y met ? à contrario de nono61984, je ne suis pas persuadé que l'on peut y mettre tout ce que l'on veut.
Marsh Posté le 30-10-2009 à 13:06:58
Il faut bien un moment que tu ais des flux vers ton réseau interne !!
sauf si tu ne met aucun serveur dessus mais alors ça sert plus à grand chose ...
Pour ta derniere phrase, tu vois la DMZ privée comme une zone potentiellement dangereuse pour l'utilisateur alors que moi je t'en parle comme une zone à proteger des utilisateurs. après l'exemple de Pandinus est très parlant sur ce que j'ai pu voir en entreprise.
Marsh Posté le 30-10-2009 à 14:10:15
nono61984 a écrit : |
Il est effectivement là le malentendu. L'architecture qui m'est imposée est la suivante (l'illustration ne fait pas apparaître la DMZ publique) :
Je pense que le pare-feu va filtrer en fonction des états de connexion et n'acceptera que les paquets de la DMZ privée vers le réseau interne en état established ou related. Si la connexion TCP est initiée par le serveur situé en DMZ privée (syn), elle ne passera pas et sera rejetée (rst).
C'est donc problématique pour des services qui initient des connexions avec des stations situées sur le réseau interne.
Marsh Posté le 30-10-2009 à 18:50:48
Salut,
Je ne vois pas où est ta problématique en fait. A quel genre de services penses-tu pour la DMZ privée ?
Marsh Posté le 30-10-2009 à 20:59:07
L'objet de mon post est à la fois une réflexion et une crainte concernant un serveur contrôleur de domaine qui pourrait-être posé en DMZ privée.
Marsh Posté le 12-10-2009 à 08:28:41
Bonjour,
Soit l'infrastructure réseau suivante :
- Réseau externe (internet)
- DMZ publique
- DMZ privée
- Réseau interne
Mes questions sont les suivante : quels types de services met-on derrière la zone DMZ privée ?
Certaines applications initient des connexions et obligeraient à ouvrir des ports de la DMZ privée vers le réseau interne.
Peut-on envisager par exemple de placer en DMZ privée une machine contrôleur de domaine ?
Merci pour vos contributions.