Besoin de conseils sur mise en place Passerelle et architech

[fcreach]

Bonjour,

Nouveau venu sur ce forum, je m'aperçois que vous êtes de nombreux experts en SME et en sécurité, je me permet donc de vous faire part de mes interrogations.

Nous avons mis une passerelle SME en place, elle doit nous servir à plusieurs choses :

1 - Passerelle vers liaison SDSL / Pare-feu
1.1 : Stockage et analyse de logs en liiaison avec notre Active Directory
2 - VPN entre 2 de nos sites (avec openvpn)** + clients nomades en pptp

Notre architecture est simple, l'ensemble de notre lan est physiquement derrière la SME.
La box SDSL est complètement "ouverte".

Voici quelques informations complémentaires :

1- Passerelle vers liaison SDSL / Pare-feu
La passerelle vers la liaison SDSL est fonctionnelle, mais le pare-feu nous pose quelques difficultés.
En effet, nous avons besoin d'accéder à certains serveurs web depuis l'extérieur, mais pour l'instant cela fonctionne mal. Reverse proxy a été mis en place mais pose des problèmes pour les sous-répertoires, et surtout nous n'arrivons pas rediriger du SSL.

Vu que nous disposons de plusieurs adresses ip externes, pouvons nous configurer la sme afin qu'elle laisse passer le flux sur certains ports quand c'est une certaine adresse ip qui est demandée ?
Par exemple :

Mon ip_externe1 port 80 ---------> sur le serveur passerelle SME port 80
Mon ip_externe1 port 443 ---------> sur le serveur passerelle SME port 443 (avec son propre certificat)
Mon ip_externe1 port 22 ---------> sur le serveur passerelle SME port 22


Mon ip_externe2 port 80 ---------> sur le serveur 2 port 80

Mon ip_externe3 port 80 ---------> sur le serveur 3 port 80
Mon ip_externe3 port 443 ---------> sur le serveur 3 port 443 (avec son propre certificat)

Mon ip_externe4 port 22 ---------> sur le serveur 4 port 22
etc...

Cela faciliterait grandement les choses (plus de reverse proxy ni de pb de certificat).

1.1 - Stockage et analyse de logs en liiaison avec notre Active Directory
Que conseillez-vous à ce propos ? car nous souhaitons que les logs contiennent le nom de l'utilisateur windows en cours et non son adresse ip. Notre domaine est sous windows 2008.

2. Le VPN entre nos sites
Nous rencontrons des difficultés entre nos sites. Par exemple, il nous est impossible d'accéder à un serveur présent sur le site distant sur le port 80, alors que les autres ports fonctionnent. La seule façon d'y accéder est de désactiver squid sur le serveur du site distant.

Exemple :
Si squid est activé sur le site 1
Site 2 appelle ip_interne:80 (physiquement sur le site 1) -> Erreur http squid
Site 2 appelle ip_interne:9090 (physiquement sur le site 1) -> Arrive sur le site 1, sur le serveur avec l'ip_interne:9090

Si squid est désactivé sur le site 1
Site 2 appelle ip_interne:80 (physiquement sur le site 1) -> Arrive sur le site 1, sur le serveur avec l'ip_interne:80
Site 2 appelle ip_interne:9090 (physiquement sur le site 1) -> Arrive sur le site 1, sur le serveur avec l'ip_interne:9090

D'autres ports semblent concernés par ce pb. Par exemple nous arrivons à faire la mise à jour distante de clients léger présents sur le site 1 depuis ce même site, mais pas à mettre à jour les clients légers présents sur le site 2 depuis le site 1.

Merci d'avance les renseignements que vous pourrez m'apporter.

[ccnet]

Quelques réflexions générales.
Plusieurs ip fixes, plusieurs serveurs web ... tout cela me laisse penser que, par rapport à l'existant et aux besoins SME n'est pas une bonne solution pour vous du point de vue sécurité. Utiliser SME signifie ne pas avoir de dmz. C'est déjà structurellement un problème lorsque l'on héberge plusieurs serveurs web. Sans compter le proxy, la messagerie. J'ignore si vous êtes près à reconsidérer ce point. Je ne vais donc pas plus loin.

Et plus précisément :

Vu que nous disposons de plusieurs adresses ip externes, pouvons nous configurer la sme afin qu'elle laisse passer le flux sur certains ports quand c'est une certaine adresse ip qui est demandée ?

SME n'est pas conçu pour assurer correctement le support d'ip publiques multiples.

Cela faciliterait grandement les choses (plus de reverse proxy ni de pb de certificat).

