salut,

Je trouve que ton argumentaire est bien détaillé.

Je viens de lire "rapidement" les livres blancs sur le site vyatta:
Vyatta a aussi un système de fail-over.
Il gère le filtrage web (squid + squidguard).

Je suis en stage et j'hésite entre pfsense et vyatta.

@ccnet:

Je vous recommande vivement de faire appel aux services d'un professionnel puisque vous êtes dans un contexte professionnel.

Faire des économies, c'est faire preuve de professionnalisme.

En revanche, perdre son temps, ça ne l'ai pas. Je demanderais à mon installateur de le faire.
Pour info : 180€ pour un système de filtrage sur Linux. ( + un PC à fournir )

@ccnet:

Vous avez besoin d'un portail captif en effet mais aussi d'un proxy.

Très bien, merci à vous.

Je crois que là, il faudrait peut-être donner des infos !

Si une question bien posée est à moitié résolue, là nous avons donc 2 questions, et mal posées de surcroit !

Qu'est ce qu'une question bien posée ?

C'est une question posée en indiquant des éléments du contexte :

je veux faire ceci … mon réseau est comme cela ... je dispose d'un pc avec les caractéristiques suivantes ... les cartes réseau sont de type ... la carte mère a tel chipset ... l'adressage réseau est le suivant ...
....
et TOUT, y compris ce que vous croyez n'avoir aucun intérêt ...

Sans cela, il n'est pas possible d'obtenir une réponse ...

Suis-je clair ?

Ce fil montre qu'à partir d'une question, on peut largement partir en vrille.

Il est particulièrement mal intentionné d'aller modifier des règles par une autre interface que celle du firewall. (Ca c'est la mauvaise idée).
(En plus, la voie du ssh est particulièrement inconsciente car quasi impossible à mettre en oeuvre.)

Juve cite les XML/RPC. Et dans RPC, il y a Remote Procedure Call ! C'est la méthode contrôlée et prévue pour faire ce genre de chose. On peut, par exemple, penser que c'est le moyen utilisé pour synchroniser 2 firewalls via CARP.

Mais, de toute façon, ce n'est TRES certainement pas la bonne méthode pour répondre à la question sous-jacente.

La question est "je veux autoriser ou interdire la navigation web à X selon des critères".

La BONNE réponse (i.e. la réponse efficace ou la réponse opérationnelle) à cette question est de trouver un moyen d'authentification qui sera obligatoirement utilisé, et que cette authentification donnera un accord en fonction des critères.

Et là, il n'y a aucune règle à modifier !

La suggestion d'un annuaire LDAP est une excellente piste car Squid/SquidGuard est capable d'interroger un annuaire LDAP … en ajoutant une condition. Or il est assez aisé de mettre à jour un annuaire LDAP à partir de PHP.

Perso, je fais quelque chose qui, dans le principe, ressemble : j'identifie les pc autorisés par leur adresse ip (c'est assez aisé à contourner mais ...), et bien, j'ai créé une petite base MySQL avec mise à jour par une petite interface PHP qui permet de créer un fichier texte "partie" du fichier de conf de SquidGuard. Un cron plus tard, j'autorise ou interdit en moins de 2' l'adresse ip que je veux !

(Je ne ferais aucun commentaire sur la confusion iptables vs pfSense.)

Merci de ta réponse mais je ne ai pas encore installé PfSense. Sûrement la semaine prochaine  ;) Je verrais donc pour installer le Proxy

Sinon, est-ce qu'il y a un crédit temps intégré au portail captif ?

je suis aussi un adepte de la séparation des rôles.
J'ai un grand nombre de proxy squid en production sur base linux(centos 4 et 5 principalement).
Je conseil des machines avec un système de stockage performant (SCSI/SAS RAID 1) dédiées à ce rôle avec cache en AUFS sur une partition reiser montée en noatime

Bonjour,
Oui, j'ai ce problème sur bon nombres d'hardware différents…

Ce problème est connu, il semble que la fonction captiveportal_unlock fonctionne mal dés lors que le CPU du serveur est fortement utilisé. Un élément de réponse ....
http://forum.pfsense.org/index.php/topic,8152.0.html

Si cela pouvait s'automatiser ….

