Mise en place d'une DMZ

par **leatherface** » 14 Juin 2009 20:08

Bonjour à tous,

Je cherche la meilleure solution pour la mise en place d'une "vraie" DMZ.
Voici mon schéma existant:
firewall frontal IPcop--->1 reverse proxy externe----->1reverse proxy interne----> les serveurs.
Les 2 reverse proxys fonctionnent en diode à savoir que c'est le RP interne qui requête l'externe et qui achemine les requêtes.
Les 2 RP sont sur le même réseau ce qui n'est pas terrible. Ce que je voudrais c'est isoler l'agent externe dans une DMZ et pour ca je souhaite mettre en place un deuxième firewall entre l'externe et l'interne.

Quelle solution (firewall) me conseillez vous?

par **ccnet** » 14 Juin 2009 20:55

leatherface a écrit:Bonjour à tous,

Je cherche la meilleure solution pour la mise en place d'une "vraie" DMZ.

C'est quoi une fausse dmz ?

firewall frontal IPcop--->1 reverse proxy externe----->1reverse proxy interne----> les serveurs.

Aucune utilité.

Les 2 reverse proxys fonctionnent en diode à savoir que c'est le RP interne qui requête l'externe et qui achemine les requêtes.

Comment voulez vous qu'un reverse proxy interne "requête" le reverse externe alors que les requêtes utilisateurs arrivent sur le reverse externe ?

l'agent externe

Qu'est ce selon vous ?

je souhaite mettre en place un deuxième firewall entre l'externe et l'interne.

Autre mauvaise idée.

Une saine lecture :
http://www.amazon.fr/S%C3%A9curit%C3%A9 ... 691&sr=1-4
pour vous remettre les idées en place et surtout évaluer les enjeux et les contre mesures.

par **leatherface** » 14 Juin 2009 22:46

Bonsoir

je pense qu'avant de répondre faux à tout il faudrait se renseigner.
Le système de reverse proxy en diode ce n'est pas une lubie de ma part mais bel et bien un produit que la société dans laquelle je travaille vend.
Le fait que les requêtes arrivent sur l'agent externe et soient requetées par l'agent interne (agent=RP) est le principe du fonctionnement de la diode ou cloisonnement réseau. Ce système evite tout flux direct sur les serveurs et donc les attaques par rebond par exemple. Pour terminer ma question ne portait pas sur l'utilité du système de reverse proxy (les clients chez qui c'est installé le font pour moi) mais sur le choix de mon 2e FW.

Je vais donc me débrouiller seul. Mais je vous recommande de vous informer un peu. Vous n'avez pas la science infuse.

par **Franck78** » 15 Juin 2009 00:50

Code: Tout sélectionner: firewall frontal IPcop--->1 reverse proxy externe----->1reverse proxy interne----> les serveurs. Les 2 reverse proxys fonctionnent en diode à savoir que c'est le RP interne qui requête l'externe et qui achemine les requêtes.

Tu voulais sans dire que c'est l'externe qui requète l'interne...
CCNET aurait alors compris ;-)

Et une définition de 'RP' eu été bienvenue!

Tu places un nouveau Firewall entre les deux PROXY.
Pour ne pas avoir a jongler avec l'adressage IP existant, ce FW devrait être transparent (même numéro de réseau sur ses pattes).
Ca élimine IPCop ;-)

Une bonne dose de brctl et de IPtablles devrait suffire sur une debian, comme ceci par exemple:
http://www.hackinthebox.org/modules.php ... =0&thold=0

par **tomtom** » 15 Juin 2009 10:40

Ha la la le troll classiqe sur les DMZ... :p

L'architecture proposée est classique elle aussi, on la trouve dans beaucoup de banques ou autres entreprises hebergeant des serveurs largement accessibles.

Donc, une "vraie" DMZ, c'est un bout de réseau encadré par 2 firewalls.

Quand on n'a pas beaucoup d'argent, ou quand on n'a pas envie de le dépneser dans le réseau, on utilise souvent un seul firewall qui joue le rôle de 2. C'est le cas typique d'IPCop.

Code: Tout sélectionner: Internet ------------- FW ------------ réseau interne | | DMZ

Dans ce cas, le FW joue plusieurs rôle :
- S'assurer que les connexions de l'exterieur ne peuvent aller que sur une machine dans la DMZ (je dirais l'agent externe dans votre phraséologie)

- S'assurer que seule une machine de la DMZ peut acceder aux serveurs en interne (l'agent interne)

Cette architecture apporte deja un bon niveau de sécurité, mais pas forcement suffisant.
En effet, une exploitation d'une faille sur l'agent externe peut permettre à un attaquant de prendre le controle de cette machine, et dans ce cas aucun équipement de filtrage ne protège l'agent interne.
On peut donc proposer d'augmenter le cloisonnement ainsi :

Code: Tout sélectionner: Internet ------------- FW ---------------------- FW------ réseau interne | | | | | Agent interne | Agent externe

Ainsi, on peut s'assurer qu'un assaillant ayant pris le controle de l'agent externe est toujours isolé, et ne peut attaquer "simplement" l'agent interne. De même, si il parvenait à prendre le controle de l'agent interne, il est toujours isolé dans une zone à part.
On parle de DMZ interne et de DMZ externe.

Il est possible de positionner les DMZ différement, sur le FW "interne" par exemple.

