conseils pour connexion wan vers lan avec pfSense

[calou82]

Bonjour !

Je débute avec pfSense que je souhaite utiliser pour sécuriser l'accès d'un ensemble de PC connectés sur une livebox par un switch vers un LAN.

Voici le schéma de l'actuel:


Actuellement, quand un PC a besoin d'accéder au LAN, il faut permuter le cable branché dans le PC ! (celui branché sur le switch du LAN avec celui branché sur le switch connecté à la Livebox)

Je souhaite permettre l'accès par smb/ssh aux postes (serveur windows et serveur linux) du LAN et interdire l'accès d'un poste du LAN vers le WAN.

Est-ce que l'une des configurations suivantes vous semble valable ? laquelle est la plus secure/simple ?

Schema 1: configuration de pfSense avec 2 cartes réseau



Et voici une autre configuration à 3 pattes, et peut-être une configuration pfSense plus complexe ?

Schema 2:



Cette configuration me semble sécuriser d'avantage les PC accédant au WAN par rapport à l'actuel.

Merci d'avance pour vos commentaires/conseils ...

[jdh]

Bonjour.

(Ca fait plaisir de lire ce genre de premier post : clair, avec des images, problème pas posé pour la n-ième fois, ... Bref bravo ! Si seulement certains pouvaient s'en inspirer ...)

Il me semble que le schéma 2 est certainement celui qui permet de bien travailler.
Néanmoins 2 remarques :
- Wan doit être appelé Dmz : Wan c'est la livebox bien sur, Dmz est l'endroit des machines qui peuvent accéder à Internet, Lan réunit les machines qui ne peuvent pas accéder à Internet (au mieux indirectement).
- La config de base du filtrage de Lan (Firewall > Rules > onglet Lan) incorpore une règle permettant de faire tout : à supprimer pour respecter ton schéma.


pfSense est un firewall très intéressant. Une différence avec les firewalls iptables genre Ipcop est que les règles de flux sont configurées en fonction de l'interface d'arrivée. C'est une question d'habitude mais on s'y fait ...

Autre intérêt de pfSense : les nombreux possibilitées déjà disponibles (vpn ipsec+openvpn, rrdtools, ..........) auquel s'ajoutent des packages. (NB: Squidguard n'est pas aussi simple que l'addon de Franck78 mais on peut arriver à utiliser la blacklist de Toulouse).

Pour m'aider à paramétrer un firewall, je trace un tableau NxN avec toutes les interfaces x toutes les interfaces. Dans chaque case, j'écris chaque flux autorisé pour l'interface d'entrée (rangée) vers l'interface d'arrivée (colonne). Je me force à éviter "any" ! Ce tableau m'aide à ne rien oublier.

Là cela fera un tableau 3x3 (les cases de la diagonales seront grisées !)

[calou82]

Merci pour cette réponse rapide, les commentaires et conseils !

Je vais installer 3 pattes dans un PC et préparer le tableau 3x3 avec eth0, eth1, eth2, installer pfSense et le configurer (enfin tenter )

Je te tiens au courant ...

Bonjour.

(Ca fait plaisir de lire ce genre de premier post : clair, avec des images, problème pas posé pour la n-ième fois, ... Bref bravo ! Si seulement certains pouvaient s'en inspirer ...)

Il me semble que le schéma 2 est certainement celui qui permet de bien travailler.
Néanmoins 2 remarques :
- Wan doit être appelé Dmz : Wan c'est la livebox bien sur, Dmz est l'endroit des machines qui peuvent accéder à Internet, Lan réunit les machines qui ne peuvent pas accéder à Internet (au mieux indirectement).
- La config de base du filtrage de Lan (Firewall > Rules > onglet Lan) incorpore une règle permettant de faire tout : à supprimer pour respecter ton schéma.

...

Pour m'aider à paramétrer un firewall, je trace un tableau NxN avec toutes les interfaces x toutes les interfaces. Dans chaque case, j'écris chaque flux autorisé pour l'interface d'entrée (rangée) vers l'interface d'arrivée (colonne). Je me force à éviter "any" ! Ce tableau m'aide à ne rien oublier.

Là cela fera un tableau 3x3 (les cases de la diagonales seront grisées !)

[ccnet]

Sans aucune hésitation c'est aussi, à mon sens, le schéma numéro 2 qui est la solution à la fois souple et efficace.

[calou82]

Bonjour !

Sans aucune hésitation c'est aussi, à mon sens, le schéma numéro 2 qui est la solution à la fois souple et efficace.

Bon, ben voila, le nouveau schéma que j'ai mis en place est le suivant (en renomant correctement !) avec trop de blocage dans les règles je pense:



et maintenant , je sèche un peu (énormément). Si vous pouvez m'aider !

Je souhaite permettre:
1) que le serveur web 10.40.1.W soit accessible depuis le WAN (internet)
=> j'ai activé DMZ vers eth0 sur la livebox: "La DMZ est configurée pour l'ordinateur : 192.168.1.2"

Quelle règle je dois activer sur WAN pour permettre d'aller sur OPT (DMZ) vers le serveur WEB ?

2) accéder depuis un PC de la DMZ sur le serveur 2 linux du LAN 10.30.1.L (avec le protocol ssh uniquement)
=> quelles règles dois-je mettre en place ? (sur l'onglet LAN et sur le OPT)
j'avais ouvert le LAN complètement pour essayer mais aucune réponse de PING ou ssh depuis PC1[OPT]
=> le subnet étant différent, je pense que ça pose problème , l'admin du LAN m'a dit qu'il n'acceptait pas un autre subnet que 10.30.x.y alors que mon OPT est en 10.40.v.w

=> est-ce qu'il faut faire de la translation d'adresse pour simuler un subnet en 10.30.x.y ?

Déjà, si j'arrive à faire ça , ça serait wonderful ...

Merci de toute aide !

PS: pas facile de trouver des pistes sur le net, pas mal de cas de figures mais pas MON cas de figure ;-(
idem pour la documentation sur la façon dont les règles sont prises en compte dans pfSense , est-ce du bas vers le haut ou du haut vers le bas quand il y en a plusieurs ?
est-ce qu'il faut tout bloquer et ajouter des règles qui libèrent ou ne mettre que des règles qui autorisent ...

[ccnet]

Bonjour !

Je souhaite permettre:
1) que le serveur web 10.40.1.W soit accessible depuis le WAN (internet)
=> j'ai activé DMZ vers eth0 sur la livebox: "La DMZ est configurée pour l'ordinateur : 192.168.1.2"

Ok tout le trafic (naté, Livebox oblige) internet est bien envoyé sur Wan.

Quelle règle je dois activer sur WAN pour permettre d'aller sur OPT (DMZ) vers le serveur WEB ?

Trois précisions concernant le fonctionnement de Pfsense.
1. Les paquets sont d'abord naté Puis les règles sont appliqués
2. Les rêgles sont appliquées de haut en bas.
3. Le filtrage de Pfsense s'applique, sur chaque interface, du réseau qui lui est connecté vers Pfsense et uniquement dans ce sens.

Serveur web 10.40.1.W accessible depuis le WAN.
Il faut une règle de nat : Firewall: NAT: Port Forward avec :
WAN TCP 80 (HTTP) 10.40.1.W (champ NAT ip) 80 (HTTP)
Pfsense vous proposera lors de la validation du nat d'ajouter les règle qui convient, accepter sa proposition.

2) accéder depuis un PC de la DMZ sur le serveur 2 linux du LAN 10.30.1.L (avec le protocol ssh uniquement)

