Publication de plusieurs sites

[spidermeu]

Bonjour,
j'ai pour projet de changer l'ISA server 2004 que nous avons dans une baie en data center. Pour cela, je voudrais migrer la solution de Microsoft sur une IPcop.
J'ai installé un environnement de test virtualisé avec ipcop en amont d'un LAN avec 2 ou 3 machines (windows / Linux).
Aujourd'hui, nous hébergeons des sites web principalement développés en ASP.NET et en PHP.

Aussi, pour notre baie, nous disposons de 16 IP publics.


Le problème qui se pose c'est pour publier tout nos sites. Comme nous avons plusieurs sites et de technologies différentes, nous utilisons plusieurs IP public en fonctions de la technologie.
Par exemple, les requêtes pour les sites ASP.NET seront redirigées vers le serveur qui a pour IP 192.168.0.1.
Les requêtes pour les sites PHP seront redirigées vers 192.168.0.2.

Avec ISA, pas de problème :

Publicationavec ISA :

= Visiteurs


se connecte sur www.monsite.com(140.115.10.1:80) => ISA => redirection vers 192.168.0.1:80
se connecte sur www.mysite.com(140.115.10.2:80) => ISA => redirection vers 192.168.0.2:80
se connecte sur www.myNewWebSite.com(140.115.10.3:80) => ISA => redirection vers 192.168.0.3:80
...


Publication avec IPcop :

Par contre, avec IPcop c'est différent. Il semblerait qu'on ne puisse rediriger qu'en fonction du port (fonctionnement PAT), et non pas par IP (fonctionnement NAT).

Je suis sur de me tromper, mais je ne vois pas comment procédé, faut-il créer des alias dans l'interface ?

Pour résumé, est-il possible d'assigner plusieurs IP public sur la carte RED et de gérer les règles avec toutes ses IP ?

Merci d'avance et bon week-end.

[ccnet]

Pour résumé, est-il possible d'assigner plusieurs IP public sur la carte RED et de gérer les règles avec toutes ses IP ?

Voulez vous bien vous donner la peine de faire une recherche sur le forum ? Ce sujet a déjà été amplement traité.
En bref c'est possible, mal commode, difficile à maintenir et les fonctionnalités sont restreintes. Simplement parce qu'ipcop n'est pas conçu pour cela. Ce serati beaucoup plus facile avec Pfsense.

[Franck78]

J'approuve CCNET,

IPCop n'est pas du tout adapté pour gérer plusieurs IP publiques.

Mais il pourrait très bien s'intercaler entre le 'pfsense' de tête et chaque serveur affecté à une IP.
Donc 16 ipcops , 16 zones, 16 ce qu'on veut.....


bye

[spidermeu]

bonjour,
toutes mes excuses pour la fonction recherche, je n'ai surement pas tapé les bons mots clés.

Je suis surpris que cette fonction ne soit pas prise en charge. Cela veut dire qu'IPcop est destiné au micro infrastructure ?

En tout cas, merci de votre aide. je vais étudier Pfsense.

A bientôt

[jdh]

En effet, sans trop chercher difficilement, il est aisé de trouver des fils sur le site qui parle de ce sujet.

Il est notable que
- IPCOP n'est pas vraiment conçu pour gérer plusieurs adresses ip publiques,
- IPCOP, comme n'importe quel firewall, n'est pas là pour rediriger des flux http selon le nom : c'est le rôle d'un reverse proxy.

Pour information, il n'y a AUCUNE raison de disposer de plusieurs adresses ip publiques selon la technologie : c'est du pur gaspillage !

La technique de reverse proxy permet de rediriger le flux http vers un ou plusieurs serveurs internes voire sur des "sous-sites".

En clair cette phrase "Comme nous avons plusieurs sites et de technologies différentes, nous utilisons plusieurs IP public en fonctions de la technologie" n'est pas justifié sur le plan technique.

Il suffit pour le comprendre d'imaginer comment les FAI font pour héberger en mutualisé : 1 serveur, avec une adresse ip, est le serveur de dizaines de noms de domaine à la fois. (ftp, avec la même ip, sait très bien envoyer avec un identifiant vers le bon répertoire.)


Je confirme que pfSense a plus de possibilités ...

[ccnet]

J'en profite pour rebondir. Le reverse proxy est bien sûr la solution à privilégier dans cette situation sauf informations dont nous n'avons pas connaissance (encore que ...).

Par ailleurs le reverse proxy a aussi un rôle important dans la sécurité de vos systèmes. Le firewall assure une défense périmétrique absolument nécesaire pas pas suffisante. Il n'a pas pour mission d'assurer un firewalling applicatif qui est tout aussi indispensable. En clair il s'agit de filtrer les url plus ou moins dangereuses qui pourraient être envoyées à vos serveurs http pour réaliser une intrusion. Les serveurs Microsoft au contact direct d'internet pose pas mal de problème et présente des risques importants en particulier si ils sont intégrés au domaine AD du réseau local. Cette configuration devrait être absolument proscrite. Il faut bien comprendre que la seule sécurité de la pile http est pas suffisante pour garantir la sécurité de la machine. N'importe quel logiciel, même inactif parfois, peut être un problème.

