remplacer boitier UTM par solution linux

[yun]

J'ai pour projet de stage de remplacer un boitier Arkoon vieillissant par une solution Opensource: mon stage se passe dans un hopital (+ de 1000 users).

La solution mise en place devra remplacer les fonctionnalités de l'Arkoon: Proxy avec authentification active directory, firewall, antivirus, IDPS, relais SMTP...

Après 2 jours de recherche, je pense me diriger vers:
Pfsense pour le Firewalling
Squid/Squidguard/Kerberos pour la partie Proxy avec authentification transparente AD
ClamAV pour l'antivirus
PostFix pour le relai SMTP
Snort pour l'IDPS

Avez-vous déjà déployé une solution de même type sur un réseau assez important?

Merci pour vos réponses et vos retours d'expérience.

[ccnet]

La solution envisagée est trop légère pour le contexte indiquée. Les limitations d'ipcop risque de poser bien des problèmes. Installer la totalité de ses services sur ipcop pour un millier d'utilisateurs est une pure folie. Du personnel pour exploiter Snort ?
Nous sommes quelqu'uns à avoir pas mal planché et traité ces sujets dans différents fils ici.
Par ailleurs le problème est pris à l'envers. Existe til une analyse de risque et une politique de sécurité qui en résulte ?

[yun]

Merci de ta réponse.
Je n'ai pas parlé d'IPCOP mais de Pfsense.
Je ne compte pas installer tout les services sur la même machine.
En ce qui concerne Snort, après l'avoir mis en place et configuré, il y aura du personnel pour l'exploiter.

[jdh]

Il est très curieux de demander à un stagaire par quoi remplacer un firewall pour un réseau de 1000 postes !

A la rigueur, on peut lui demander quelles solutions seraient intéressantes (avec avantages/inconvénients).

En tout état de cause, s'il n'y a personne en interne pour faire le ou les choix, je doute qu'il y ait en interne les personnes capables d'analyser le résultat de Snort.


Ce qu'il faudrait comprendre c'est que remplacer 1 firewall, c'est choisir une architecture parce qu'aujourd'hui, on (je) mettrait en place plusieurs machines.

Par exemple, Snort ne devrait être utiliser QUE s'il y a VRAIMENT des personnes capables de l'exploiter et ayant le temps nécessaire. Snort devrait être placé derrière le firewall sur un port de switch avec programmation particulière, sur une machine sans IP et relié par câble droit à la machine d'analyse avec sa propre imprimante.

Par exemple, on utilisera des proxy pour http, smtp sur des machines séparées et dument calibrées.

....

[ccnet]

Merci de ta réponse.
Je n'ai pas parlé d'IPCOP mais de Pfsense.

Et je me demande bien pourquoi moi, je l'ai fait. Reprenons.

Les questions de la politique de sécurité et de l'analyse de risque restent entières. Et la formulation de cette demande suscite de mon point de vue les mêmes interrogations que jdh. Plus de 1 000 utilisateurs sur un réseau hospitalier, et la refonte de l'architecture du point de vue sécurité confié à un stagiaire ? Je ne comprend pas. Néanmoins tant mieux pour (tant pis pour eux) le sujet est intéressant et valorisant.

Quelques idées à priori (faute des éléments nécessaires). Il semble nécessaire de prévoir deux dmz (interne, externe) en plus du réseau local (1 000 utilisateurs, une seule zone, un seul segment, pas de Vlan ?). Un firewall, Pfsense. Utiliser des switch permettant la gestion de vlan pour cloisonner dans une même zone le trafic afin d'éviter que la compromission d'une machine permette d'en accéder une autre.
Prévoir la configuration d'un port de copie pour éviter (entre autre) la détection de l'ids. Sur des Cisco, ne pas utiliser le Valn1 et désactiver des protocoles tel que VTP.

Dans la dmz externe le relais smtp assurant AS-AV. Postfix est un bon choix. Bien utiliser les restrictions et les access lists de Postfix pour rejeter les spams certains avant de faire travailler un AS comme Spamassassin. Postfix + Cmav+Spamassasin+Razor etc est une config un peu délicate à installer à la main entièrement. ClarkConnect (version gratuite) est une très bonne solution pour ce travail.

Si des services http doivent être accédés de l'extérieur sans vpn, prévoir un reverse proxy, lui aussi en dmz externe, pour protéger le serveur Web placé en dmz interne. Serveur de mail en dmz interne. Proxy aussi en dmz interne. Ne pas laisser sortir le trafic dns des utilisateurs, préférer une résolution interne avec le service dns fourni pas Pfsense.

Monter l'ids sur une machine séparée avec deux interfaces, une en 0.0.0.0 et l'autre dans un réseau protégé (une autre dmz par exemple). Des outils comme IDS Policy Manager sont fort utiles surtout si vous devez placer plusieurs sondes. Ne pas utiliser Snort sur Pfsense : trop dangereux et trop lourd.

Tout cela ce sont des techniques un peu en vrac. Sans le travail préalable (politique de sécurité et analyse de risque), je ne sais pas faire mieux.

[yun]

Merci ccnet et jdh pour toutes ces précisions.

J'étais parti sur cette architecture:

http://www.2shared.com/file/5289860/212943fe/archi.html

Dans ma DMZ, je pense mettre le relai SMTP (POSTFIX) avec antispam + connexions VPN (cisco ASA) + futur serveur WEB.
Le proxy SQUID avec authentification "transparente" avec AD serait au niveau du LAN (voir possibilité de LOAD BALANCING sûrement sur 2 serveurs SQUID).
Je pense aussi doubler les firewalls (Pfsense) avec possibilité de FAILOVER.

Merci d'avance pour vos remarques.