Quelle régle avez vous essayé ?
N'aurait il pas été plus simple de paramétrer les interfaces lan et wan dans "l'autre sens" dès le départ ? C'est une bien curieuse (et dangereuse) idée d'administrer Pfsense sur l'interface Wan.

Petit up svp …

Bonjour,

Je me permet de relancer la discussion sur ce sujet.

En effet, j'ai installer Pfsense sur une lame HS21-XM (dernière génération sur blade center); à présent Pfsense détecte bien les deux interfaces réseaux de la lame. (UP)

J'assigne donc les interfaces (LAN-WAN) et je configure une IP LAN.
LA config des switch nortel du blade est correcte (confirmée par un prestataire).

Mais lorsque j'effectue un PING ou même un PFtop aucune activitée réseau n'est détectée.

Un problème de config je suppose ? Mais à quel niveau ?

Merci d'avance.

Cdt,
Sig

Semble être reglé en supprimant les SAD existantes sur pfsense et en spécifiant dans le NETOPIA dans IP Profile Parameters du profil vpn dans remote tunnel endpoint l'adresse ip publique du pfsense (tans pis pour ceux qui n'ont pas d'adresses ip publiques fixes) ….

Ah oui ! Cela semble très bien fonctionner. C'est parfait ! Merci.

@hubsd:

effectivement le schema n'est pas genial

Le problème c'est surtout le contenu du schéma …

je ne dispose pas de hub ni de switch supportant le port mirroring

Par définition, sur un hub cela n'a pas de sens.

le point d'acces wifi sera plutot isolé dans un vlan a part

Selon l"usage prévu les solutions ne sont pas les mêmes. Si c'est pour des invités, c'est clairement une zone spécifique qui est nécessaire avec portail captif. Si c'est le réseau de l'entreprise, il faut envisager des solutions de type NAC. Utiliser un vlan ou non n'est qu'un choix de mise en ouvre.

concernant la sonde, je pensais la mettre en dmz
je dispose d'un serveur vmware esxi dans la dmz avec 2 cartes reseaux et je pensais héberger ma sonde dessus (dans l'hypothese que cela soit faisable)

Je ne vois pas l'intérêt de mettre la sonde sur une vm, ou alors il y a d'autres vm sur ESX auquel cas avec deux cartes nous avons des problèmes de sécurité. Une carte pour l'administration d'ESX, une carte pour l'interface en sonde (mode promiscuité) et une carte pour accéder à l'administration d'EasyIDS (par exemple). Cela fait déjà 3 interfaces physiques nécessaires.

le but du jeu est de sécurisé au maximum la partie lan et de pouvoir monitorer les attaques externes

Tout le monde commence par écrire cela. Ce qui bien sûr ne veut rien dire. Pour le moment et sur divers points aucune vue d'ensemble cohérente ne se dégage, il est donc difficile de prétendre à la sécurité "maximum" du lan. Lorsque l'on vient à une discussion plus précise on découvre qu'une sécurité relativement laxiste fini par être adoptée.
Je ne vois pas comment, si votre firewall est bien configuré, vous allez pouvoir observer les préparatifs d'une tentative d'intrusion avec la sonde placée en dmz. A moins que vous estimiez qu'elles viennent principalement du lan ? Mais comme tout cela est très flou dans l'exposé des actifs à protéger et des risques encourus, il est toujours aussi difficile de placer la sonde. Sans parler des règles Snort qu'il faut activer ou non selon ce qui est à protéger.

les regles internes n'autorisent que certains protocoles (http, https, dns, ftp) vers l'exterieur.

Cela ne tient pas lieu d'une politique de sécurité. Il est évident que l'autorisation du dns sortant, l'absence de proxy en zone intermédiaire nous éloigne beaucoup de la fameuse sécurité maximum.

Bref encore beaucoup de travail.

Si vous nagez, et cela semble être le cas, utilisez OpenVPN pour vos connexions d'un poste à un réseau. Vous n'avez pas, à votre niveau, d'inquiétude à avoir sur la sécurité d'OpenVPN. Actuellement, et sauf changement de dernière minute dont je ne serai pas informé, SSL est considéré comme sûr dès lors que l'implémentation est correcte.

Une solution de chiffrement peut être sûre au niveau de sa conception mais une implémentation défectueuse peut tout réduire à néant. A l'inverse la conception peut être mauvaise (wep, pptp initialement par exemple). Ce sont deux problématiques très différentes.

