Bonjours à tous !
Je veux mettre en place un petit serveur web pour le compte de mon
entreprise sur notre ligne ADSL. Je veux le faire en local car j'ai besoin
de mettre en ligne notre catalogue basé sur notre base de données de
matériel. Cette base de données est utilisée quotidiennement par un
logiciel spécifique à sa gestion ( c'est une entreprise de location de
matériel ). Le serveur web devra donc faire tourner un site avec des
parties php reliées à la bdd ODBC.
L'administrateur réseau est d'accord, c'était pas gagné, c'est déjà une
bonne chose ! On va donc installer une machine qui servira de firewall en
plus d'une autre machine dédiée serveur web, et mettre en place une zone
DMZ dans laquelle sera installé le serveur Web.
Le problème arrive là : l'admin me dit qu'il faut 3 IP, une pour le routeur,
une pour le serveur et une autre pour le réseau local ?!?!?! Je l'ai
d'abord regardé avec des yeux ronds, puis je me suis inquiété de mes
connaissances en réseaux, lui ayant plus d'expérience que moi dans le
domaine...
Je reste sur un doute : pour moi, on a besoin que d'une seule IP, et le
routeur fera le boulot de redirection. J'ai raison ou pas ?
--
yoloosis
ICQ : 101663794
Jabber : yoloosis@jabber.org
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jacques Caron
Salut,
On 23 Feb 2004 19:15:03 GMT, yoloosis wrote:
Je veux mettre en place un petit serveur web pour le compte de mon entreprise sur notre ligne ADSL. Je veux le faire en local car j'ai besoin de mettre en ligne notre catalogue basé sur notre base de données de matériel. Cette base de données est utilisée quotidiennement par un logiciel spécifique à sa gestion ( c'est une entreprise de location de matériel). Le serveur web devra donc faire tourner un site avec des parties php reliées à la bdd ODBC.
Je ne vois pas en quoi ça oblige à avoir le serveur en question en local. Le serveur peut très bien être hébergé quelque part, et faire des requêtes vers la BDD chez vous. Ou inversement, le serveur et la BDD peuvent être hébergés, et les postes chez vous attaquer la BDD distante.
Le problème arrive là : l'admin me dit qu'il faut 3 IP, une pour le routeur, une pour le serveur et une autre pour le réseau local ?!?!?!
Euh, il ne faut probablement pas "une IP pour le réseau local", à moins que celui-ci soit NATé derrière une autre machine. Mais dans le principe de base, il faut: - une plage d'adresses avec (au moins) 2 adresses dedans pour le réseau routeur-firewall - une plage d'adresses avec au moins 2 adresses pour le réseau firewall-serveur web. - une plage d'adresses pour le réseau local.
Après, suivant l'endroit (ou les endroits) où il y a du NAT ou pas, il faut des adresses publiques ou privées pour chacun de ces réseaux.
Je reste sur un doute : pour moi, on a besoin que d'une seule IP, et le routeur fera le boulot de redirection. J'ai raison ou pas ?
Si le routeur externe fait du NAT, on peut en interne tout mettre avec des adresses IP privées, et faire le routage approprié (et/ou un deuxième niveau de NAT au niveau du firewall, bof bof). Les choix vont pas mal dépendre de ce que le routeur est capable de faire ou pas.
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et des différentes contraintes existantes.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 23 Feb 2004 19:15:03 GMT, yoloosis <yoloosis@free.fr> wrote:
Je veux mettre en place un petit serveur web pour le compte de mon
entreprise sur notre ligne ADSL. Je veux le faire en local car j'ai
besoin de mettre en ligne notre catalogue basé sur notre base de
données de matériel. Cette base de données est utilisée quotidiennement
par un logiciel spécifique à sa gestion ( c'est une entreprise de
location de matériel). Le serveur web devra donc faire tourner un site
avec des parties php reliées à la bdd ODBC.
Je ne vois pas en quoi ça oblige à avoir le serveur en question en local.
Le serveur peut très bien être hébergé quelque part, et faire des requêtes
vers la BDD chez vous. Ou inversement, le serveur et la BDD peuvent être
hébergés, et les postes chez vous attaquer la BDD distante.
Le problème arrive là : l'admin me dit qu'il faut 3 IP, une pour le
routeur, une pour le serveur et une autre pour le réseau local ?!?!?!
Euh, il ne faut probablement pas "une IP pour le réseau local", à moins
que celui-ci soit NATé derrière une autre machine. Mais dans le principe
de base, il faut:
- une plage d'adresses avec (au moins) 2 adresses dedans pour le réseau
routeur-firewall
- une plage d'adresses avec au moins 2 adresses pour le réseau
firewall-serveur web.
- une plage d'adresses pour le réseau local.
Après, suivant l'endroit (ou les endroits) où il y a du NAT ou pas, il
faut des adresses publiques ou privées pour chacun de ces réseaux.
Je reste sur un doute : pour moi, on a besoin que d'une seule IP, et le
routeur fera le boulot de redirection. J'ai raison ou pas ?
Si le routeur externe fait du NAT, on peut en interne tout mettre avec des
adresses IP privées, et faire le routage approprié (et/ou un deuxième
niveau de NAT au niveau du firewall, bof bof). Les choix vont pas mal
dépendre de ce que le routeur est capable de faire ou pas.
Maintenant, quand on utilise un firewall, en général, on met des adresses
publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le
réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et
des différentes contraintes existantes.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Je veux mettre en place un petit serveur web pour le compte de mon entreprise sur notre ligne ADSL. Je veux le faire en local car j'ai besoin de mettre en ligne notre catalogue basé sur notre base de données de matériel. Cette base de données est utilisée quotidiennement par un logiciel spécifique à sa gestion ( c'est une entreprise de location de matériel). Le serveur web devra donc faire tourner un site avec des parties php reliées à la bdd ODBC.
Je ne vois pas en quoi ça oblige à avoir le serveur en question en local. Le serveur peut très bien être hébergé quelque part, et faire des requêtes vers la BDD chez vous. Ou inversement, le serveur et la BDD peuvent être hébergés, et les postes chez vous attaquer la BDD distante.
Le problème arrive là : l'admin me dit qu'il faut 3 IP, une pour le routeur, une pour le serveur et une autre pour le réseau local ?!?!?!
Euh, il ne faut probablement pas "une IP pour le réseau local", à moins que celui-ci soit NATé derrière une autre machine. Mais dans le principe de base, il faut: - une plage d'adresses avec (au moins) 2 adresses dedans pour le réseau routeur-firewall - une plage d'adresses avec au moins 2 adresses pour le réseau firewall-serveur web. - une plage d'adresses pour le réseau local.
Après, suivant l'endroit (ou les endroits) où il y a du NAT ou pas, il faut des adresses publiques ou privées pour chacun de ces réseaux.
Je reste sur un doute : pour moi, on a besoin que d'une seule IP, et le routeur fera le boulot de redirection. J'ai raison ou pas ?
Si le routeur externe fait du NAT, on peut en interne tout mettre avec des adresses IP privées, et faire le routage approprié (et/ou un deuxième niveau de NAT au niveau du firewall, bof bof). Les choix vont pas mal dépendre de ce que le routeur est capable de faire ou pas.
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et des différentes contraintes existantes.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Martinus
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et des différentes contraintes existantes.
C'est exactement cette subtilité avec les contraintes des deux solutions que je cherche à comprendre depuis quelques jours ... Et je n'ai rien trouvé d'assez clair ... il faut dire que je ne suis pas ingenieur ... mais bon
Vous connaissez un site bien fait la dessus ?
Maintenant, quand on utilise un firewall, en général, on met des adresses
publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le
réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et
des différentes contraintes existantes.
C'est exactement cette subtilité avec les contraintes des deux
solutions que je cherche à comprendre depuis quelques jours ...
Et je n'ai rien trouvé d'assez clair ... il faut dire que je ne suis
pas ingenieur ... mais bon
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. Mais ça va dépendre beaucoup de ce qu'on cherche à faire et des différentes contraintes existantes.
C'est exactement cette subtilité avec les contraintes des deux solutions que je cherche à comprendre depuis quelques jours ... Et je n'ai rien trouvé d'assez clair ... il faut dire que je ne suis pas ingenieur ... mais bon
Vous connaissez un site bien fait la dessus ?
Stephane Catteau
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)] Jacques Caron nous disait récement dans fr.comp.securite <news: :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
[1] Avec la complicité d'une mauvaise configuration du logiciel s'occupant de la NAT, évidement. -- Les promesses sont à l'images des cuisses d'une belle femme. Plus elles sont fermes, plus on a envie de passer outre, pour s'elever vers une occupation plus plaisante... S. C.
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)]
Jacques Caron nous disait récement dans fr.comp.securite
<news:opr3vkkfemq1hokb@news.free.fr> :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des
adresses publiques à l'extérieur et sur la DMZ, et du privé (avec
du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT
pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à
avoir une adresse IP publique pour les serveurs en DMZ. Au contraire
même, ça garantie que personne ne pourra accéder à un quelconque
serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure
que les paquets seront redirigé vers la DMZ. Dans le cas présent, à
savoir un petit réseau "privé" avec un seul serveur derrière, c'est
parfaitement jouable.
[1]
Avec la complicité d'une mauvaise configuration du logiciel s'occupant
de la NAT, évidement.
--
Les promesses sont à l'images des cuisses d'une belle femme. Plus elles
sont fermes, plus on a envie de passer outre, pour s'elever vers une
occupation plus plaisante... S. C.
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)] Jacques Caron nous disait récement dans fr.comp.securite <news: :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
[1] Avec la complicité d'une mauvaise configuration du logiciel s'occupant de la NAT, évidement. -- Les promesses sont à l'images des cuisses d'une belle femme. Plus elles sont fermes, plus on a envie de passer outre, pour s'elever vers une occupation plus plaisante... S. C.
Sebastien Reister
Stephane Catteau wrote:
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)] Jacques Caron nous disait récement dans fr.comp.securite <news: :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Si sur le papier je suis tous a fait d'accord avec toi stephane, en pratique, nater completement en frontal ta DMZ, c'est t'exposer a des problemes en plus sans gagner forcement en securité.
Surtous que ton exemple, une machine tu la met en DMZ avec une ip publique, qu'a partir du moment ou tu la passe en prod, soit apres installation, patchage, verification.
Stephane Catteau wrote:
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)]
Jacques Caron nous disait récement dans fr.comp.securite
<news:opr3vkkfemq1hokb@news.free.fr> :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des
adresses publiques à l'extérieur et sur la DMZ, et du privé (avec
du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT
pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à
avoir une adresse IP publique pour les serveurs en DMZ. Au contraire
même, ça garantie que personne ne pourra accéder à un quelconque
serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure
que les paquets seront redirigé vers la DMZ. Dans le cas présent, à
savoir un petit réseau "privé" avec un seul serveur derrière, c'est
parfaitement jouable.
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une
seule machine est chargé de nater toute les adresses de ta DMZ, si elle
a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Si sur le papier je suis tous a fait d'accord avec toi stephane, en
pratique, nater completement en frontal ta DMZ, c'est t'exposer a des
problemes en plus sans gagner forcement en securité.
Surtous que ton exemple, une machine tu la met en DMZ avec une ip
publique, qu'a partir du moment ou tu la passe en prod, soit apres
installation, patchage, verification.
[Publication limitée (désolé, problème de robot qui sucrait les Fu2)] Jacques Caron nous disait récement dans fr.comp.securite <news: :
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Si sur le papier je suis tous a fait d'accord avec toi stephane, en pratique, nater completement en frontal ta DMZ, c'est t'exposer a des problemes en plus sans gagner forcement en securité.
Surtous que ton exemple, une machine tu la met en DMZ avec une ip publique, qu'a partir du moment ou tu la passe en prod, soit apres installation, patchage, verification.
Stephane Catteau
Sebastien Reister nous disait récement dans fr.comp.securite <news:c1i5r8$uj4$ :
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la machine tombe, elle ne pourra de toute façon plus router les paquets vers la DMZ, quelques soient les adresses IP utilisés pour cette dernière. La contrainte matériel étant présente d'office, il me semble inutile d'alourdir (d'un point de vue financier) inutilement le problème. Autrement, c'est-à-dire si le financier n'est pas un facteur déterminant, autant prendre un serveur dédié chez un hébergeur quelconque. Ca règlerait le problème des adresses IP, celui de la mise en DMZ et celui de la bande passante (puisque l'entreprise est en ADSL).
-- Les promesses sont à l'images des cuisses d'une belle femme. Plus elles sont fermes, plus on a envie de passer outre, pour s'elever vers une occupation plus plaisante... S. C.
Sebastien Reister nous disait récement dans fr.comp.securite
<news:c1i5r8$uj4$1@s1.read.news.oleane.net> :
Si tu fais ça tu obtiens un beau SPOF (single point of failure),
si une seule machine est chargé de nater toute les adresses de ta
DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui
est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en
tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la
machine tombe, elle ne pourra de toute façon plus router les paquets
vers la DMZ, quelques soient les adresses IP utilisés pour cette
dernière. La contrainte matériel étant présente d'office, il me semble
inutile d'alourdir (d'un point de vue financier) inutilement le
problème.
Autrement, c'est-à-dire si le financier n'est pas un facteur
déterminant, autant prendre un serveur dédié chez un hébergeur
quelconque. Ca règlerait le problème des adresses IP, celui de la mise
en DMZ et celui de la bande passante (puisque l'entreprise est en
ADSL).
--
Les promesses sont à l'images des cuisses d'une belle femme. Plus elles
sont fermes, plus on a envie de passer outre, pour s'elever vers une
occupation plus plaisante... S. C.
Sebastien Reister nous disait récement dans fr.comp.securite <news:c1i5r8$uj4$ :
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la machine tombe, elle ne pourra de toute façon plus router les paquets vers la DMZ, quelques soient les adresses IP utilisés pour cette dernière. La contrainte matériel étant présente d'office, il me semble inutile d'alourdir (d'un point de vue financier) inutilement le problème. Autrement, c'est-à-dire si le financier n'est pas un facteur déterminant, autant prendre un serveur dédié chez un hébergeur quelconque. Ca règlerait le problème des adresses IP, celui de la mise en DMZ et celui de la bande passante (puisque l'entreprise est en ADSL).
-- Les promesses sont à l'images des cuisses d'une belle femme. Plus elles sont fermes, plus on a envie de passer outre, pour s'elever vers une occupation plus plaisante... S. C.
Nicob
On Wed, 25 Feb 2004 13:35:10 +0000, Stephane Catteau wrote:
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la machine tombe, elle ne pourra de toute façon plus router les paquets vers la DMZ, quelques soient les adresses IP utilisés pour cette dernière. La contrainte matériel étant présente d'office, il me semble inutile d'alourdir (d'un point de vue financier) inutilement le problème.
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ soit en adressage publique ou privé.
De plus, dans certains cas complexes, il est *très* pratique d'avoir les DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de perte d'adresses de réseau et de broadcast), les parties "visibles" et privées étant totalement indépendantes (resizing des DMZ, changement de leur plan d'adressage, ...)
Nicob
On Wed, 25 Feb 2004 13:35:10 +0000, Stephane Catteau wrote:
Si tu fais ça tu obtiens un beau SPOF (single point of failure),
si une seule machine est chargé de nater toute les adresses de ta
DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui
est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en
tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la
machine tombe, elle ne pourra de toute façon plus router les paquets
vers la DMZ, quelques soient les adresses IP utilisés pour cette
dernière. La contrainte matériel étant présente d'office, il me semble
inutile d'alourdir (d'un point de vue financier) inutilement le
problème.
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT
étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ
soit en adressage publique ou privé.
De plus, dans certains cas complexes, il est *très* pratique d'avoir les
DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de
perte d'adresses de réseau et de broadcast), les parties "visibles" et
privées étant totalement indépendantes (resizing des DMZ, changement de
leur plan d'adressage, ...)
On Wed, 25 Feb 2004 13:35:10 +0000, Stephane Catteau wrote:
Si tu fais ça tu obtiens un beau SPOF (single point of failure), si une seule machine est chargé de nater toute les adresses de ta DMZ, si elle a un pbm de onfig ou materiel, c'est toute ta DMZ qui est out.
Dans la mesure où l'ensemble s'appuyerait sur un routeur/firewall en tête de réseau, est-ce que ça changerait vraiment quelque chose ? Si la machine tombe, elle ne pourra de toute façon plus router les paquets vers la DMZ, quelques soient les adresses IP utilisés pour cette dernière. La contrainte matériel étant présente d'office, il me semble inutile d'alourdir (d'un point de vue financier) inutilement le problème.
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ soit en adressage publique ou privé.
De plus, dans certains cas complexes, il est *très* pratique d'avoir les DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de perte d'adresses de réseau et de broadcast), les parties "visibles" et privées étant totalement indépendantes (resizing des DMZ, changement de leur plan d'adressage, ...)
Nicob
T0t0
"Nicob" wrote in message news:
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ soit en adressage publique ou privé.
Sans compter le gaspillage d'adresses IP publiques si chères quand on split une plage pour adresses publiquement une DMZ. NAT powa !
De plus, dans certains cas complexes, il est *très* pratique d'avoir les DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de perte d'adresses de réseau et de broadcast), les parties "visibles" et privées étant totalement indépendantes (resizing des DMZ, changement de leur plan d'adressage, ...)
Tout à fait, d'un point de vue management, tout est centralisé sur le firewall (qui ne devient plus un spof si on fait du HA)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Nicob" <nicob@I.hate.spammers.com> wrote in message
news:pan.2004.02.25.14.10.57.102301@I.hate.spammers.com
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT
étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ
soit en adressage publique ou privé.
Sans compter le gaspillage d'adresses IP publiques si chères quand on
split une plage pour adresses publiquement une DMZ.
NAT powa !
De plus, dans certains cas complexes, il est *très* pratique d'avoir les
DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de
perte d'adresses de réseau et de broadcast), les parties "visibles" et
privées étant totalement indépendantes (resizing des DMZ, changement de
leur plan d'adressage, ...)
Tout à fait, d'un point de vue management, tout est centralisé sur le
firewall (qui ne devient plus un spof si on fait du HA)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Je ne peux que être d'accord avec Stéphane : la machine qui fait la NAT étant celle qui route, elle bloquera la DMZ si elle tombe, que la DMZ soit en adressage publique ou privé.
Sans compter le gaspillage d'adresses IP publiques si chères quand on split une plage pour adresses publiquement une DMZ. NAT powa !
De plus, dans certains cas complexes, il est *très* pratique d'avoir les DMZ en adressage privé et de gérer le tout au niveau du firewall (pas de perte d'adresses de réseau et de broadcast), les parties "visibles" et privées étant totalement indépendantes (resizing des DMZ, changement de leur plan d'adressage, ...)
Tout à fait, d'un point de vue management, tout est centralisé sur le firewall (qui ne devient plus un spof si on fait du HA)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Martinus
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
Je voulais savoir si un firewall de type pix 515 accompagné d'un switch de type startack 2 3300 peut suffire à effectuer ce type d'operation ?
[Snip]
Maintenant, quand on utilise un firewall, en général, on met des
adresses publiques à l'extérieur et sur la DMZ, et du privé (avec
du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT
pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à
avoir une adresse IP publique pour les serveurs en DMZ. Au contraire
même, ça garantie que personne ne pourra accéder à un quelconque
serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure
que les paquets seront redirigé vers la DMZ. Dans le cas présent, à
savoir un petit réseau "privé" avec un seul serveur derrière, c'est
parfaitement jouable.
Je voulais savoir si un firewall de type pix 515 accompagné d'un
switch de type startack 2 3300 peut suffire à effectuer ce type
d'operation ?
Maintenant, quand on utilise un firewall, en général, on met des adresses publiques à l'extérieur et sur la DMZ, et du privé (avec du NAT) sur le réseau local. [...]
Pourquoi ? :-/ Dans la mesure où l'on fait de toute façon de la NAT pour le LAN, il n'y a rien, pas même en terme de sécurité, qui oblige à avoir une adresse IP publique pour les serveurs en DMZ. Au contraire même, ça garantie que personne ne pourra accéder à un quelconque serveur ouvert par inadvertance sur le LAN[1], puisque la NAT assure que les paquets seront redirigé vers la DMZ. Dans le cas présent, à savoir un petit réseau "privé" avec un seul serveur derrière, c'est parfaitement jouable.
Je voulais savoir si un firewall de type pix 515 accompagné d'un switch de type startack 2 3300 peut suffire à effectuer ce type d'operation ?
