Bonjour, je vais profiter d'un nouveau transit pour modifier mon
architecture réseau (qui en fait n'existe pas actuellement car le
reseau a ete fait par des developpeurs)
Voici ma problematique :
J'ai plusieurs IP publiques, et je dois avoir les services suivants :
Reverse Proxy WWW
FTP (sachant que je dois monter du nfs depuis le LAN, ou alors proxy
ftp avec les petits problemes que ca entraine)
Concentrateur VPN
Ma question porte surtout sur le point suivant :
Est ce que je ne met qu'une carte reseau sur les machines publiques,
avec une autre machine (avec firewall et IDS) qui possede une carte
reseau qui va vers le lan ?
Ou alors est ce que je met deux cartes reseaux sur chaque machine
publique, une pour le publique justement, et une pour le privee (pas
directement ratache au lan)
Je sais bien que la deuxieme solution n'est pas tres courante, mais
j'avoue que j'ai un peu de réticence a utiliser la premiere solution.
Ca m'embete d'avoir par exemple du trafic NFS (depuis le FTP vers le
LAN) sur le meme lien physique que les données qui arrivent depuis
Internet. Avec cette solution, je pense que l'ecriture des regles sur
FW2 serait plus simple non ? Et ca me parait moins choquant que la
premiere archi, au final. mais bon, je suis tres loin de m'y connaitre
bien en secu
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
Dominique Blas
Bruno Bonfils wrote:
Bonjour, je vais profiter d'un nouveau transit pour modifier mon architecture réseau (qui en fait n'existe pas actuellement car le reseau a ete fait par des developpeurs)
Premier point : bravo et merci ... pour les schémas. En effet, trop de personnes postent ici en expliquant grosso modo ce qu'elles souhaitent. Mais, ne disposant pas du vocabulaire ou du temps imparti pour s'exprimer correctement, il n'en sort qu'une bouillie infâme de mots et on comprend rarement ce qu'elles souhaitent même à l'issue de la cinquième lecture. C'est donc une perte de temps pour tout le monde.
Là, vous avez pris le temps de faire des schémas propres et clairs donc bravo à nouveau.
Puisse votre courage et votre détermination faire école :-)
Pour répondre : la solution 2 est clairement la meilleure en terme de sécurité ... absolue. Mais, car il y a un mais, c'est une solution << riche >>. Par riche je n'entends pas que l'aspect coût de matériel mais également coûts de maintenance. Il faut les administrer les machines bicéphales, configurer les services pour qu'ils répondent sur les 2 interfaces (ou sur une seule), etc. ET plus c'est compliqué plus la probabilité d'erreur est importante ce qui impose de mettre en place une sur-couche procédurière (avec des consignes, des tests, etc) et donc là encore un surcoût. En outre, il est raisonnable d'ajouter un firewall interne afin d'éviter que le piratage d'une des machines ne conduise à une intrusion du réseau local.
C'est la raison pour laquelle on préfère en général la première solution. Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours. ET on n'a qu'un seul élément de secours à prévoir en cas de panne de cet élément clé.
Comme d'habitude c'est de la gestion de risques. Si vous estimez que le jeu en vaut la chandelle (*) alors optez pour la deuxième architecture (en ajoutant un FW interne) sinon prenez la 1.
db
(*) Qu'il faut minimiser au maximum les cas d'intrusion quel qu'en soit le prix.
-- email : usenet blas net
Bruno Bonfils wrote:
Bonjour, je vais profiter d'un nouveau transit pour modifier mon
architecture réseau (qui en fait n'existe pas actuellement car le
reseau a ete fait par des developpeurs)
Premier point :
bravo et merci ... pour les schémas.
En effet, trop de personnes postent ici en expliquant grosso modo ce
qu'elles souhaitent. Mais, ne disposant pas du vocabulaire ou du temps
imparti pour s'exprimer correctement, il n'en sort qu'une bouillie infâme de
mots et on comprend rarement ce qu'elles souhaitent même à l'issue de la
cinquième lecture. C'est donc une perte de temps pour tout le monde.
Là, vous avez pris le temps de faire des schémas propres et clairs donc
bravo à nouveau.
Puisse votre courage et votre détermination faire école :-)
Pour répondre :
la solution 2 est clairement la meilleure en terme de sécurité ... absolue.
Mais, car il y a un mais, c'est une solution << riche >>.
Par riche je n'entends pas que l'aspect coût de matériel mais également
coûts de maintenance. Il faut les administrer les machines bicéphales,
configurer les services pour qu'ils répondent sur les 2 interfaces (ou sur
une seule), etc. ET plus c'est compliqué plus la probabilité d'erreur est
importante ce qui impose de mettre en place une sur-couche procédurière
(avec des consignes, des tests, etc) et donc là encore un surcoût.
En outre, il est raisonnable d'ajouter un firewall interne afin d'éviter que
le piratage d'une des machines ne conduise à une intrusion du réseau local.
C'est la raison pour laquelle on préfère en général la première solution.
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au
final, plus simple dans la vie de tous les jours. ET on n'a qu'un seul
élément de secours à prévoir en cas de panne de cet élément clé.
Comme d'habitude c'est de la gestion de risques. Si vous estimez que le jeu
en vaut la chandelle (*) alors optez pour la deuxième architecture (en
ajoutant un FW interne) sinon prenez la 1.
db
(*) Qu'il faut minimiser au maximum les cas d'intrusion quel qu'en soit le
prix.
Bonjour, je vais profiter d'un nouveau transit pour modifier mon architecture réseau (qui en fait n'existe pas actuellement car le reseau a ete fait par des developpeurs)
Premier point : bravo et merci ... pour les schémas. En effet, trop de personnes postent ici en expliquant grosso modo ce qu'elles souhaitent. Mais, ne disposant pas du vocabulaire ou du temps imparti pour s'exprimer correctement, il n'en sort qu'une bouillie infâme de mots et on comprend rarement ce qu'elles souhaitent même à l'issue de la cinquième lecture. C'est donc une perte de temps pour tout le monde.
Là, vous avez pris le temps de faire des schémas propres et clairs donc bravo à nouveau.
Puisse votre courage et votre détermination faire école :-)
Pour répondre : la solution 2 est clairement la meilleure en terme de sécurité ... absolue. Mais, car il y a un mais, c'est une solution << riche >>. Par riche je n'entends pas que l'aspect coût de matériel mais également coûts de maintenance. Il faut les administrer les machines bicéphales, configurer les services pour qu'ils répondent sur les 2 interfaces (ou sur une seule), etc. ET plus c'est compliqué plus la probabilité d'erreur est importante ce qui impose de mettre en place une sur-couche procédurière (avec des consignes, des tests, etc) et donc là encore un surcoût. En outre, il est raisonnable d'ajouter un firewall interne afin d'éviter que le piratage d'une des machines ne conduise à une intrusion du réseau local.
C'est la raison pour laquelle on préfère en général la première solution. Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours. ET on n'a qu'un seul élément de secours à prévoir en cas de panne de cet élément clé.
Comme d'habitude c'est de la gestion de risques. Si vous estimez que le jeu en vaut la chandelle (*) alors optez pour la deuxième architecture (en ajoutant un FW interne) sinon prenez la 1.
db
(*) Qu'il faut minimiser au maximum les cas d'intrusion quel qu'en soit le prix.
-- email : usenet blas net
Thomas
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$, Dominique Blas wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$626a14ce@news.free.fr>,
Dominique Blas <cacaboum@nospam.int> wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au
final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple
plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en
l'occurence dans la sécurité
--
si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE
(seulement dans le 1/4 h où mon ordi est mis en veille,
donc je vous invite à réclamer à free : l'acces à arp -s,
ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC"
"petit Free qui devient grand, gêne les requins blancs"
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$, Dominique Blas wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
-- si je dors : wakeonlan -i tDeContes.hd.free.fr 00:03:93:AF:45:AE (seulement dans le 1/4 h où mon ordi est mis en veille, donc je vous invite à réclamer à free : l'acces à arp -s, ou la possibilité de rediriger le NAT sur l'adresse de broadcast :-) )
"don't put your PC out of the window, put windows out of your PC" "petit Free qui devient grand, gêne les requins blancs"
Dominique Blas
Thomas wrote:
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$, Dominique Blas wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
Il n'y pas que chez l'élève brillante de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info. Mais cela nécessite tout de même quelques dispositions,
db -- email : usenet blas net
Thomas wrote:
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$626a14ce@news.free.fr>,
Dominique Blas <cacaboum@nospam.int> wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au
final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple
plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en
l'occurence dans la sécurité
Il n'y pas que chez l'élève brillante de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info.
Mais cela nécessite tout de même quelques dispositions,
j'ai pas compris ce que fait le 2 eme lien du vpn dans le 1er shema
In article (Dans l'article) <41f141e8$0$14930$, Dominique Blas wrote (écrivait) :
Toute la sécurité est concentrée sur un élément c'est vrai mais c'est, au final, plus simple dans la vie de tous les jours.
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
Il n'y pas que chez l'élève brillante de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info. Mais cela nécessite tout de même quelques dispositions,
db -- email : usenet blas net
Dominique Blas
Thomas wrote:
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
Il n'y pas que chez la brillante élève de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info. Mais cela nécessite tout de même quelques dispositions,
db -- email : usenet blas net
Thomas wrote:
les programmeurs ada disent souvent, que le fait que qqch soit simple
plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en
l'occurence dans la sécurité
Il n'y pas que chez la brillante élève de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info.
Mais cela nécessite tout de même quelques dispositions,
les programmeurs ada disent souvent, que le fait que qqch soit simple plutot qu'une usine à gaz, ca compte bcp dans sa fiabilité, et donc en l'occurence dans la sécurité
Il n'y pas que chez la brillante élève de Charles que cela est vrai c'est
vrai de manière générale et notamment en sécurité des systèmes d'info. Mais cela nécessite tout de même quelques dispositions,
db -- email : usenet blas net
David Bizeul
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Mais vu ta typologie réseau qui semble assez simple, je privilégierai plutôt le fait de rester sur quelque chose de simple et de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal. Rien ne t'empêche de mettre en place une DMZ avec des ressources publiques et une autre avec des ressources privées. Cette seconde DMZ, tu l'as déjà conceptualisée par ton concentrateur VPN
Sur la DMZ publique, tu installes tes adresses IP publiques Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour le NAT, il faut un Firewall qui soit capable de comprendre le protocole).
En espérant que cela te donne une autre piste de réflexion
Personnellement, je rejoins l'avis de Dominique pour définir la solution
2 comme étant une solution pour riches. Je connais des environnements
client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela
dans un but précis. Mais vu ta typologie réseau qui semble assez simple,
je privilégierai plutôt le fait de rester sur quelque chose de simple et
de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une
DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal.
Rien ne t'empêche de mettre en place une DMZ avec des ressources
publiques et une autre avec des ressources privées. Cette seconde DMZ,
tu l'as déjà conceptualisée par ton concentrateur VPN
Sur la DMZ publique, tu installes tes adresses IP publiques
Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle
ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour
le NAT, il faut un Firewall qui soit capable de comprendre le protocole).
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Mais vu ta typologie réseau qui semble assez simple, je privilégierai plutôt le fait de rester sur quelque chose de simple et de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal. Rien ne t'empêche de mettre en place une DMZ avec des ressources publiques et une autre avec des ressources privées. Cette seconde DMZ, tu l'as déjà conceptualisée par ton concentrateur VPN
Sur la DMZ publique, tu installes tes adresses IP publiques Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour le NAT, il faut un Firewall qui soit capable de comprendre le protocole).
En espérant que cela te donne une autre piste de réflexion
Bruno Bonfils
David Bizeul writes:
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Mais vu ta typologie réseau qui semble assez simple, je privilégierai plutôt le fait de rester sur quelque chose de simple et de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal. Rien ne t'empêche de mettre en place une DMZ avec des ressources publiques et une autre avec des ressources privées. Cette seconde DMZ, tu l'as déjà conceptualisée par ton concentrateur VPN
Ben voila, y a aussi, de toute facon je dois avoir une 'DMZ' privée obligatoire pour le VPN, donc t'a qu'a faire, autant en profiter de cette patte.
Sur la DMZ publique, tu installes tes adresses IP publiques Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour le NAT, il faut un Firewall qui soit capable de comprendre le protocole).
Je ne suis pas sur de comprendre l'interet de ce mécanisme. Je ne comptais mettre aucun service publique sur la patte (publique donc) du FW2. Je pensais le mettre pour le masquerading du LAN et les regles de firewall venant de la DMZ privée.
En espérant que cela te donne une autre piste de réflexion
Disons que ca ma donne au moins l'impression de pas etre totalement fou :)
Merci a vous (ceux qui m'ont repondu)
David Bizeul <whatever@nomail.com> writes:
Personnellement, je rejoins l'avis de Dominique pour définir la solution
2 comme étant une solution pour riches. Je connais des environnements
client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela
dans un but précis. Mais vu ta typologie réseau qui semble assez simple,
je privilégierai plutôt le fait de rester sur quelque chose de simple et
de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une
DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal.
Rien ne t'empêche de mettre en place une DMZ avec des ressources
publiques et une autre avec des ressources privées. Cette seconde DMZ,
tu l'as déjà conceptualisée par ton concentrateur VPN
Ben voila, y a aussi, de toute facon je dois avoir une 'DMZ' privée
obligatoire pour le VPN, donc t'a qu'a faire, autant en profiter de
cette patte.
Sur la DMZ publique, tu installes tes adresses IP publiques
Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle
ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour
le NAT, il faut un Firewall qui soit capable de comprendre le
protocole).
Je ne suis pas sur de comprendre l'interet de ce mécanisme. Je ne
comptais mettre aucun service publique sur la patte (publique donc) du
FW2. Je pensais le mettre pour le masquerading du LAN et les regles de
firewall venant de la DMZ privée.
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Mais vu ta typologie réseau qui semble assez simple, je privilégierai plutôt le fait de rester sur quelque chose de simple et de bien fait (cf KISS). De fait, on assigne un niveau de confiance à une DMZ, que tu n'aies pas confiance dans ta DMZ publique, c'est normal. Rien ne t'empêche de mettre en place une DMZ avec des ressources publiques et une autre avec des ressources privées. Cette seconde DMZ, tu l'as déjà conceptualisée par ton concentrateur VPN
Ben voila, y a aussi, de toute facon je dois avoir une 'DMZ' privée obligatoire pour le VPN, donc t'a qu'a faire, autant en profiter de cette patte.
Sur la DMZ publique, tu installes tes adresses IP publiques Sur ta DMZ privée tu installes le serveur FTP en adresse privée et celle ci sera natée par ton FW-2 en adresse IP publique (attention au FTP pour le NAT, il faut un Firewall qui soit capable de comprendre le protocole).
Je ne suis pas sur de comprendre l'interet de ce mécanisme. Je ne comptais mettre aucun service publique sur la patte (publique donc) du FW2. Je pensais le mettre pour le masquerading du LAN et les regles de firewall venant de la DMZ privée.
En espérant que cela te donne une autre piste de réflexion
Disons que ca ma donne au moins l'impression de pas etre totalement fou :)
Merci a vous (ceux qui m'ont repondu)
Dominique Blas
David Bizeul wrote:
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement
imposée par des considérations de sécurité.
db -- email : usenet blas net
David Bizeul wrote:
Personnellement, je rejoins l'avis de Dominique pour définir la solution
2 comme étant une solution pour riches. Je connais des environnements
client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela
dans un but précis.
Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement
Personnellement, je rejoins l'avis de Dominique pour définir la solution 2 comme étant une solution pour riches. Je connais des environnements client où l'on peut trouver jusqu'à 6 interfaces par serveur, et cela dans un but précis. Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement
imposée par des considérations de sécurité.
db -- email : usenet blas net
Cedric Blancher
Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :
Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement imposée par des considérations de sécurité.
Une carte quad ne coûte pas si cher que ça. Les DLink 570 se trouvaient à 140¤ HT. On en trouve d'occasion à moins de 100¤. Maintenant il est vrai que si tu vas taper dans du Intel e1000 Quad, effectivement, la porte-feuille va souffrir. Même les cartes bi-ether sont relativement bon marché.
Sinon, on a toujours la solution VLAN si le switch qui est derrière supporte. C'est une solution de segmentation qui peut valoir le coup, à condition que le trafic ne soit pas trop important sur le trunk et que les impératifs de segmentation n'impliquent pas un niveau de sécurité ne souffrant pas l'éventualité d'une défaillance du code de gestion des VLAN au niveau du switch ou du firewall qui permettrait une fuite.
-- O: Je crois qu'un système nouveau permettant de détecter les odeurs artificielles est en cours pour les nouvelles générations de micros. M: et mon cul ? -+- in: Guide du Cabaliste Usenet - Bien configurer son odeur -+-
Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :
Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement
imposée par des considérations de sécurité.
Une carte quad ne coûte pas si cher que ça. Les DLink 570 se trouvaient
à 140¤ HT. On en trouve d'occasion à moins de 100¤. Maintenant il
est vrai que si tu vas taper dans du Intel e1000 Quad,
effectivement, la porte-feuille va souffrir. Même les cartes
bi-ether sont relativement bon marché.
Sinon, on a toujours la solution VLAN si le switch qui est derrière
supporte. C'est une solution de segmentation qui peut valoir le coup, à
condition que le trafic ne soit pas trop important sur le trunk et que les
impératifs de segmentation n'impliquent pas un niveau de sécurité ne
souffrant pas l'éventualité d'une défaillance du code de gestion des
VLAN au niveau du switch ou du firewall qui permettrait une fuite.
--
O: Je crois qu'un système nouveau permettant de détecter les odeurs
artificielles est en cours pour les nouvelles générations de micros.
M: et mon cul ?
-+- in: Guide du Cabaliste Usenet - Bien configurer son odeur -+-
Le Tue, 25 Jan 2005 16:16:09 +0000, Dominique Blas a écrit :
Ce qui n'exclue pas le caractère riche de la solution si elle est uniquement imposée par des considérations de sécurité.
Une carte quad ne coûte pas si cher que ça. Les DLink 570 se trouvaient à 140¤ HT. On en trouve d'occasion à moins de 100¤. Maintenant il est vrai que si tu vas taper dans du Intel e1000 Quad, effectivement, la porte-feuille va souffrir. Même les cartes bi-ether sont relativement bon marché.
Sinon, on a toujours la solution VLAN si le switch qui est derrière supporte. C'est une solution de segmentation qui peut valoir le coup, à condition que le trafic ne soit pas trop important sur le trunk et que les impératifs de segmentation n'impliquent pas un niveau de sécurité ne souffrant pas l'éventualité d'une défaillance du code de gestion des VLAN au niveau du switch ou du firewall qui permettrait une fuite.
-- O: Je crois qu'un système nouveau permettant de détecter les odeurs artificielles est en cours pour les nouvelles générations de micros. M: et mon cul ? -+- in: Guide du Cabaliste Usenet - Bien configurer son odeur -+-