Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Sommaire des articles  -  Liens & Actualités

[pfSense] Troubleshooting / Dépannage de ses règles de NAT

icon 30/06/2020 - Aucun commentaire

La gestion du NAT peut parfois poser problème.

Dans cet article, nous traitons des problèmes les plus fréquemment rencontrés avec la gestion du NAT sous pfSense.


La gestion du NAT sous pfSense (généralités)

Il existe principalement 3 types de NAT (Network Address Translation) sous pfSense :

  • Port forward : pour la gestion de la redirection de port par adresse IP ; on parle de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
  • 1:1 NAT : NAT un-pour-un pour la redirection de tout le trafic d'une adresse IP vers une autre ; on parle également de D-NAT (Destination NAT), c'est-à-dire une modification de l’adresse IP de destination.
  • Outbound : les règles de NAT pour le trafic sortant ; dans ce cas, on part de S-NAT (Source NAT), c'est-à-dire une modification de l'adresse IP source.

Pour approfondir le fonctionnement du NAT sous pfSense, vous pouvez consulter notre article dédié [pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense.



Problèmes de port forward (redirection de port)

Règle de redirection de port incorrecte

Avant toute autre analyse, il est important de vérifier que la règle de redirection de port soit correctement configurée.
Il faut vérifier notamment les éléments suivants :

  • Interface : s'assurer que ce soit la bonne : celle sur laquelle les paquets réseaux arrivent ; il s'agit de l'interface d'entrée, soit le WAN pour une redirection de port depuis Internet vers le réseau local par exemple.
  • Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP".
  • Source : il est très rare de devoir la préciser ; elle devrait être laissée à sa valeur par défaut, c'est-à-dire "*" ou "any".
  • Dest. Address : il s'agit de l'adresse de destination recevant les paquets devant être translatés ; cette adresse IP est portée par le pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agit donc de l'adresse IP côté WAN.
  • Dest. Ports : le port ou la plage de ports de destination recevant les paquets devant être translatés ; il s'agit donc bien du port d'écoute sur le pfSense, pas du port de destination sur le serveur cible (qui peuvent être similaires ou différents).
  • NAT IP : l'adresse IP translatée ; c'est-à-dire l'adresse IP de destination finale vers laquelle le trafic doit être redirigé par pfSense. Dans le cas d'une redirection de port depuis Internet vers le réseau local, il s'agira donc de l'adresse IP locale du serveur cible.
  • NAT Ports : le port ou la plage de ports de destination finale recevant les paquets ; il s'agit donc bien du port d'écoute du serveur cible final, pas du port d'écoute du pfSense (ils peuvent être similaires ou différents).

Enfin, il faut également avoir en tête que le filtrage s'effectue après la règle de redirection de port. Ainsi, si l'on n'a pas choisi la création automatique d'une règle de filtrage (Add associated filter rule), il faut créer une règle avec la bonne adresse IP de destination, c'est-à-dire l'adresse IP locale du serveur cible.


Règle de filtrage incorrecte ou manquante

Il s'agit d'une erreur couramment rencontrée.
Il faut créer la règle de filtrage sur l'interface d'arrivée du paquet réseau (soit l'interface WAN dans le cas d'une redirection de port depuis Internet vers le réseau local) et il faut garder en tête que la translation d'adresse à déjà eu lieu et que c'est donc avec l'adresse IP de destination translatée (l'adresse IP finale) et le port de destination translaté (le port final) qu'il faut configurer la règle de filtrage.


Un pare-feu est présent sur le serveur cible

Un autre point à prendre en considération : la redirection de trafic peut être correctement effectuée par pfSense, mais le serveur cible peut avoir un pare-feu local d'installé qui bloque le trafic. Il convient donc de vérifier ce point également.


Le service sur le serveur cible n'est pas en écoute sur le bon port réseau

Il faut s'assurer que le serveur cible soit bien en écoute sur le port de destination.
S'il s'agit d'un port TCP, on peut utiliser l'outil de test intégré à pfSense et accessible depuis le menu Diagnostics > Test Port :

Menu Diagnostics > Test Port - pfSense - Provya