[spidermeu]

Certes.
Concernant l'entête du site, nous laissons les serveurs web les négocier eux même.
Pour le gaspillage d'adresse IP, je suis assez d'accord, mais le contrat nous propose 16 IP, pas plus, pas moins. Nous en utilisons pas mal et nous les dispatchons par technologie.

Et dans notre cas, sans reserve proxy, il est préférable d'utiliser 1 IP par technologie (il ne faudrait pas que les sites ASP soit redirigé vers un serveur lamp -_-, et inversement).

Merci pour la pertinence de vos remarques.

[jdh]

Encore un /28 donné à la légère ! (Le problème c'est de donner soit 1 adresse soit 6 adresses =/29, ensuite c'est 15 adresses =/28 )

Je peux présumer que la limite est la taille du tuyau plutôt que l'adresse ip.

Une seule adresse ip est suffisante (pour http) puisque tout peut être envoyé à un reverse proxy qui à son tour dispatchera selon le nom (et effectuera sans doute du "reverse cache"). Reverse proxy qui, au passage et comme l'indique ccnet, vérifie la conformité de la requête http ce qui complète le firewall, voire ajoute quelques suppressions dans les entêtes afin de limiter les infos. (Sans compter les logs et stats ainsi centralisés !)

Ce qui compte, serait plutôt l'environnement technique : on ne fait pas tourner raisonnablement du .net sur Linux, et de même, même face à un WAMP, un linux est largement plus efficace pour faire tourner un AMP (ne serait parce qu'Apache2 est multi-thread sous Linux et pas sous Windows, si je ne me trompe).

Outre des économies électriques et des charges d'amortissement, il est essentiel de capitaliser et de réduire le nombre de serveurs ...


Je peux penser qu'il serait un excellent exercice de préparer la mise en place d'un reverse-proxy (et, qui sait, avec même un antivirus face aux POST avec pièces jointes ?)

[spidermeu]

Outre des économies électriques et des charges d'amortissement, il est essentiel de capitaliser et de réduire le nombre de serveurs ...

Je peux penser qu'il serait un excellent exercice de préparer la mise en place d'un reverse-proxy (et, qui sait, avec même un antivirus face aux POST avec pièces jointes ?)

