Question : interface secondaire

thonik

Bonjour,

Je suis étudiant, actuellement en stage. Je débute donc avec Pfsense. J'utilise actuellement Pfsense sur 2 machines en failover. La première est un P2 400Mhz et la 2eme un P3. J'utilise la version 1.2.2

Je dois mettre IPcop devant PfSense pour faire du reverse-proxy/antispam/antivirus. Car mon maître de stage ne veut pas que ce soit sur la même machine.

Ma question est la suivante : Si je rajoute une carte réseau connectée directement au réseau WAN, y a t'il moyen que PfSense sache la laisser down tant que Ipcop ne tombe pas. Une sorte de chemin secondaire quand on ne sait plus acceder par le chemin primaire (Ipcop).
Il faudrait bien évidement que Pfsense n'empreinte jamais cette route SAUF quand il ne sait plus passer par Ipcop.

Si c'est possible, un tuto est-il disponible? Ou puis-je configurer ça?

Voici un schéma de ce que j'aimerai réaliser :
P.S : Désolé je suis pas doué en schéma ;D

PfSense 1
xl0: -> LAN
xl1 : <–- IPcop <-- WAN
(xl2 down?): <--- WAN

PfSense 2
xl0 :LAN
xl1 : <–-- Ipcop <-- WAN
(xl2 down?) <---- WAN

ccnet

Je dois mettre IPcop devant PfSense pour faire du reverse-proxy/antispam/antivirus. Car mon maître de stage ne veut pas que ce soit sur la même machine.

1. Ipcop n'est pas du tout adapté à ce type de tâche.
2. Cette architecture n'est pas correcte.
3. Je ne mettrai certainement pas le proxy et le reverse proxy sur la même machine.
4. Le proxy et le reverse proxy ne devraient pas se trouver dans la même zone.

La seule chose pour laquelle votre maitre de stage a raison c'est que cela ne doit se trouver sur la même machine. Qui a parlé d'utiliser Ipcop pour ces tâches ?

L'antispam-antivirus est un travail potentiellement lourd. Tout dépend de votre trafic de messagerie. Evaluer le nombre moyen de mail quotidien.

Une base de départ en terme d'architecture c'est Pfsense avec 4 interfaces : Lan, wan, opt1 (dmz interne), opt2 (dmz externe). Les machines recevant des connexions venant d'internet sont en dmz externe : reverse proxy, passerelle AS-AV.
Les serveurs mails sont en dmz internes, ainsi que le proxy.
Le reverse proxy peut être Apache + ModSecurity.
Le proxy peut être squid.
La passerelle AS-AV : Postfix plus spamassassin, clamav, etc … Un distribution telle que ClarkConnect Community peut être utilisée. On veillera attentivement à la configuration de Postfix pour effectuer le maximum de détection de spam sans solliciter spamassassin qui est gourmand et lent.
Il y a du travail à faire sur les switchs (Vlans) pour isoler les différents serveurs situées dans la même zone.
On peut aussi virtualiser tout cela dans Vmware (pas sur Windows mais Vmware ESXi 3.5) avec 3 cartes réseau dans votre cas.

Bref il y a du travail et pour le début vous n'êtes pas sur les bons rails.

thonik

Pour IpCop, il proposait d'utiliser l'addon "SquidGuard" qui comprend l'antivirus, l'antispam.

Je vais me renseigner sur vos infos.

merci ;)

ccnet

Ipcop est avant tout un firewall.
Encore une fois il n'est pas fait pour cela. Par ailleurs vous devez utiliser deux interfaces avec Ipcop et une translation d'adresse est systématiquement réalisée entre les deux interfaces. Ce n'est pas un avantage d'accumuler inutilement les translations.
SquidGuard n'est pas un proxy mais un addon pour le proxy Squid.
Squidguard ne traite pas les mails.
Squidguard effectue du filtrage d'url en s'appuyant sur des blacklists : "SquidGuard is a URL redirector used to use blacklists with the proxysoftware Squid". Source : http://www.squidguard.org
A la base vous avez un problème d'architecture à penser mais vous prenez le problème par la fin et non le début en choisissant des solutions techniques d'abord. De plus il y a une certaine confusion dans les fonctionnalités des outils.

thonik