=> quelles règles dois-je mettre en place ? (sur l'onglet LAN et sur le OPT)[/quote]
Mettre la règle sur eth2 (si j'ai bien compris c'est opt1)

=> le subnet étant différent, je pense que ça pose problème , l'admin du LAN m'a dit qu'il n'acceptait pas un autre subnet que 10.30.x.y alors que mon OPT est en 10.40.v.w
=> est-ce qu'il faut faire de la translation d'adresse pour simuler un subnet en 10.30.x.y ?

A priori oui.

PS: pas facile de trouver des pistes sur le net, pas mal de cas de figures mais pas MON cas de figure ;-(
idem pour la documentation sur la façon dont les règles sont prises en compte dans pfSense , est-ce du bas vers le haut ou du haut vers le bas quand il y en a plusieurs ?
est-ce qu'il faut tout bloquer et ajouter des règles qui libèrent ou ne mettre que des règles qui autorisent ...

En bas une règle qui bloque tout et au dessus des autorisations spécifiques.

Pour débugger l'ensemble activer le log sur toutes les règles.

[jdh]

(encore une fois, c'est très bien de poser des questions, de montrer la progression de sa réflexion de son schéma !)

(Juste une chose : tu choisis WAN+LAN+OPT1 : il faut s'y tenir et, donc, faire disparaître toute mention DMZ !)


* la "dmz" de la livebox.
Bien, la patte WAN du pfSense est effectivement la "dmz" de la livebox.
(Il serait plus sur de définir les seuls transferts de ports utiles, mais on peut faire ...)

* aller de WAN vers OPT1
Il faut, sous pfSense, faire 2 choses :
- créer le renvoi dans Firewall > NAT > onglet Port Forward
- créer la règle dans Firewall > Rules > onglet Wan

A noter qu'en principe créer le renvoi créé automatiquement le règle, ce qui est sympa ! Mais attention modifier le renvoi ne modifie pas la règle !

A noter qu'on peut désactiver la règle tout en laissant le renvoi, ce qui est efficace pour contrôler.

* accès d'un PC d'OPT1 vers un serveur en LAN
Il n'y a qu'une seule règle (Firewall > Rules) à créer :
- onglet OPT1 : la paquet initial arrive bien par cette interface !
- ssh -> tcp/22 mais pfSense connaît déjà SSH

A noter qu'il FAUT créer des alias (Firewall > Alias) pour se simplifier la vie. Par exemple, je créé systématiquement des alias du genre :
- srvlin : host 192.168.x.x
- portsmtp : port 25
et ainsi de suite. Avec un avantage sympa : on peut définir plusieurs valeurs : portweb : host : 80,443,8080 par exemple.

Je préconise que TOUTES les règles utilisent un ou plusieurs alias !

Par exemple, j'ai créé
- portntp =ports:123,
- clintp=hosts:192.168.1.50, 192.168.1.62.
La règle LAN: tcp+udp/other:portntp/src=clintp/dst=fr.pool.ntp.org !
Cette règle est nette et lisible : les machines de clintp peuvent accéder en tcp+udp pour ntp les serveurs de fr.pool.ntp. C'est simple et lisible !

* translation d'adresse OPT1 vers LAN
Normalement LAN et OPT1 sont considérés comme internes, et par conséquent, les adressages devraient être acceptés : le serveur en LAN devrait accepter un accès d'un PC en OPT1.

Néanmoins, comment faire pour quand même translater l'adresse ip source ? Il faut utiliser Firewall > NAT > onglet Outbond. Je pense qu'on doit pouvoir y arriver dans cet onglet. Mais je n'ai pas essayé ce genre de chose sur pfSense (je l'ai fait avec iptables).

Mais je préfèrerai nettement négocier avec l'administrateur du serveur ssh.

* ordre des règles
Je présume que c'est de haut en bas.

En utilisant des alias, il n'y a que très peu de lignes à créer. Donc ce devrait être assez facile ...

[ccnet]

En utilisant des alias, il n'y a que très peu de lignes à créer. Donc ce devrait être assez facile ...

Je confirme, à utiliser absolument.