Souvenez vous de cette phrase de Bruce Schneier : "IPSec est probablement ce que nous avons de mieux, mais il est trop compliqué pour être sûr."

La réponse est non. Maintenant comme vous ne donnez aucune information ni sur la configuration, ni sur le matériel, je doute que nous puissions vous répondre autre chose de plus que ce "Non".

votre architecture réseau me parait très discutable…
concernant votre question, comme ca je dierais que soit le proxy est transparent (pas besoin d'authenfication) soit le proxy n'est pas configuré pour récuperer les flux http (au niveau des regles nat du routeur ou du pare feu en aval du proxy) et donc il ne sert a rien.
renseignez vous aupres de votre admin concernant la configuration du proxy

merci pour votre réponse,

apres plus d'un mois avec pfsense, celui ci est vraiment excellent à tout point de vue.

bravo aux développeurs.

le ST609 peux passer en bridge non ? Dans ce cas Pfsense s'occupe du PPP et connait donc l'adresse IP publique.

Autre solution, celle que j'ai adopté, passer le modem en half bridge (anciennement appelé DHCP spoofing).

Dans ce cas, le modem s'occupe du PPP, mais délivre une adresse IP publique en DHCP vers PFsense.

Avantage du full bridge : possibilité d'avoir de l'IPv6 en natif par Nérim en ADSL. (double session PPP, IPv4 + IPv6).

Inconvénient du full bridge : PPP semble poser de sérieux problèmes en multiwan, quelque soit le routeur Opensource. Seuls les routeurs commerciaux du type PePlink savent gérer ca correctement. Peut être Pfsense 2.0 d'ici un an ou deux lorsqu'il sera stable.

Inconvénient du Half bridge : IPv6 non supporté car les modems ne savent pas gérer IPv6 en interne (difficile à croire moins de deux ans avant le déployement global d'IPv6 en Europe !!)

Le ST609 est un ancêtre. Thomson ne semble plus fournir aucun support sur ces modems, si tant est qu'ils aient fourni ce qu'on peut appeler un support.

J'utilise des Linksys AM200, ils supportent tous les modes courants sans se prendre la tête avec la configuration ultra complexe des thomsons  : full bridge, half bridge pppoe ou pppoa, mode routé en pppoe ou pppoa, et même le RFC1483 routé (IPoa) ou bridgé (MER).

La seule chose qu'on peut pas faire sur le linksys, c'est du multi VC, et la gestion QOS atm. Mais de toutes façons, aucun opérateur en France ne propose du multi VC. (trop compliqué pour eux et pas assez rentable, ils préfèrent louer des SDSL à 200-500 euros / mois).

Les fournisseurs d'accès français nous cassent les pieds avec le PPP en ADSL. C'est inutile pour l'utilisateur. La France est un des rares pays à s'entêter à faire du PPP sur ADSL, sauf chez Free, qui fait du RFC1483 routé (IpoA).

France Telecom est le principal responsable de l'omniprésence du PPP sur l'ADSL. A l'étranger, on fait des efforts pour évoluer. Au niveau hardware, Cisco supporte très bien les modes RFC1483 routés et bridgés.

Alors si le PPP vous casse les pieds, faites le savoir à votre FAI. Ca fera avancer un peu les choses. Le PPP était utile à l'époque des modems RTC et de la facturation horaire. En ADSL ou est l'intérêt d'un controle de la durée de session ?

Le RFC1483 routé (IPoA) choisi par Free est le plus optimisé en terme d'efficacité du lien, mais pose le problème de la configuration automatique de l'adresse IPv4 car aucun protocole n'est prévu délivrer une IP au niveau 3. Free utilise un protocole propriétaire pour délivrer l'adresse IP. Sinon, IP statique manuellement configurée obligatoire.

Le RFC1483 bridgé (MER ou EthoA) ajoute un peu d'entêtes (ethernet), mais permet de délivrer une IP en DHCP.

ce n'est pas un bug à proprement parler. J'ai rencontré ce soucis avec un pfsense mal installé ou je ne pouvais pas me servir de la version disque dur (pfsense ne fonctionnait qu'en live cd).

je précise d'avance que la machine respectait bien les pré-requis de pfsense.