Pour ce qui est du choix des firewalls, on ne pourra malheureusement pas répondre dans l'absolu. Tout dépnd de ce que l'on en attend.
Une "bonne pratique" est d'en utiliser deux différents, c'est une règle qui se discute. Je n'entre pas dans le troll.
Ensuite, il faut regarder les paramètres : Performances réseau. Possibilité de les mettre en haute dispo, redondances. Facilité d'administration. Nombre de règles à gérer...
Tout ceci dépnd beaucoup de l'activité du client, du nombre de personnes pour exploiter le bouzin, etc.

Ca depend aussi du role des agents.
Typiquement, l'agent externe fait un filtrage basique (adresses sources, validité des requetes, etc) et surtout on lui demand ede la performace (c'est en général le end-point SSL, il doit donc traiter beaucoup de requete et gerer la crypto).
On met plutot sur l'agent interne des fonctions de filtrage plus fines, plus proches du metier (URL accessibles, en liste blanche/liste noire, droits d'accès, pourquoi pas authentification etc.)

J'aime les devinettes... .Solutions NSOne (vu les termes employés) ?
Pour équilibrer la balance, je citerai aussi un gros concurrent : DenyAll

Pour Franck : Pourquoi les firewalls devraient-ils etre forcement transparents ?

A+

t.

par **leatherface** » 15 Juin 2009 16:51

Franck78 a écrit:
Code: Tout sélectionner
firewall frontal IPcop--->1 reverse proxy externe----->1reverse proxy interne----> les serveurs. Les 2 reverse proxys fonctionnent en diode à savoir que c'est le RP interne qui requête l'externe et qui achemine les requêtes.

Tu voulais sans dire que c'est l'externe qui requète l'interne...
CCNET aurait alors compris
Et une définition de 'RP' eu été bienvenue!

Non Franck c'est bien l'interne qui requête l'externe. C'est un mécanisme d'inversion des flux.
L'agent externe recoit les requêtes, via un mécanisme de polling toutes les 10 ms l'agent interne vient requêter l'externe et achemine les requêtes si elles doivent l'être. Bien sur les RP (pour reverse proxy) intègrent eux mêmes des mécanismes de sécurité telles que des sondes IDS, un analyseur protocolaire (rfc http compliant) .....
On parle alors de diode car utilisée conjointement avec le Firewall les flux ne sont plus que sortants et plus entrants.

par **leatherface** » 15 Juin 2009 16:53

Tomtom bravo il s'agit de Nsone. Je suis Ingénieur avant-vente chez eux.

par **Franck78** » 15 Juin 2009 22:09

IPCop c'est l'implémentation de la 'colapsed DMZ'. Y'en a qui disent 'DMZ du pauvre'.

Je suggèrais 'transparent' car ça ne remet pas en cause l'adressage réseau existant. Vu que c'est un nouvel équipement peut être pas anticipé, autant pas trop chambouler le réseau selon moi.
Et commei il y déja un IPCop, une debian ne peut faire tache ;-)

par **ccnet** » 16 Juin 2009 00:29

leatherface a écrit:Bonsoir

je pense qu'avant de répondre faux à tout il faudrait se renseigner.
Le système de reverse proxy en diode ce n'est pas une lubie de ma part mais bel et bien un produit que la société dans laquelle je travaille vend.
[ ... ] Mais je vous recommande de vous informer un peu. Vous n'avez pas la science infuse.

Si vous aviez commencé par là, en donnant le nom de votre produit, je n'aurai pas été le seul à avoir des doutes ...

Pour le reste Tomtom a donné l'essentiel de ce que l'on peut dire avec si peu de données en entrée. J'ai été en discussion avec DenyAll il y a assez longtemps pour un projet. Leur opacité sur les produits n'était pas engageante. Opacité tarifaire un peu aussi.

Une chose m'étonne : comment ce fait il que cette question, compte tenu de l'entreprise et de son activité, arrive ici ? Etant les vendeurs (concepteurs ?) du produit, vous avez infiniment plus de clés que nous pour répondre à ces questions.

par **tomtom** » 16 Juin 2009 08:33

ccnet a écrit:J'ai été en discussion avec DenyAll il y a assez longtemps pour un projet. Leur opacité sur les produits n'était pas engageante. Opacité tarifaire un peu aussi.

Ha, tiens ?
De mon coté, même si le poduit n'est evidement pas une panacée universelle, j'ai trouvé que les devs étaient plutot à l'écoute et que le fonctionnement du produit était assez clair... Enfin, ça remonte aussi à quelques années....

Pour les tarifs, je dirais que vu que les sociétés qui utilisent ces produits en ont les moyens, c'est un buisness plan comme un autre....
Puis ce n'est pas si simple de faire de bons reverse proxys filtrants

t.

par **ccnet** » 16 Juin 2009 09:16

Sur l'aspect tarifaire, ce n'était pas tant le prix lui même, que la facturation selon les modules, le nombre d'utilisateurs, ou de serveurs, j'en garde le souvenir de quelque chose de compliqué. Cela d'autant plus qu'une fonctionnalité n'était pas encore disponible mais en développement. Le tarif était en dev aussi.

Mise en place d'une DMZ

Mise en place d'une DMZ

Re: Mise en place d'une DMZ

Qui est en ligne ?