Bien que je n'en ai jamais installé, je pense que le reverse-proxy ne doit pas être sur Ipcop (je préfère laissé Ipcop faire son travail de firewall et rien d'autre). Donc cela demande une machine supplémentaire (donc des ressources supplémentaire (bien qu'un vieux coucou ferait l'affaire).
Je suppose que la solution largement utilisé est Squid.

Il faudrait donc avoir un topologie de ce type :

reserve proxy << ---> IpCop << ---> WAN
X serveurs web << --->
X serveurs FTP,... << --->

[ccnet]

Bien que je n'en ai jamais installé, je pense que le reverse-proxy ne doit pas être sur Ipcop (je préfère laissé Ipcop faire son travail de firewall et rien d'autre). Donc cela demande une machine supplémentaire (donc des ressources supplémentaire (bien qu'un vieux coucou ferait l'affaire).
Je suppose que la solution largement utilisé est Squid.

Loin de nous (jdh je me permet ...) l'idée de vous conseiller un reverse proxy sur ipcop. Un reverse proxy c'est nécessairement et absolument une machine séparée. Au surplus elle sera placé dans une zone différente de celles des serveurs webs.
La solution largement utilisée pour cela n'est pas Squid mais Apache avec mod_security notamment et sous Linux. Voir l'exemple de Vulture.

Il faudrait donc avoir un topologie de ce type :

reserve proxy << ---> IpCop << ---> WAN
X serveurs web << --->
X serveurs FTP,... << --->

Pas exactement. Le reverse est placé dans une dmz dite "externe" et les serveurs web dans une autre dmz (dmz interne). La règle étant que toutes les machines devant accepter du "trafic SYN" venant d'internet sont isolées dans une dmz spécifique. Les machines en dmz interne sont des machines qui ne font qu'initier du trafic sortant et n'accepte que du trafic de la dmz externe mais pas d'internet.
Au passage cela nécesite au moins quatre interfaces physqiues sur le firewall. Et de préférence la possibilité de créer des vlans pour interdire les rebonds d'une machine à l'autre sans passer par le firewall.

[spidermeu]

Je ne sais pas si cette solution sera évidente à mettre en place. Nous migrons également notre parc informatique vers un gros serveur virtuel.
Je ne sais pas si virtualiser un firewall, un reserve proxy et une DMZ interne sur une meme machine soit une bonne idée. Qu'en pensez-vous ?

[ccnet]

Je viens de terminer un chantier de ce type et j'en ai un autre cours. J'ai aussi à faire, pour d'autres raisons à une grosse infrastucture fortement virtualisée. Autant vous dire tout de suite ce n'est pas totalement trivial. Si vous virtualisez, ce qui est une bonne chose si c'est correctement conçu, il y a des avantages. Mais on peut énoncer quelque règles simples de prudence.

Vmware ESX est souhaitable. Au moins deux cartes réseaux pour séparer la console d'admin de Vmware du switch virtuel. Utilisation des vlans.
Pas de firewall virtualisé.
Pas de machines appartenant à des zones (domaine de confiance) différentes sur le même serveur physique.

Mettre l'ensemble de vos serveurs http sur un vmware est une idée cohérente. Toutefois les serveurs http, IIS comme Apache, permettent l'hébergement de multiples sites sur une même machine, avec une ou plusieurs ip. Ceci avec des charges importantes. Si vous avez des bases de données qui sont utilisées leur déport est pratiquement indispensable.
La mauvaise idée de la virtualisation est de penser que l'on peut tout mettre sur un seul serveur. On peut néanmoins faire beaucoup de choses. Mais avec prudence. Pour cela il est important de bien regarder en particulier les flux réseau Vmawre. Il y a de multiples ports ouverts. Il faut se méfier du plat de spaghettis ! Lors de la conférence Black Hat 2009 il a été présenté comment exploiter des vulnérabilités pour réaliser une sortie d'isolation. ce n'est pas simple mais réellement faisable. Je cite "La virtualisation n'est pas une couche de sécurité de plus mais un endroit de plus où exploiter des failles." Cela ne signifie pas qu'il ne faut pas utiliser la virtualisation, mais qu'il faut le faire avec discernement. Nous ne sommes ni dans le tout blanc ni dans le tout noir. Vous trouverez sans difficultés des gens pour vous dire que ça marche très bien chez eux avec tout sur le même serveur. La question n'est pas que cela marche ou pas. C'est une situation qui augmente la probabilité d'occurrence des risques. Pourquoi augmenter délibérément les risques ?

[jdh]

Il manque là quelques bonnes bases en terme de sécurité.

Règle 1 : on ne virtualise pas un firewall.

Règle 2 : on ne doit virtualiser sur la même machine que des machines situés sur la même zone.

J'ajoute que 2 ou 3 serveurs LAMP semblables gagnent à être installé sur la même machine (ou VM). On y gagne en simplicité et on securise en 1 seule fois les 2 ou 3 serveurs !



Pour revenir à un reverse proxy, il ne peut être placé sur un firewall, c'est clair (et rappelé par ccnet).
ccnet propose mod_security mais Squid peut aussi être utilisé (cf http://www.visolve.com/squid/whitepaper ... eproxy.php). Les fichiers logs de l'un et l'autre sont proches et ne pose pas de difficulté pour ajouter une appli de stat (laquelle aura besoin d'Apache !).

Un schéma avec un reverse proxy dans une zone différente des serveurs web augmente la complexité et peut apporter encore plus de sécurité (si on prend garde à éviter toute fuite à l'intérieur du protocole genre "via" ou "forwarded").

Edit : Je vois qu'on est assez en ligne avec ccnet (qui a répondu plus vite que moi). Quelle surprise !

[spidermeu]

Notre parc est assez simple :
- 1 serveur IIS avec plusieurs sites ASP.NET + une base de données SQL-server 2008 express.
- 1 lamp
- 1 serveur linux de data pour des accès client VPN + un FTP
- 1 serveur linux de sauvegarde (en cours d'etude)
- 1 serveur de messagerie Microsoft Exchange 2003
- 1 serveur oracle xe
- 1 firewall

C'est une petite structure, mais on héberge une bonne dizaine de sites web. Actuellement, les petits serveur que nous avons font tourner largement toutes les applis. En revanche, je migre plusieurs serveurs sous linux (pour le stockage de données et la sauvegarde (sur disque) par exemple).

Nous avons deux serveurs physiques :
- 1 qui sera sous ESX, avec toutes les machines virtuelles dessus,
- 1 qui sera sous linux pour accueillir le serveur de sauvegarde ( la sauvegarde ne doit surtout pas être sur le même serveur physique que ce qu'il doit sauvegarder, bien évidemment).

Il n'est pas possible d'installer un firewall sur une machine supplémentaire, le nombre de U dans la baie ne le permet malheureusement pas.

La seule solution qui me semblait correct, était d'installer le firewall sur le serveur virtuel.

[ccnet]

Il n'est pas possible d'installer un firewall sur une machine supplémentaire, le nombre de U dans la baie ne le permet malheureusement pas.

Soit le rack est très petit ou alors les serveurs sont très gros. Quoi qu'il en soit ce n'est pas raisonnable ni comme argument, ni comme "politique" de sécurité. Si vous tirez vos revenus de l'existence des sites web ce n'est pas déraisonnable. C'est suicidaire. Il existe d'excellents serveurs 1U ou 2U. Le cout d'un Proliant d'occasion est dérisoire pour disposer d'un firewall digne de ce nom.