Mais dégrade fortement la sécurité. Aujourd'hui la présence d'un firewall applicatif (reverse proxy par exemple) devant un serveur web est pratiquement indispensable. Voir Vulture.

1.1 : Stockage et analyse de logs en liiaison avec notre Active Directory

La consultation de squid-cache.org devrait vous donner la solution. Elle a été aussi donné je pense sur un des forums Ixus.

2 - VPN entre 2 de nos sites (avec openvpn)** + clients nomades en pptp

Pptp est obsolète et peu sûr. Il ne devrait pas être utilisé.

Je ne sais pas ce qui motive le choix de SME. Je constate encore une fois que l'on a raisonné d'abord en terme de solutions techniques avant d'avoir posé entièrement le problème. Pour ce que je perçois des besoins SME ne convient pas.

[jdh]

(Voilà un fil parti sur de bonnes bases : une présentation "fournie" du problème suivie d'une analyse impeccable ... Quand on fait un effort de présentation, on obtient des réponses !)


Je confirme le point de vue de ccnet : SME n'est pas conçu pour gérer plusieurs adresses ip publiques.
De plus, les (autres) besoins semblent dépasser de loin le cadre SME.

Gérer des adresses ip publiques, les renvois utiles, une dmz, un vpn avec d'autres sites, c'est l'affaire d'un firewall. Le plus à même de faire tout cela est surement pfSense. Nul besoin d'un pc puissant : penser à recycler un "vieux" PC type P4 2,4 + 1 G de mémoire + 40 G de disque + 3 cartes réseaux.

Construire une DMZ, y installer un reverse proxy (1 seul pour tous les serveurs web en http). Prévoir une adresse ip différente pour chaque serveur web en https. Gérer le "NAT Outbound" : chaque serveur en https doit recevoir et sortir avec sa propre ip ...

Attention les règles de pfSense s'écrivent (en utilisant généreusement les alias) selon la carte d'arrivée sur le firewall !

Pour le VPN, pensez à IPSEC pour le site à site et OpenVPN pour les nomades. Je plussoie la remarque concernant pptp, aujourd'hui dépassé !

[fcreach]

Merci Bp pour vos réponses, il faut croire que j'ai été mal conseillé jusque là...
Je vais étudier les solutions évoquées, mais est-ce qu'une solution comme pfSense répond à toutes mes attentes (analyse de logs en lien avec l'AD...), ou est-il préférable de déléguer cela à un autre serveur ?
Merci

[ccnet]

est-ce qu'une solution comme pfSense répond à toutes mes attentes

Difficile à dire si vous ne les exposez pas toutes ... Mais la richesse fonctionnelle de Pfsense est sans commune mesure avec Ipcop. En particulier le support d'adresses ip multiples sur Wan, le nat Outbound, les Vlans, les dmz multiples, ...