En cas de connexion réussie :

Test connexion TCP avec succès - pfSense - Provya

Connexion TCP réussie


En cas d'échec :

Test connexion TCP en échec - pfSense - Provya

Connexion TCP échouée



pfSense n'est pas la passerelle par défaut du serveur cible

Si pfSense n'est pas la passerelle par défaut du serveur cible, alors les paquets ne seront pas routés correctement. Il y a deux solutions par rapport à ce problème :

  • définir pfSense comme passerelle par défaut sur le serveur cible ;
  • configurer une règle d'Outbound NAT (NAT sortant) afin que l'adresse IP source du trafic reçue par le serveur cible soit l'adresse IP du pfSense ; cette solution peut poser des problèmes d'affinité de session côté serveur, elle est donc à manier avec prudence.

Si vous souhaitez implémenter une règle de NAT sortant, dans le cas d'une redirection de port depuis Internet vers le réseau local, la configuration à réaliser serait la suivante :

  • Interface : votre interface locale sur laquelle est rattachée le serveur cible (LAN, DMZ, OPT, ...) ;
  • Protocol : TCP, UDP, ICMP, ... ; si vous avez un doute entre TCP et UDP, choisir "TCP/UDP" ;
  • Source : dans notre cas pris en exemple, choisir any ;
  • Destination : choisir "Network" et indiquer l'adresse IP du serveur cible ; indiquer "32" pour le champ masque afin de ne cibler que le trafic à destination de ce serveur et, enfin, préciser le port réseau de destination sur lequel le serveur est en écoute.

Il faudra également passer le mode d'Outbound NAT d'Automatic vers Hybrid (ou Manual).
Exemple de configuration obtenue :

Exemple configuration Outbound NAT pfSense - Provya

Exemple de règle d'Outbound NAT pour un serveur cible n'ayant pas pfSense comme passerelle par défaut



Tester depuis le réseau local directement au lieu de le faire depuis l'extérieur

Il s'agit ici d'une erreur très courante lorsque l'on souhaite tester une configuration de redirection de port : faire les tests depuis le réseau local lui-même.
Par défaut, la redirection de port ne fonctionnera que pour les connexions provenant de l'extérieur du réseau.


Si après tous ces tests et toutes ces vérifications, la redirection de ports ne fonctionne toujours pas, vous pouvez relire nos articles [pfSense] Comprendre et analyser ses règles de routage et [pfSense] Troubleshooting / Dépannage de ses règles de filtrage.



Problèmes d'Outbound NAT (NAT sortant)

La démarche a suivre sera très similaire à celle détaillée précédemment pour les règles de redirection de port.

Le premier élément à avoir en tête est que les règles d'Outbound NAT se configurent sur l'interface de sortie du firewall. Tandis que pour les règles de redirection de port, c'est l'inverse : elles se configurent sur l'interface d'arrivée du firewall.

Le deuxième élément est qu'il est nécessaire de configurer autant de règles de NAT sortant qu'il y a de réseaux locaux.

Une bonne indication démontrant qu'il existe un problème de NAT sortant sera de voir des paquets quitter pfSense avec une adresse IP source en dehors du sous-réseau de l'interface ; par exemple, voir des paquets réseaux avec une adresse IP source du LAN sur l'interface WAN de pfSense indique qu'il y a une anomalie de NAT. Ces éléments se voient aisément à l'aide de l'outil "Packet Capture" accessible depuis le menu Diagnostics > Packet Capture :

Menu Diagnostics > Packet Capture pfSense - Provya


L'utilisation de l'outil "Packet Capture" fera l'objet d'un article dédié.



Pour aller plus loin