ClarkConnect Community est bon comme antispam et antivirus de mail mais je ne vois pas dans les "features" (http://www.clarkconnect.com/info/compare.php) qu'il gère aussi antivirus web.

Or IpCop, même si j'ai bien compris qu'il n'étais pas à la base prévu pour ce que je veux faire, comprend un addon assez intéressant "CopFilter" qui comprend notamment SpamAssassin, ClamAV, + havp comme proxy antivirus… En bref, il comprend ce que j'ai besoin... et je ne pense pas que ClarckConnect comprenne tout ça...

Si IpCop n'est pas la distribution "ideale", je ne pense pas que ClarckConnect non plus vu qu'il ne possède pas toutes les fonctionnalités dont j'ai besoin. Alors quel choix me reste-il?

Pour info, l'entreprise reçois environ entre 50 et 100 spam/jour/utilisateur. Sachant qu'il y a environ 70 utilisateurs.

ccnet

@thonik:

ClarkConnect Community est bon comme antispam et antivirus de mail mais je ne vois pas dans les "features" (http://www.clarkconnect.com/info/compare.php) qu'il gère aussi antivirus web.

Je n'ai jamais dit qu'il fallait l'utiliser pour cela ! Par contre Squid peut le faire en effet. Mais pas seul.

Or IpCop, même si j'ai bien compris qu'il n'étais pas à la base prévu pour ce que je veux faire, comprend un addon assez intéressant "CopFilter" qui comprend notamment SpamAssassin, ClamAV, + havp comme proxy antivirus… En bref, il comprend ce que j'ai besoin... et je ne pense pas que ClarckConnect comprenne tout ça...

Moi non plus. Si tel était le cas je l'aurais dit. Le moteur SMTP de Copfilter est beaucoup trop faible. Copfilter s'appuie essentiellement sur Spamassassin pour détecter le spam. Or la réalité montre qu'un énorme volume de spams est détectable sans utiliser spamassassin mais avec un bon relais smtp (Postfix). Celui ci est capable de faire un certain nombre de vérifications portant sur l'émetteur du mail, son respect des rfc dans la conduite d'une session smtp et par ailleurs il possède des capacités de filtrage beaucoup plus efficace (mémoire , CPU). Spamassassin est utile mais après tout ces tests, dès lors qu'il s'agit d'analyser le contenu du mail. Mais beaucoup d'autres facteurs que Spamassassin ne gère pas entrent en ligne de compte. Spamassassin est en fait la dernière étape du filtrage lorsque la mail a passé tous les autres tests. La vérification d'un MX correct pour un expéditeur est un test fiable à 100% alors que Spamassassin évalue la probabilité de spam. Fondamentalement différent. Il est indispensable de rejeter, dans la transaction smtp, les mails qui sont manifestement des spams. De nombreux spammeurs n'y reviennent pas lorsque leur connexion smtp est rejetée. Avec Spamassassin la connexion doit être accepté et le mail reçu avant de pouvoir commencer l'évaluation. Les spammeurs reviendront puisque vous acceptez leurs mails !
Je ne développe pas plus, il faut revoir votre conception du filtrage antispam. En fait la solution ne peux reposer sur Spamassassin seul. Pour l'avoir testé en maquette, en vraie grandeur, je sais les problèmes que cela pose.
Mais il y a aussi des problèmes plus complexes en suspend. Quelle politique face aux expéditeurs dont les enregistrements DNS (PTR en particulier) ne sont pas corrects ? Spammeurs ? Légitimes ? Que décidez vous ? Il y a les deux !

Si IpCop n'est pas la distribution "ideale", je ne pense pas que ClarckConnect non plus vu qu'il ne possède pas toutes les fonctionnalités dont j'ai besoin. Alors quel choix me reste-il?

Concevoir une architecture correct. Voilà le choix. Il n'y a pas de distribution idéale.
Les différents services dont vous avez besoin Proxy, AS-AV messagerie, reverse Proxy (comme beaucoup de monde d'ailleurs) ne doivent pas être sur la même machine physique et ne doivent pas être dans la même zone du réseau. Et par ailleurs ces machines ne doivent pas pouvoir communiquer entre elles.
Vous continuez à raisonner à l'envers en recherchant des logiciels ou des distributions. La sécurité c'est, avant de choisir des logiciel ou des produits, une question d'architecture. C'est encore autre chose avant l'architecture mais bref … L'architecture doit être par construction, par nature, résistante. Cela passe, entre autre, par une segmentation stricte des flux, le cloisonnement des services, l'ajustement des accès possibles au minimum nécessaire.