(analyse de logs en lien avec l'AD...), ou est-il préférable de déléguer cela à un autre serveur ?

La réponse est ailleurs. Le proxy n'est pas à sa place sur le firewall, ce doit être une machine séparée, placée en dmz. Nous avons déjaà expliqué pourquoi à plusieurs reprises sur les forums Ixus et Pfsense.
Squid et ses addons vous permettront d'obtenir les logs que vous souhaitez.

[fcreach]

Bonjour,

Désolé pour le "déterrage" de post.

Nous avons commencé à travailler sur la mise en place de pfsense, mais nous sommes confronté à un difficulté.
Après discussion en interne, il apparait plus sécurisant d'avoir 3 interfaces réseaux : wan, lan et dmz.
Seulement, la plupart de nos serveurs sont aujourd'hui virtualisés, l'intérêt de la 3ème carte réseau me parait donc plus que limité, car nous ne pourrons pas séparé les réseaux physiquement.

Je pense donc laisser 2 cartes réseaux, l'une pour le wan, l'autre pour la dmz, et donc placer le lan et son proxy dans la dmz.

Qu'en pensez-vous ?

Merci

[jdh]

Personnellement, je conseille plusieurs choses nettes et claires :

- on ne virtualise pas, en production, un firewall,
- on ne virtualise pas, en production, des machines situées dans des zones réseau différentes sur le même hôte de virtualisation.

Dans les 2 cas, il faut comprendre que si l'ôte est compromis, toutes les VM sont compromises, et par conséquent n'importe quelle zone !


NB : Je ne suis pas une référence, je répète là l'avis de beaucoup de professionnels sérieux et impliqués dans la sécurité réseaux ...

[fcreach]

Bonjour jdh,

Je te rassure, le firewall n'est pas virtualisé.
Pour ta 2ème remarque, c'est également mon point de vue, mais voila, on a pas le choix !

Merci

[sibsib]

Hello,

Je plussoie largement l'avis de JDH.

Ceci dit, il est possible en virtualisation d'avoir plusieurs cartes réseaux reliées chacune à un switch virtuel différent.

En ce sens, il est possible d'avoir une architecture de ce type :

Code: Tout sélectionner

Internet
    |
    |        --------------------------------------
    |        |                                    |
Firewall ----|--- Vswitch DMZ                     |
    |        |                                    |
    |        |                        VM Host     |
    |        |                                    |
   Lan ------|--- Vswitch LAN                     |
             |                                    |
             --------------------------------------



Mais évidemment, si le VM Host est compromis, c'est la cata.

A+,
Pascal, spécialiste en Ascii ART

[jdh]

Il est notable que la plupart des hôtes de virtualisation sont en train de mettre en place des firewalls au niveau de l'hôte. Ce n'est certainement pas que du marketing !

cf http://www.vmware.com/pdf/vsz_10U1_introduction.pdf
cf http://wiki.xensource.com/xenwiki/XenNetworking (section Bridging)
cf (pour le fun) http://social.technet.microsoft.com/For ... 13bf93d278

La question est aussi :
- puis-je avoir le même réseau SAN (sur carte giga dédiée) pour les différents hôtes de virtualisation ?

[ccnet]

- on ne virtualise pas, en production, des machines situées dans des zones réseau différentes sur le même hôte de virtualisation.

Dans les 2 cas, il faut comprendre que si l'ôte est compromis, toutes les VM sont compromises, et par conséquent n'importe quelle zone !

C'est aussi mon avis. Néanmoins on peut réduire le risque au moyen de Vlans pour cloisonner le trafic entre les vm et le firewall.

[unnilennium]

- on ne virtualise pas, en production, des machines situées dans des zones réseau différentes sur le même hôte de virtualisation.

Dans les 2 cas, il faut comprendre que si l'ôte est compromis, toutes les VM sont compromises, et par conséquent n'importe quelle zone !

C'est aussi mon avis. Néanmoins on peut réduire le risque au moyen de Vlans pour cloisonner le trafic entre les vm et le firewall.

heu je me trompe ou vlan ou pas si l'hote est compromis il aura accés pareil aux 2 vlan ?

[fcreach]

Sauf si l'esx contient plusieurs cartes réseaux, et qu'elles sont attribués aux serveurs virtuels en fonction des VLAN. (je ne sais pas si je me fais comprendre !)

[ccnet]

- on ne virtualise pas, en production, des machines situées dans des zones réseau différentes sur le même hôte de virtualisation.

Dans les 2 cas, il faut comprendre que si l'ôte est compromis, toutes les VM sont compromises, et par conséquent n'importe quelle zone !

C'est aussi mon avis. Néanmoins on peut réduire le risque au moyen de Vlans pour cloisonner le trafic entre les vm et le firewall.

heu je me trompe ou vlan ou pas si l'hote est compromis il aura accés pareil aux 2 vlan ?

:shock:

L'hyperviseur lui même ? Il est indispensable que l'hyperviseur utilise une carte séparée dans un autre numéro de réseau.

Sinon pour un hôte, c'est à dire une vm, la réponse est oui sauf à réaliser une sortie d'isolation, ce qui reste très difficile. Une compromission, même sous root ou administrateur, ne permettra pas de sortir directement du Vlan celui ci étant défini au niveau du switch virtuel (Vmware Infrastructure Client pour y accéder). Ce qui n'empêche pas d'essayer.

Si on résume en terme de risque, du plus sûr au plus risqué nous avons :
- Machines physiques séparées dans des zones différentes avec leur propre switch.
- Machines virtuelles appartenant à la même zone et néanmoins "Vlanisées"sur un seul ESX qui ne comporte pas de VM dans d'autres zones.
- Idem sans Vlan.
- Machines virtuelles appartenant à des zones différentes sur un seul ESX avec une carte réseau par zone.
- Machines virtuelles appartenant à des zones différentes sur un seul ESX avec une carte réseau pour toutes les zones mais avec des Vlans.

Je ne vais pas plus loin.

Dans tous les cas l'interface de gestion de l'hyperviseur est séparée physiquement.

[fcreach]

Bonsoir,

Je reviens vers vous car j'ai une nouvelle question.

Comme je l'ai expliqué sur mon 1er post, j'ai une plage de 8 ip qui arrivent sur la même interface wan.

J'ai donc une seule interface wan, mais du coup je ne vois pas comment faire (par exemple) pour avoir plusieurs sites web sur le port 80, en les distinguant selon l'ip publique ?

Pourriez-vous m'aider de nouveau ??

Merci d'avance