[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Comprendre et analyser ses règles de routage
[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

pfSense 2.4.5-p1 est disponible !

icon 10/06/2020 - Aucun commentaire

English version: pfSense 2.4.5-p1 now available

Mardi 09 juin 2020 est sortie la dernière version de pfSense. La version 2.4.5-p1.

Cette mise à jour comporte des correctifs de sécurité et de stabilité.

Dans cet article, nous faisons le tour des éléments marquants de cette mise à jour.



Sécurité

Les mises à jour de sécurité majeures sont les suivantes :

  • Correction du bug provoquant un emballement du CPU sur les pfSense virtualisés. Le bug apparaissait lors du rechargement d'une grande table pf (comme la liste des bogons, par exemple). Nous avions détaillé le bug dans notre article pfSense 2.4.5 est disponible !.
  • Correction d'un bug sur le package SSHGuard qui l'empêchait de protéger correctement les attaques par force brute.
  • Mise à jour de Unbound afin de corriger les vulnérabilités CVE-2020-12662 [EN] et CVE-2020-12663 [EN] ; il s'agit de vulnérabilités d'importance "haute" ; Unbound est un résolveur DNS.
  • Mise à jour de json-c afin de corriger la vulnérabilité CVE-2020-12762 [EN] ; il s'agit d'une vulnérabilité d'importance "haute" ; json-c est une bibliothèque d'implémentation du format JSON en C.
  • Correction d'une mauvaise gestion des droits attribués aux groupes d'utilisateurs.
  • Corrections de plusieurs avis de sécurité de FreeBSD.



Bugs / Amélioration

Plusieurs bugs ont été corrigés et des améliorations apportées :

  • Correction d'un problème lié au choix de la langue. C'est principalement le Mandarin de Taïwan qui était impacté par ce problème.
  • Ajout du pilote iwm pour les cartes wifi Intel (le pilote ne permet aux cartes wifi Intel de ne fonctionner qu'en mode client uniquement).
  • Ajour du pilote glxgb pour le support des cartes Ethernet QLogic 10Gbit/s.
  • Mise à jour du support de la norme EDNS ; EDNS (Extension mechanisms for DNS) est une extension au protocole DNS permettant l'ajout de fonctionnalités et l'augmentation de la taille de certains paramètres.
  • Squid : correction d'un dysfonctionnement sur les filtres LDAP contenant des accents.



Processus de mise à jour

Cette nouvelle version est disponible pour les mises à jour, et en téléchargement pour les nouvelles installations.

Si aucune mise à jour ne vous est proposée, il peut être utile de rafraîchir les dépôts de votre pfSense à l'aide des commandes suivantes (en saisir en console ou depuis un shell) :

pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade

Pensez à faire une sauvegarde avant de lancer la mise à jour, et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : 2.4.5-p1 New Features and Changes [EN]



Pour aller plus loin

[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des utilisateurs

icon 09/06/2020 - Aucun commentaire

Dans cet article nous traitons de la gestion des utilisateurs et des droits associés sous pfSense. Cette gestion permet de donner des droits aux utilisateurs pour l'accès à l'interface d'administration du pfSense ou pour l'authentification des utilisateurs sur les connexions VPN.



Gestion des utilisateurs

Il existe deux types d'utilisateurs sous pfSense : les utilisateurs locaux, c'est-à-dire dont l'administration (création, modification, suppression) va être gérée localement sur le pfSense ; et les utilisateurs externes authentifiés par un serveur d'authentification, c'est-à-dire des utilisateurs dont l'administration s'effectue depuis un serveur centralisé de type LDAP ou Radius.

Les utilisateurs peuvent être inclus dans un ou plusieurs groupes. Des droits sont donnés soit à l'utilisateur directement, soit au groupe. Les droits appliqués à un groupe s'appliquent à l'ensemble des utilisateurs membres du groupe.

La gestion des droits permet de définir avec précision les autorisations d'accès à l'interface du pfSense. Pour chaque utilisateur (ou chaque groupe), il est possible de définir jusqu'à quelle page précisément il a accès.
La gestion des utilisateurs permet également l'authentification pour les connexions VPN (OpenVPN ou IPsec) des utilisateurs nomades.

La gestion des droits s'opère depuis le menu System > User Manager :

menu System > User Manager sous pfSense - Provya


C'est depuis ce menu que sont gérés les utilisateurs, les groupes et les serveurs d'authentification.



Gestion des droits

Les droits peuvent être gérés au niveau des utilisateurs ou au niveau des groupes. Que l'on souhaite donner un droit à un utilisateur ou à un groupe, l'ordre des opérations à réaliser sera exactement le même : il faut d'abord créer l'utilisateur ou le groupe, puis modifier cet utilisateur (ou ce groupe) afin de lui attribuer les droits souhaités.

Pour chaque utilisateur, les droits attribués sont listés dans le tableau Effective Privileges. Pour chaque droit existant, il existe un champ description qui permet de facilement comprendre le périmètre associé.

Exemple gestion des droits utilisateur sous pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que l'utilisateur dispose du droit "WebCfg - Diagnostics: Halt system" qui se lit : accès à l'interface web (WebCfg), menu Diagnostics, page Halt System. Le champ description nous précise que ce droit "permet d'accéder à la page 'Diagnostics: Halt system'.".

Il est possible d'ajouter de nouveaux droits en cliquant sur le bouton "+ Add" se trouvant sous le tableau des droits déjà attribués.

Les droits disponibles sont affichés sous la forme d'une liste. Il est possible de sélectionner plusieurs éléments dans la liste en maintenant la touche "Ctrl" enfoncée.

Le champ Filter permet de filtrer sur un terme précis (il faudra cliquer sur le bouton "Filter" en bas de page pour activer le filtre).

Enfin, le champ sur fond bleu en bas de la page présente la description liée au droit sélectionné.

Exemple de recherche sur la gestion des droits utilisateur sous pfSense - Provya


Sur la capture d'écran ci-dessus, une recherche sur le terme "openvpn" a été faite (1). La ligne "WebCfg - Status: OpenVPN" a été sélectionnée (2) et le champ description sur fond bleu en bas de page nous précise que ce droit permet l'accès à la page 'Status: OpenVPN' (3).

Les principaux droits couramment utilisés sont les suivants :

  • WebCfg - All Pages : donne l'accès à toutes les pages de l'interface web de pfSense.
  • WebCfg - Dashboard (all) : donne l'accès uniquement au tableau de bord et à toutes ses fonctions associées (widgets, graphs, etc.).
  • WebCfg - System: User Password Manager : donne accès uniquement à la page de modification de son mot de passe et à rien d'autre.
  • User - System: Shell account access : donne le droit de se connecter en SSH au pfSense. Cependant, si l'utilisateur ne dispose pas d'un compte root, les fonctionnalités offertes seront limitées...



Ajout / Modification d'un utilisateur

L'ajout d'un utilisateur se fait en cliquant sur le bouton "+ Add" en bas à droite de la page "Users" (page par défaut du menu System > User Manager). Les champs configurables sont les suivants :

  • Disabled : cocher cette case pour désactiver l'utilisateur sans pour autant le supprimer ;
  • Username : le login de l'utilisateur. Le nom d'utilisateur peut faire jusqu'à 16 caractères au maximum et ne doit contenir que des lettres, chiffres, points, tirets ou underscores ;
  • Password : le mot de passe et sa confirmation ;
  • Full name : le nom complet de l'utilisateur ;
  • Expiration date : il est possible de définir une date d'expiration au compte utilisateur. Si ce champ est laissé vide, le compte n'expirera jamais. Si l'on souhaite renseigner une date il faut faire attention au format qui est le format américain (MM/JJ/AAAA - Mois/Jour/Année) ;
  • Custom Settings : permet de modifier les paramètres d'affichage pour l'utilisateur comme le thème de l'interface web, le comportement du menu, l'ordre d'affichage des interfaces réseaux, etc. ;
  • Group membership : les groupes d'appartenance de l'utilisateur. Un utilisateur peut faire partie de plusieurs groupes. Les droits de chaque groupe s'applique alors à l'utilisateur ;
  • Effective Privileges : ce tableau permet d'attribuer des droits directement à l'utilisateur. Il est à noter que ce tableau n'apparaît qu'à la modification d'un utilisateur, il n'est pas proposé lors de la création ;
  • Certificate : permet la création d'un certificat utilisateur. Il est à noter que cette section n'a pas exactement le même affichage suivant si l'on crée ou si l'on modifie l'utilisateur. Lors de la modification d'un utilisateur, il sera possible de lui associer un certificat existant. Pour davantage d'informations sur la création d'un certificat, voir notre article [pfSense] La gestion des certificats pour les connexions OpenVPN ;
  • Authorized keys : une clé publique pour l'authentification SSH peut être saisie ici. Ainsi, l'utilisateur pourra s'authentifier avec sa clé privée plutôt qu'avec un son mot de passe ;
  • IPsec Pre-Shared Key : utilisé uniquement si l'on utilise un VPN IPsec mobile avec une clé pré-partagée pour une authentification non-XAuth (Extended Authentication). Dans le cas contraire, ce champ doit être laissé vide.

Si certaines options ne sont pas accessibles lors de la création de l'utilisateur, il faut sauvegarder, puis modifier l'utilisateur pour y avoir accès.



Ajout / Modification d'un groupe

Les groupes sont le moyen le plus pratique pour gérer les droits affectés aux utilisateurs sans avoir besoin de les gérer individuellement utilisateur par utilisateur.
Un utilisateur bénéficiera des droits cumulés de chaque groupe dont il fait partie.

Comme pour les utilisateurs, il faut d'abord créer un groupe avant de pouvoir lui attribuer des droits. Il faut donc créer un groupe, puis le modifier pour lui ajouter des droits.

L'ajout d'un groupe se fait en cliquant sur le bouton "+ Add" en bas à droite de la page "Groups" (accessible depuis le menu System > User Manager). Les champs configurables sont les suivants :

  • Group name : le nom du groupe. Le nom du groupe peut faire jusqu'à 16 caractères au maximum et ne doit contenir que des lettres, chiffres, points, tirets ou underscores ;
  • Scope : la portée du groupe. Deux valeurs sont possibles : local - crée le groupe localement pour des utilisateurs locaux ; remote utilisé pour l'authentification via un serveur externe ;
  • Description : champ optionnel purement informatif ;
  • Group Membership : la liste des utilisateurs membres du groupe ;
  • Assigned Privileges : Ce tableau permet d'attribuer des droits aux membres du groupe. Il est à noter que ce tableau n'apparaît qu'à la modification d'un groupe, il n'est pas proposé lors de la création.



Quelques options avancées

L'onglet Settings permet de configurer deux éléments : la durée de validité d'une session et comment les utilisateurs sont authentifiés.

Durée de validité de la session (Session timeout)

La durée de validité d'une session est, par défaut, de quatre heures (240 minutes). Il est possible de réduire ou d'augmenter la durée de validité de la session. La durée de session est exprimée en minutes.
Il est également possible de faire en sorte que les sessions n'expirent jamais ; il faut pour cela passer la valeur à 0.

Notre recommandation est d'avoir une validité de session d'une durée d'une heure au maximum.


Serveur d'authentification (Authentication Server)

Cette option permet de choisir le serveur primaire d'authentification. Ce peut être un serveur distant Radius ou LDAP, ou la base de données locale de pfSense.
Dans le cas, où une authentification via un serveur distant est configurée et que celui-ci n'est pas accessible, l'authentification se fera via la base de donnée locales en secours.

Lorsque l'on souhaite utiliser l'authentification via un serveur Radius ou LDAP, les utilisateurs et/ou les groupes doivent également être définis côté firewall afin que les droits soient correctement alloués. Il n'y a pas vraiment de solution pour obtenir dynamiquement les autorisations à partir d'un serveur d'authentification.

Ainsi, pour que les droits attribués à un groupe fonctionnent, il faut :

  1. Que le groupe existe sur le serveur d'authentification distant.
  2. Que le même groupe (avec le même nom) existe en local sur le firewall.
  3. Que le pfSense puisse joindre le serveur d'authentification et récupérer la liste des groupes.

Nous avons fait le tour des éléments à connaître pour la gestion des utilisateurs sous pfSense.
L'authentification via un serveur externe fera l'objet d'un autre article détaillé.



Pour aller plus loin

Best practices / Recommandations pour la configuration de votre firewall
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, assemblés en France, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :