Provya

Expertise pfSense

Sommaire des articles  -  Liens & Actualités  -  Firewall pour pfSense

pfSense 2.7.2 est disponible

icon 11/12/2023 - Aucun commentaire

Jeudi 07 décembre 2023 est sortie la dernière version de pfSense. La version 2.7.2.

Cette nouvelle version intervient moins d'un mois après la sortie de pfSense 2.7.1.

pfSense 2.7.2 corrige principalement des problèmes potentiels de corruption du système de fichiers ZFS, ainsi que d'autres bugs et problèmes de sécurité.

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



Changements principaux


Cette toute nouvelle version de pfSense vise principalement à corriger des problèmes avec le système de fichiers ZFS.

En effet, peu de temps après la sortie de pfSense 2.7.1, plusieurs anomalies sérieuses ont été annoncées, puis rapidement corrigées, sur FreeBSD 14 (le système d'exploitation sur lequel repose pfSense).

Dans le détail, pfSense 2.7.2 comporte des modifications relatives à trois problèmes liés au système de fichiers ZFS, dont deux pourraient entraîner une corruption des données.

Le premier est lié au clonage de blocs, une fonctionnalité de ZFS qui n'est actuellement pas activée dans le logiciel pfSense.

Le second est lié au signalement de trous dans les fichiers sparse. C'est un cas normalement très difficile à rencontrer dans le cadre d'une utilisation typique sur un système équipé du logiciel pfSense. Cependant, étant donné que d'autres problèmes de corruption de données ont été rapportés dans la même zone par le passé, l'éditeur a préféré intégrer rapidement les corrections proposées par FreeBSD. Cette correction peut entraîner une légère augmentation de l'espace de stockage utilisé.

Enfin, pfSense 2.7.2 corrige également un troisième problème ZFS qui peut entraîner une utilisation élevée du processeur.

En plus de ces problèmes spécifiques à ZFS, cette nouvelle version apporte également les correctifs suivants :
  • Correction d'un avis de sécurité concernant une attaque potentielle par déni de service sur la pile TCP à partir de paquets RST usurpés ;
  • Mise à jour d'OpenVPN vers la version 2.6.8_1 ;
  • Mise à jour de strongSwan (IPsec) pour résoudre un problème potentiel de dépassement de mémoire tampon (CVE-2023-41913) ;
  • Correction de bugs dans l'implémentation du fallback de AES-GCM ;
  • Correction de plusieurs erreurs PHP sur les pages de création d'une interface PPP et de modification du service DHCPv6
  • Plusieurs autres bugs, failles de sécurité et autres problèmes mineurs ont également été corrigés



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 (à saisir en console ou depuis un shell) :

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

Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un point de restauration.

Dans tous les cas, 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.7.2 New Features and Changes [EN]



Pour aller plus loin



[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Évolutions et actualités du logiciel pfSense
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfsense 2.7.1 est disponible

icon 21/11/2023 - Aucun commentaire

Jeudi 16 novembre 2023 est sortie la dernière version de pfSense. La version 2.7.1.

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



OpenSSL mis à jour vers la version 3.0.12


pfSense embarquait jusqu'à présent OpenSSL en version 1.1.1. Il s'agit d'une vieille version d'OpenSSL dont la date de fin de vie (EOL) était dépassée.

La mise à niveau vers OpenSSL 3.0.12 signifie qu'un certain nombre d'algorithmes de chiffrement et de hachage, aujourd'hui considérés comme trop faibles, ont été supprimés.

Il est donc très important de s'assurer ces algorithmes ne sont pas utilisés avant de mettre à jour son firewall pfSense !

Les algorithmes de chiffrement supprimés sont :
  • ARIA
  • Blowfish (notamment BF-CBC, qui était auparavant un algorithme par défaut d'OpenVPN)
  • CAST5
  • DES
  • DESX
  • IDEA
  • RC2
  • RC5
  • SEED
  • SM4

Les algorithmes de hachage retirés sont :
  • MD4
  • MDC2
  • SM3
  • Whirlpool



Le serveur Kea DHCP est proposé en option


Le serveur DHCP de Kea est proposé en option "opt-in".

Qu'est-ce que Kea DHCP ?

L'Internet Systems Consortium (ISC) distribue deux serveurs DHCP complets à code source ouvert : Kea DHCP et ISC DHCP.

L'ISC a annoncé la fin de vie (EOL) du serveur DHCP ISC qui est jusqu'à présent embarqué dans pfSense pour servir de serveur DHCP.

Kea est plus récent, comprend toutes les fonctionnalités les plus demandées et est conçu pour un environnement réseau plus moderne. Bref, il était plus que temps de mettre à jour.

Pour le moment Kea est proposé à titre expérimental. Certaines fonctionnalités ne sont pas supportées.
Notamment si vous utilisez l'attribution de nom d'hôte via des baux statiques ou si vous vous appuyez sur l'enregistrement dynamique des baux DHCP dans votre configuration DNS, cela ne fonctionnera pas correctement avec Kea. Il faudra rester sur ISC pour le moment.

De la même manière, Kea ne supporte pas pour le moment les installations de pfSense en haute-disponibilité.

Si vous souhaitez activer et tester Kea, la procédure est la suivante :
  • Se rendre dans le menu System > Advanced
  • Onglet Networking
  • Modifier la valeur de Server Backend à Kea DHCP
  • Cliquer sur le bouton Save en bas de page.

Activer serveur DHCP Kea sur pfSense




Amélioration de la prise en charge du protocole SCTP


Le support de SCTP a été amélioré dans PF pour les règles de pare-feu, NAT et la journalisation.

Les règles peuvent maintenant agir sur les paquets SCTP par numéro de port. Auparavant, il n'était possible de filtrer que sur l'adresse source ou l'adresse de destination.

Pour rappel, SCTP (Stream Control Transmission Protocol) est un protocole de la couche transport qui garantit un transport fiable des données en séquence.



La section de configuration IPv6 Router a été déplacée


Dans le cadre de l'intégration du serveur DHCP Kea, la section permettant la configuration des IPv6 Router Advertisement a été déplacée dans le menu Services > Router Advertisement.



Autres changements


Les changements suivants sont aussi à noter :
  • PHP mis à jour vers la version 8.2.11
  • FreeBSD 14 a été mis à jour vers sa version la plus récente disponible
  • Plusieurs bugs, failles de sécurité et autres problèmes mineurs ont également été corrigés



Avant de mettre à jour


Avant de lancer une mise à jour, il faut impérativement s'assurer que l'on n'utilise aucun algorithme de chiffrement ou de hachage qui a été retiré :

Les algorithmes de chiffrement supprimés sont :
  • ARIA
  • Blowfish (notamment BF-CBC, qui était auparavant un algorithme par défaut d'OpenVPN)
  • CAST5
  • DES
  • DESX
  • IDEA
  • RC2
  • RC5
  • SEED
  • SM4

Les algorithmes de hachage retirés sont :
  • MD4
  • MDC2
  • SM3
  • Whirlpool



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 (à saisir en console ou depuis un shell) :

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

Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un point de restauration.

Dans tous les cas, 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.7.1 New Features and Changes [EN]



Pour aller plus loin



[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Le proxy Squid est retiré de pfSense pour des raisons de sécurité

icon 14/11/2023 - Aucun commentaire

Netgate, l'éditeur du logiciel pfSense, a annoncé le 10/11/2023 que le package Squid (proxy) serait retiré des prochaines versions de pfSense pour des raisons de sécurité.

C'est à travers une annonce pour le moins lapidaire que l'éditeur du logiciel pfSense a averti sur son blog du retrait prochain du package Squid.



Squid, qu'est-ce que c'est ?


Squid est un serveur mandataire (ou proxy).

Squid offre, notamment, les fonctionnalités suivantes :
  • accélération de la navigation : mise en cache et réutilisation du contenu web fréquemment consulté afin de réduire l'utilisation de la bande passante ;
  • historique (logs) : journalisation des requêtes ;
  • la sécurité du réseau local ;
  • le filtrage : restrictions de sites, blocage des publicités ou des contenus lourds.

Squid est très sûrement le serveur mandataire le plus utilisé au monde. On le retrouve dans de très nombreux produits open-source ou propriétaires.



Failles de sécurité non résolues dans Squid


Netgate souligne que plusieurs rapports récents ont identifié un grand nombre de failles de sécurité non résolues dans Squid.

En fait, l'affaire remonte à un audit de sécurité mené par Joshua Rogers, un chercheur en sécurité, réalisé en 2021.

Lors de son audit, Joshua a découvert 55 failles de sécurité et 26 bugs non liés à la sécurité.

L'ensemble de ces éléments a été rapporté aux développeurs de Squid.

Toujours d'après Joshua, seulement une poignée de ces failles ont été corrigées plus de deux ans après : trente-cinq d'entre elles n'ont reçu aucun correctif.

Le chercheur précise que "l'équipe Squid a été d'une grande aide et d'un grand soutien tout au long du processus de signalement de ces problèmes. Cependant, elle manque de personnel et n'a tout simplement pas les ressources nécessaires pour résoudre les problèmes découverts. Le fait de leur demander de résoudre ces problèmes ne mènera à rien".

Au vu de ces éléments, Netgate, l'éditeur du logiciel pfSense, considère désormais que le package Squid, ainsi que les packages additionnels Lightsquid et SquidGuard, sont "obsolètes".

Ces packages continueront à être disponibles dans la prochaine mouture de pfSense, la version 2.7.1, qui devrait sortir cette semaine, mais ils seront en revanche retirés des versions suivantes.



Quelles solutions de remplacement ?


Dans l'immédiat, Squid peut toujours être utilisé ; il n'a pas été retiré de pfSense pour le moment, mais il devrait l'être à partir de pfSense 2.8.0.

Ceci étant, la version de Squid proposée sous pfSense est concernée par les failles de sécurité remontées par Joshua Rogers. Il peut donc être préférable d'envisager une solution alternative à Squid.

Pour le filtrage des noms de domaine, il est possible de se pencher sur les solutions à base de filtrage DNS. Sous pfSense, cette solution peut être implémentée avec le package pfBlockerNG.

Côté OPNsense, des solutions de filtrage DNS sont déjà implémentées ; il suffit de les configurer en fonction de ses besoins.

Enfin, côté OPNsense, il est possible d'opter pour le plugin Zenarmor. Il s'agit d'une solution très complète pour le filtrage des accès à Internet avec des possibilités de personnalisations avancées.

Zenarmor fera d'ailleurs l'objet d'un prochain article.


Si vous souhaitez obtenir davantage d'informations sur le sujet (en anglais), vous pouvez consulter les liens suivants :

Deprecation of Squid Add-On Package For pfSense Software

Squid games: 35 security holes still unpatched in proxy after 2 years, now public

Squid Caching Proxy Security Audit: 55 Vulnerabilities, 35 0days

Dozens of Squid Proxy Vulnerabilities Remain Unpatched 2 Years After Disclosure

55 Vulnerabilities in Squid Caching Proxy and 35 0days



Pour aller plus loin


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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Maintenir son firewall à jour avec les patches

icon 26/10/2023 - Aucun commentaire

Il est possible de mettre à jour son pfSense avec un système de correctifs (patches). Ces patches permettent de corriger des failles de sécurité ou bogues entre deux mises à jour de pfSense.

Dans cet article, nous présentons le mode de fonctionnement des correctifs.


Mettre à jour son firewall pfSense


Disposer d'un firewall à jour est une nécessité. Le firewall assurant généralement la sécurité périmétrique du réseau d'une entreprise, il paraît indispensable que cet outil soit correctement et régulièrement mis à jour.

Certains firewall proposent des mises à jour très régulièrement. C'est le cas notamment d'OPNsense : il y a 2 mises à jour majeures par an (en janvier et en juillet) et une succession de mises à jour intermédiaires (généralement toutes les deux à trois semaines en moyenne) permettant de corriger les bugs ou failles de sécurité découverts.

pfSense Plus, la version non open-source et payante de pfSense, propose quant à elle des mises à jour trois fois par an (janvier, mai et septembre). L'éditeur a cependant régulièrement un peu de retard dans son cycle de publication (par exemple, la version bêta de pfSense Plus 23.09 a été publiée mi-octobre 2023 alors que le calendrier de sortie prévoyait une publication de la version finale en septembre...).

Enfin, pfSense (dans sa version communautaire) propose des mises à jour "quand c'est prêt". Le temps peut parfois être long entre deux mises à jour du système (un an à un an et demi, en moyenne).

Cependant, il existe une fonctionnalité plutôt méconnue sur pfSense (ainsi que sur pfSense Plus) permettant d'installer des correctifs entre deux mises à jour. Un certain nombre de ces correctifs est recommandé par l'éditeur. Il est donc conseillé d'appliquer ces correctifs recommandés lorsqu'ils sont disponibles.



Patcher son firewall pfSense


Pour installer des correctifs, il faudra tout d'abord installer le package "System Patches". Pour cela, se rendre dans le menu System > Package Manager :

Menu System > Package Manager - pfSense


Cliquer sur l'onglet "Available Packages" et faire une recherche sur le mot-clef "patch". Installer ensuite le package en cliquant sur le bouton "Install" :

Installer un package - pfSense



Une fois le package System_Patches installé, nous pouvons le retrouver depuis le menu System > Patches :

Menu System > Patches - pfSense


Cette page permet d'appliquer des correctifs, que ce soit des correctifs officiels ou non.

Dans le cas présent, c'est la liste des correctifs recommandés qui nous intéresse :

Installer un correctif - pfSense


Sur la capture d'écran ci-dessus, nous pouvons voir qu'il y a sept correctifs recommandés pour pfSense 2.7.0, dont un (le dernier) qui a déjà été installé.

Pour installer les correctifs recommandés, nous cliquons simplement sur le bouton "Apply All Recommended". L'application est immédiate. Aucun redémarrage n'est nécessaire.



Retirer un correctif installé


Enfin, il est tout à fait possible de retirer un correctif installé. Nous pouvons soit cliquer sur le bouton "Revert" associé au correctif que l'on souhaite retirer, soit cliquer sur le bouton "Revert All Recommended". L'action est immédiate. Aucun redémarrage n'est nécessaire.


Cette page d'application des correctifs offre d'autres possibilités avancées que nous ne détaillons pas ici. L'objectif était de présenter une bonne pratique méconnue d'installation de correctifs entre deux mise à jour de pfSense.

Maintenant, il ne vous reste plus qu'à patcher !



Pour aller plus loin



[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfsense 2.7.0 est disponible

icon 03/07/2023 - Aucun commentaire

Jeudi 29 juin 2023 est sortie la dernière version de pfSense. La version 2.7.0.

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



Changements principaux


Les principaux changements ou mises à jour sont les suivants :
  • passage de FreeBSD 12 à FreeBSD 14 : bascule de la branche stable/12 vers la branche current/14. Nous expliquions plus en détails ce changement dans notre article Évolutions et actualités du logiciel pfSense
  • passage de PHP 7.4.x à PHP 8.2.x
  • plusieurs anciens algorithmes de chiffrement ou de hachage ont été dépréciés
  • il ne sera bientôt plus possible de créer des tunnels OpenVPN à clefs partagées
  • l'outil de capture de paquets a été grandement amélioré

Dans la suite de cet article, nous présentons les autres principales évolutions.



Gestion des règles de filtrage


L'utilisation et la modification des règles de firewall ont été améliorées.

Il est possible de tuer les états liés à une règle de filtrage en particulier :

Tuer sessions d'une règle pfSense - Provya


La duplication d'une règle d'une interface à une autre a également été facilitée avec un nouveau bouton permettant une copie assistée :

Copier règle de filtrage pfSense - Provya




OpenVPN


Mise à jour d'OpenVPN vers la version 2.6.4.
La création de tunnels OpenVPN site-à-site à clef partagée est fortement déconseillée. Il faut privilégier l'utilisation de certificats.
On peut continuer à créer de nouveaux tunnels à clef partagée, mais cela générera des alertes dans les logs.

À l'avenir, il faudra migrer ses tunnels à clef partagée vers des tunnels avec certificats.

Serveur OpenVPN pfSense - Provya

Une alerte est affichée si l'on choisi "Peer to peer (Shared Key)"




IPsec


Le passage de FreeBSD 12 à FreeBSD 14 a entraîné le déclassement d'un certain nombre d'algorithmes de chiffrement ou de hachage.
Les algorithmes suivants ne sont plus supportés :
  • 3DES
  • Blowfish
  • CAST 128
  • MD5

Si vous utilisez ces algorithmes pour vos accès IPsec, il faudra modifier vos configurations avant de pouvoir mettre à jour vers pfSense 2.7.0.

De toute façon, si vous êtes utilisateurs de ces algorithmes, il est plus que temps de modifier vos configurations car celles-ci sont considérées comme non-sûres depuis déjà plusieurs années.

Enfin, il a été ajouté le supporte de l'algorithme ChaCha20-Poly1305 pour les connexions IPsec.



Troubleshooting / capture de paquets


L'outil de capture de paquets s'est enrichi. C'est tant mieux car il faisait franchement obsolète lorsqu'on le comparait à celui intégré à OPNsense (note : il faut bien reconnaître que pfSense en général paraît bien obsolète lorsqu'on le compare à OPNsense...).

Il est possible d'appliquer davantage de filtres sur ce que l'on souhaite capturer.

La nouvelle interface ressemble à ceci :

Nouvel outil de capture de paquets - pfSense 2.7.0




Alias


Il s'agit ici principalement de la correction de bugs, dont notamment :
  • un bug faisant que certains alias ne se chargeaient pas complètement lorsqu'ils contenaient un mélange d'adresses IP et de FQDN
  • lorsqu'un alias contenait un FQDN non-résolu, cela pouvait casser le contenu de l'alias (les autres entrées n'étaient pas correctement chargées)
  • lors de l'import / export d'alias, les descriptions pouvaient être perdues
  • lorsque l'on renommait un alias, cela ne mettait pas forcément à jour les routes statiques associées ou les instances OpenVPN



Unbound


La version d'Unbound embarquée sur pfSense 2.6 était franchement obsolète et comportait des bugs. La mise à jour corrige ces bugs.

Il y avait notamment un vieux bug qui traînait depuis quelques années qui, dans certaines configurations avec pfBlockerNG, pouvait faire planter Unbound lors d'un redémarrage. C'est corrigé.



Sécurité


Comme pour toute mise à jour, pfSense 2.7.0 apporte son lot de corrections de sécurité.

La plupart des problèmes de sécurité pouvait déjà être corrigée grâce au system patch (qui permet l'application de correctifs entre deux mises à jour de pfSense).

La plupart des failles de sécurité détectées concernait la gestion des alias et notamment des alias de type URL et URL Table.
Pour un rappel complet sur le fonctionnement des alias, voir notre article dédié : [pfSense] Tout comprendre aux alias.

Les problèmes étaient des failles de type XSS. Il est à noter qu'il y avait également d'autres vulnérabilités XSS potentielles sur certaines pages de l'interface web de pfSense.

Autre point lié à la sécurité : il était possible de contourner la protection contre les attaques par force brute (sshguard) avec des entêtes particulières. En simplifiant, il suffisait d'inclure dans ses entêtes la référence à un proxy pour empêcher que son adresse IP ne puisse être bloquée.



Bugs


Les principaux bugs corrigés sont :
  • Il était possible d'utiliser des mots clefs réservés par PF (packet filter) dans le champ description des interfaces (comme par exemple USER = "{ vtnet2 }" ). Dans son mode de fonctionnement, pfSense crée des alias implicites pour chaque interface. Utiliser un mot clef réservé faisait que le chargement des règles de filtrage plantait.
  • Lors du démarrage du firewall, les VIP CARP peuvent devenir maîtres trop tôt ce qui pouvait entraîner le fait d'avoir plusieurs master sur le réseau pendant quelques dizaines de secondes.
  • Lorsque qu'on sortait CARP du mode "persistent maintenance mode", cela pouvait générer une tempête de broadcast d'événement CARP.
  • Si on changeait l'adresse IP et la passerelle d'une interface depuis la console, il pouvait arriver que la nouvelle passerelle ne soit pas correctement enregistrée.
  • Certains utilisateurs rencontraient des problèmes avec UPnP (notamment pour les jeux en ligne).
  • Pas mal de petits bugs du côté du portail captif ont été corrigés également.



Améliorations


Pas mal d'améliorations. Les principales sont :
  • Ajout d'une option sur l'interface graphique pour sélectionner l'algorithme de hachage du mot de passe utilisateur (on a dorénavant le choix entre bcrypt [par défaut] et SHA-512).
  • Ajout d'une option pour activer/désactiver la sonnerie de la console lorsque l'on se connecte sur le firewall (avant, il fallait passer les system tunables et jouer avec la valeur du paramètre kern.vt.enable_bell).
  • Lors d'une restauration, il est maintenant possible de restaurer uniquement l'emplacement des widget sur le tableau de bord.
  • Lorsque l'on renouvelle un certificat, il est maintenant proposé une option pour conserver le numéro de série existant.
  • Meilleure lisibilité des baux DHCP : il y a maintenant une distinction entre les entrées en ligne et les entrées inactives/hors ligne dans la liste des baux DHCP.
  • Le portail captif reposait jusqu'à présent sur IPFW (ipfirewall), il repose désormais sur PF (Packet Filter).
  • Ajout de nouvelles options de destruction de l'état de la passerelle pour un basculement plus fluide.



Avant de mettre à jour


Avant de lancer une mise à jour, il faut impérativement s'assurer sur ses liens IPsec n'utilisent pas un algorithme de chiffrement déprécié (3DES, Blowfish, CAST 128, MD5).

Concernant les tunnels OpenVPN à clefs partagées, il est recommandé de les migrer vers une configuration avec certificats avant de lancer la mise à jour (ce n'est pas obligatoire, mais fortement recommandé).



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 (à saisir en console ou depuis un shell) :

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

Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un point de restauration.

Dans tous les cas, 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.7.0 New Features and Changes [EN]



Pour aller plus loin



[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Tout comprendre aux alias
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Je n'ai plus accès à mon firewall, comment faire ?

icon 22/06/2023 - Aucun commentaire

Il peut parfois arriver que l'on se bloque l'accès au firewall pfSense.
Il peut y avoir plusieurs raisons à cela : une mauvaise manipulation, la saisie d'un trop grand nombre de mots de passe erronés, un firewall qui tourne depuis des années et dont on a égaré les codes d'accès, etc.

pfSense


L'objectif de cet article est de traiter ces différents cas où l'on n'a plus accès à l'interface du firewall, et les solutions associées.

Dans le pire des cas, si l'on dispose d'un accès physique au firewall, alors il sera toujours possible de reprendre la main dessus.
Il est d'ailleurs important de noter qu'une personne qui dispose d'un accès physique au firewall pourra contourner la totalité des mesures de sécurité.


Mot de passe admin oublié ou perdu


Si le mot de passe a été perdu ou oublié, la solution la plus efficace est de se connecter en console (ou de brancher un clavier et un écran) afin de lancer la réinitialisation du mot de passe admin.

Il faudra choisir l'option 3 :

Console de pfSense


Cette option permet également de réinitialiser le compte admin s'il est désactivé ou a expiré.

Le mot de passe admin sera réinitialisé à sa valeur par défaut, c'est-à-dire pfsense.


Mot de passe oublié avec l'accès console verrouillé


L'accès à la console peut être protégé par un mot de passe.
Ce n'est pas le mode par défaut pour pfSense, mais cela peut être activé depuis le menu System > Advanced en cochant la case "Password protect the console menu" :

Protéger la console de pfSense par un mot de passe


Dans ce cas, un identifiant et un mot de passe sont demandés lors de la connexion en console ou lorsque l'on branche un clavier et un écran au firewall :

Console de pfSense protégée par un mot de passe


Heureusement, tout n'est pas perdu !

La procédure pour réinitialiser le mot de passe est la suivante :
  • se brancher sur le firewall (en console ou avec un clavier et un écran)
  • redémarrer le firewall et choisir Boot Single User option (2) à partir du menu de chargement avec le logo ASCII

Menu ASCII de pfSense


Si on trouve que le menu se déroule trop vite, on peut appuyer sur la touche "espace" pour l'arrêter.

  • appuyer sur Entrée lorsque l'on est invité à choisir le shell /bin/sh :

Choix du prompt sur pfSense


  • Il faut ensuite remonter les partitions. La procédure est différente en fonction du système de fichier (filesystem) : UFS ou ZFS.

Pour les systèmes de fichier UFS, la commande à saisir sera la suivante :

# /sbin/mount -a -t ufs

Pour les systèmes de fichier ZFS, les commandes à saisir seront les suivantes :

# /sbin/mount -u /

Si cela retourne une erreur, on peut essayer :
# /sbin/zfs set readonly=off pfSense/ROOT/default

Et enfin :
# /sbin/zfs mount -a


Une fois que le système de fichier est monté, saisir la commande suivante et se laisser guider :
/etc/rc.initial.password

Enfin, il faudra redémarrer le firewall en saisissant la commande suivante :
/sbin/reboot


L'interface web de pfSense ne répond plus...


Il peut y avoir plusieurs raisons à cela.

Une erreur classique est de se tromper de protocole entre HTTP et HTTPS. Si l'un ne fonctionne pas, on peut essayer l'autre.
Si l'interface graphique n'a pas été configurée correctement, il est tout à fait possible que le firewall fasse tourner l'interface web sur une combinaison inattendue de port et de protocole, par exemple :
https://<hostname>:80
http://<hostname>:443

Pour réinitialiser la configuration, on peut se connecter en console (ou brancher un écran et un clavier), faire le choix 2 permettant de reconfigurer l'adresse IP de pfSense sur son interface LAN et de réinitialiser le protocole d'écoute de l'interface web de pfSense.

Une autre possibilité est que l'interface web de pfSense soit plantée. C'est extrêmement rare, mais ça peut toujours arriver. Si l'on souhaite forcer un redémarrage de l'interface web, on peut se connecter en console (ou avec un clavier et un écran) et faire le choix 11 "Restart webConfigurator" :

Restart du webui de pfSense



Une nouvelle règle de filtrage bloque l'accès au firewall


Si un administrateur distant perd l'accès à l'interface graphique en raison d'une modification des règles du pare-feu, l'accès peut toujours être obtenu du côté du LAN.
Par défaut, il n'est pas possible de se couper l'accès à l'interface web de pfSense depuis le LAN, sauf si la règle "anti-lockout" a été désactivée.

Sinon, il est toujours possible de se connecter en console (ou clavier et écran) et supprimer la dernière règle de filtrage qui vient d'être créée.
Il s'agit d'une fonctionnalité très pratique de pfSense : à chaque modification, une sauvegarde locale est effectuée sur le firewall. Ainsi, il est aisé de revenir en arrière.

Dans notre cas, sur la console, on choisira l'option 15 "Restore recent configuration" et on choisira la dernière configuration à restaurer :

Restaurer une ancienne configuration de pfSense



Je suis bloqué car j'ai saisi trop de mots de passe erronés


Si l'on tente de se connecter à l'interface web ou en SSH et qu'on échoue à plusieurs reprises, notre adresse IP de connexion sera ajoutée à la liste de blocage.

Pour se débloquer l'accès, il faudra changer l'adresse IP de notre machine pour se connecter à pfSense, puis se rendre dans le menu Diagnostics > Tables et sélectionner sshguard dans la liste des alias disponibles pour supprimer l'adresse IP bloquée.

Débloquer son adresse IP sur pfSense


Il est également possible de faire la même chose en ligne de commande (videra complètement la table "sshguard") :
pfctl -T flush -t sshguard


Activer l'accès à l'interface web sur le WAN depuis une console


Le moyen le plus simple (et le plus propre), si l'on connaît son adresse IP publique est d'utiliser le script shell easyrule pour ajouter une nouvelle règle de filtrage.

Dans l'exemple suivant, le script easyrule autorisera l'accès sur l'interface WAN, de 1.2.3.4 (l'adresse IP du client) à 6.7.8.9 (vraisemblablement l'adresse IP WAN) sur le port TCP 443 :
easyrule pass wan tcp 1.2.3.4 6.7.8.9 443

Dès que la commande aura été saisie, le client (1.2.3.4) pourra se connecter au firewall (6.7.8.9).

Si l'on ne connaît pas son adresse IP publique, il est techniquement possible de créer une règle de type "allow all" sur le firewall. Pour cela, la commande à saisir en console sera la suivante :
pfSsh.php playback enableallowallwan

Une fois que l'administrateur a retrouvé l'accès et corrigé le problème initial qui l'empêchait d'accéder à l'interface web de pfSense, il faut impérativement supprimer la règle "allow all" du WAN.


Je ne m'en sors pas, comment désactiver le firewall ?


Il s'agit là d'une solution très dangereuse, mais qui peut s'avérer pratique dans des cas désespérés (bon dans ces cas-là, il vaut mieux nous appeler plutôt que de prendre de trop gros risques avec la sécurité de votre réseau ;-)

En mode console, on fera le choix 8 (Shell) et on saisira la commande suivante :
pfctl -d

Le firewall pourra ensuite être réactivé avec la commande :
pfctl -e

Le firewall sera aussi réactivé dès que l'on aura créé ou modifié une règle de filtrage et cliqué sur le bouton "Apply changes".


Le proxy Squid me bloque l'accès au firewall !


Cela peut arriver si l'on configure un peu trop vite squid et qu'on lui attribue le port d'écoute de l'interface web de pfSense par exemple.

La solution sera toujours la même : se connecter en console (ou avec un écran et un clavier) afin de reprendre la main.

On fera le choix 8 (Shell) et on saisira la commande suivante :
/usr/local/etc/rc.d/squid.sh stop

Si ça ne fonctionne pas, on pourra plutôt saisir l'une des deux commandes ci-dessous :
killall -9 squid
squid -k shutdown

Une fois que squid est arrêté, il faudra redémarrer l'interface web de pfSense en revenant au menu (saisir "exit" depuis le shell) et en faisant le choix 11 :

Restart du webui de pfSense


Il est à noter qu'il faut ensuite agir sans traîner : squid risque de redémarrer rapidement automatiquement grâce à ses scripts de supervision propres.


Le serveur d'authentification est H.S. - comment faire ?


Si vous vous connectez sur l'interface web de pfSense avec un compte LDAP ou Radius et que le serveur d'authentification est injoignable, pas de soucis : en secours, il est toujours possible de s'identifier avec un utilisateur local (avec le compte admin, par exemple).

Si tous les utilisateurs locaux ont été désactivés ou que les mots de passe ont été perdus, il faudra se connecter en console et faire le choix 3 pour réactiver et remettre à sa valeur par défaut le mot de passe admin.

Les identifiants seront alors :
  • utilisateur : admin
  • mot de passe : pfsense

Nous avons fait le tour des principaux problèmes d'accès qui peuvent exister !

Ce qu'il faut retenir, c'est qu'il est toujours possible de reprendre la main sur un firewall à partir du moment où l'on dispose d'un accès physique à la machine.



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é ou vous souhaitez approfondir vos connaissances sur pfSense / OPNsense ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

OPNsense 23.1 est disponible

icon 09/02/2023 - Aucun commentaire

Jeudi 26 janvier 2023 est sortie la dernière version d'OPNsense. La version 23.1, surnommée "Quintessential Quail".

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


logo OPNsense




Les infos clefs en un coup d’œil


Les informations clefs de cette mise à jour sont les suivantes : grosse mise à jour d'Unbound DNS intégrant des statistiques détaillées sur les requêtes DNS traitées par OPNsense ; intégration de WireGuard au noyau de FreeBSD (qui remplace la version déjà proposée qui tournait dans l'espace utilisateur) ; amélioration de l'outil de capture de paquets (tcpdump) ; passage à PHP 8.1 ; beaucoup de mises à jour "sous le capot".

Dans la suite de l'article, nous présentons plus en détails les changements et nouveautés significatifs.



Mise à jour d'Unbound


Unbound est le résolveur DNS (validateur, cache, récursif) intégré à OPNsense.

Il connaît une grosse mise à jour offrant notamment une nouvelle interface permettant de voir des statistiques détaillées sur les requêtes DNS traitées par OPNsense.

Les statistiques sont accessibles depuis le menu Reporting.
Il faudra d'abord activer la collecte locale des statistiques : se rendre dans le menu Reporting > Settings et cocher la case "Enables local gathering of statistics." :

Activation des statistiques d'Unbound


La page de statistiques ressemblera à ceci :

Statistiques d'Unbound


Autre mise à jour intégrée à Unbound, le système d'intégration des listes de blocage DNS a été ré-écrit en python (vs un mix-PHP auparavant).



Amélioration de la gestion des interfaces


Il y a plusieurs mises à jour notables dans la gestion des interfaces sur les configurations avancées. Les principales sont :

  • Support du stacking de VLAN (802.1ad ou QinQ) ; techniquement, QinQ permet d'insérer plusieurs tags de VLAN dans la même trame Ethernet, ça permet, par exemple, de faire passer ses propres VLANs à l'intérieur d'un VLAN fourni par un opérateur télécom sur un réseau étendu.
  • GIF et GRE prennent désormais en charge les configurations IPv6 basées sur des sous-réseaux au lieu de toujours revenir à une configuration point à point (/128).
  • Plusieurs améliorations sur la gestion d'IPv6 sur les interface GIF, GRE et PPPoE.
  • Il est maintenant possible de filtrer par adresse MAC sur l'outil de capture de paquets. Cet outil de débogage est vraiment très riche et très performant surtout si on le compare à ce qui est proposé sur pfSense...
  • Quand on crée un groupe d'interfaces, il est maintenant possible de choisir si ce groupe apparaît uniquement dans les règles de filtrage ou également parmi la liste des interfaces (dans ce cas, les interfaces ne sont plus visibles que depuis leur groupe d'appartenance dans le menu Interfaces). Exemple :

Interfaces groupées OPNsense

Sur cette capture d'écran, les interfaces "LAN" et "VLAN_VOIP" sont regroupées sous "Groupe_Local"




Évolutions diverses


Plusieurs améliorations ou évolutions diverses, dont notamment :

  • LibreSSL est définitivement abandonné. C'était prévu et annoncé. OPNsense ne supporte plus qu'OpenSSL.
  • Il n'est plus possible de filtrer par système d'exploitation dans la gestion avancée des règles de filtrage. Tant mieux, cette option était totalement obsolète.
  • OpenVPN : il y aura dorénavant un nom de démon unique pour chaque instance. Cela facilite le débogage en cas de besoin.
  • WireGuard : la version de WireGuard intégrée au noyau FreeBSD est enfin disponible ! OPNsense proposait jusqu'à présent une version de WireGuard tournant dans l'espace utilisateur. On va donc pouvoir envisager d'intégrer réellement WireGuard sur ses firewall en production...
  • Pas mal de ré-écritures de codes afin de mettre à jour les pages qui étaient soit obsolètes (plus utilisées), soit qui n'étaient pas totalement (voire par du tout) développées suivant une implémentation MVC/API.



Problèmes connus et points d'attention


LibreSSL n'est plus proposé. Il faudra donc basculer sur OpenSSL avant de pouvoir mettre à jour. Il est à noter que c'est OpenSSL qui était déjà utilisé par défaut par OPNsense. Si vous n'y avez pas touché, il n'y a donc pas beaucoup de questions à se poser...

La configuration IPsec était jusqu'à présent gérée dans le fichier ipsec.conf ; elle bascule sur le fichier swanctl.conf. Pour l'immense majorité des tunnels IPsec cela ne devrait rien changer, mais pour quelques cas particuliers, il n'est pas impossible de voir apparaître des bugs (des configurations mal reprise principalement).

Plusieurs corrections rapides (hotfix) ont déjà été publiées (six, pour le moment). Si vous avez déjà mis à jour votre OPNsense vers la version 23.1, il peut donc être utile de refaire une vérification afin de vous assurer que vous disposez des derniers patchs.

Comme d'habitude, si vous n'avez pas appliqué les dernières mises à jour d'OPNsense, vous devrez d'abord mettre à jour votre OPNsense vers la dernière ancienne version disponible (soit la 22.7.11_1) avant de pouvoir procéder à la mise à jour vers la nouvelle version (23.1).



Processus de mise à jour


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

Pensez à faire une sauvegarde avant de lancer la mise à jour.

Si votre système de fichiers est ZFS, pensez également à créer un point de restauration.

Pour la mise à jour, vous pouvez vous appuyer sur notre tuto écrit pour pfSense, mais facilement adaptable pour OPNsense : [pfSense] Mettre à jour son serveur pfSense.

La mise à jour d'OPNsense prendra environ 10 minutes.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : OPNsense 23.1 released [EN]



Pour aller plus loin


[pfSense / OPNsense] Créer un point de restauration pour des mises à jour et des retours arrière en toute sérénité
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Évolutions et actualités du logiciel pfSense

icon 05/10/2022 - 2 commentaires

Un certain nombre de gros changements "sous le capot" ont été annoncés concernant pfSense.
Les deux principaux changements annoncés sont le passage à PHP 8.1 et l'adoption de FreeBSD 14.

Dans cet article, nous passons en revue ces deux principales évolutions et les impacts associés qui concerneront pfSense 2.7.



Passage à PHP 8.1


Les dernières versions de pfSense (2.6.0) étaient basées sur PHP 7.4, dont le support actif arrive à terme fin novembre. Il devenait donc nécessaire de migrer vers une version plus récente de PHP.

La prochaine version de pfSense embarquera donc PHP 8.1, qui est la dernière version de PHP et dont le support actif s'étend jusqu'à fin novembre 2024.

Le passage à PHP 8.1 implique de grosses évolutions sur le code qui embarque des éléments ou des fonctions obsolètes.
Cela entraîne un gros travail de tests de non-régression, de ré-écriture de code et de renforcement de la sécurité sur la manière dont PHP est exploité par pfSense. Autant le dire, il y a du travail... :-)

Cette évolution peut également remettre en cause le fonctionnement de pas mal de packages qui devront également tourner sur PHP 8.1.



Adoption de FreeBSD 14


pfSense tournait jusqu'à présent sur FreeBSD 12-STABLE.

Pour rappel, il y a principalement trois branches actives pour les versions de FreeBSD :

  • stable/12 : la branche la plus ancienne. Ses versions (nommées 12.x-RELEASE) seront théoriquement supportées jusqu'en juin 2024.
  • stable/13 : l'autre branche stable. Ses versions (nommées 13.x-RELEASE) seront théoriquement supportées jusqu'en janvier 2026.
  • current/14 : il s'agit de la version de développement. Le développement sur cette branche est très actif, au prix d'un risque d'instabilité plus fort qu'avec les deux autres branches.

L'intérêt évoqué par Netgate (la société éditrice de pfSense) de passer à FreeBSD 14, qui est la version de développement, est de pouvoir intégrer à pfSense les toutes dernières fonctionnalités ajoutées à FreeBSD.
De plus, ils considèrent que la branche de développement bénéficie plus rapidement des corrections de bugs, des corrections de sécurité et des autres corrections d'une façon générale.

Aussi, lorsque le support d'un nouveau matériel est ajouté à FreeBSD, il est d'abord intégré à la branche principale (CURRENT).
Ainsi, suivre la branche principale de FreeBSD donne au logiciel pfSense les pilotes les plus à jour pour une variété de matériel.

Même si ce n'est pas évoqué officiellement, on peut aussi penser au support de plus en plus important des matériels à base d'architectures ARM.
En effet, Netgate a connu plusieurs fois dans le passé des difficultés à sortir des mises à jour de pfSense dans les délais car ils rencontraient énormément de difficultés à faire fonctionner correctement une partie de leurs appliances qui tournent sur des architectures ARM.

Enfin, Netgate est un contributeur important à l'écosystème FreeBSD. Il est donc plus simple pour les équipes de développement de travailler sur la version CURRENT qui est directement intégrée à pfSense. Cela permet de réduire fortement la dette technique et de voir intégrer plus rapidement leurs contributions à FreeBSD dans les versions de pfSense.

Il est à noter que Netflix a adopté une stratégie similaire : tous leurs serveurs qui tournent sous FreeBSD utilisent la branche current.



Quels impacts pour les utilisateurs de pfSense ?


En réalité, assez peu.

Le principal impact est que certaines suites cryptographiques jusqu'alors supportées par pfSense, mais totalement désuètes, ne seront probablement plus supportées sous pfSense 2.7.

On pense notamment aux algorithmes MD5 ou 3DES, ainsi qu'aux groupes d'échange de clés Diffie-Hellman disposant d'une taille de clef trop faible.

Enfin, on peut légitimement s'attendre à voir apparaître quelques bugs lors de la sortie de pfSense 2.7.0
Il ne faudra, bien évidemment, pas se précipiter pour mettre à jour (sauf si vous souhaitez jouer au bêta-testeur sur votre production) afin de s'assurer que ces grosses mises à jours n'entraînent pas trop d'effets de bord.

Et il faut espérer que les utilisateurs de pfSense n'auront pas à revivre les difficultés de pfSense 2.5 qui avait vu la sortie de pas moins de 3 versions à quelques semaines / mois d'intervalle afin de corriger les très nombreux bugs.

pfSense 2.7.0 ne devrait pas sortir avant la fin de cette année. Aucune date n'est annoncée pour le moment.

Pour davantage d'informations sur les évolutions du logiciel pfSense, nous conseillons la lecture de l'article pfSense Software is Moving Ahead, écrit par le Directeur Technique de Netgate (Jim Thompson).

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

OPNsense 22.7 est disponible

icon 03/08/2022 - Aucun commentaire

English version: OPNsense 22.7 now available

Jeudi 28 juillet 2022 est sortie la dernière version d'OPNsense. La version 22.7, surnommée "Powerful Panther".

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


logo OPNsense




Les infos clefs en un coup d’œil


Les informations clefs de cette mise à jour sont les suivantes : passage de la version de FreeBSD 13.0 vers la 13.1 ; passage à PHP 8.0 ; passage à Phalcon 5 (phalcon est le framework PHP utilisé par OPNsense) ; amélioration du support des VLAN stacké et d'Intel QuickAssist (QAT) ; amélioration de la protection contre les attaques DDOS ; intégration des nouveaux plugins APCUPSD et du très à la mode CrowdSec.

Il est également à noter qu'il s'agit sûrement de la dernière version d'OPNsense intégrant LibreSSL. Les versions suivantes, à partir de la version 23.1 très sûrement, proposeront uniquement OpenSSL.

Dans la suite de l'article, nous présentons plus en détails les changements et nouveautés.



Amélioration de la gestion de la mémoire-vive


La gestion de la mémoire-vive a été revue. L'objectif est d'éviter une saturation de la mémoire-vive par certains processus.

Le changements notables sont les suivants :
  • la partition /tmp MFS peut utiliser dorénavant 50% de la mémoire-vive au maximum ; ce paramètre peut être ajusté si besoin.
  • la partition /var MFS devient /var/log MFS and et peut utiliser, elle aussi, 50% de la mémoire-vive au maximum ; ce paramètre peut également être modifié.
  • plusieurs améliorations pour éviter que le processus syslog-ng ne soit impacté par le "out of memory kills" (lorsque la mémoire-vive est saturée, intervient le processus “Out-of-memory Killer” ou “OOM-Killer” dont le but est d'éviter le crash du système, ou Kernel Panic, en tuant les processus jugés trop gourmands. Ce sont des mécanismes de protection que l'on retrouve également sur toutes les distributions GNU/Linux).



Gestion des logs


Plusieurs améliorations notables au niveau de la gestion et de l'accès aux fichiers de journalisation (logs) :
  • modification du widget (au niveau du tableau de bord) de visualisation des logs afin de lui ajouter un filtre
  • prise en charge de la journalisation des règles NTP (Network Time Protocol)
  • ajout des logs concernant l'utilisation des alias



Sécurité


Les paramètres de clé Diffie-Hellman considérés comme n'étant pas suffisamment robustes ont été supprimés. C'est une bonne chose d'un point de vue sécurité.

Au niveau de l'IDS/IPS, les règles McAfee qui pointaient vers des liens morts ont été supprimées.



IPsec


Plusieurs légères modifications ou améliorations au niveau de la gestion d'IPsec :
  • Ajout du choix "IPv4+6" pour la configuration de la phase 1 pour les IPsec mobiles
  • Mise à jour de l'interface d'administration sur les pages des connexions, SPD et SAD afin qu'elles utilisent les API
  • Quelques autres ajustement de l'interface sur la page d'état des connexions IPsec



Améliorations diverses


Quelques autres améliorations ou changements notables :
  • Amélioration du support de certaines cartes wifi Intel (celles utilisant le driver iwlwifi)
  • Amélioration des performances sur les alias de ports
  • Amélioration des performances sur la consultation des logs en temps-réel (live view)
  • Serveur DHCP : il est maintenant possible de lancer le service DHCP Relay sur les interfaces de type bridge.
  • Traduction : retour de l'italien dans la liste des traductions disponibles. L'italien avait été retiré d'OPNsense 22.1 car son niveau de traduction a été jugé trop faible. Les traductions pour d'autres langues ont été mises à jour vers leurs dernières versions disponibles. Il faut encore souligner ici la qualité de la traduction d'OPNsense comparativement à pfSense (qui est, elle, particulièrement mauvaise).



Plugins


Enfin, la liste des plugins mis à jour :
  • Le plugin Crowdsec 1.0 fait son apparition
  • Les plugins os-nginx et os-postfix ont été mis à jour pour ajouter des paramètres Diffie Hellman manquants.
  • Plugin os-tayga  : mis à jour vers la version 1.2
  • Plugin os-apcupsd : mis à jour vers la version 1.0

D'autres ont été retirés :
  • os-tor n'est plus disponible avec LibreSSL à cause d'incompatibilités liées aux dernières versions de Tor.
  • os-web-proxy-useracl a été retiré : il n'y avait plus de mise à jour depuis 2017.
  • os-boot-delay a également été retiré.



Problèmes connus et points d'attention


Le paramètre Diffie-Hellman a été retiré d'OpenVPN, en application de la RFC 7919. Le seul vrai impact est pour les machines les moins puissantes, sur lesquelles étaient configurées des clés plus petites. Besoin de changer de firewall ? Pensez à notre boutique en ligne ;-)

Le plugin os-dyndns est toujours disponible (il avait été question de le supprimer), mais il pourrait disparaître dans les prochaines versions car il repose sur le paquet ddclient qui ne semble plus mis à jour depuis un certain temps. Donc, finalement rien de changé pour OPNsense 22.7, mais il est possible que le plugin soit supprimé à l'avenir.

Si vous lancez la mise à jour de votre firewall en ligne de commande, le changelog sera dorénavant présenté. Pour le faire défiler, il faut utiliser les flèches directionnelles de son clavier ou appuyer sur "q" pour quitter et retrouver le processus de mise à jour habituel.

Le serveur DHCPv6 sur une interface configurée en mode tracking ("suivre l'interface" sur la version française) requiert que soit définie la plage d'adresses à utiliser (un peu comme son pendant pour une interface configurée avec une adresse IP statique). Aussi, si vous utilisez le mode tracking sur une interface disposant d'un /64 ou inférieur, cela générera une alerte. Il est possible que le service DHCPv6 refuse de se lancer. Dans ce cas, il suffit d'adapter / corriger la configuration et ça devrait résoudre le problème.

Enfin, il est à noter que quatre problèmes ont été remontés et qu'ils ont déjà été corrigés via un patch correctif rapide ("hotfix"). Si vous avez déjà mis à jour votre OPNsense vers la version 22.7, il peut donc être utile de refaire une vérification afin de vous assurer de disposer de ce dernier patch.

Comme d'habitude, si vous n'avez pas appliqué les dernières mises à jour d'OPNsense, vous devrez d'abord mettre à jour votre OPNsense vers la dernière ancienne version disponible (soit la 22.1.10) avant de pouvoir procéder à la mise à jour vers la nouvelle version (22.7).




Processus de mise à jour


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

Pensez à faire une sauvegarde avant de lancer la mise à jour.

Si votre système de fichiers est ZFS, pensez également à créer un point de restauration.

Pour la mise à jour, vous pouvez vous appuyer sur notre tuto écrit pour pfSense, mais facilement adaptable pour OPNsense : [pfSense] Mettre à jour son serveur pfSense.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : OPNsense 22.7 released [EN]



Pour aller plus loin


[pfSense / OPNsense] Créer un point de restauration pour des mises à jour et des retours arrière en toute sérénité
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Filtrer les adresses IP à risque

icon 29/03/2022 - Aucun commentaire

Dans cet article nous présentons une solution afin de filtrer les adresses IP publiques réputées à risques ou hébergeant des malwares ou des contenus malveillants.

Il s'agit d'une solution intéressante et très rapide à mettre en œuvre sur ses firewall.

Nous présenterons deux solutions : une gratuite et une payante.



Filtrer les IP à risque, pourquoi ?


Une bonne pratique de sécurité informatique est d'empêcher le trafic à destination ou provenant de sources réputées à risque. C'est-à-dire le trafic vers ou à destination de serveurs ou d'adresses IP hébergeant des virus, des malwares, du contenu malveillant ou aux mains de pirates informatiques.

Cela apporte une couche de sécurité pour le trafic internet sortant : en cas de détournement DNS ou d'infection par un vers ou un malware, du trafic est généralement émis ou redirigé vers des serveurs frauduleux. Essayer de détecter ces serveurs et de bloquer le trafic à leur destination est une bonne approche.

De la même manière, lorsqu'une entreprise héberge un service comme un accès OpenVPN ou un serveur web, il n'est généralement appliqué aucun filtrage sur les adresses IP publiques pouvant se connecter. Bloquer a minima le adresses IP connues pour être utilisées par des personnes malintentionnées est donc également une approche intéressante.

Pour être efficace, ces listes d'adresses IP à risque doivent être mises à jour très régulièrement afin de coller au plus près des menaces en cours. Elles doivent éviter de comporter des faux-positifs, c'est-à-dire ne pas répertorier des adresses IP qui sont en réalité parfaitement légitimes.
Si le taux de faux-positifs est trop fort, alors cela devient complètement inutilisable en production pour des TPE/PME.

C'est donc un subtile équilibre qu'il faut trouver pour d'une part être efficace et d'autre part ne pas bloquer du trafic légitime.

Le filtrage des adresses IP publiques réputées à risque fait partie d'une approche de sécurité de défense en profondeur.

Nous présenterons deux solutions :

Les listes DROP et eDROP de SpamHaus. Ce sont des listes gratuites sans risque de faux-positifs.
Les listes proposées par nos soins. Ce sont des listes payantes qui permettent un filtrage beaucoup plus fin et complet que SpamHaus tout en étant très attentif à éviter les faux-positifs.

L'implémentation se fera ensuite en deux étapes : créer un alias se chargeant de récupérer les listes d'adresses IP à bloquer, puis créer les règles de filtrage bloquant le trafic associé à ces alias.



SpamHaus - créer un alias contenant la liste des adresses IP à filtrer (gratuit)


The Spamhaus Project (SpamHaus) est une organisation internationale non gouvernementale dont l'objectif est de fournir une protection en temps-réel contre les pourriels.

SpamHaus fournit un certain nombre d'outils en ce sens, ainsi que plusieurs listes de filtrage d'adresses IP à risque.

Ces listes de filtrage nommées DROP (Don't Route Or Peer) et EDROP (Extended DROP) sont composées de blocs réseau qui sont "détournés" ou loués par des spammeurs professionnels ou utilisés à des fins cybercriminelles (diffusion de logiciels malveillants, téléchargement de chevaux de Troie, botnet, etc.).

Les listes DROP et EDROP n'incluent pas d'adresses IP uniques, mais seulement des blocs d'adresses IP. Ainsi, une adresse IP isolée connue pour être malveillante ne sera jamais bloquée par les listes SpamHaus. Seuls des blocs d'adresses IP attribués à des LIR seront bloqués par la liste DROP. La liste EDROP étend un peu le concept en bloquant des sous-réseaux plus fins.

Ainsi, c'est un filtrage grosse-maille qui est proposé par SpamHaus. Le gros intérêt est que le risque de faux-positif est théoriquement nul. L'inconvénient est que le filtrage manque de précision, ce qui réduit forcément la sécurité apportée par ces listes.

Les listes DROP et EDROP sont donc des solutions gratuites que nous recommandons fortement d'utiliser sur tous les firewall. Même si le filtrage n'est pas parfait, mieux vaut un filtrage grosse maille qu'aucun filtrage.

SpamHaus propose principalement 3 listes :

Nous allons créer trois alias : un pour chaque liste proposée par SpamHaus.

Nous nous rendons dans le menu Firewall > Aliases et cliquons sur le bouton "+ Add" :

Menu Firewall > Alias - pfSense - Provya


Les champs à compléter sont les suivants :
  • Name : le nom que nous souhaitons donner à notre alias
  • Type : choisir "URL Table (IPs)"
  • URL Table (IPs) : saisir l'url d'une des listes de SpamHaus. Le nombre après le slash indique la fréquence de mise en jour en nombre de jours. 128 signifie que le contenu du fichier sera téléchargé tous les 128 jours. Nous pouvons, par exemple, choisir "1", les listes de SpamHaus étant mises à jour moins une fois par semaine en moyenne.

Exemple de résultat obtenu pour la liste DROP :

Configuration de l'alias drop sous pfSense - Provya


Nous répétons l'opération pour chacune des trois listes. Ce qui nous donne le résultat suivant :

Alias des listes DROP et EDROP de SpamHaus - pfSense - Provya



Si vous êtes utilisateurs d'OPNsense, l'approche est exactement la même. Il faut se rendre dans le menu Pare-feu > Alias et cliquer sur le discret bouton "+" :

Configuration de la liste DROP de SpamHaus - OPNsense - Provya


Compléter les champs de la manière suivante :
  • Nom : le nom que nous souhaitons donner à notre alias
  • Type : URL Table (IPs)
  • Refresh Frequency : la fréquence de rafraîchissement. Une fois par jour est largement suffisant. Les listes de SpamHaus sont mises à jour plus ou moins toutes les semaines.
  • Contenu : saisir l'url d'une des listes de SpamHaus

Exemple de résultat obtenu pour la liste DROP :

Configuration de la liste DROP de SpamHaus - OPNsense - Provya


Nous répétons l'opération pour chacune des trois listes.

Nos alias sont prêts. Il nous reste à configurer nos règles de filtrage pour bloquer le trafic entrant provenant de ces adresses IP, ainsi que le trafic sortant à destination de ces adresses IP.



Provya - créer un alias contenant la liste des adresses IP à filtrer (payant)


Note : dans ce chapitre, nous présentons une solution commerciale payante. Si vous n'êtes pas intéressé, vous pouvez passer directement au chapitre suivant : Créer les règles de filtrage associées.

Nous avons décidé de créer notre propre liste de filtrage d'adresses IP malveillantes.

Pour cela, nous nous appuyons sur une trentaine de sources (dont SpamHaus) que nous traitons et que nous recoupons afin de comparer les adresses IP présentes. Cela nous permet de déterminer la fréquence d'apparition d'une adresse IP détectée. Plus une adresse IP est détectée et plus la probabilité que ce soit une adresse IP malveillante est forte. A contrario, plus la probabilité de rencontrer un faux-positif est faible.

Cela permet d'avoir une source unique très complète et efficace avec des sources fiables et recoupées, tout en conservant un risque de faux-positifs extrêmement faible.

Nous proposons trois listes :
  • strict : cette liste contient les adresses IP que nous avons détectées dans au mois deux sources de collectes différentes. La probabilité de rencontrer un faux-positif est faible.
  • main : cette liste contient les adresses IP que nous avons détectées dans au mois trois sources de collectes différentes. La probabilité de rencontrer un faux-positif est extrêmement faible. C'est cette liste que nous recommandons d'utiliser.
  • soft : cette liste contient les adresses IP que nous avons détectées dans au mois quatre listes de collectes différentes. La probabilité de rencontrer un faux-positif est théoriquement nulle.

L'accès à ces listes est payant sous la forme d'un abonnement mensuel ou annuel.

Si vous êtes intéressé, vous pouvez consulter notre boutique en ligne : Liste IP malveillantes.

Pour découvrir le service, nous proposons une offre de lancement à 1 € H.T. pour le premier mois.

Passons à l'implémentation. Pour cela, nous allons créer un alias en nous rendant dans le menu Firewall > Aliases et cliquons sur le bouton "+ Add" :

Menu Firewall > Alias - pfSense - Provya


Les champs à compléter sont les suivants :
  • Name : le nom que nous souhaitons donner à notre alias
  • Type : choisir "URL Table (IPs)"
  • URL Table (IPs) : saisir l'url de la liste que l'on souhaite télécharger (cf. paragraphe suivant). Le nombre après le slash indique la fréquence de mise en jour en nombre de jours. Nous indiquons "1".

Pour pouvoir télécharger la liste de votre choix, il faudra disposer d'une clef de licence valide. L'URL à saisir sera de la forme suivante : https://provya.fr/download/VERSION.txt?key=VOTRE_CLEF (en remplaçant VERSION par le fichier choisi et VOTRE_CLEF par la clef de licence que vous aurez reçu par e-mail).
Ce qui donne l'une des URLs suivantes à utiliser :

Exemple de résultat obtenu :

Configuration de la liste Provya - pfSense


Alias de la liste Provya - pfSense


Par défaut, pfSense ne propose une mise à jour des alias de type "URL Table" qu'au mieux une fois par jour. Ce qui est trop peu pour pouvoir disposer d'une liste réellement à jour. Nous recommandons de mettre à jour la liste toutes les heures ou toutes les deux heures.

Pour y remédier, nous suggérons d'installer le package "cron" afin d'effectuer des mises à jour plus fréquentes.

Pour cela, nous nous rendons dans le menu System > Package Manager, onglet "Available Packages". Nous faisons une recherche avec le mot-clé "cron" et cliquons sur l'icône d'installation :

Installer le package cron sous pfSense - Provya


Une fois le package "cron" installé, naviguer dans le menu Services > Cron :

Menu Services > cron - pfSense - Provya


Nous repérons la ligne rc.update_urltables et cliquons sur son icône de modification (crayon) :

Modifier un cron - pfSense - Provya


Nous suggérons d'effectuer la mise à jour toutes les heures ou toutes les deux heures. Il faut modifier le champ "Hour" :

Modifier le cron pour l'URL Table - pfSense - Provya

La mise à jour est ici effectuée toutes les deux heures



Si vous êtes utilisateurs d'OPNsense, l'approche est exactement la même. Il faut se rendre dans le menu Pare-Feu > Alias et cliquer sur le discret bouton "+" :

Configuration de la liste DROP de SpamHaus - OPNsense - Provya


Compléter les champs de la manière suivante :
  • Nom : le nom que nous souhaitons donner à notre alias.
  • Type : URL Table (IPs)
  • Refresh Frequency : la fréquence de rafraîchissement. Nous recommandons de faire un rafraîchissement une fois par heure ou une fois toutes les deux heures.
  • Contenu : saisir l'url de la liste que l'on souhaite télécharger (cf. paragraphe suivant).

Pour pouvoir télécharger la liste de votre choix, il faudra disposer d'une clef de licence valide. L'URL à saisir sera de la forme suivante : https://provya.fr/download/VERSION.txt?key=VOTRE_CLEF (en remplaçant VERSION par le fichier choisi et VOTRE_CLEF par la clef de licence que vous aurez reçu par e-mail).
Ce qui donne l'une des URLs suivantes à utiliser :

Exemple de résultat obtenu :

Configuration de la liste Provya - OPNsense



Avantage d'OPNsense sur pfSense : il est possible de préciser un taux de rafraîchissement aussi bien en jours qu'en heures (contre uniquement en jours pour pfSense). Toute l'étape liée à la gestion du cron décrite pour pfSense n'est donc pas nécessaire sur OPNsense !

La configuration de notre alias est terminée. Il nous reste à configurer nos règles de filtrage pour bloquer le trafic entrant provenant de ces adresses IP, ainsi que le trafic sortant à destination de ces adresses IP.



Créer les règles de filtrage associées


Se rendre dans le menu Firewall > Rules et ajouter sur l'interface WAN (ou d'une façon générale sur les interfaces de vos connexions à Internet) une règle en haut de liste en cliquant sur le bouton Ajouter en haut de liste - pfSense.

Configurer la règle avec les paramètres suivants :
  • Action : Block
  • Protocol : Any
  • Source : "Single host or alias" et saisir le nom de l'alias créé à l'étape précédente
  • Destination : any

Exemple d'une règle de filtrage côté WAN - pfSense - Provya


Il faut bien sûr adapter avec le nom de l'alias utilisé à l'étape précédente.

Si vous utilisez une liste Provya, une seule liste doit être utilisée (strict, main ou soft). Il est également inutile d'utiliser une liste SpamHaus en complément car les adresses IP fournies par SpamHaus sont déjà incluses dans les listes Provya.

Si vous utilisez SpamHaus, il faudra créer une règle pour chaque alias (DROP et EDROP). Si vous utilisez la liste DROPv6, il faudra bien penser à choisir IPv6 pour le champ "Address Family" de votre règle de filtrage.

Enfin, nous créons également une règle sur l'interface LAN (ou d'une façon plus générale sur toutes nos interfaces locales qui disposent d'un accès vers Internet) que nous plaçons en haut de liste en cliquant sur le bouton Ajouter en haut de liste - pfSense.

Les paramètres à saisir sont les suivants :
  • Action : Block
  • Protocol : Any
  • Source : LAN net
  • Destination : "Single host or alias" et saisir le nom de l'alias créé à l'étape précédente

Exemple d'une règle de filtrage côté LAN - pfSense - Provya


Il faudra bien sûr adapter avec le nom de l'alias utilisé à l'étape précédente.
Si vous utilisez SpamHaus, il faudra encore une fois créer autant de règles que vous avez créé d'alias.

Voilà, le filtrage des adresses IP à risque est en place.
Il s'agit d'un élément de sécurité essentiel et vraiment simple à mettre en œuvre afin d'apporter un niveau de sécurité supplémentaire pour le trafic passant par notre firewall.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfSense 2.6.0 est disponible

icon 15/02/2022 - 9 commentaires

Lundi 14 février 2022 est sortie la dernière version de pfSense. La version 2.6.0.

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



Filtrage / NAT


Plusieurs modifications / corrections apportées, dont notamment :
  • Ajout du support d'IPv6 pour les règles easyrule.
  • Possibilité d'utiliser un alias pour le champ destination des règles de NAT 1:1
  • La copie d'une règle de redirection de port (Port Forward) tient maintenant compte de la configuration existante pour l'association d'une règle de filtrage (Filter Rule Association).
  • Ajout d'une icône permettant de visualiser le sens du filtrage pour les règles de l'onglet "Floating".
  • Lorsque le nom d'un groupe d'interfaces commençait par un chiffre, cela générait un XML invalide. C'est corrigé.



IPsec


Cette version apporte plusieurs modifications importantes à IPsec. Ce sont des modifications portant sur la stabilité et les performances.

Le nom des interfaces IPsec VTI (IPsec routé) a changé. Les configurations existantes seront mises à jour automatiquement dans la mesure du possible pour utiliser les nouveaux noms.

Une fois la mise à jour vers pfSense 2.6.0 réalisée, il est conseillé de vérifier que les noms des instances VTI configurées ont correctement été repris pour l'assignation des interfaces. Cette vérification s'opère depuis le menu Interfaces > Assignments.

Il y a énormément de corrections de petits bugs spécifiques apportés à cette version de pfSense. Il est compliqué de tous les lister, mais en résumé, si vous avez des problèmes avec IPsec, mettez à jour !



ZFS


Plusieurs modifications mineures ont été apportées. Notamment le nom du pool ZFS et les ensembles de données ont été mis à jour.

Ces modifications ne sont pas appliquées lors de la mise à jour pour les pfSense déjà installés avec ZFS.
Ces changements ne sont pris en compte que pour les nouvelles installations.

Autre changement concernant ZFS : la compression pour les rotations des fichiers de journalisation est maintenant désactivée, car ZFS effectue sa propre compression.
Encore une fois, ce paramètre s'applique uniquement pour les nouvelles installations, mais pas pour les mises à jour. Aussi, si vous êtes sur un système de fichiers ZFS et que vous mettez à jour, il est conseillé de désactiver la compression pour les rotations des fichiers de journalisation. Cette opération s'effectue depuis le menu Status > System Logs, onglet "Settings".

Pour rappel, ZFS permet, entre autre, de créer des points de restauration permettant de réaliser des retours en arrière très simplement et très rapidement en cas de besoin.



Sécurité


  • Le format de hachage des mots de passe pour les utilisateurs locaux a été modifié de bcrypt à SHA-512.
  • Plusieurs corrections ont été apportées à l'interface graphique qui présentait des vulnérabilités potentielles à des attaques de type cross-site scripting (XSS).
  • Désactivation de l'accès ssh pour les comptes admin et root lorsque le compte admin est désactivé sur l'interface web.



Bugs / Améliorations


  • Il est enfin possible de configurer l'adresse IP WAN avec un /32 depuis le menu de la console (très utile pour des serveurs pfSense hébergés, par exemple).
  • Diverses améliorations sur la page et sur le processus de déconnexion du portail captif.
  • Correction de plusieurs bugs sur la validation du formulaire de configuration d'un serveur OpenVPN. Certains paramètres (notamment les paramètres NCP permettant une négociation des paramètres cryptographiques entre le client et le serveur) n'étaient pas correctement appliqués.
  • Correction d'une erreur qui apparaissait lorsqu'un alias de type "URL Table" était rechargé mais qu'il était vide.
  • Correction de plusieurs bugs qui existaient sur l'imbrication d'alias (c'est-à-dire un alias faisant référence à un autre alias).
  • Correction de bugs d'affichage.
  • Le service AutoConfigBackup a été amélioré sur plusieurs points, dont : amélioration des informations liées à la restauration, précisions sur l'emplacement des sauvegardes, amélioration de la performance générale du service.
  • Plusieurs corrections liées à CARP. Ces corrections portent principalement sur le fait de pouvoir modifier le VHID d'une adresse VIP déjà créée (la mise à jour n'était pas correctement appliquée ou diffusée).
  • Corrections de problématiques d'encodage de caractères UTF-8 pour les certificats créés localement sur pfSense.
  • Amélioration de la stabilité d'Unbound qui avait tendance à crasher facilement sur les installations personnalisées comportant des erreurs.
  • Il n'était plus possible d'utiliser le protocole de priorisation de trafic CBQ sur les interfaces VLAN (cela plantait). C'est corrigé.



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 (à saisir en console ou depuis un shell) :

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

Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un point de restauration.

Dans tous les cas, 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.6.0 New Features and Changes [EN]



Pour aller plus loin


[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité

icon 08/02/2022 - 5 commentaires

Dans cet article nous présentons l'intérêt de l'utilisation du système de fichiers ZFS et de ses instantanés lors des mises à jour de pfSense.
Il s'agit d'une solution très efficace pour gérer ses mises à jour et ses possibilités de retour arrière vers des points de restauration très facilement.



ZFS, c'est quoi ? Quel intérêt ?


ZFS est un système de fichiers et un gestionnaire de volume open source.

ZFS offre de très nombreuses fonctionnalités. Nous ne les détaillerons pas dans cet article, nous proposons la consultation de la page Wikipédia qui lui est dédiée : ZFS.

Pour des firewall tournant sous pfSense, ZFS présente deux gros intérêts : la facilité d'installation de deux disques en haute-disponibilité (Raid) et la possibilité de réaliser des instantanés (snapshot).

Dans cet article, nous nous intéressons particulièrement à l'intérêt des snapshot ZFS lors des mises à jour de pfSense.

En effet, il peut arriver qu'une nouvelle version de pfSense comporte des bugs et que ceux-ci ne soient pas corriger immédiatement (ex : les versions 2.5.0 et 2.5.1 qui étaient catastrophiques) ; ou qu'il y ait une incompatibilité matérielle suite à une mise à jour (aucun risque si vous prenez votre matériel chez Provya ;-) ).

Dans ce cas, il peut être pratique de disposer d'un point de restauration pour pouvoir faire un retour-arrière rapide vers la version précédente de pfSense (ex : 2.4.5-p1).

Dans cet article, nous présentons comment créer un point de restauration grâce aux instantanés. Comment procéder à une restauration si besoin. Et comment supprimer le point de restauration si la mise à jour s'est bien passée.

Cette stratégie est applicable aussi bien à pfSense qu'à OPNsense.



Instantané, snapshot, qu'est-ce que c'est ?


Un instantané est une copie en lecture seule d'un système de fichiers ou d'un volume.

La création d'un instantané est quasiment immédiate.

Initialement, un instantané ne consomme pas d'espace disque supplémentaire. Toutefois, à mesure que les données contenues dans le jeu de données actif changent, l'instantané consomme de l'espace disque en continuant à faire référence aux anciennes données et empêche donc de libérer de l'espace disque.

Snapshot est le terme anglais pour instantané. Les termes "instantané" et "snapshot" désignent donc la même chose.



Pré-requis


1/2. Disposer d'un accès au firewall


Il faut disposer d'un accès en mode console au firewall. Il existe trois possibilités : utiliser la console présente dans l'interface web de pfSense, activer le serveur SSH de pfSense ou activer le port console (si le firewall est équipé d'un port console).


Utiliser la console de l'interface web

Il s'agit de la solution la plus simple. pfSense dispose d'un accès console depuis l'interface web. Pour y accéder, se rendre dans le menu Diagnostics > Command Prompt :

Invite de commande depuis le webui de pfSense - Provya


Il sera possible de saisir les commandes indiquées et de cliquer sur le bouton "Execute" pour les exécuter. Le résultat de la commande sera affiché à l'écran.

OPNsense n'offre pas d'accès console depuis son interface web. Ceci pour des raisons de sécurité.


Activer le serveur SSH de pfSense

La deuxième possibilité est de se connecter au firewall via son serveur SSH.
Par défaut, le serveur SSH est désactivé.

Pour l'activer, se rendre dans le menu System > Advanced :

Menu System > Advanced - pfSense - Provya


Descendre au niveau de la section "Secure Shell" et cocher la case "Enable Secure Shell".
Il est également possible de paramétrer la méthode d'authentification (mot de passe ou certificat) et le port d'écoute (22 par défaut).

Activer le serveur SSH de pfSense - Provya


Il faudra aussi potentiellement créer une règle de filtrage côté LAN pour autoriser la connexion sur le port 22 (ou sur le port choisi à l'étape précédente, s'il a été personnalisé).

Exemple de règle :

Règle de firewall pour l'accès SSH - pfSense - Provya


Pour OPNsense, le principe est le même : il faut activer le serveur SSH du firewall. La configuration s'opère depuis le menu Système > Paramètres > Administration.

Au niveau de la section "Shell Sécurisé", cocher la case "Activer le Shell sécurisé", autoriser potentiellement le compte root à se connecter si l'on ne possède pas un autre compte administrateur, autoriser (ou non) l'authentification par mot de passe et choisir le port d'écoute.
Il est également possible de personnaliser un certain nombre de paramètres de sécurité.

Activer serveur SSH - OPNsense - Provya



Activer le port console de pfSense

La troisième et dernière possibilité est de se connecter au firewall par son port console (ou port série).
Le port console est désactivé par défaut.
Il faudra bien sûr que le firewall soit équipé d'un port console.

Se rendre dans le menu System > Advanced et descendre jusqu'à la section "Serial Communications".
Cocher la case "Enable serial port" et cocher la case "Password protect the console menu" afin de protéger la console par un mot de passe.

Par défaut, lorsque le port console est activé, n'importe qui peut se brancher directement sur le firewall et disposer d'un accès root. Ce qui représente un risque en terme de sécurité.

Activer port console - pfSense - Provya



Pour OPNsense, la configuration s'opère depuis le menu Système > Paramètres > Administration :

Activer port console - OPNsense - Provya




2/2. Disposer d'un système de fichiers ZFS



Dernier pré-requis, il faut bien sûr que notre firewall soit installé avec le système de fichiers ZFS.

Pour savoir si notre système de fichiers est ZFS, saisir la commande suivante :

zfs list

S'il s'agit d'un système de fichiers ZFS, nous devrions obtenir un résultat du type :

NAME                 USED  AVAIL  REFER  MOUNTPOINT
zroot                900M  12.2G    88K  /zroot
zroot/ROOT           886M  12.2G    88K  none
zroot/ROOT/default   886M  12.2G   886M  /
zroot/tmp            192K  12.2G   192K  /tmp
zroot/var           11.4M  12.2G  11.4M  /var

Autrement, nous obtenons un résultat du type :

no datasets available



Procédure


Dans cet article, nous prenons comme exemple la mise à jour de pfSense de la version 2.5.2 vers la version 2.6.0 (non, la version 2.6.0 n'est pas encore sortie, mais ce n'est plus qu'une question de jours / semaines ;-) )

Les étapes à suivre sont les suivantes.

1. Voir les environnements de démarrage actuels avec la commande bectl list.

Si nous n'avons jamais trifouillé ces options, nous devrions obtenir quelque chose comme ceci :

[2.5.2-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE      Active Mountpoint Space Created
default NR     /          886M  2021-12-17 16:21

  • N signifie actif actuellement (Now)
  • R signifie actif au prochain redémarrage (Reboot)


2. Ajouter un nouvel environnement de démarrage que l'on appelle "pfsense-2.5.2" (ce sera notre point de restauration en cas de besoin) :

bectl create pfsense-2.5.2

3. Pour plus de lisibilité, renommer l'environnement de démarrage actuel (default) en "pfsense-2.6.0" :

bectl rename default pfsense-2.6.0

Une fois ces commande saisies, nous obtenons les environnements de démarrage suivants :

BE            Active Mountpoint Space Created
pfsense-2.5.2 -      -          8K    2022-02-07 17:56
pfsense-2.6.0 NR     /          886M  2021-12-17 16:21

On peut voir que notre nouvel environnement de démarrage ne prend que très peu d'espace disque à ce stade (8 Ko).

4. Réaliser un instantané des partitions /var et /tmp :

zfs snapshot zroot/var@pfsense-2.5.2
zfs snapshot zroot/tmp@pfsense-2.5.2

Les partitions /var et /tmp ne sont pas sur le même pool. Il faut donc les sauvegarder via un instantané. C'est ce que nous venons de faire.

Il est possible d'afficher la liste des instantanés ZFS avec la commande suivante :

zfs list -t snapshot

Le résultat ressemblera à ceci :

NAME                                             USED  AVAIL  REFER  MOUNTPOINT
zroot/ROOT/pfsense-2.6.0@2022-02-07-17:56:35-0      0      -   886M  -
zroot/tmp@pfsense-2.5.2                           64K      -   192K  -
zroot/var@pfsense-2.5.2                           88K      -  11.4M  -

Encore une fois, on voit que les instantanés ne consomment pratiquement pas d'espace disque supplémentaire au moment de leur création.

C'est tout !

Nous avons créé un deuxième environnement de démarrage (qui est une copie du premier à ce stade) et un instantané des partitions /var et /tmp.

À ce stade, nous pouvons lancer la mise à jour de pfSense (ou d'OPNsense) de manière tout à fait classique.

On peut aussi tester la branche de développement, installer des packages, tester des configurations, etc. En cas de pépin, nous pourrons très rapidement revenir à notre point de restauration.

Dans notre cas, et pour l'exemple, nous décidons de tester la version 2.6.0 de pfSense :

Tester pfSense 2.6.0 Release Candidate - Provya


Pour mettre à jour notre serveur, n'hésitons pas à nous appuyer sur notre article dédié : [pfSense] Mettre à jour son serveur pfSense



La mise à jour s'est bien passée, comment supprimer l'instantané ?



Si notre mise à jour s'est bien passée. Nous conseillons de ne toucher à rien durant les premiers jours / semaines, le temps de s'assurer qu'il n'y ait pas d'effets de bord et que tous les services fonctionnent tel qu'attendu.

Si c'est le cas, alors nous pouvons supprimer notre point de restauration et nos instantanés, ce qui permettra de libérer de l'espace sur le disque-dur.

En effet, là où notre point de restauration de notre environnement de démarrage ne prenait que 8 Ko à sa création, il en consomme maintenant bien plus :

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE            Active Mountpoint Space Created
pfsense-2.5.2 -      -          777M  2022-02-07 17:56
pfsense-2.6.0 NR     /          1.74G 2021-12-17 16:21

Notre point de restauration de notre environnement de démarrage consomme maintenant 777 Mo d'espace sur le disque-dur.

Idem pour les instantanés de /var et /tmp :

[2.6.0-RELEASE][root@pfSense.home.arpa]/root: zfs list -t snapshot
NAME                                             USED  AVAIL  REFER  MOUNTPOINT
zroot/ROOT/pfsense-2.6.0@2022-02-07-17:56:35-0   777M      -   886M  -
zroot/tmp@pfsense-2.5.2                          160K      -   192K  -
zroot/var@pfsense-2.5.2                         5.05M      -  11.4M  -


Pour supprimer le point de restauration et les instantanés, les trois commandes à saisir sont les suivantes :

bectl destroy pfsense-2.5.2
zfs destroy zroot/var@pfsense-2.5.2
zfs destroy zroot/tmp@pfsense-2.5.2

C'est tout.



Je souhaite faire un retour-arrière, comment faire ?



Si la mise à jour s'est mal passée ou si nous souhaitons revenir à l'état antérieur, il suffit de restaurer les instantanés ZFS et de modifier l'environnement de démarrage pour choisir notre point de restauration.

Pour activer notre point de restauration au prochain démarrage, la commande à saisir est la suivante :

bectl activate pfsense-2.5.2

Nous obtenons un message de confirmation. Il est également possible de vérifier la bonne prise en compte de la configuration via la commande bectl list :

BE            Active Mountpoint Space Created
pfsense-2.5.2 R      -          886M  2022-02-07 17:56
pfsense-2.6.0 N      /          893M  2021-12-17 16:21

Le marqueur R a bien basculé sur notre environnement de démarrage pfsense-2.5.2.

Et pour rétablir les instantanés, les commandes à saisir sont les suivantes :

zfs rollback -R zroot/var@pfsense-2.5.2
zfs rollback -R zroot/tmp@pfsense-2.5.2

Il reste à redémarrer le firewall pour que les changements soient totalement pris en compte.

Le redémarrage peut être lancé depuis l'interface web ou depuis la ligne de commande. La ligne de commande à saisir sera :

shutdown -r now


Une fois redémarré, on pourra supprimer les instantanés et l'environnement de démarrage qui ne sont plus utilisés, soit dans notre exemple :

bectl destroy pfsense-2.6.0
zfs destroy zroot/var@pfsense-2.5.2
zfs destroy zroot/tmp@pfsense-2.5.2

On peut vérifier que les commandes ont bien été prises en compte en listant les instantanés ZFS :

[2.5.2-RELEASE][root@pfSense.home.arpa]/root: zfs list -t snapshot
no datasets available

Les instantanés ont bien été supprimés.


Puis, en vérifiant les environnements de démarrage disponibles :

[2.5.2-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE            Active Mountpoint Space Created
pfsense-2.5.2 NR     /          886M  2022-02-07 17:56


Enfin, pour se remettre totalement dans la situation d'origine, on pourrait renommer l'environnement de démarrage en "default" avec la commande suivante :

bectl rename pfsense-2.5.2 default

Voilà, nous avons fait le tour des éléments à connaître pour créer des points de restauration super facilement sur pfSense et OPNsense.
C'est une approche que nous recommandons fortement de suivre avant de lancer la mise à jour de nos firewall.



Pour aller plus loin


[pfSense] Mettre à jour son serveur pfSense
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

OPNsense 22.1 est disponible

icon 27/01/2022 - Aucun commentaire

Jeudi 27 janvier 2022 est sortie la dernière version d'OPNsense. La version 22.1.

Il s'agit d'une mise à jour importante, avec notamment la migration d'HardenedBSD vers FreeBSD 13.

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


logo OPNsense




OS : passage d'HardenedBSD à FreeBSD


Il s'agit là d'un changement important : OPNsense s'appuyait jusqu'à présent sur le système d'exploitation HardenedBSD. OPNsense 22.1 s'appuie dorénavant sur FreeBSD.

HardenedBSD est un fork de FreeBSD visant à améliorer la sécurité du système en implémentant des technologies d'atténuation et de durcissement contre l'exploitation de vulnérabilité informatique.

Beaucoup d'améliorations proposées par HardenedBSD ont été réintégrées à FreeBSD, notamment FreeBSD 13.

Enfin, lorsque certaines bugs spécifiques à HardenedBSD étaient rencontrés, ils étaient parfois difficiles à résoudre car la communauté HardenedBSD est beaucoup plus petite que la communauté FreeBSD.

Les équipes de développement d'OPNsense ont donc jugé qu'il était préférable de s'appuyer directement sur FreeBSD.

Autre point notable par rapport au système d'exploitation : il y a une amélioration de la gestion du système de fichiers ZFS.



Gestion des logs


La journalisation circulaire (circular log) a été retirée.

De manière simplifiée, la journalisation circulaire permet de définir une taille maximale par fichier de journalisation (ex : 100 Ko) et un nombre maximal de fichiers de journalisation à conserver (ex : 30 fichiers).

La journalisation se définit maintenant en nombre de jours de rétention : un fichier est conservé par jour et par type de services. On peut choisir la durée de conservation des fichiers de journalisation.

Le format de stockage des fichiers de journalisation est le suivant :
/var/log/<application>/<application>_[YYYYMMDD].log

Il était déjà possible de désactiver la journalisation circulaire depuis OPNsense 20.7. Elle est donc maintenant supprimée.


Nouveau fichier de journalisation "latest.log"

Le fichier latest.log contient les derniers logs toutes catégories confondues.

L'utilisation de ce fichier peut être très pratique pour gagner en efficacité lors de ses sessions de dépannage / troubleshooting, il évite d'avoir à passer d'un fichier de journalisation à l'autre pour chaque service.


Support de la RFC 5424

Les fichiers de journalisation sont maintenant tous compatibles avec le format syslog et offrent la possibilité de filtrer par gravité.



Gestion des interfaces


Plusieurs améliorations, dont :
  • Amélioration de la gestion des interfaces PPP en environnement haute-disponibilité : possibilité de désactiver l'interface PPP lorsque CARP passe en mode backup.
  • Meilleure granularité sur le choix de l'adresses MAC pour une interface donnée : le spoof d'adresse MAC s'applique maintenant uniquement sur l'interface sélectionnée et pas à ses parents ou enfants : avant, par exemple, le spoof s'apliquait sur l'interface parente et sur toutes les interfaces vlan configurées dessus, maintenant, la configuration se fait uniquement sur l'interface logique choisie.
  • Uniformisation et amélioration de la configuration des interfaces bridge (pont réseau) lorsqu'elles sont connectées au réseau.
  • Il est maintenant possible d'associer une adresse IP virtuelle (VIP) à une interface qui n'est pas configurée ; cette configuration peut s'avérer très utile dans certains environnements spécifiques comme par exemple la possibilité d'avoir un cluster de firewall OPNsense avec une interface WAN qui ne possède qu'une seule adresse IP.



Pare-feu / Alias


  • Suppression de l'option obsolète "kill states on gateway failure". Cette action est effectuée automatiquement pour les passerelles qui sont surveillées.
  • Ajout du support des alias d'hôtes IPv6 dynamiques.
  • Il est maintenant possible d'utiliser des alias dans la gestion des Router Advertisements pour IPv6.
  • Priorisation de trafic : ajout de l'option Gbit/s lors de la configuration des pipes (avant, pour 1 Gbit/s, il fallait saisir 1 000 Mbit/s).



IPsec


  • Lors de la création de nouvelles phases 1 et 2, certains paramètres de sécurité par défaut ont été remplacés par des paramètres plus modernes et sécurisés.
  • Suppression de certains algorithmes de chiffrement qui ne sont plus supportés par FreeBSD 13 (dans le détail : MD5, Blowfish, DES, 3DES et CAST128 ne sont plus pris en charge pour la phase 2).



Traductions


Amélioration de la traduction pour plusieurs langues dont le français (sont concernés dans le détail : français, allemand, italien, japonais, norvégien, espagnol et turc).

A contrario, l'italien a été rétrogradé au rang de "en cours de développement" à cause de son faible niveau de traduction.

Il est à noter que la traduction de l'interface d'OPNsense en français est vraiment très bonne (surtout si on compare à pfSense...).



Plugins


Plusieurs plugins ont été mis à jour dont ACME , bind, haproxy, zabbix, ...



Problèmes connus et points d'attention


  • OPNsense 22.1 contient une nouvelle version majeure du système d'exploitation. Les mises à jour doivent donc être effectuées avec prudence. Malgré tous les tests qui ont pu être effectués, il peut toujours subsister des anomalies ou des changements modifiant le comportement par défaut.
  • L'évolution du support des algorithmes de hachage ou de chiffrement sous FreeBSD 13 peut avoir des impacts sur les VPN IPsec déjà configurés. Si vous utilisez l'un des algorithmes de hachage obsolètes (MD5, Blowfish, DES, 3DES ou CAST128), il faut modifier la configuration de votre tunnel IPsec avant de lancer la mise à jour.
  • Si vous utilisez des cartes réseau Realtek (notamment avec des ports 2,5 Gbps), il est recommandé d'installer le plugin os-realtek-re avant de lancer la mise à jour. En effet, le pilote propriétaire Realtek n'est pas fourni par défaut sous FreeBSD 13, ce qui a pour conséquence que certaines cartes Realtek ne sont pas supportées par défaut.
  • L'usurpation (spoof) d'adresse MAC ne concerne maintenant que l'interface configurée et non les autres VLAN configurés sur la même interface ou l'interface parent. Il faut donc modifier la configuration de ses interfaces nécessitant une adresse MAC usurpée avant de faire la mise à jour.
  • Les valeurs par défaut du service NTPD ont été modifiées pour exclure l'option "iburst" par défaut. Le paramètre "limited" a été détaché de l'option "kod". Il faut donc vérifier ces points avant de mettre à jour si vous êtes concernés.
  • Le support GRE link1 a été supprimé et nécessite une route statique pour fonctionner.
  • La prise en charge de la journalisation circulaire a été supprimée. Aucune action n'est requise.



Processus de mise à jour


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

Pensez à faire une sauvegarde avant de lancer la mise à jour.

Si votre système de fichiers est ZFS, pensez également à créer un point de restauration.

Vous pouvez vous appuyer sur notre tuto écrit pour pfSense, mais facilement adaptable pour OPNsense : [pfSense] Mettre à jour son serveur pfSense.

Enfin, vous pouvez consulter la liste complète des changements en visitant la page suivante : OPNsense 22.1 released [EN]



Pour aller plus loin


[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en toute sérénité
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des passerelles (gateway)

icon 05/10/2021 - Aucun commentaire

Dans cet article nous traitons de la gestion des passerelles réseaux (gateway) sous pfSense.



Passerelle - la clé de voûte du routage


Une passerelle réseau (gateway) est un dispositif permettant de donner accès d'un réseau à un autre réseau.

La passerelle la plus connue est la passerelle par défaut (default gateway) ; c'est celle qui nous permet d'accéder à Internet ou à tout autre réseau inconnu d'une façon plus générale.

Généralement, les passerelles disposent d'une adresse IP dans chaque sous-réseau qu'elles permettent de joindre. Si ce n'est pas le cas, elles posséderont alors, à leur tour, une passerelle par défaut.

Il existe une exception notable avec les interfaces point à point, comme celles utilisées avec les protocoles PPP. Ces interfaces ont souvent des adresses IP de passerelle dans un autre sous-réseau car elles ne sont pas utilisées de la même manière.

Pour une introduction plus complète, nous proposons la consultation de la page Wikipédia Passerelle (informatique).

Nous allons voir comment pfSense gère ses passerelles et les possibilités de configuration qui nous sont offertes.



Passerelle - IPv4 et IPv6


Les principes de routage et de fonctionnement des passerelles sont les mêmes avec IPv4 et IPv6.
Cependant, il n'est pas possible de mélanger les deux types d'adresses IP dans ses configurations. Par exemple, un réseau IPv4 devra avoir une passerelle disposant d'une adresse IPv4 ; une route ne peut pas être créée en utilisant une passerelle IPv6 pour un réseau IPv4.

De la même façon, lorsque l'on travaille avec des groupes de passerelles (dont nous verrons la configuration plus loin dans cet article), il n'est pas possible de mixer des passerelles IPv4 et IPv6 au sein d'un même groupe.



Gestion des passerelles


La gestion des passerelles s'effectue depuis le menu System > Routing :

menu System > Routing - pfSense - Provya



Depuis ce menu il est possible de modifier une passerelle existante, ajouter/supprimer une passerelle, définir des routes statiques, créer des groupes de passerelles et choisir sa passerelle par défaut.

Certaines passerelles sont obtenues automatiquement via DHCP ; dans ce cas, il n'est pas possible de les supprimer. Il est cependant possible des les personnaliser.

Dans la suite de cet article nous passons en revue les configurations possibles pour les passerelles.


Création / Modification d'une passerelle


L'ajout d'une nouvelle passerelle se fait en cliquant sur le bouton "+ Add" depuis l'onglet "Gateways" (onglet par défaut).
La modification se fait en cliquant sur l'icône en forme de crayon modification se trouvant sur la ligne de la passerelle.
Enfin, il est possible de dupliquer une passerelle en cliquant sur l'icône associée duplication.

Les éléments configurables sont les suivants :

  • Disabled : permet de désactiver une passerelle.
  • Interface : l'interface sur laquelle la passerelle est joignable. Dans une configuration classique pour une accès vers Internet, il s'agit de l'interface "WAN".
  • Address Family : IPv4 ou IPv6.
  • Name : le nom que l'on souhaite donner à notre passerelle. Ce nom ne peut contenir que des caractères alphanumériques ou underscore ; pas de caractères spéciaux, ni d'espace.
  • Gateway : l'adresse IP de la passerelle ; cette adresse IP doit être dans le même sous-réseau que celui configuré sur l'interface choisie (WAN, dans notre exemple). Si ce n'est pas le cas, il faudra cocher la case "Use non-local gateway" dans les options avancées.
  • Gateway Monitoring : cocher la case permet de désactiver la supervision de la passerelle. Ainsi, la passerelle sera considérée comme étant toujours joignable. Sauf si vous avez une bonne raison, cette case ne devrait pas être cochée.
  • Gateway Action : cocher cette case permet de considérer que la passerelle est toujours joignable. Cette option peut être pratique si l'on souhaite superviser l'état de la passerelle sans pour autant laisser pfSense modifier le routage automatiquement en cas d'injoignabilité de la passerelle. Sauf bonne raison, cette case devrait rester décochée.
  • Monitor IP : l'adresse IP qui sera pinguée afin de déterminer si la passerelle est joignable ou non-joignable. Par défaut, si ce champ est laissé vide, c'est l'adresse IP de la passerelle elle-même qui sera pinguée. Il peut être pratique de choisir une autre adresse IP si la passerelle ne répond pas aux PING ou si on préfère pinguer une adresse IP sur Internet plutôt que l'adresse IP de la BOX de l'opérateur, par exemple.
  • Force state : cocher cette case permet de forcer l'état de la passerelle à "injoignable" ; ainsi, elle ne sera pas utilisée par pfSense. Ce peut être une option pratique si on rencontre du bagot (instabilité) sur une passerelle ; cela permet alors de la désactiver sans avoir besoin de la supprimer.
  • Description : un champ description.

Exemple de résultat obtenu :

Configuration d'une passerelle sous pfSense - Provya


On peut également, si on le souhaite, personnaliser les options avancées de la passerelle en cliquant sur le bouton "Display Advanced". Les paramètres avancés que l'on peut configurer sont les suivants :

Weight
Le poids de la passerelle. Cette valeur est utilisée dans les groupes de passerelle pour répartir le trafic de manière inéquitable entre deux passerelles. Par exemple, si nous avons 2 accès à Internet : WAN1 avec 10 Mbps de bande-passante et WAN2 avec 20 Mbps de bande-passante, alors nous pouvons configurer la passerelle de WAN1 avec un poids de 1 et celle de WAN2 avec un poids de 2 ; ainsi pour 3 trafics sortant, 2 passeront par WAN2 et 1 passera par WAN1 (répartition 1/3 - 2/3). Le poids donné peut aller de 1 à 30.

Data Payload
Par défaut, le ping envoyé vers la passerelle a une taille de payload à 0 (aucune donnée n'est contenue dans la requêtes ICMP). Dans de très rares circonstances, cela peut poser des problèmes (routeur intermédiaire refusant les paquet avec un payload à 0) ; dans ce cas, passer le payload à 1 devrait corriger le problème.

Latency thresholds
Permet de configurer les seuils d'alerte pour la latence de la passerelle.
Les valeurs sont exprimées en millisecondes.
Le premier seuil définit le seuil d'alerte : lorsqu'il est atteint, une alerte est générée, mais la passerelle est considérée comme étant toujours joignable. Par défaut, cette valeur est de 200 ms.
Le second seuil définit le seuil maximal de tolérance : lorsqu'il est atteint, la passerelle est considérée comme n'étant plus joignable. Par défaut, cette valeur est de 500 ms.

Packet Loss thresholds
Permet de configurer les seuils d'alerte pour le taux de perte de paquets de la passerelle.
Les valeurs sont exprimées en pourcentage (0 signifie 0% de perte de paquets, 100 signifie 100% de perte de paquets).
Le premier seuil définit le seuil d'alerte : lorsqu'il est atteint, une alerte est générée, mais la passerelle est considérée comme étant toujours joignable. Par défaut, cette valeur est de 10%.
Le second seuil définit le seuil maximal de tolérance : lorsqu'il est atteint, la passerelle est considérée comme n'étant plus joignable. Par défaut, cette valeur est de 20%.

Probe Interval
La valeur du champ "Probe Interval" détermine la fréquence à laquelle une requête ping est envoyée vers l'adresse IP de la passerelle (ou l'adresse IP à superviser, si elle a été personnalisée), en millisecondes. Par défaut, une requête ping est envoyée deux fois par seconde (500 ms).

Loss Interval
La durée au bout de laquelle les PING restés sans réponse sont considérés comme perdus. La valeur par défaut est 2000 ms (2 secondes).
Cette valeur doit être supérieure ou égale au seuil maximale toléré pour la latence.

Time Period
La durée sur laquelle les résultats du ping sont moyennés. La valeur par défaut est 60000 ms (60 secondes, une minute).
Saisir une durée plus longue mettra ainsi plus de temps pour que la latence ou la perte déclenche une alarme ; en revanche, elle sera moins susceptible d'être affectée par un comportement erratique dans les résultats de ping.

La durée choisie doit être supérieure à deux fois la somme de Probe Interval et de Loss Interval, autrement les résultats retournés peuvent être incohérents.

Alert interval
L'intervalle de temps, en millisecondes, entre deux vérifications de la présence d'une alerte. La valeur par défaut est 1000 ms (1 seconde).
Cette valeur devrait être supérieure ou égale à la valeur de Probe Interval, car il n'est pas possible qu'une alerte soit déclenchée entre deux mesures distinctes (c'est la nouvelle mesure qui peut potentiellement déclencher une alerte si les seuils configurés ont été atteints).

Use non-local gateway
Cocher cette option permet une configuration non-standard où l'adresse IP de la passerelle n'est pas dans le même sous-réseau que celui configuré sur l'interface de pfSense. Il reste très rare d'avoir besoin d'activer cette option ; cependant avec la pénurie d'IPv4, un certain nombre d'opérateurs ont, semble-t-il, tendance à recourir à cet artifice pour économiser le nombre d'adresses IP publiques consommées par client.


Création d'un groupe de passerelles


Un groupe de passerelles est une solution efficace pour mettre en place de la redondance (une passerelle primaire, une secondaire) ou de la répartition de charge (deux passerelles primaires).

La configuration d'un groupe de passerelles est utile dans un environnement multi-WAN, par exemple.

La création ou la modification d'un groupe de passerelles s'opère depuis l'onglet "Gateway Groups" du menu System > Routing.

Les éléments configurables sont les suivants :

Group Name
Le nom du groupe de passerelles. Ce nom ne peut contenir que des caractères alphanumériques ou underscore ; pas de caractères spéciaux, ni d'espace.
La longueur maximale est de 32 caractères.

Gateway Priority
Cette liste contient toutes les passerelles disponibles. Pour chaque passerelle, deux éléments de configuration sont à définir :

Tier : l'ordre de priorité de la passerelle ; il y a cinq niveaux de priorité de Tier 1 (le plus prioritaire) à Tier 5 (le moins prioritaire). Si deux passerelles sont configurées avec deux niveaux de priorité différente, alors seule la passerelle avec le niveau de priorité le plus fort sera utilisée.

Pour bien comprendre, c'est-à-dire que ce sont les passerelles disposant du niveau de priorité Tier 1 qui seront utilisées exclusivement ; s'il n'y pas ou plus de passerelles Tier 1 de disponibles, alors ce seront les passerelles disposant d'une priorité Tier 2 qui seront utilisées exclusivement ; etc.

Si deux passerelles sont configurées avec le même niveau de priorité, alors le trafic sera réparti sur ces deux passerelles en fonction de leur poids respectif (configurable dans les options de la passerelle - champ "Weight" des options avancées).

Enfin, il est possible de choisir "Never" pour ne pas inclure la passerelle en question dans le groupe.

Virtual IP : l'adresse IP à utiliser. Par défaut, il s'agit de l'adresse IP de pfSense sur l'interface concernée, mais cela pourrait aussi être une adresse IP virtuelle, par exemple.

Trigger Level
Ce champ permet de définir selon quelle condition une passerelle doit être exclue du groupe. 4 valeurs sont possibles :

Member Down : exclu la passerelle que si elle est considérée comme non-joignable.
Packet Loss : exclu la passerelle si le taux de perte de paquet atteint la valeur du seuil d'alerte de Packet Loss thresholds de la passerelle (10% par défaut).
High Latency : exclu la passerelle si la latence atteint la valeur du seuil d'alerte de Latency thresholds de la passerelle (200ms par défaut).
Packet Loss or High Latency : exclu la passerelle si la latence ou le taux de perte de paquets atteint le seuil d'alerte de la passerelle.

Description
Un champ description.

Exemple configuration :
Configuration d'un groupe de passerelles sous pfSense - Provya


Sur la capture d'écran ci-dessus, la configuration est la suivante : uniquement la passerelle "WAN_Gateway_1" sera utilisée (c'est la seule en Tier 1) ; si elle devient injoignable, alors les deux passerelles "WAN_Gateway_2" et "WAN_Gateway_3" seront utilisées en répartition de charge (toutes les deux sont en Tier 2).
Dès que la passerelle "WAN_Gateway_1" sera de nouveau joignable, alors le trafic rebasculera exclusivement sur celle-ci.


Configuration d'une route statique


Les routes statiques sont utilisées lorsque des hôtes ou des réseaux sont accessibles par un routeur autre que la passerelle par défaut.
Le firewall connaît les réseaux qui lui sont directement rattachés et il atteint tous les autres réseaux selon les indications de la table de routage ; c'est-à-dire via sa passerelle par défaut ou via une route statique.
Ainsi, dans les réseaux où un routeur interne connecte des sous-réseaux internes supplémentaires, une route statique doit être définie pour que ces réseaux soient accessibles.

Pour ajouter une nouvelle route, se rendre dans l'onglet "Static Routes" du menu System > Routing.

Les éléments configurables sont les suivants :

Destination network
L'adresse IP ou le réseau de destination.
Ce peut être une adresse IPv4, un préfixe IPv6 ou un alias.
Nous déconseillons très fortement l'utilisation d'un alias car la table de routage n'est pas mise à jour quand un alias est mis à jour. Il s'agit donc d'une solution totalement déconseillée.

Gateway
La passerelle par laquelle le réseau sera joignable.

Disabled
Permet de désactiver une route sans pour autant la supprimer.

Description
Un champ de description.


Que l'on ait créé ou modifié une passerelle, un groupe de passerelles ou une route statique, il faut penser à cliquer sur le bouton "Apply Changes" afin que les configurations soient prises en compte.



Choix de la passerelle par défaut


Le choix de la passerelle par défaut s'opère depuis l'onglet Gateways du menu System > Routing (en bas de page).

Il est possible de définir une passerelle par défaut pour IPv4 et une autre pour IPv6.
Par défaut, IPv6 aura la priorité sur IPv4.

Si l'on préfère qu'IPv4 ait la préférence sur IPv6, alors il faut cocher la case "Prefer IPv4 over IPv6" depuis l'onglet Networking du menu System > Advanced.

Préférer IPv4 à IPv6 sous pfSense - Provya


Pour le choix de la passerelle par défaut, les valeurs suivantes seront proposées :

  • Automatic : choix par défaut ; pfSense utilisera la première passerelle disponible dans la liste des passerelles configurées, en allant du haut vers le bas.
  • Choisir une passerelle : cette passerelle sera systématiquement utilisée comme passerelle par défaut par pfSense.
  • Choisir un groupe de passerelles : pfSense utilisera les passerelles du groupe dans l'ordre de priorité dans lequel elles ont été définies ; pour que cela fonctionne correctement, il faut qu'il n'y ait qu'une seule passerelle par priorité (il n'est pas possible de faire du load-balancing sur la passerelle par défaut).
  • None : aucune passerelle par défaut ne sera définie pour ce type d'adresse (IPv4 ou IPv6).



Ordre de priorité des règles de routage


L'ordre de priorité suivant lequel le routage se fera est le suivant :

  1. Règle de filtrage : si dans une règle de filtrage (menu Firewall > Rules), une passerelle a été choisie dans les options avancées de configuration de la règle, alors c'est vers cette passerelle que le trafic sera routé, quel que soit l'état de la table de routage de pfSense.
  2. Réseau attaché à une interface : si un sous-réseau est connu par pfSense car il est configuré sur une de ses interfaces, alors pfSense va router directement le trafic sans passer par une passerelle.
  3. Route statique : si la destination d'un trafic correspond à un route statique configurée, alors pfSense suivra cette route statique.
  4. Passerelle par défaut : enfin, si la destination n'est pas connue de pfSense, alors il routera le trafic vers sa passerelle par défaut.

Enfin, si un doute subsiste sur le routage que va suivre pfSense ou sur l'état de la table de routage, on peut s'appuyer sur notre article dédié : [pfSense] Comprendre et analyser ses règles de routage


Voilà, nous avons fait un tour complet des éléments à connaître pour la gestion de ses passerelles réseaux sous pfSense !



Pour aller plus loin


[pfSense] Comprendre et analyser ses règles de routage
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfSense 2.5.2 est disponible

icon 08/07/2021 - Aucun commentaire

English version: pfSense 2.5.2 now available

Mercredi 07 juillet 2021 est sortie la dernière version de pfSense. La version 2.5.2.

Il s'agit d'une mise à jour qui apporte principalement des corrections de bugs, ainsi qu'un timide retour de Wireguard.

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



Bugs / Améliorations


Concernant le routage, il existait deux bugs importants qui ont été corrigés :
  • Correction de l'énorme bug qui empêchait de mettre en œuvre des redirections de ports sur les WAN secondaires. Ce problème était apparu avec la version 2.5.1.
  • Correction d'un bug qui empêchait de faire du 1:1 NAT sur les VPN IPsec.

De nombreuses anomalies liées à l'interface web ou à PHP ont également été corrigées :
  • Dashboard / sonde de température : les valeurs retournées étaient vides ou fausses pour certains matériels.
  • Widget IPsec : uniquement la première phase 2 était affichée dans certain cas sur le tableau de bord.
  • La modification de Widget pouvait provoquer des avertissements PHP (Warning).
  • Le Widget NTP affichait des valeurs incorrectes ou incohérentes.
  • Affichage / code PHP : correction d'un certain nombre d'erreurs d'affichage ou d'erreurs PHP.
  • Corrections des erreurs PHP qui étaient affichées lorsque le fichier PHP_error.log était trop volumineux.

Les autres corrections notables sont les suivantes :
  • Portail captif : correction d'une faille de sécurité de type XSS qui permettait l'exécution de code javascript s'il était passé dans la variable redirurl ;
  • Résolveur DNS (Unbound) : retour vers Unbound 1.12.x car il y avait trop d'instabilité avec Unbound 1.13.x. C'est temporaire, les futures version de pfSense re-basculeront sur Unbound 1.13.x dès que cela aura été stabilisé ;
  • AES-NI (accélération cryptographique) : correction d'un bug sur le support de SHA1 et SHA-256 lorsqu'AES-NI est utilisé ;
  • IPsec : correction de nombreux bugs résiduels qui étaient apparus avec pfSense 2.5.0 et qui n'avaient pas été corrigés avec la version 2.5.1 ;
  • OpenVPN : correction de plusieurs petits bugs et mise à jour d'OpenVPN vers la version 2.5.2 ;
  • Interfaces réseaux : correction d'un bug qui empêchait de modifier la MTU si IPv4 et IPv6 étaient tous les deux actifs sur l'interface.


Enfin, plusieurs améliorations au niveau du système d'exploitation (FreeBSD) ont été ajoutées :
  • Ajout du pilote RTL8153 (qui est un adaptateur USB vers Ethernet) au noyau FreeBSD ;
  • Ajout du support pour la console Xen ;
  • Ajout de nouveaux algorithmes de contrôle de la congestion réseau.



Nouveautés


Il n'y a pas de grosses nouveautés pour cette version de pfSense.

On peut cependant noter l'ajout du support des fournisseurs de DNS dynamique suivant : Mythic-Beasts, one.com, Yandex PDD, NIC.RU et Gandi LiveDNS IPv6.

Dernier élément notable, le package WireGuard est réintroduit en tant que package expérimental.
À utiliser avec précaution, donc.



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 (à 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.5.2 New Features and Changes [EN]



Pour aller plus loin


[pfSense] Mettre à jour son serveur pfSense
WireGuard est retiré de pfSense pour des raisons de sécurité
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Sauvegarder automatiquement son firewall avec un script

icon 29/06/2021 - 5 commentaires

English version: [pfSense] Making automatic backups with a script

Dans cet article, nous présentons une solution pour sauvegarder automatiquement son pfSense avec un script shell.

Nous nous appuyons sur le script shell bm-backup-pfsense proposé par le site Blogmotion.



Principe de fonctionnement


Le script va se connecter sur l'interface web du pfSense à sauvegarder et va "naviguer" dans les menus afin de déclencher le téléchargement du fichier de configuration (config.xml).

L'intérêt de ce script est qu'il passe par l'interface web de pfSense pour effectuer la sauvegarde. Ainsi, il n'y a pas besoin d'activer un accès SSH sur le serveur pfSense que l'on souhaite sauvegarder et l'on peut créer un compte utilisateur avec les droits strictement nécessaires pour effectuer la sauvegarde.

D'une façon générale, nous recommandons de se méfier des scripts ou applications qui nécessitent un accès SSH "root" sur les firewall pfSense ; cela représente un risque trop important en terme de sécurité.

Le script bm-backup-pfsense fonctionne très bien sous pfSense 2.4.x, 2.5.x et 2.6.x.



Création d'un compte utilisateur


Pour commencer, nous allons créer un compte utilisateur dédié à la sauvegarde.
Se rendre dans le menu System > User Manager :

Menu System > User Manager - pfSense - Provya


Depuis l'onglet "Users" (onglet par défaut), cliquer sur le bouton "+ Add".

Nous créons un nouvel utilisateur en précisant simplement un nom d'utilisateur (username) et un mot de passe (password). Les autres champs peuvent être laissés vides.

Exemple de résultat obtenu :

Création d'un utilisateur pour la sauvegarde - pfSense - Provya

Création d'un utilisateur dédié pour la sauvegarde


Pour en savoir plus sur la gestion des utilisateurs sous pfSense, consultez notre article dédié : [pfSense] La gestion des utilisateurs.


Nous pouvons maintenant modifier cet utilisateur afin de lui assigner les bons droits d'accès.
Pour cela, cliquer sur l'icône en forme de crayon se situant sur la ligne de l'utilisateur que nous venons de créer :

Modification d'un utilisateur pour la sauvegarde - pfSense - Provya



Descendre au niveau de la rubrique "Effective Privileges" et cliquer sur le bouton "+ Add" :

Ajout de droits à un utilisateur pour la sauvegarde - pfSense - Provya



Nous ajoutons le droit d'accès à la page de Sauvegarde / Restauration en sélectionnant la ligne "WebCfg - Diagnostics: Backup & Restore" :

Choix des droits pour un utilisateur pour la sauvegarde - pfSense - Provya



Nous validons notre choix en cliquant sur le bouton "Save", puis nous sauvegardons la modification de l'utilisateur en cliquant de nouveau sur le bouton "Save".

Ainsi, notre utilisateur "sauvegarde-auto" peut se connecter sur l'interface web de pfSense mais n'aura accès qu'à la page Backup & Restore :

Menu limité à la sauvegarde - pfSense - Provya

L'utilisateur sauvegarde-auto n'a accès qu'à une seule page de notre pfSense




Configuration du script


Le script bm-backup-pfsense doit pouvoir s'exécuter sur n'importe quelle distribution GNU/Linux ou serveur FreeBSD/pfSense.

Dans notre cas, nous exécuterons ce script depuis un serveur de sauvegarde Linux hébergé sur notre réseau local (LAN).

Nous téléchargerons le script pfmotion_curl.sh.

Il existe deux autres versions de bm-backup-pfsense : une version utilisant le programme wget et une version permettant de sauvegarder plusieurs pfSense (à condition que le nom d'utilisateur et le mot de passe soient identiques sur tous les pfSense à sauvegarder).

Le fichier pfmotion_curl.sh est très simple à paramétrer ; il suffit de compléter les variables suivantes :

  • PFSENSE_HOST (ligne 14) : l'adresse IP du serveur pfSense à sauvegarder
  • PFSENSE_USER (ligne 17) : le compte utilisateur pour se connecter à pfSense. Dans notre cas : sauvegarde-auto
  • PFSENSE_PASS (ligne 18) : le mot de passe associé au compte utilisateur
  • BACKUP_DIR (ligne 21) : le dossier de sauvegarde (par défaut, les sauvegardes seront enregistrées dans le dossier conf_backup du répertoire où est exécuté le script)

Exemple de résultat obtenu :

Configuration du script pfMotion-backup - pfSense - Provya


Il ne nous reste plus qu'à lancer le script :

Lancement du script pfMotion-backup - pfSense - Provya

Le script s'est déroulé avec succès. Sauvegarde effectuée


Nous pouvons automatiser le lancement de ce script, toutes les nuits par exemple, via une tâche cron.

Enfin, et pour être complet, nous proposons d'ajouter deux fonctionnalités complémentaires au script :

  • Une alerte par e-mail si la sauvegarde ne s'effectue pas correctement
  • La suppression des sauvegardes de plus de 30 jours


Alerte par e-mail si la sauvegarde ne s'effectue pas correctement


Il suffit d'ajouter le code suivant aux lignes 71 et 78 :

echo "Erreur lors de la sauvegarde de pfSense" | mail -s "Sauvegarde auto pfSense - ERREUR" mon@adresse.tld

Ce qui donnera quelque chose comme ceci :

Alerte par e-mail en cas de problème avec pfMotion-backup - pfSense - Provya


Il faut, bien-sûr, remplacer mon@adresse.tld par l'adresse e-mail destinée à recevoir les notifications.

Il faut également avoir préalablement configuré sur son serveur un programme d'envoi d'email tel que Postfix ou Sendmail.
Nous proposons un article succinct sur l'installation et la configuration de Postfix sur un serveur Ubuntu ou Debian : [Postfix] Installer et configurer Postfix pour envoyer ses e-mails depuis un serveur dédié


Suppression des sauvegardes de plus de 30 jours


Nous proposons d'ajouter le code suivant qui va s'occuper de rechercher et supprimer les fichier de plus de 30 jours se trouvant dans le dossier de sauvegarde.

# Suppression au dela de 30 jours
find "$BACKUP_DIR/" -type f -mtime +30 -exec rm {} \;

Ce code est à placer en fin de script, juste avant les deux dernières lignes :

echo
exit 0

Voilà, nous disposons d'une solution simple, pratique et efficace pour sauvegarder automatiquement notre serveur pfSense.
Merci à Mr Xhark du site Blogmotion pour sa réalisation et son partage.



Pour aller plus loin


[pfSense] Sauvegarder automatiquement sa configuration avec AutoConfigBackup
[Postfix] Installer et configurer Postfix pour envoyer ses e-mails depuis un serveur dédié
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 visitez notre boutique en ligne.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des packages sous pfSense

icon 08/06/2021 - 2 commentaires

English version: [pfSense] The package system in pfSense

pfSense propose l'installation de packages afin de pouvoir lui ajouter des fonctionnalités supplémentaires.

Dans cet article, nous présentons le fonctionnement des packages, leur gestion (installation, mise à jour, suppression), ainsi que les principaux packages.



Qu'est-ce qu'un "package"


Dans son installation par défaut, pfSense offre une large palette de fonctionnalités. Il est en plus possible de lui adjoindre des fonctionnalités supplémentaires par l'installation de packages. Ces packages peuvent offrir des services complémentaires ou des informations statistiques avancées.

Ces packages sont intégrés à pfSense. C'est-à-dire que leur utilisation se fait généralement via l'interface web de pfSense.
De même, la liste des packages disponibles est maintenue et vérifiée par Netgate, l'éditeur du logiciel pfSense, afin de s'assurer que les packages proposés soient correctement mis à jour et maintenus.

Les packages sont les seuls outils additionnels que l'on peut installer aisément sur un pfSense existant. En effet, le logiciel pfSense tournant sur une base FreeBSD modifiée, l'ensemble des packages ou logiciels habituellement disponibles sous FreeBSD (via pkg, par exemple, l'outil de gestion des paquets de FreeBSD) ne pourra pas forcément être installé sur pfSense (pour des problématiques de dépendances, principalement).

Enfin, il est important de rappeler que l'installation de packages sur pfSense doit se faire de manière mesurée et pragmatique ; pour des raisons de sécurité, il est recommandé de n'installer que les package strictement nécessaires.



Comment installer un package


L'installation d'un package s'opère depuis le menu System > Package Manager :

Menu System > Package Manager - pfSense - Provya


La gestion des packages est organisée sous la forme de deux onglets :

Gestion des packages - pfSense - Provya


Le premier onglet (Installed Packages) permet de visualiser les packages installés. Il est également possible depuis cet onglet de réinstaller un package ou de le mettre à jour.

Le deuxième onglet (Available Packages) permet de parcourir la liste complète des packages disponibles et pas encore installés.

Pour chaque package, les informations suivantes sont présentées :

  • Name : le nom du package ; un lien peut être présent sur le nom du package en priorité vers la page de documentation associée, vers la catégorie dédiée sur le forum pfSense ou vers le site de l'éditeur.
  • Version : la version installée ou installable.
  • Description : une description succincte en anglais du package.

Depuis l'onglet "Available Packages", il est également possible de lancer une recherche sur un mot clef.

Pour installer un package donné, il suffit de cliquer sur le bouton "Install" se situant sur la même ligne.

Installer un paquet - pfSense - Provya


Une confirmation nous sera demandée, il suffira de cliquer sur le bouton "Confirm" :

Installer un paquet - pfSense - Provya


Le processus d'installation se déroule et les informations d'installation sont affichées à l'écran. Une fois l'installation réalisée avec succès, un message d'information est affiché :

Installation réussie d'un paquet - pfSense - Provya


De la même façon, en cas d'erreur ou d'anomalie lors de l'installation d'un package, un message d'erreur explicite est affiché.



Gérer les mises à jour de package


Les packages disposent de leur propre rythme de mise à jour.
Aussi, lorsque l'on installe un package, il est important de maintenir ce dernier à jour.

Lorsqu'un package dispose d'une mise à jour, son nom apparaît en jaune et l'icône Icône de mise à jour d'un package sous pfSense - Provya est également affichée :

Mettre à jour un package sous pfSense - Provya

Les packages ntopng et openvpn-client-export peuvent être mis à jour


Pour lancer la mise à jour, il suffit de cliquer sur l'icône de mise à jour Icône de mise à jour d'un package sous pfSense - Provya.

Pour les packages à jour, l'icone affichée est la suivante : Icône d'un package à jour sous pfSense - Provya.

Icône d'un package à jour sous pfSense - Provya

Le package acme est à jour



Point d'attention concernant les mises à jour : lors de la sortie d'une nouvelle version de pfSense, les dépôts proposés par défaut sont mis à jour pour correspondre à la nouvelle version de pfSense ; ainsi les packages (et les mises à jour) proposés sont ceux correspondant à la nouvelle version de pfSense.
Si on n'utilise pas la dernière version de pfSense et que l'on souhaite installer ou mettre à jour un package, il faut modifier la branche de version utilisée pour les dépôts. Nous détaillons la procédure dans le paragraphe suivant.

Enfin, lors d'une mise à jour de pfSense, il faut d'abord mettre à jour pfSense, avant de mettre à jour les packages. Nous présentons la procédure complète pour mettre à jour son pfSense dans notre article dédié : [pfSense] Mettre à jour son serveur pfSense



Installer et mettre à jour des packages pour les anciennes versions de pfSense


Si une nouvelle mise à jour de pfSense est sortie et que l'on ne souhaite pas y passer, mais que l'on veut continuer à pouvoir installer/mettre à jour ses packages, il faut modifier les dépôts cibles.

Pour cela, il faut se rendre dans le menu System > Update :

Menu System > Update - pfSense - Provya


Se rendre sur l'onglet "Update Settings" et dans liste déroulante "Branch", choisir la branche correspondant à notre version de pfSense actuellement installée :

Changement branche mise à jour - pfSense - Provya


Il faut, bien-sûr, cliquer sur le bouton "Save" pour valider le changement.



Désinstaller ou réinstaller un package


Il peut parfois être utile de réinstaller un package lorsque celui-ci rencontre des problèmes de stabilité ou suite à une mise à jour qui ne s'est pas bien passée.

Il y a deux approches possibles : réinstaller le package ou désinstaller puis installer de nouveau le package.

Pour cela, deux icônes sont proposées pour chaque package installé ; la première icône permet de désinstaller le package Désinstaller un package sous pfSense - Provya, la seconde de le réinstaller Réinstaller un package sous pfSense - Provya.

Il faudra confirmer l'action choisie en cliquant sur le bouton "Confirm".

Gestion des packages sous pfSense - Provya




Présentation des principaux packages


Il existe plus ou moins une soixantaine de packages. Nous proposons ici de présenter succinctement les principaux :


ACME


Le paquet ACME (Automated Certificate Management Environment) permet la gestion des certificats auprès des fournisseurs supportant le protocole ACME, comme Let's Encrypt par exemple.


arping et arpwatch


Ces deux paquets permettent d'envoyer des requêtes ARP de type who-has et de surveiller / alerter dès qu'une nouvelle adresse MAC est détectée sur le réseau.


apcupsd


Ce paquet permet de contrôler tous les modèles d'onduleurs APC. Il peut surveiller et enregistrer l'état actuel de l'alimentation et de la batterie, effectuer un arrêt automatique et peut aussi fonctionner en mode réseau pour mettre hors tension d'autres hôtes sur le réseau.


BIND


Ce paquet fournit une interface graphique pour le serveur DNS BIND (permettant de mettre en place un serveur DNS faisant autorité ou un résolveur DNS).


Cron


Propose une interface graphique pour manipuler le programme cron (qui est un planificateur de tâches) de pfSense.


HAproxy


Installe le logiciel HAProxy qui est un reverse proxy et équilibreur de charge (load balancing) puissant.


LADVD et lldpd


Ces deux paquets offrent des fonctionnalités similaires et permettent la prise en charge des protocoles LLDP (Link Layer Discovery Protocol), CDP (Cisco Discovery Protocol), EDP (Extreme Discovery Protocol) et NDP (Nortel Discovery Protocol).


squid, squidGuard et Lightsquid


Ce paquets permettent d'installer le serveur proxy squid, de filtrage d'URL ou de noms de domaine squidGuard et l'analyseur de logs Lightsquid.


ntopNG


ntopNG agit comme une sonde réseau qui montre l'utilisation détaillée du réseau. ntopNG dispose d'un émetteur/collecteur NetFlow/sFlow.


OpenVPN Client Export


Ce paquet permet de générer des fichiers de configuration OpenVPN pré-configurés pour les clients, des installateurs de clients Windows pré-configurés et des bundles de configuration Viscosity.


pfBlockerNG


Installe le logiciel pfBlockerNG qui est un utilitaire très complet permettant de contrôler les connexions à travers le pare-feu sur la base de critères plus généraux que les règles du pare-feu elles-mêmes (par exemple, par pays, par nom de domaine, etc.).
pfBlockerNG gère des listes d'adresses IP dans des formats de type "Deny, Permit ou Match", permet d'accéder à la base de données GeoIP, gère des liste noire DNS (DNSBL), etc.


Siproxd


Ce paquet permet d'installer un proxy SIP pour la VoIP. Pour la plupart des configurations SIP modernes, ce type de logiciel n'est absolument plus du tout nécessaire. Le paquet Siproxd ne doit donc être installé / utilisé que si c'est vraiment utile.


Snort et Suricata


Ces paquets offrent des fonctionnalités très similaires. Ils permettent d'installer un système de prévention d'intrusion de type IDS/IPS.


System Patches


Ce paquet permet l'installation de correctifs (patches) personnalisés.


Zabbix-agent et Zabbix-proxy


Ces paquets permettent la collecte et la remontée d'informations de supervision vers un serveur Zabbix.


Nous avons fait le tour de la gestion des packages sous pfSense et listé les principaux d'entre eux.

Dans de prochains articles, nous présenterons plus en détail certains packages : leurs intérêts concrets et leurs utilisations détaillées.



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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfSense 2.5.1 est disponible

icon 15/04/2021 - 3 commentaires

English version: pfSense 2.5.1 now available

Mardi 13 avril 2021 est sortie la dernière version de pfSense. La version 2.5.1.

Il s'agit d'une mise à jour qui corrige principalement les très nombreux bugs apportés avec pfSense 2.5.0. Autre nouveauté importante : le logiciel WireGuard est retiré de pfSense.

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



Nouveautés


Il s'agit de la seule nouveauté de pfSense 2.5.1, comme nous l'avions annoncé dans un précédent article, WireGuard est retiré de pfSense 2.5.1 pour des raisons de sécurité.

/!\ Attention : pour bénéficier de cette mise à jour, vous devez supprimer toutes configurations existantes de WireGuard : si vous avez configuré un VPN WireGuard sur votre pfSense, la mise à jour 2.5.1 ne pourra pas se faire.



Bugs / Améliorations


Les principaux bugs corrigés ou les principales améliorations apportées sont les suivantes :
  • Alias : il n'était plus possible de renommer un alias déjà en cours d'utilisation. C'est corrigé.
  • Authentification : correction d'un problème d'authentification LDAP pour les accès SSH à pfSense.
  • Certificats : plusieurs bugs ont été corrigés. Notamment des bugs portant sur le renouvellement de certificat.
  • Tableau de bord : correction de plusieurs indicateurs qui remontaient des valeurs incorrectes, notamment sur le processeur ou sur la table d'états.
  • Gateway : plusieurs bugs corrigés notamment sur la gestion de passerelles se trouvant sur un sous-réseau différent de l'interface WAN.
  • IPsec : énormément de bugs ont été corrigés (bugs qui avaient été introduits par la version 2.5.0).
  • OpenVPN : plusieurs bugs, plutôt mineurs, ou anomalies d'affichage ont été corrigés.
  • IPv6 : correction d'une anomalie sur la gestion des RA (Routeur Advertisements).
  • Notifications : certaines notifications (notamment via Telegram) ne respectaient pas la configuration du proxy. C'est corrigé.
  • Haute-disponibilité : correction d'erreurs de synchronisations avec XMLRPC.



Processus de mise à jour


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

Vous ne pourrez pas mettre à jour si vous utilisez un VPN WireGuard : la mise à jour vous sera proposée, mais elle échouera. Vous devez d'abord supprimer les configuration WireGuard existantes avant de pouvoir mettre à jour.

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 (à 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 : 21.02.2/2.5.1 New Features and Changes [EN]



Pour aller plus loin


[pfSense] Mettre à jour son serveur pfSense
WireGuard est retiré de pfSense pour des raisons de sécurité
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

WireGuard est retiré de pfSense pour des raisons de sécurité

icon 23/03/2021 - Aucun commentaire

Netgate, l'éditeur du logiciel pfSense, a annoncé le 18/03/2021 que le logiciel WireGuard était retiré de pfSense 2.5.

Cette annonce fait suite à une annonce similaire de la part de l'équipe de base (core team) de FreeBSD : WireGuard sera retiré de FreeBSD 13, jusqu'à ce qu'une version plus mature puisse être ajoutée par la suite.

La raison de ce retrait est la présence de graves lacunes en terme de sécurité au niveau du code-source de la version de WireGuard livrée avec pfSense / FreeBSD.

Dans cet article, nous présentons ce qu'il s'est passé.



WireGuard, qu'est-ce que c'est ?


WireGuard est à la fois un logiciel open-source et un protocole de communication permettant de mettre en place un réseau privé virtuel (VPN).

Il s'agit d'une alternative à OpenVPN et IPsec.

La solution WireGuard se veut être une solution simple à mettre en oeuvre, à l'état de l'art en termes de développement, de fonctionnalités et de sécurité et offrir des performances réseaux particulièrement intéressantes.

WireGuard est développé par Jason A. Donenfeld et par les sociétés ZX2C4 et Edge Security.

WireGuard a, à l'origine, été développé et intégré au noyau Linux.



Implémentation de WireGuard sous FreeBSD / pfSense


Il s'agissait d'une des principales nouveautés de pfSense 2.5 : l'intégration de WireGuard au noyau de FreeBSD.

La plupart des distributions GNU/Linux supportent WireGuard depuis un petit moment déjà (car WireGuard a été intégré au noyau Linux 5.6), ainsi qu'OPNsense qui a intégré un support de WireGuard dans l'espace utilisateur (en attendant une intégration au noyau de FreeBSD).

Le développement de WireGuard pour FreeBSD a été assuré par des développeurs de Netgate (l'éditeur de pfSense). Le développement a duré pratiquement un an.

Le code a ensuite été intégré au noyau FreeBSD.

Malheureusement, il est vite apparu que le code intégré au noyau FreeBSD ne respectait pas les standards habituels de qualité et de sécurité.

Le fondateur du projet WireGuard, Jason Donenfeld (qui n'a pas participé au développement de la version présente dans pfSense 2.5) s'est penché sur le code ajouté au noyau de FreeBSD et a émis des critiques sévères que nous retranscrivons ici :

Ce code, c'est ce qui donne une mauvaise image au langage C !
Il y a des instructions "sleep" aléatoires pour corriger des problématiques d'accès concurrents, des fonctions de validation qui renvoient systématiquement "true", des vulnérabilités cryptographiques absolument catastrophiques, des pans entiers du protocole WireGuard non-implémentés, des "kernel panic", des contournements de sécurité, des dépassements de tampon, des "printf" arbitraires enfouis dans la partie cryptographique du code-source, et toute la litanie habituelle des choses horribles qui peuvent aller mal quand les gens ne font pas attention à ce qu’ils écrivent en C.

Il semblerait que cette déclaration soit légèrement exagérée (par exemple en employant le pluriel, là où un seul cas a été constaté). Cependant, toutes ces alertes de sécurité et de qualité du code sont bien réelles et confirmées par d'autres développeurs dont Kyle Evans qui est un guru FreeBSD et mainteneur du package WireGuard pour FreeBSD.

Des problématiques de sécurité sur les Jumbo frame ou d'élévation des privilèges ont également été rapportées.


Dans un premier temps Netgate a annoncé que l'implémentation de WireGuard ne posait pas de réels problèmes de sécurité pour les utilisateurs de pfSense, avant de finalement déconseiller son utilisation, puis enfin retirer le logiciel WireGuard de pfSense.



Peut-on utiliser WireGuard sous pfSense ou FreeBSD ?


Techniquement, la réponse est oui. Mais c'est totalement déconseillé.

Il vaut mieux éviter d'utiliser WireGuard pour le moment et privilégier d'autres solutions comme OpenVPN ou IPsec.

Si vous voulez ou devez à tout prix continuer à utiliser WireGuard sur votre pfSense, alors il est indispensable que celui-ci ne soit pas configuré sur une interface dont le MTU est supérieur à 1420.

Pour vérifier le MTU employé sur votre interface, rendez-vous dans le menu Status > Interfaces :

Menu Status > Interfaces - pfSense - Provya


La valeur du MTU sera indiquée pour chacune de vos interfaces.



Je suis utilisateur d'OPNsense, suis-je concerné ?


Non, pas directement. Le plugin WireGuard proposé sous OPNsense n'est pas celui implémenté avec le noyau FreeBSD.
Il s'agit d'une version tournant dans l'espace utilisateur.

Cependant, la version de WireGuard proposée sous OPNsense reste expérimentale : il reste déconseillé de l'utiliser en production.
Un avertissement est d'ailleurs présent dans la documentation d'OPNsense :

Avertissement WireGuard OPNsense - Provya


Pour notre part, nous déconseillons l'utilisation de WireGuard aussi bien sous pfSense que sous OPNsense.



Est-ce que WireGuard reviendra sous FreeBSD / pfSense ?


Oui, bien-sûr. Un nouveau développement complet, en repartant de l'implémentation de WireGuard réalisée pour OpenBSD, et auquel participe Jason Donenfeld (à l'origine du projet WireGuard), les équipes de Netgate et des développeurs de FreeBSD et d'OpenBSD a été lancé.

Il est fort probable que WireGuard fasse son retour pour la version FreeBSD 13.1 (ou une suivante).

La future implémentation de WireGuard pour FreeBSD promet d'être de haute qualité, ce qui est une très bonne nouvelle pour tous les utilisateurs de FreeBSD, pfSense et OPNsense.



Si vous souhaitez obtenir davantage d'informations sur le sujet (en anglais), vous pouvez consulter les liens suivants :

WireGuard est supprimé des logiciels pfSense® CE et pfSense® Plus

Suppression du support WireGuard de la base FreeBSD

Déclaration sur la controverse Wireguard

E-mail de Jason A. Donenfeld

Article d'Ars Technica - WireGuard intégré au noyau est en route vers FreeBSD et le routeur pfSense



Pour aller plus loin


[pfSense] Configurer un VPN IPsec site à site
[pfSense] Monter un accès OpenVPN site-à-site
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfSense 2.5.0 et pfSense Plus 21.02 sont disponibles !

icon 18/02/2021 - Aucun commentaire

English version: pfSense 2.5.0 and pfSense Plus 21.02 now available

Mercredi 17 février 2021 est sortie la dernière version de pfSense. La version 2.5.0. Ainsi que la première version de pfSense Plus : la version 21.02.

Il s'agit d'une mise à jour importante en terme de fonctionnalités, de correctifs de sécurité et de stabilité.

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



Nouveautés


Les nouveautés principales sont les suivantes :

  • mise à jour de l'OS vers FreeBSD 12.2 (qui est la dernière version stable de FreeBSD) ;
  • implémentation de Wireguard, qui est une solution VPN open-source qui se veut être très simple à mettre en œuvre et très performante ;
  • suppression de la fonctionnalité "Load Balancer" intégrée à pfSense : il est recommandé de se tourner vers le package HAProxy ;
  • Ajout de l'authentification Radius pour les utilisateurs SSH ;
  • Amélioration de la gestion des sauvegardes (davantage d'options sont disponibles, notamment pour sauvegarder les baux DHCP, ou les adresses MAC utilisées sur le portail captif, ...)
  • mise à jour d'OpenSSL vers la version 1.1.1 ;
  • mise à jour d'OpenVPN vers la version 2.5.0 ;
  • mise à jour de PHP (7.4) et de Python (3.7)



Bugs / Améliorations


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

  • Alias : correction de plusieurs bugs (notamment pour les alias mélangeant des adresses IPv4 et IPv6).
  • LDAP / Radius : correction de plusieurs bugs pour l'authentification LDAP / Radius.
  • Portail captif : correction de plusieurs bugs mineurs sur la gestion de l'authentification.
  • Certificats : amélioration sur la gestion, la création et le renouvellement des certificats.
  • Service DHCP : ajout de fonctionnalités diverses (suppression de tous les baux en un clic, ajout d'options DHCP pour les entrées statiques, ...).
  • Passerelle : amélioration de la gestion des passerelles par défaut : il est maintenant possible d'obtenir une passerelle par DHCP qui soit en dehors du sous-réseau de l'interface ; et corrections de quelques bugs mineurs liés à IPv6.
  • IPsec : pas mal d'améliorations cosmétiques ou techniques : plusieurs petits bugs ont été corrigés et la gestion des VPN IPsec gagne en lisibilité.
  • Notifications : évolution de la gestion des notifications : les notifications via Growl ont été supprimées ; ajout de la possibilité d'envoi de notifications via Telegram.
  • OpenVPN : il n'est plus possible de désactiver la négociation des paramètres de sécurité (NCP - Negotiable Cryptographic Parameters) ; et dorénavant par défaut, lorsqu'un client envoie des paquets compressés, pfSense les décompresse, mais les réponses ne seront pas compressées (la compression sous OpenVPN est dépréciée depuis très longtemps pour des raisons de sécurité et de performance).



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 : 21.02/2.5.0 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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Avec pfSense Plus, l'avenir de pfSense ne sera pas (que) open-source

icon 09/02/2021 - 6 commentaires

Netgate, l'éditeur du logiciel pfSense a annoncé en janvier 2021 de grands changements dans le cycle de développement du logiciel pfSense avec l'arrivée d'un nouveau logiciel : "pfSense Plus".

pfSense Plus sera une version propriétaire et plus évoluée de pfSense.

Dans cet article nous faisons le point sur cette annonce et ses conséquences.

Logo pfSense Plus




pfSense, pfSense CE, pfSense FE, etc : commençons par quelques précisions liminaires


Il nous paraît important de commencer par bien préciser les termes que nous employons.

pfSense est une marque déposée par la société Netgate. Cette marque est déposée et protégée internationalement.

Autour de cette marque, deux logiciels sont proposés :

pfSense Community Edition (également appelé pfSense CE) qui désigne le logiciel open-source pfSense en tant que tel. Aussi, lorsque nous parlons de "pfSense" pour désigner le logiciel, ceci est un abus de langage : pour être très précis, nous devrions parler de "pfSense CE".
Cet abus de langage est communément répandu pour deux raisons : à l'origine, le terme pfSense désignait le logiciel et la marque (jusqu'au rachat par Netgate en 2014) ; et l'éditeur communique très majoritaire sur le terme "pfSense software" pour parler du logiciel pfSense CE.

pfSense Factory Edition (également appelé pfSense FE) qui désigne un logiciel propriétaire que l'on retrouve sur les firewall commercialisés par Netgate et chez des fournisseurs de solutions de cloud (Cloud Service Provider - CSP) comme AWS ou Azure.

Aussi, il faut bien avoir en tête que lorsque vous achetez des firewall Netgate ou que vous installez pfSense via le marketplace d'AWS ou d'Azure, vous n'utilisez en aucun cas un logiciel open-source : vous utilisez le logiciel propriétaire pfSense FE.



pfSense CE et pfSense FE : quelles différences ?


Les principales caractéristiques de pfSense FE, par rapport à pfSense CE, sont les suivantes :

  • pfSense FE n'est pas open-source ;
  • pfSense FE supporte les firewall Netgate qui tourne sur des architectures ARM ;
  • pfSense FE est proposée sur les marketplace d'AWS et d'Azure ;
  • pfSense FE propose des options de configurations spécifiques aux ports switch des firewall Netgate (la plupart des firewall Netgate ne dispose pas de ports réseaux indépendants, mais de ports switch : cela leur permet d'offrir une plus grande densité de ports réseaux pour un coût plus faible, mais au prix d'une performance plus limitée).

Les autres fonctionnalités que l'on trouve sous pfSense CE ou pfSense FE sont exactement les mêmes. Ce sont donc des logiciels très proches.



pfSense Plus, qu'est-ce que c'est ?


En février 2021, le logiciel propriétaire pfSense Factory Edition sera renommé pfSense Plus.

À partir de cette date, les logiciel pfSense CE et pfSense Plus vont diverger.

Netgate va procéder à une ré-écriture d'une grande partie du code-source de pfSense Plus afin de le rendre plus lisible, plus sécurisé et plus facilement maintenable.
Il s'agit là d'un des reproches majeurs formulés à l'encore de pfSense : un code-source à la qualité inégale et pas suffisamment structuré.

Ensuite, pfSense Plus incorporera rapidement de nouvelles fonctionnalités très demandées, comme par exemple :

  • Une refonte complète de l'interface graphique (plus sécurisée)
  • Un tableau de bord plus moderne et efficace
  • Des outils de statistiques et de reporting avancés
  • La prise en charge des normes sans-fil 802.11ac (Wi-Fi 5) et 802.11ax (Wi-Fi 6)
  • Le support du mode Zero Touch Provisioning pour des déploiements facilités

La roadmap détaillée de développement sera précisée prochainement par Netgate.

Autre élément important, pfSense Plus sera publié selon un rythme beaucoup plus régulier que pfSense CE. Il y a aura 3 versions majeures par an : janvier, mai et septembre.

C'est également là un des reproches formulés à l'encore de pfSense : un rythme de mise à jour trop irrégulier et ne respectant pas les cycles de versions de FreeBSD.
Par exemple, la dernière version stable de pfSense à ce jour est la version 2.4.5-RELEASE-p1 qui repose sur FreeBSD 11.3. Or, FreeBSD 11.3 est arrivé en fin de vie le 30/09/2020 et n'est donc plus maintenu depuis plusieurs mois déjà !

Le nommage des versions de pfSense Plus se fera selon le format AA.MM (année sur deux chiffres, mois sur deux chiffres). La première version de pfSense Plus, qui devrait sortir en février 2021, sera donc la version 21.02.

Dernier élément important : pfSense Plus sera dans un premier temps proposé uniquement pour les firewall Netgate, puis sur les instances de cloud partenaire, et enfin (d'ici la fin de l'année 2021) pour tous, installable sur tous matériels.



Quel sera le prix de pfSense Plus ?


Ces informations n'ont pas encore été communiquées par Netgate.

Ce que l'on sait pour le moment, c'est que l'utilisation de pfSense Plus pour un usage non-commercial (usage personnel, labo de tests, etc.) sera gratuite.

Pour les usages commerciaux, la grille de prix n'a pas encore été communiquée. Elle le sera dans le courant du mois de juin 2021.

À titre de comparaison, les tarifs de tnsr (logiciel propriétaire de Netgate pour des réseaux de + 40 Gbps) démarrent à 400 dollars / an. On peut donc, a priori, s'attendre à un tarif similaire ou inférieur pour pfSense Plus.



pfSense Plus marque-t-il la fin de pfSense CE ?


Le message délivré par Netgate est très clair : la priorité de développement est donnée à pfSense Plus. La plupart des améliorations qui seront apportées à pfSense Plus ne seront pas directement reversées à pfSense.

Cependant, les développements concernant des éléments communs aux deux versions de pfSense seront bien évidemment reversés vers pfSense CE ; comme par exemple les contributions à FreeBSD ou à packet filter.
Il faut garder en tête que Netgate est, depuis des années, et restera, un gros contributeur à de nombreux projets open-source.

pfSense CE continuera à être maintenu.
Le rythme de développement continuera comme aujourd'hui : c'est-à-dire qu'une nouvelle version sortira quand elle sera prête !

Beaucoup de monde avait déjà constaté que le rythme de développement de pfSense CE avait énormément ralenti. Il faut visiblement s'attendre à ce qu'il soit peut-être encore plus faible.

Ainsi, les corrections de bugs, les mises à jour de sécurité ou les améliorations apportées aux briques open-source utilisées dans pfSense CE continueront à être proposées. En revanche, il ne faut pas s'attendre à l'ajout de nouvelles fonctionnalités importantes. Ces nouvelles fonctionnalités seront réservées prioritairement (voire quasi-uniquement ?) à pfSense Plus.

Vraisemblablement, pfSense CE va continuer à être maintenu mais ne va plus vraiment évoluer.



pfSense Plus, bonne ou mauvaise nouvelle ?


Les deux !

C'est une bonne nouvelle car :
Ces annonces permettent de clarifier la stratégie de développement de Netgate concernant pfSense.
Tout le monde avait constaté un ralentissement du rythme de développement et des mises à jour. Il était donc nécessaire de clarifier le projet industriel porté par Netgate. C'est chose faite.

Netgate annonce un rythme de développement soutenu de pfSense Plus, la refonte d'une partie du code source (qui en a bien besoin...) et l'ajout de nouvelles fonctionnalités très attendues.
Si les tarifs annuels proposés sont raisonnables et que le côté "logiciel propriétaire" n'est pas un point de blocage pour vous, alors pfSense Plus être une très bonne solution.

Enfin, cette solution reste gratuite d'utilisation pour un usage non-commercial.

Mais c'est également une mauvaise nouvelle car :
Les annonces faites sont très claires : le développement sera prioritairement (quasi-exclusivement ?) sur pfSense Plus. Il n'y aura aucun rythme de développement nouveau pour pfSense CE.

Aucune nouvelle fonctionnalité n'est annoncée pour pfSense CE, hormis les corrections de bugs, mises à jour de sécurité et les mises à jour des briques open-source utilisées dans pfSense CE.

Il ne faut pas se voiler la face : ces annonces augure très visiblement la fin à petit feu de la version open-source de pfSense.



Que faire ? Quelles solutions envisagées ?


Notre première réponse est surtout de ne pas se précipiter !

pfSense CE 2.5.0 va sortir très prochainement (en février 2021). Il s'agit d'une version majeure qui apportera son lot de nouveautés. Wireguard sera notamment intégré à pfSense 2.5.0.

Il n'y a donc pas d'urgence à migrer. pfSense reste un bon logiciel, robuste, stable et sécurisé. Au cours des prochaines années il continuera d'être maintenu, mais évoluera très peu.

Nous attendons de voir l'offre tarifaire associée à pfSense Plus. Nous ne rejetons pas, a priori, cette solution. Les fonctionnalités et le rythme de développement annoncés pour pfSense Plus attirent notre curiosité.
Nous attendons les annonces complémentaires de Netgate sur le sujet.

Il est à noter que Netgate annonce que la compatibilité de migration de pfSense CE vers pfSense Plus sera maintenue. Il sera ainsi possible de migrer facilement de pfSense CE vers pfSense Plus à l'avenir.

Enfin, il est possible de se tourner vers OPNsense qui est un fork de pfSense né fin 2014, début 2015.
OPNsense bénéficie d'un code-source qui a été en très grande partie réécrit (+ 90 %), sécurisé, épuré et simplifié. L'interface graphique d'OPNsense est moderne et vraiment bien pensée.

OPNsense bénéficie d'un rythme de mise à jour important et régulier : deux mises à jour majeures par an, ainsi que des mises à jour additionnelles mineures dès que nécessaire.

Au cours de ses premières années, OPNsense souffrait de bugs trop nombreux pour en faire un bon firewall utilisable en production. Depuis, le logiciel a grandement gagné en maturité et en stabilité. Il s'agit donc sûrement de la solution idéale vers laquelle se tourner à l'avenir.

Nous sommes curieux de savoir si nous allons assister à une migration massive des utilisateurs de pfSense vers OPNsense ?

Wait & see.


Vous pouvez retrouver toutes les informations détaillées concernant pfSense Plus sur le blog de Netgate (en anglais) :




Et vous, que pensez-vous des annonces liées à la sortie de pfSense Plus ?



Pour aller plus loin


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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Sauvegarder automatiquement sa configuration avec AutoConfigBackup

icon 26/01/2021 - Aucun commentaire

English version: [pfSense] Making automatic backups with AutoConfigBackup

Cet article est le premier d'une série présentant des solutions pour sauvegarder automatiquement la configuration de son pfSense.

Dans cet article nous nous appuyons sur le service AutoConfigBackup directement intégré à pfSense.



Principe de fonctionnement


AutoConfigBackup (ACB) est un service directement intégré de base à pfSense. Aucun package supplémentaire n'est nécessaire pour l'utiliser.

Lorsqu'il est activé, dès qu'un changement est fait sur le firewall, ou à intervalle régulier, AutoConfigBackup extrait la configuration du firewall, la chiffre à l'aide d'une phrase secrète (passphrase), puis l'envoie via HTTPS vers les serveurs de sauvegarde de Netgate (l'éditeur du logiciel pfSense).

Il est également possible de forcer une sauvegarde manuelle via AutoConfigBackup.

Les cent dernières sauvegardes sont conservées sur les serveurs de Netgate. Il est donc possible de revenir jusqu'à cent sauvegardes en arrière.



Principe de sécurité


Afin de garantir la confidentialité des données sauvegardées, le firewall les chiffre à l'aide de l'algorithme AES-256-CBC et d'une phrase secrète, puis envoie les données chiffrées vers les serveurs de Netgate.
Ainsi, les données envoyées et stockées sur les serveurs Netgate sont indéchiffrables sans cette phrase secrète.

Cette phrase secrète est personnalisable et conservée exclusivement en local sur le firewall. Elle n'est jamais directement transmise aux serveurs Netgate.

Il est important de faire une sauvegarde manuelle de cette phrase secrète car elle sera nécessaire en cas de restauration. Si cette phrase secrète est perdue, il n'y a aucune possibilité de la retrouver. Il ne sera donc pas possible de restaurer les données sauvegardées via AutoConfigBackup.

Enfin, pour identifier de manière unique un firewall, AutoConfigBackup utilise un hash SHA256 de la clé publique SSH du firewall.

Cet identifiant unique doit également être conservé. En cas de perte de cet identifiant, il ne sera pas possible de restaurer les données sauvegardées via AutoConfigBackup.

Il y a donc deux éléments que nous devons conserver précieusement :

  • la phrase secrète
  • l'identifiant unique

Passons à la configuration du service AutoConfigBackup.



Configuration du service AutoConfigBackup


Pour démarrer la configuration, nous nous rendons dans le menu Services > Auto Config Backup, onglet Settings

Menu Services > Auto Config Backup - pfSense - Provya


Les éléments à configurer sont les suivants :

  • Enable ACB : cocher cette case pour activer le service AutoConfigBackup.
  • Backup Frequency : 2 choix sont possibles - sauvegarder la configuration à chaque changement (Automatically backup on every configuration change) ou sauvegarder la configuration à intervalle régulier (Automatically backup on a regular schedule).
  • Schedule : si nous choisissons de faire une sauvegarde à intervalle régulier, il faut préciser les heures et jours de sauvegarde. Le format à utiliser est le format cron.
  • Encryption Password : notre phrase secrète. Les données sauvegardées étant envoyées sur des serveurs tiers, il est important que cette phrase secrète soit suffisamment robuste. Si cette phrase secrète est perdue, il n'y a aucune possibilité de restaurer les données sauvegardées.
  • Hint/Identifier : il est possible de préciser un identifiant qui sera transmis en clair avec les sauvegardes et qui pourra être utilisé par le support Netgate dans le cas où nous aurions perdu l'identifiant unique du firewall. Ce champ est utile uniquement si vous avez souscrit un contrat de support auprès de Netgate. Attention cependant, Netgate prévient officiellement qu'ils ne garantissent pas qu'ils puissent récupérer les sauvegardes via ce paramètre.
  • Manual backups to keep : le nombre de sauvegarde manuelle à conserver. Sur les cent sauvegardes conservées, il est possible de réserver jusqu'à cinquante places pour les sauvegardes manuelles. Nous proposons le nombre 10, qui nous semble être un bon compromis.

Exemple de résultat obtenu pour une sauvegarde automatique à chaque changement de configuration :

Exemple configuration AutoConfigBackup à chaque changement - pfSense - Provya


Exemple de résultat obtenu pour une sauvegarde automatique à intervalle régulier :

Exemple configuration AutoConfigBackup à intervalle régulier - pfSense - Provya

Les sauvegardes sont réalisées tous les samedi à 23h30


Il reste, bien-sûr, à cliquer sur le bouton "Save" afin de sauvegarder notre configuration.

Le service AutoConfigBackup est configuré !

Pour s'assurer que le service fonctionne bien, il nous reste à faire une modification sur la configuration de notre firewall (comme modifier une règle de filtrage, par exemple), puis se rendre dans le menu Services > Auto Config Backup, onglet Restore pour visualiser les sauvegardes automatiques réalisées :

Voir les sauvegardes automatiques - pfSense - Provya


Dans le cas où nous avons choisi de faire une sauvegarde à intervalle régulier, plutôt qu'à chaque changement, il faut attendre que la sauvegarde planifiée ait lieu.


Faire une sauvegarde manuelle


Une sauvegarde manuelle peut être réalisée à n'importe quel moment. Par exemple, avant et après une mise à jour ou des modifications importantes.

Pour lancer une sauvegarde manuelle, il suffit de se rendre dans le menu Services > Auto Config Backup, onglet Backup Now :

Menu Sevices > Auto Config Backup - Backup Now - pfSense - Provya


Il faut saisir les informations liées à la modification afin de pouvoir la retrouver plus facilement, puis cliquer sur le bouton "Backup".

Exemple d'une sauvegarder manuelle via Auto Config Backup - pfSense - Provya




Restauration des sauvegardes


La restauration d'une sauvegarde se fait depuis le menu Services > Auto Config Backup, onglet Restore :

Liste des sauvegardes réalisées avec Auto Config Backup - pfSense - Provya


Il est possible de personnaliser le champ "Device key" afin de restaurer la configuration provenant d'un autre firewall ; la phrase secrète sera également nécessaire.

Pour chaque sauvegarde, il est possible de réaliser 3 actions :

  • Restaurer : Restore this revision - permet de restaurer la sauvegarde choisie - il est conseillé de redémarrer le firewall après avoir lancé la restauration
  • Visualiser : Show info - permet de visualiser le fichier de configuration au format xml
  • Supprimer : Delete config - permet de supprimer une sauvegarde donnée


Voilà, votre firewall est sauvegardé régulièrement et vous savez comment procéder à une restauration depuis une sauvegarde réalisée par AutoConfigBackup.



Limites du service AutoConfigBackup


Le service AutoConfigBackup est très pratique car directement intégré à pfSense et configurable en quelques clics. Il permet d'avoir des sauvegardes régulières et de faire face sereinement en cas de nécessité de retour-arrière ou en cas de défaillance du firewall.
Il s'agit d'une solution efficace et vraiment très simple à mettre en œuvre.

Cependant, en utilisant ce service, les sauvegardes sont envoyées sur les serveurs d'une entreprise tiers, située aux États-Unis et par conséquent soumis au droit américain. De plus, vous devez avoir pleine confiance dans la disponibilité et la fiabilité des serveurs Netgate : en cas de panne chez eux, vous risquez de perdre en partie, voire en totalité, vos sauvegardes.

Pour ces raisons, nous ne conseillons pas forcément d'utiliser ce service. En tout état de cause, si vous décidez d'utiliser AutoConfigBackup, nous vous recommandons de le coupler, a minima, avec des sauvegardes manuelles régulières.

Dans un prochain article, nous présenterons une solution pour sauvegarder soi-même, en toute autonomie et de manière automatisée, la configuration de son pfSense : [pfSense] Sauvegarder automatiquement son firewall avec un script.



Pour aller plus loin


[pfSense] Sauvegarder automatiquement son firewall avec un script
[pfSense] Mettre à jour son serveur pfSense
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un VPN IPsec natté (Overlap network)

icon 27/10/2020 - Aucun commentaire

English version: [pfSense] Site-to-site IPsec VPN with overlapping subnets

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage.
Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Par exemple, si l'on souhaite connecter deux sites utilisant le sous-réseau 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le plan d'adressage du réseau distant est le même que celui du réseau local.

Afin d'y remédier, nous proposons d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer un VPN IPsec site-à-site. Il existe déjà un article dédié sur le sujet : [pfSense] Configurer un VPN IPsec site à site.



Principe de fonctionnement


Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

schéma réseau pfSense - VPN IPsec NAT - Provya


Afin de pouvoir relier ces deux sites en VPN, nous avons deux possibilités :

  • translater l'intégralité du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN IPsec. Et inversement, nous ferons de même du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN IPsec.
  • translater l'intégralité du trafic sur une seule adresse IP. C'est un peu ce principe qui est utilisé lors de la navigation sur Internet : toutes les adresses IP privées du réseau local sont nattées sur l'adresse IP publique de la connexion Internet.

Le choix du type de NAT dépend du contexte et des attendus.

Si l'on souhaite accéder à plusieurs équipements et que le plan d'adressage disponible le permet, le mieux est de réaliser un NAT un-pour-un (1:1 NAT) - c'est-à-dire la première solution évoquée ci-dessus.
Dans le cas contraire, un NAT simple sur une seule adresse IP suffira.

Dans notre exemple, nous allons faire en sorte que :

  • depuis le site A : le réseau local du site B sera joignable via le sous-réseau 192.168.200.0/24 ; ainsi, depuis le site A, pour joindre le serveur 192.168.1.222 (présent sur le site B), on attaquera l'adresse IP 192.168.200.222.
  • depuis le site B : le réseau local du site A sera joignable via le sous-réseau 192.168.100.0/24 ; ainsi, depuis le site B, pour joindre le serveur 192.168.1.111 (présent sur le site A), on attaquera l'adresse IP 192.168.100.111.



Configuration du VPN natté


Sur le serveur pfSense du site A, nous nous rendons dans le menu VPN > IPsec :

Menu VPN > IPsec - pfSense - Provya


Nous ne détaillons pas la configuration de la phase 1; cette partie est traitée dans notre article dédié [pfSense] Configurer un VPN IPsec site à site.

Concernant la phase 2, les éléments spécifiques à configurer sont les suivants :

  • Mode : choisir Tunnel IPv4. Attention, le NAT n'est pas possible avec la mise en place d'un VPN IPsec routé [Routed (VTI)].
  • Local Network : choisir "LAN subnet", ou d'une façon générale, le sous-réseau local réel que nous souhaitons rendre accessible à travers le VPN IPsec (192.168.1.0/24, dans notre cas).
  • NAT/BINAT translation : choisir "Network" et indiquer "192.168.100.0/24" pour les champs adresses et masques.
  • Remote Network : choisir "Network" et indiquer "192.168.200.0/24".

Les autres paramètres de la phase 2, ne sont pas spécifiques au fait de monter un VPN natté, nous ne les détaillons donc pas ici.

Exemple de résultat obtenu pour le site A :

Exemple de configuration d'une phase 2 nattée du VPN IPsec - pfSense - Provya


Sur le serveur pfSense du site B, nous réalisons la même configuration, mais en pensant à bien inverser les valeurs.

Exemple de résultat obtenu pour le site B :

Exemple de configuration d'une phase 2 nattée du VPN IPsec - pfSense - Provya




Configuration des règles de filtrage


Il nous reste à adapter nos règles de filtrage au plan d'adressage translaté.

Ainsi, sur notre interface LAN, pour filtrer le trafic du réseau local du site A à destination du site B, en source nous préciserons le LAN subnet (192.168.1.0/24) et en destination le sous-réseau natté pour le site B (192.168.200.0/24).

Exemple de résultat obtenu pour le site A :

Configuration du filtrage sur un VPN IPsec natté - pfSense - Provya


Pour filtrer le trafic en provenance du VPN IPsec (onglet IPsec), l'opération de NAT ayant déjà eu lieu, le filtrage doit bien se faire sur les adresses IP réelles du site local et sur les adresses IP nattées du site distant.

Exemple de résultat obtenu pour le site A :

Exemple configuration du filtrage sur un VPN IPsec natté - pfSense - Provya


Voilà, nous avons vu comment mettre en œuvre un VPN IPsec natté avec pfSense.



Pour aller plus loin


[pfSense] Configurer un VPN IPsec site à site
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Monter un VPN natté (Overlap network) 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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Ajouter un accès IPv6 à une connexion Internet IPv4 (via un tunnel)

icon 08/09/2020 - 3 commentaires

Dans cet article, nous présentons une solution pour bénéficier d'un accès Internet IPv6 pour les connexion Internet ne proposant qu'une connectivité IPv4. Cette solution repose sur la mise en place d'un tunnel IPv6.

La solution présentée repose sur le service Tunnelbroker d'Hurricane Electric. Ce service est gratuit et permet de bénéficier d'une plage /48 d'adresses IPv6.
La méthodologie suivie est, bien évidemment, applicable pour d'autres fournisseurs de tunnels IPv6.



Pré-requis


Le seul pré-requis est que nous disposions d'une adresse IPv4 publique pouvant répondre aux PING. Il n'est pas nécessaire que cette adresse IPv4 soit fixe.



1. Création d'un compte sur Tunnelbroker.net


La première étape consiste à se créer un compte sur le site tunnelbroker.net.

Inscription TunnelBroker IPv6 pour pfSense - Provya


On valide l'inscription en suivant le lien envoyé par e-mail. Puis on peut se connecter au site Tunnelbroker.

Dans la colonne de gauche "User functions", nous cliquons sur le lien "Create Regular Tunnel" :

Création d'un tunnel IPv6 chez TunnelBroker - Provya


Il faut renseigner son adresse IPv4 publique (qui doit répondre aux ping) et choisir le serveur avec lequel le tunnel IPv6 sera monté. Étant basé en France métropolitaine, nous choisissons le serveur Hurricane de Paris. Nous cliquons enfin sur "Create Tunnel".

TunnelBroker - choisir le serveur IPv6 d'accès - Provya


Une fois le tunnel créé, nous disposons de toutes les informations nécessaires pour créer notre interface IPv6 sur notre pfSense :

TunnelBroker - information de configuration pour pfSense - Provya


Depuis l'onglet "Advanced", il est possible de personnaliser un certain nombre de paramètres :

  • MTU : il est de 1 480 par défaut. Si vous utilisez une connexion Internet montée via le protocole PPPoE, alors il faut réduire ce MTU. 1 452 devrait être une bonne valeur.
  • Adresse IP publique dynamique : si votre connexion Internet IPv4 ne dispose que d'une adresse IP publique dynamique, alors il faudra mettre à jour automatiquement le tunnel à l'aide de l'Update Key (nous décrivons la procédure dans la suite de l'article).



2. Préparer pfSense au tunnel IPv6


Comme indiqué en pré-requis, il est nécessaire que notre adresse IPv4 publique puisse répondre au PING. Pour configurer notre pfSense afin qu'il réponde au ping sur son adresse IPv4 publique, nous nous rendons dans le menu Firewall > Rules :

menu Firewall > Rules - pfSense - Provya


Depuis l'onglet WAN, nous cliquons sur le bouton "+ Add" afin d'ajouter une nouvelle règle qui comportera les paramètres suivants :

  • Action : Pass
  • Interface : WAN, ou d'une façon générale, l'interface sur laquelle est rattachée votre connexion Internet
  • Address Family : IPv4
  • Protocol : ICMP
  • ICMP Types : any
  • Source : "Single host or Alias" et nous indiquons l'adresse IP du serveur choisi à l'étape précédente. Soit dans notre cas : 216.66.84.42
  • Destination : This firewall

Nous cliquons sur "Save", puis sur "Apply Changes" pour sauvegarder et appliquer la configuration.
La règle une fois créée devrait ressembler à quelque chose comme ceci :

Autoriser ping sur l'interface WAN de pfSense - Provya


Enfin, il est nécessaire que notre pfSense accepte le trafic IPv6. Il s'agit de la configuration par défaut de pfSense. Cependant, si le support d'IPv6 a été désactivé, il est possible de le réactiver en se rendant dans le menu System > Advanced, onglet "Networking" :

Menu System > Advanced > Networking - pfSense - Provya


Vérifier que la ligne "Allow IPv6" soit bien cochée, puis cliquer sur "Save".


Activer IPv6 sur pfSense - Provya




3. Création de l'interface IPv6 sur pfSense


Nous pouvons maintenant créer une nouvelle interface pour notre connexion IPv6. Pour cela, se rendre dans le menu Interfaces > Assignment > GIFs :

Menu Interfaces > Assignments > GIFs - pfSense - Provya


Nous cliquons sur le bouton vert "+ Add". Les champs à remplir sont les suivants :

  • Parent Interface : WAN dans notre cas
  • GIF Remote Address : l'adresse IPv4 du serveur distant, soit dans notre cas : 216.66.84.42
  • GIF tunnel local address : l'adresse IPv6 du client. Cette information correspond à la ligne "Client IPv6 Address" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas : 2001:470:abcd:781::2
  • GIF tunnel remote address : l'adresse IPv6 du serveur. Cette information correspond à la ligne "Server IPv6 Address" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas : 2001:470:abcd:781::1
  • GIF tunnel subnet : la taille du sous-réseau IPv6 (au format CIDR). Soit, dans notre cas : 64.

Les autres options doivent être laissées vides ou non-cochées, à moins que vous ne sachiez ce que vous faites.

Exemple de résultat obtenu :

Configuration d'une interface GIF pour IPv6 sur pfSense - Provya


Notre tunnel GIF est créé.
Il reste à lui associer une interface logique. Pour cela, nous nous rendons dans l'onglet Assignment, choisissons l'interface GIF nouvellement créée et cliquons sur le bouton "+ Add" :

Création d'une interface logique GIF sur pfSense - Provya


Nous cliquons sur notre interface OPT1 (ou OPTx d'un façon générale) afin de la configurer de la manière suivante :

  • Enable : cocher la case pour activer l'interface
  • Description : le nom de l'interface. On lui donne un nom plus parlant qu'OPT1. Exemple : WANv6

Les autres options doivent être laissées vides ou non-cochées, à moins que vous ne sachiez ce que vous faites.

Exemple de résultat obtenu :

Configuration d'une interface IPv6 sur pfSense - Provya




4. Configuration de la gateway IPv6 sur pfSense


Lors de la création de l'interface IPv6 (WANv6), une gateway est automatiquement ajoutée.
Si vous possédez déjà une passerelle IPv6, la nouvelle passerelle ne sera pas marquée comme passerelle par défaut. Si vous le souhaitez, il faut donc penser à modifier votre passerelle par défaut depuis le menu System > Routing et renseigner les champs du tableau "Default gateway" :

Configurer passerelle par défaut - pfSense - Provya




5. Ajouter des résolveurs DNS IPv6


TunnelBroker fournit un résolveur DNS IPv6 qui sera ajouté automatiquement à pfSense lorsque l'interface GIF sera montée. Cependant, il est toujours possible d'opter pour d'autres résolveurs DNS. Cette configuration s'opère depuis le menu System > General Setup.

Voici quelques exemples de résolveurs DNS IPv6.

DNS Google :
  • 2001:4860:4860::8888
  • 2001:4860:4860::8844

DNS Quad9 :
  • 2620:fe::fe
  • 2620:fe::9

DNS FDN :
  • 2001:910:800::12
  • 2001:910:800::40



6. Configurer le LAN pour IPv6


À ce stade, pfSense lui-même dispose d'une connectivité IPv6. Pour en faire bénéficier les ordinateurs du LAN, une possibilité est de configurer un dual-stack IPv4/IPv6.

Se rendre dans le menu Interfaces > LAN et apporter les modifications suivantes :

  • IPv6 Configuration Type : choisir "Static IPv6"
  • IPv6 address : indiquer une adresse comprise dans le /64 routé fourni par tunnelbroker. Cette information se trouve à la ligne "Routed /64" du tableau "Tunnel Details" vu précédemment. Soit, dans notre cas 2001:470:abce:781::/64 ; nous pouvons, par exemple, choisir l'adresse 2001:470:abce:781::1 comme adresse IPv6 pour la patte LAN du pfSense

Exemple de résultat obtenu :

Configurer l'interface LAN en IPv6 - pfSense - Provya


Puis, nous cliquons sur "Save" et "Apply Changes" pour valider les modifications.

Nous nous rendons ensuite dans le menu Services > DHCPv6 Server & RA. Les champs à renseigner sont les suivants :

  • DHCPv6 Server : cocher la case pour activer DHCPv6 sur le LAN
  • Range : choisir la plage d'adresses IP que nous souhaitons utiliser pour le service DHCP

Exemple de résultat obtenu :

Configurer DHCPv6 pour l'interface LAN - pfSense - Provya


Nous cliquons sur "Save" pour sauvegarder les changements, puis nous basculons sur l'onglet "Router Advertisements"


Enfin, il ne nous reste plus qu'à configurer une règle de firewall afin d'autoriser le trafic IPv6 pour le LAN. Normalement, une telle règle existe déjà par défaut, mais si nous l'avons supprimée, il faudra la re-créer. Pour cela, nous nous rendons dans le menu Firewall > Rules, onglet LAN et nous cliquons sur "+Add" afin d'ajouter une règle avec les paramètres suivants :

  • Action : pass
  • Interface : LAN
  • Address Family : IPv6
  • Protocol : any
  • Source : LAN net
  • Destination : any

Exemple de résultat obtenu :

Règle de filtrage IPv6 pour l'interface LAN - pfSense - Provya



À ce stade, tout doit fonctionner. On peut tester !

Plusieurs sites permettent de tester sa connectivité. LaFibre.info : ip.lafibre.info/

Tester sa connexion IPv6 sur lafibre.info - Provya


Test-IPv6.com : test-ipv6.com

Tester sa connexion IPv6 - Provya




Mise à jour du tunnel pour les connexions IPv4 avec une adresse IP publique dynamique


Dernier point qui ne concerne que ceux qui ne disposent pas d'une adresse IPv4 fixe : il faut maintenir le tunnel à jour. Pour cela, il faut naviguer dans le menu Services > Dynamic DNS et cliquer sur le bouton "+Add" et configurer les champs de la manière suivante :

  • Service Type : HE.net Tunnelbroker
  • Interface to monitor : WAN
  • Hostname : le tunnel ID qui se trouve sur la première ligne de notre tableau "Tunnel Details"
  • Username : saisir le nom d'utilisateur pour l'accès au site tunnelbroker.net
  • Password : saisir l'Update Key configurable depuis l'onglet "Advanced" du tableau "Tunnel Details"

Cliquer sur "Save" pour sauvegarder les paramètres.


Voilà, nous avons ajouté un accès IPv6 à une connexion Internet n'offrant qu'une connectivité IPv4.

TunnelBroker n'est pas la seule solution existante. Il existe une liste comparative sur Wikipedia (EN)



Pour aller plus loin


[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

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

icon 30/06/2020 - 2 commentaires

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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des utilisateurs

icon 09/06/2020 - 2 commentaires

English version: [pfSense] Local user management

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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Créer des règles de firewall basées sur des conditions horaires

icon 05/05/2020 - Aucun commentaire

Une fonctionnalité pratique de pfSense, mais très méconnue, est la possibilité de définir des règles de filtrage qui seront appliquées en fonction de la date, du jour ou de l'heure.

On peut imaginer l'utilité pour ouvrir des accès temporaires le temps de mises à jour planifiées, pour différencier les horaires d'accès à Internet pour un usage professionnel / personnel ou encore pour un événement éphémère.

Ces règles de filtrage sont présentes avec les autres règles, mais elles seront actives uniquement sur les créneaux horaires définis. Le reste du temps, elles seront simplement ignorées par pfSense.



Configurer un calendrier


La première étape consiste à configurer un calendrier. Cela se passe dans le menu Firewall > Schedules :

menu Firewall > Schedules - pfSense - Provya


Cliquer sur le bouton "+ Add".

Les champs à compléter sont les suivants :

  • Schedule Name : le nom de votre "calendrier", sans espace ni caractères spéciaux.
  • Description : champ purement informatif.
  • Month : le mois et l'année applicable ; on ne peut sélectionner qu'un seul mois à la fois.
  • Date : les jours où la condition horaire sera appliquée. Pour sélectionner chaque jour individuellement, il suffit de cliquer sur la case correspondante. Un jour sélectionné sera sur fond vert. Il est également possible de sélectionner toutes les occurrences d'un jour donné (par exemple tous les samedis) ; pour cela, on peut cliquer directement sur l'entête de colonne correspondant (Sat dans notre exemple du samedi). Les jours sélectionnés seront sur fond bleu.
  • Time : l'horaire de début et de fin (se configure par tranche de quinze minutes)

Par exemple, si nous souhaitons sélectionner tous les samedis du mois de mai 2020 sur le créneau 12h - 14h, le résultat ressemblera à ceci :

Exemple de condition horaire sous pfSense - Provya


Une fois notre configuration réalisée, il faut la valider en cliquant sur le bouton "+Add Time".
Cela permet également d'ajouter d'autres dates et d'autres créneaux horaires à notre calendrier.

Enfin, il reste à cliquer sur le bouton "Save" pour sauvegarder notre calendrier.



Appliquer le calendrier à une règle de filtrage


La création, ou la modification, d'une règle de filtrage s'effectue depuis le menu Firewall > Rules :

menu Firewall > Rulles - pfSense - Provya


Une fois sur votre règle de filtrage, il faut se rendre dans les options avancées (Section "Extra Options", cliquer sur le bouton "Display Advanced" :

options avancées des règles de filtrages - pfSense - Provya


Puis pour le champ Schedule, choisir le calendrier créé précédemment :

Affectation d'un calendrier au filtrage - pfSense - Provya


Exemple de résultat obtenu :

exemple règle de firewall - pfSense - Provya


Le pictogramme jaune indique que la règle n'est actuellement pas active ; c'est le cas de la première règle avec le calendrier "samedi_provya".
Le pictogramme vert indique que la règle est actuellement active ; c'est le cas de la seconde règle avec le calendrier "vendredi_provya".


Dernier élément pour conclure ce court article : par défaut les états sont réinitialisés dès l'expiration du calendrier.
Cela signifie que l'accès est immédiatement coupé y compris pour les sessions actives.

Si l'on souhaite conserver les sessions actives jusqu'à leur expiration, il faut cocher la case "Do not kill connections when schedule expires" accessible depuis System > Advanced, onglet "Miscellaneous".



Pour aller plus loin


Best practices / Recommandations pour la configuration de votre firewall
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[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.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Aider la montée en charge (scalabilité) de ses liens OpenVPN

icon 14/04/2020 - 2 commentaires

Dans cet article nous allons voir les bonnes pratiques à connaître et appliquer afin d'accompagner le mieux possible la montée en charge de ses accès OpenVPN.
Le but est d'améliorer le débit et le nombre maximum d'utilisateurs simultanés.

Dans cet article, nous nous concentrons sur les accès OpenVPN. Dans un prochain article, nous nous attaquerons à IPsec.



IPsec est plus rapide


De part son mode de fonctionnement et son implémentation, IPsec offre de meilleures performances qu'OpenVPN.
Aussi, une solution (radicale ?), pour accroître la capacité de vos liens VPN est de basculer d'OpenVPN vers IPsec.

IPsec peut être utilisé aussi bien pour établir un lien VPN entre deux sites distants, que pour des utilisateurs nomades. Quoique nous ne recommandions pas IPsec pour les utilisateurs distants (OpenVPN est bien plus pratique et facile à mettre en œuvre et passe bien mieux les problématiques de NAT ou CGN).

Notre recommandation est d'utiliser IPsec pour les liens VPN en mode site-à-site, et d'utiliser OpenVPN pour les accès utilisateurs distants.



Utiliser UDP


Lors de la configuration d'OpenVPN, vous avez le choix du protocole de transport TCP ou UDP.
De par son mode de fonctionnement (transmission sans connexion, contrairement à TCP), UDP sera plus efficace et plus rapide.

Ainsi, il vaut donc mieux conserver UDP qui est le protocole par défaut.



Utiliser TLS uniquement pour l'authentification


OpenVPN peut utiliser le protocole TLS aussi bien pour l'authentification que pour le chiffrement du Control Channel (c'est-à-dire le canal de communication établi entre le serveur et le client OpenVPN).
Il est possible d'utiliser TLS uniquement pour l'authentification. Il s'agit d'ailleurs de la configuration par défaut proposée sous pfSense.

TLS pour l'authentification OpenVPN sous pfSense - Provya


Dans tous les cas, le trafic VPN sera chiffré.



Utiliser l'accélération cryptographique


De plus en plus de firewall sont pourvu d'une puce d'accélération cryptographique (AES-NI). La différence de performance pour les liens VPN entre les firewall supportant l'AES-NI et les autres est véritablement importante, d'environ un facteur 10, voire davantage.

Si votre firewall le supporte, il faut activer l'accélération cryptographique AES-NI et BSD Cryptodev depuis le menu System > Advanced ; onglet Miscellanous :

Menu System > Advanced > Miscellaneous - pfSense - Provya


Pour l'option "Cryptographic Hardware", choisir "AES-NI and BSD Crypto Device (aesni, cryptodev)" et penser à valider le changement en cliquant sur le bouton "Save" en bas de page :

Activer l'accélération cryptographique sous pfSense - Provya


Il faut ensuite configurer votre VPN avec un algorithme de chiffrement compatible avec l'accélération cryptographique AES-NI, comme par exemple AES-GCM ou AES-CBC.



Utiliser AES-GCM


L'utilisation d'un chiffrement efficace comme les codes AEAD (authenticated encryption with associated data), qui combinent chiffrement et authentification, permet d'accroître la sécurité et les performances.
Aussi bien IPsec, qu'OpenVPN peuvent utiliser AES-GCM, qui est un code AEAD. En revanche, le support côté client peut varier selon la plate-forme.

C'est pourquoi pour les accès OpenVPN pour les utilisateurs distants, il est conseillé de proposer en priorité AES-GCM, tout en autorisant la négociation des paramètres cryptographiques (NCP - Negotiable Cryptographic Parameters) si besoin.

D'un point de vue configuration de votre serveur OpenVPN, la configuration ressemblera à cela :

  • Encryption Algorithm : choisir AES-GCM
  • Enable NCP : cocher la case Enable Negotiable Cryptographic Parameters
  • NCP Algorithms : choisir AES-GCM (à placer en premier) ainsi que les autres algorithmes que vous souhaitez activer

Utiliser AES-GCM pour OpenVPN sous pfSense - Provya




Réduire le chiffrement au strict minimum


Pour la configuration des liens VPN, nous recommandons généralement d'opter pour de l'AES-256 ou supérieur. Cependant, dans le cas d'une forte activité ou si vous constatez des lenteurs, il est possible de diminuer le niveau de chiffrement et par conséquent le niveau de sécurité au pallier inférieur. Le strict minimum aujourd'hui est l'utilisation d'une clef de 128 bits.

Dans son Référentiel Général de Sécurité (RGS), l'ANSSI recommande l'utilisation de clés symétriques d'une taille d'au moins 128 bits.



Désactiver la compression


Il peut être tentant d'activer la compression sur les liens à faible débit. En réalité, c'est inefficace et non-sécurisé.

Aujourd'hui, la plupart des données qui transitent via les liens VPN est déjà chiffrée ou incompressible. Aussi, activer la compression sur le lien OpenVPN va juste gaspiller du CPU, sans réellement réduire la consommation de bande-passante.
De plus, la compression utilisée par OpenVPN est sensible à des attaques telles que VORACLE (EN).

Aussi, côté serveur OpenVPN, il faut conserver la compression désactivée dans tous les cas. Il s'agit du choix par défaut sur pfSense.
Le paramètre Compression doit rester à Disable Compression :

Désactiver la compression LZO sur les liens OpenVPN sous pfSense - Provya




Utiliser plusieurs serveurs OpenVPN


OpenVPN ne supporte pas le multithreading. Aussi, si votre serveur dispose de plusieurs CPU, un seul sera utilisé par votre serveur OpenVPN.
Ainsi, si le CPU est le facteur limitant, une bonne solution de contournement consiste à configurer plusieurs serveur OpenVPN.

Deux approches sont possibles :

  • Répartir de manière fixe la charge sur plusieurs serveurs OpenVPN : certains clients auront accès à un serveur OpenVPN, d'autres à un autre serveur. Il s'agit de la solution la plus simple et rapide à mettre en œuvre (mais pas nécessairement la meilleure).
  • Répartir la charge aléatoirement sur les plusieurs serveurs OpenVPN : pour cela, il faut que la configuration soit la même pour les deux serveurs OpenVPN (même CA, mêmes paramètres de chiffrement, etc.), mais avec un sous-réseau différent pour chacun. Puis, il faut ajouter le paramètre remote-random dans la configuration du client afin qu'il se connecte de manière aléatoire sur l'un des serveurs OpenVPN configurés. Il s'agit de la solution optimale d'un point de vue scalabilité.

Attention, en démultipliant le nombre de serveurs OpenVPN en fonctionnement sur un même serveur pfSense, on augmente forcément la consommation de mémoire-vive.



Réduire le MSS


Il est possible que vous rencontriez des lenteurs importantes pour des accès via VPN à des partages de fichiers Windows ou à des sites web (ou d'une façon générale à des services utilisant TCP). Dans ce cas, il peut être très utile de réduire le MSS (Maximum Segment Size).

Ce paramètre se définit en ajoutant le code suivant dans le champ "Custom Options" de votre serveur OpenVPN :
mssfix 1400

Régler MSS MTU d'OpenVPN sous pfSense - Provya


Notre recommandation est de démarrer avec une valeur à 1400, puis, si ça fonctionne, l'augmenter progressivement jusqu'à ce que les problèmes réapparaissent. Une fois atteint le point de dysfonctionnement, il suffit de réduire de nouveau très légèrement la valeur du MSS.


Nous avons fait le tour des recommandations de configuration pour l'optimisation de ses accès OpenVPN. D'autres réglages sont également possibles et peuvent permettre, suivant les cas, d'aider à la montée en charge de son VPN, mais ces réglages sont souvent expérimentaux et générateurs de bugs ou entraînent de grosses lacunes de sécurité ; c'est la raison pour laquelle nous ne les présentons pas ici.



Pour aller plus loin


[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

pfSense 2.4.5 est disponible !

icon 31/03/2020 - 2 commentaires

English version: pfSense 2.4.5 now available

Jeudi 26 mars 2020 est sortie la dernière version de pfSense. La version 2.4.5.

Cette mise à jour comporte des correctifs de sécurité, plusieurs nouvelles fonctionnalités et des correctifs de stabilité.

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



Nouvelles fonctionnalités


Les nouvelles fonctionnalités majeures sont les suivantes :

  • Le système d'exploitation est mis à jour vers FreeBSD 11.3 ;
  • Ajout de la possibilité de faire des recherches et des filtres sur plusieurs pages, dont notamment, la page de gestion des certificats (System > Cert. Manager), la page de visualisation des baux DHCP (Status > DHCP Leases), la page de visualisation de la table ARP (Diagnostics > ARP Table) ;
  • Ajout des groupes DH et PFS 25, 26, 27 et 31 pour les VPN ;
  • Modification de la configuration par défaut du système de fichiers UFS à noatime pour les nouvelles installations (ce paramètre n'est pas appliqué si vous faites une mise à jour de votre pfSense). Cela permet de réduire les écritures inutiles sur le disque ;
  • Ajout du paramètre autocomplete=new-password sur les formulaires de l'interface web contenant des champs d'authentification. Cela évite une auto-complétion par le navigateur ;
  • Ajout de Gandi et Linode dans la gestion des DNS dynamique (Services > Dynamic DNS).



Sécurité


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

  • Renforcement contre les attaques de type cross-site scripting (XSS) sur plusieurs pages de l'interface web ;
  • Résolution d'un problème d'escalade de privilège : un utilisateur authentifié, qui était autorisé à accéder au widget d'image pouvait exécuter un code PHP arbitraire ou accéder à des pages pour lesquelles il n'avait normalement pas les droits ;
  • Correction du format des messages d'échec d'authentification XMLRPC (servant pour la réplication sur une installation avec deux pfSense en cluster) afin que ces messages puissent être traités par sshguard ;
  • Mise à jour de la page d'erreur CSRF (Cross-site request forgery).



Bugs


Plusieurs bugs importants ont également été corrigés. C'est une très bonne chose.

Les bugs en question sont les suivants :

  • La durée de vie par défaut du certificat de l'interface web a été réduite à 398 jours. Ce qui est beaucoup plus conforme aux standards actuels. Un certificat avec une durée de vie trop longue entraînait des erreurs sur un certain nombre de plateformes (principalement iOS 13 et macOS 10.15). Si vous êtes sur une mise à jour et non pas sur une nouvelle installation, vous pouvez générer un nouveau certificat à partir de la console ou en SSH avec la commande : pfSsh.php playback generateguicert ;
  • Corrections de plusieurs bugs sur les IPsec VTI (IPsec routé) ;
  • Correction de plusieurs bugs d'affichage avec la gestion des vues personnalisées sur la page de supervision (Status > Monitoring) ;
  • Correction du bug de redirection pour les utilisateurs (autre que le compte admin) qui étaient redirigés vers une mauvaise page lorsqu'ils souhaitaient accéder à la page de gestion des utilisateurs (System > User Manager) ;
  • Correction d'un problème lors de la résolution des entrées FQDN dans les alias où certaines entrées pouvaient être manquantes.



Processus de mise à jour


En raison de la nature importante des changements dans cette mise à jour, des alertes ou des erreurs peuvent être affichées durant le process de mise à jour. Il ne faut pas spécialement en tenir compte. Notamment si vous voyez des erreurs concernant PHP ou la mise à jour de packages.
En conséquence, seules les erreurs qui persistent après la mise à jour sont significatives.

Dans tous les cas, 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 New Features and Changes[EN]



Avertissement : Hyper-V


Attention, un bug a été rapporté pour les installations pfSense 2.4.5 fonctionnant sous Hyper-V (versions 2016 ou 2019). Il y a un emballement du CPU dès que plus de 2 CPU sont attribués à la VM faisant tourner pfSense.
Une solution de contournement consiste à réduire à un le nombre de CPU virtuel alloué à la VM.

Merci à @Hello qui a signalé ce problème en commentaire.

Mise à jour : l'origine du problème a été trouvé. Un bug a été ouvert : pf: tables use non SMP-friendly counters. Le bug apparaît lorsqu'un grande table est rechargée (la liste des bogons, par exemple) ; aussi une possible solution de contournement est de décocher la case "Block bogon networks" sur toutes les interfaces.



Pour aller plus loin


[pfSense] Mettre à jour son serveur pfSense
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Tout comprendre aux alias
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 ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre et analyser les logs de son VPN IPsec

icon 10/03/2020 - Aucun commentaire

Savoir lire les logs de pfSense concernant IPsec peut être difficile.
Nous donnons dans cet article les clefs pour comprendre les logs IPsec et identifier les erreurs de configuration associées.

Après notre article sur comment configurer un VPN IPsec sous pfSense, notre article sur les causes de défaillances généralement rencontrées sur un VPN IPsec et leurs solutions les plus probables, nous abordons dans cet article la gestion des logs d'IPsec sous pfSense et la signification des messages pouvant être rencontrés dans ces fichiers de journalisation.



Configurer les logs IPsec


Les logs pour les VPN IPsec peuvent être configurés pour apporter des informations utiles pour le debogage. Pour effectuer cette configuration, se rendre dans le menu VPN > IPsec, puis onglet Advanced :

menu VPN > IPsec > Advanced - pfSense - Provya


Au sein de la rubrique "IPsec Logging Controls", configurer les options avec les valeurs suivantes :

  • IKE SA : Diag
  • IKE Child SA : Diag
  • Configuration Backend : Diag
  • Autres options : Control

Exemple de résultat obtenu :

Configuration des logs pour debug VPN IPsec sous pfSense - Provya


Il est à noter que modifier ces options ne coupera pas le VPN IPsec.



Interpréter les logs IPsec liés à la phase 1


Les logs des VPN IPsec sont accessibles depuis le menu Status > System Logs, onglet IPsec :

Menu Status > System Logs > IPsec - pfSense - Provya


Nous allons parcourir les messages que l'on peut rencontrer le plus couramment dans les logs.

La bonne manière de procéder, pour analyser les logs, consiste à rechercher les expressions clés indiquant quelles étapes fonctionnent ou, au contraire, échouent. Cela permet d'orienter très pécisément le diagnostique.

Par exemple, si l'on voit dans les logs "IKE_SA ... established", cela signifie que la phase 1 s'est déroulée avec succès et qu'une SA (Security Association) a été négociée. Ce qui signifie que les deux firewall établissant le tunnel IPsec arrivent à échanger de manière sécurisée.

Si l'on voit "CHILD_SA ... established", alors cela signifie qu'une phase 2 s'est déroulée avec succès également. Le tunnel doit être UP (en tout cas, pour au moins l'une des phases 2 ; dit autrement, pour au moins un sous-réseau local et un sous-réseau distant).



Connexions réussies


Lorsqu'un tunnel est correctement monté, les deux firewall doivent disposer dans leurs logs respectifs d'informations indiquant qu'un IKE SA et un Child SA ont été montés avec succès.

Quand il y a plusieurs phases 2, on doit visualiser un "CHILD_SA ... established" pour chacune d'entre elles.

Exemple de log d'un tunnel monté avec succès :

Logs IPsec tunnel monté pfSense - Provya


On voit sur cette capture d'écran que la phase 1 a été négociée avec succès (IKE_SA con2000[11] established) entre le firewall possédant l'adresse IP 192.0.2.90 et celui possédant l'adresse IP 192.0.2.74).

Puis, on voit qu'une phase 2 a été négociée avec succès (CHILD_SA con2000{2} established) permettant aux sous-réseaux 192.168.48.0/24 d'un côté et 10.42.42.0/24 de l'autre d'échanger entre eux.



Connexions échouées


Les exemples suivants montrent plusieurs cas de connexions IPsec échouées.

Un point important à avoir en tête est que dans la plupart des cas, le firewall initiant la connexion IPsec (initiateur) aura peu d'informations pertinentes dans ses logs (on ne saura pas précisément la raison de l'échec de la connexion) ; tandis que le firewall répondant à la demande de connexion IPsec (répondant) aura des informations beaucoup plus précises et détaillées. C'est normal. Il s'agit là d'un élément de sécurité : il serait en effet peu sûr de fournir à un attaquant potentiel trop d'informations sur la configuration du VPN.



Phase 1 - Écart de configuration Main / Aggressive


Dans cet exemple, l'initiateur est configuré en mode "Aggressive", tandis que le répondant est configuré en mode "Main".

Extrait des logs pour l'initiateur :

Échec négociation phase 1 IPsec pfSense - Provya


On lit bien dans les logs que la négociation de la phase 1 se fait en mode "Aggressive" et que l'authentification a échoué (AUTHENTICATION FAILED). Mais l'on ne connaît pas la raison de cet échec.

Extrait des logs pour le répondant :

Échec négociation phase 1 côté répondant IPsec pfSense - Provya


On lit dans les logs que la négociation de la phase 1 a échoué et que la raison de cet échec est que le mode "Aggressive" n'est pas autorisé. Les logs sont bien plus explicites.



Phase 1 - Erreur d'identifiant


Lorsque l'identifiant ne correspond pas (pour rappel, l'identifiant est généralement configuré pour être l'adresse IP publique du firewall), l'initiateur montre seulement que l'authentification a échoué. Le répondant précise la raison de cet échec.

Extrait des logs pour l'initiateur :

Échec identifiant phase 1 côté initiateur IPsec pfSense - Provya


On peut voir que l'erreur retournée est la même que dans le cas précédent : il s'agit d'une erreur d'authentification standard.

Extrait des logs pour le répondant :

Échec identifiant phase 1 côté répondant IPsec pfSense - Provya


Les logs sont beaucoup plus explicites : "no peer config found" ; l'identifiant correspondant à la requête n'a pas été trouvé.



Phase 1 - Erreur sur la Pre-Shared Key


Une erreur sur la PSK peut être difficile à diagnostiquer. En effet, on ne trouvera pas de message explicite dans les logs indiquant qu'il y a une erreur sur la Pre-Shared Key.

Les logs, aussi bien côté initiateur que répondant, ressembleront à ceci :

Erreur PSK sur VPN IPsec phase 1 pfSense - Provya


Si vous voyez ces messages apparaître dans vos logs IPsec, un conseil : vérifiez la valeur de votre Pre-Shared Key sur chaque firewall établissant le VPN IPsec.



Phase 1 - Écart sur le choix de l'algorithme de chiffrement ou de hachage


Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 1 côté initiateur pfSense - Provya



Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 1 côté répondant pfSense - Provya


Les messages sont très explicites et indiquent le problème exact. Ici, l'initiateur était configuré avec de l'AES-128 et le répondant avec de l'AES-256.

Il est à noter que la portion de message "MODP" correspond au groupe Diffie-Hellman (DH group). Ici, on voit que les deux firewall ont bien la même configuration de groupe Diffie-Hellman "MODP_1024".
S'il y avait eu un écart, nous aurions eu deux valeurs différentes, comme par exemple MODP_1024 d'un côté et MODP_8192 de l'autre.

Enfin, la portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.



Interpréter les logs IPsec liés à la phase 2


Phase 2 - Erreur sur la configuration des sous-réseaux


Dans l'exemple ci-dessous, la phase 2 du firewall initiateur est configurée avec le sous-réseau 10.3.0.0/24 vers le 10.5.0.0/24. Tandis que le firewall répondant est configuré avec 10.5.1.0/24 pour son côté.

Extrait des logs pour l'initiateur :

Erreur log config VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur log config VPN IPsec phase 2 côté répondant pfSense - Provya


Dans les logs du répondant, on peut visualiser les sous-réseaux présents dans la négociation de la phase 2 (ligne "looking for a child config for ...") et les sous-réseaux présents dans sa configuration locale (lignes "proposing traffic selectors for ...").

En comparant les deux, une erreur peut être détectée.
Enfin, la mention "no matching CHILD_SA config found" sera toujours présente dans les logs lorsqu'il y aura une erreur de configuration de ce type. Ce message signifie que pfSense n'a pas pu trouver de phase 2 correspondant à la requête du firewall initiateur.



Phase 2 - Écart sur le choix de l'algorithme de chiffrement ou de hachage


Extrait des logs pour l'initiateur :

Erreur chiffrement sur VPN IPsec phase 2 côté initiateur pfSense - Provya


Extrait des logs pour le répondant :

Erreur chiffrement sur VPN IPsec phase 2 côté répondant pfSense - Provya


Dans ce cas, l'initiateur reçoit un message indiquant que le répondant n'a pas pu trouver de proposition correspondant à la demande (ligne "received NO_PROPOSAL_CHOSEN").
Côté répondant, les logs sont plus détaillés et précisent la proposition reçue (ligne received proposals) et la proposition configurée localement (ligne configured proposals).

Dans l'exemple ci-dessus, sur les extraits de logs, on voit que c'est l'algorithme de chiffrement qui est différent (AES_CBC_128 dans un cas et AES_CBC_256 dans l'autre).

La portion "HMAC" correspond à l'algorithme de hachage. Ici, la valeur est HMAC_SHA1_96. Encore une fois, s'il y a un écart entre les deux, il faut alors corriger.


Voilà ! Nous avons fait le tour des messages de logs les plus courants pour les VPN IPsec sous pfSense.



Pour aller plus loin


[pfSense] Configurer un VPN IPsec site à site
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[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 ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec

icon 25/02/2020 - 2 commentaires

Comprendre et dépanner un VPN IPsec qui ne fonctionne pas comme voulu n'est jamais une chose facile.
Heureusement, pfSense offre tout un panel d'outils permettant d'aider à orienter le diagnostique afin de trouver l'origine du problème.

Après notre article sur comment configurer un VPN IPsec sous pfSense, nous présentons dans cet article les causes de défaillances généralement rencontrées et leurs solutions les plus probables.
Dans un autre article, nous présentons dans le détail comment lire et comprendre les logs d'IPsec sous pfSense.



Le tunnel IPsec ne monte pas


La première étape consiste à vérifier que le service IPsec est bien démarré sur pfSense. Pour cela, se rendre dans le menu Status > Services et vérifier que le service IPsec ne soit pas arrêté :

Vérifier statut service VPN IPsec sous pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que le service ipsec est bien démarré.

Si le service ipsec n'est pas lancé ou arrêté (c'est-à-dire soit il n'apparaît pas dans la liste des services, soit il est à l'état "stop"), il faut vérifier que la phase 1 du VPN IPsec soit bien démarrée. Cette vérification s'effectue depuis le menu VPN > IPsec :

État phase 1 VPN IPsec pfSense - Provya


Sur la capture d'écran ci-dessus, on peut voir que le tunnel IPsec est désactivé. Il suffit de cliquer sur le bouton vert "Enable" se trouvant en début de ligne pour activer le tunnel IPsec.

De la même façon, s'il s'agit d'un VPN IPsec pour client mobile, il faut se rendre dans l'onglet "Mobile Clients" et vérifier que la case "Enable IPsec Mobile Client Support" soit bien cochée.

Si le service est correctement lancé, il faut ensuite vérifier dans les logs du firewall (menu Status > System Logs ; onglet Firewall) que la connexion IPsec ne soit pas bloquée. Le cas échéant, il faudra ajouter une règle de filtrage pour autoriser le trafic bloqué.

Les règles de filtrage sont normalement activées automatiquement pour IPsec, mais cette option étant désactivable, mieux vaut vérifier...

Enfin, si le tunnel ne monte toujours pas, la cause principale (et de loin) pour laquelle un VPN IPsec ne monte pas est une erreur de configuration. C'est parfois une erreur simple comme le groupe DH qui n'est pas configuré de la même manière des deux côtés, ou une erreur sur un masque de sous-réseau (/24 d'un côté et /32 de l'autre).
Si le lien VPN est monté avec un routeur autre que pfSense de l'autre côté, il faut avoir en tête que sur ces équipements des options peuvent être masquées par défaut sous un bouton "Advanced" ou "Configuration avancée". Bref, il est important de vérifier avec précision que la configuration de chaque côté du tunnel IPsec soit bien la même pour les différentes options.

Dernier point à vérifier : en fonction du type d'accès à Internet utilisé de part et d'autre, notamment dans le cas d'un VPN IPsec pour les clients mobiles (qui peuvent être derrière un CGN - Carrier-grade NAT) il est possible que le trafic IPsec puisse être bloqué. Dans ce cas, l'utilisation du NAT-T (NAT Traversal) peut être une solution car il permet d'encapsuler le protocole ESP sous le port UDP 4500 pour contourner ces problèmes.



Le tunnel IPsec monte mais le trafic ne passe pas


Le suspect numéro un dans ce type de situation est un problème au niveau des règles de filtrage. Il faut s'assurer que les règles de filtrage ont correctement été configurées. Il faut vérifier l'état des règles de filtrage pour l'interface LAN (ou les autres interfaces locales, le cas échéant) et pour l'interface IPsec. Si les règles semblent être bonnes à première vue et que le trafic ne passe toujours pas, il faut activer la journalisation (dans les options avancées des règles de filtrage concernées) et vérifier les logs (depuis le menu Status > System Logs - onglet Firewall).

Si les paquets ne semblent pas bloqués mais que le trafic ne passe toujours pas, il est possible que ce soit un problème de routage.

Dernier point à vérifier : la configuration des phases 2. Il est important, pour la configuration des réseaux locaux ou distants, de saisir l'adresse IP du réseau et non l'adresse IP du firewall. Par exemple, si d'un côté, il est configuré 192.168.0.1/24 et de l'autre 192.168.0.0/24, alors il est fort probable que le trafic ne passera pas. Il faut saisir correctement l'adresse du sous-réseau. Soit 192.168.0.0/24.



Certains hôtes du réseau sont joignables, mais pas tous


Lorsque pour un même sous-réseau on arrive à joindre certains hôtes, mais pas tous, alors le problème a très probablement pour origine l'une de ces quatre erreurs de configuration :

Passerelle par défaut manquante, incorrecte ou ignorée

Si la machine concernée n'a pas pour passerelle par défaut le pfSense (ou le firewall portant le lien VPN d'une façon générale), il est probable qu'il y ait une problème de routage sur votre réseau interne. Il faut corriger la passerelle par défaut renseignée sur la machine concernée ou corriger le problème de routage interne à votre réseau local.


Masque de sous-réseau incorrect


Il faut vérifier la configuration du masque de sous-réseau pour les machines concernées. Par exemple, si, sur votre réseau local, vous utilisez le sous-réseau 192.168.1.0/24, mais que l'une des machines est configurée avec une adresse IP fixe (ce qui est une mauvaise pratique ; mieux vaut utiliser l'adressage statique via votre serveur DHCP) avec un mauvais masque de sous-réseau comme, par exemple, 192.168.1.0/16 ; cela ne va pas perturber le fonctionnement sur votre réseau local et par conséquent vous n'allez pas forcément vous en rendre compte. En revanche, si le réseau distant joignable via IPsec est, par exemple, le 192.168.2.0/24, alors il sera injoignable par cette machine car elle croira qu'il fait parti du même sous-réseau (/16) et les paquets ne seront donc pas envoyés vers la gateway.

Si ces notions de masque ou de sous-réseau ne sont pas claires pour vous, nous vous recommandons la lecture, très rapide, de la page Wikipédia "Sous-réseau"


Pare-feu de la machine


S'il y a un pare-feu configuré sur la machine, il est possible qu'il bloque les connexions. Il faut vérifier.


Règles de filtrage sur pfSense


Enfin, il faut vérifier que les règles de filtrage soient bien configurées sur les deux firewall établissant le VPN IPsec.



Perte régulière de la connexion


Historiquement, IPsec peut rencontrer des problèmes avec les paquets fragmentés. C'est de moins en moins le cas aujourd'hui, mais si des pertes de paquets ou de connexions sont rencontrées uniquement sur certains protocoles spécifiques (SMB, RDP, etc.), alors l'activation et la configuration du paramètre MSS clampling (Maximum Segment Size) pour le VPN peut être nécessaire.

Le paramètre MSS clamping peut être activé depuis le menu VPN > IPsec - onglet Advanced Settings.
Cocher la case "Enable Maximum MSS" (se trouvant plutôt en bas de page) et saisir une valeur :

Configurer le paramètre MSS clamping sous pfSense - Provya


Notre recommandation est de démarrer avec une valeur à 1400, puis, si ça fonctionne, l'augmenter progressivement jusqu'à ce que les problèmes réapparaissent. Une fois atteint le point de dysfonctionnement, il suffit de réduire de nouveau très légèrement la valeur du MSS.



Déconnexions "aléatoires" du tunnel VPN sur des routeurs peu puissants


Si votre tunnel IPsec tombe régulièrement, puis remonte, et que vous utilisez un mini-PC (du type carte Alix) ou un firewall dont le CPU tourne à 100% de charge, alors vous pouvez rencontrer des problèmes avec le mécanisme de DPD (Dead Peer Detection).
Cela peut se produire lors d'une utilisation élevée de la bande-passante. Dans ce cas, il peut arriver que les paquets DPD ne soient pas envoyés ou que les réponses soient ignorées.
Il n'y a pas 36 solutions, votre firewall n'est pas correctement dimensionné pour votre usage, il faut envisager de le remplacer par un firewall plus puissant.



Le tunnel monte lorsque le firewall initie la connexion, mais pas lorsqu'il répond


Si un tunnel monte uniquement de temps en temps, mais pas tout le temps, c'est qu'il y a sûrement un écart de configuration entre les deux firewall établissant le tunnel IPsec.
Cela peut se produire lorsqu'il y a un écart de niveau de sécurité entre les deux firewall ; celui qui a les paramètres de sécurité les plus forts réussira à initialiser la connexion, mais refusera lorsque c'est l'autre firewall qui sera en initialisation.
Par exemple, si le firewall1 est configuré en mode "Main" pour la négociation d'IKEv1 et que le firewall2 est configuré en mode "Aggressive", alors le tunnel montera lorsque le firewall1 initiera la connexion. En revanche, si c'est le firewall2 qui initie la connexion en mode "Aggressive", alors elle sera refusée par le firewall1.


Nous avons fait le tour des pannes couramment rencontrées lorsque l'on met en place un VPN IPsec.
Un dernier élément à aborder pour être complet est l'analyse des logs. Ce sujet étant très riche, il fera l'objet d'un prochain article dédié.



Pour aller plus loin


[pfSense] Configurer un VPN IPsec site à site
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
[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 ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer un VPN IPsec site à site

icon 11/02/2020 - 12 commentaires

English version: [pfSense] Configuring a Site-to-Site IPsec VPN

Dans cet article nous traitons de la configuration d'un VPN IPsec entre deux firewall.
La configuration porte sur un firewall pfSense, mais les grandes lignes de configuration sont applicables à tous les équipements du marché supportant IPsec.


1/4. Schéma de mise en œuvre


Nous suivrons la configuration présentée sur le schéma suivant :

Schéma réseau tunnel VPN IPsec pfSense - Provya


Pour le site A :
  • Adresse IP publique : 1.1.1.1
  • Réseau local : 192.168.50.0/24

Pour le site B :
  • Adresse IP publique : 2.2.2.2
  • Réseaux locaux : 192.168.10.0/24 et 192.168.20.0/24

Nous présenterons la configuration pour le site A uniquement. La configuration pour le site B étant facilement déductible à partir de celle du site A.


2/4. Configuration de la Phase 1


Se rendre dans le menu VPN > IPsec

Menu VPN > IPsec - pfSense - Provya


Cliquer sur le bouton "+ Add P1". Les éléments à configurer sont les suivants :

  • Disabled : cocher cette case permet de désactiver la phase 1 du VPN IPsec (et donc de désactiver le VPN IPsec)
  • Key Exchange version : permet de choisir la version du protocole IKE (Internet Key Exchange). Nous choisissons "IKEv2". Si l'autre pair ne support par l'IKEv2 ou si un doute subsiste, il est recommandé de choisir "Auto".
  • Internet Protocol : IPv4 ou IPv6 ; dans notre cas, nous choisissons IPv4
  • Interface : l'interface sur laquelle nous souhaitons monter notre tunnel VPN IPsec. Nous choisissons WAN
  • Remote Gateway : l'adresse IP publique du site distant. Dans notre cas : 2.2.2.2
  • Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
  • Authentication Method : la méthode d'authentification des deux pairs. Deux choix sont possibles : authentification par clé pré-partagée (PSK) ou par certificat (RSA). Le plus simple et le plus courant est de choisir "Mutual PSK" ; ce que nous faisons.
  • My identifier : notre identifiant unique. Par défaut, il s'agit de l'adresse IP publique. Nous laissons donc la valeur "My IP address".
  • Peer identifier : l'identifiant unique de l'autre pair. Par défaut, il s'agit de son adresse IP publique. Nous laissons la valeur "Peer IP address"
  • Pre-Shared Key : la clé pré-partagée. Nous laissons pfSense la générer et cliquons pour cela sur "Generate new Pre-Shared Key". Cette clé pré-partagée devra être saisie sur l'autre firewall lors de sa configuration.
  • Encryption Algorithm : l'algorithme de chiffrement. Si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (DH group - utilisé pour l'échange de clés).
  • Lifetime (Seconds) : permet de définir la fréquence de renouvellement de la connexion. La valeur par défaut, 28800 secondes, reste un bon choix
  • Advanced Options : nous laissons les valeurs par défaut

Exemple de résultat obtenu :

Exemple configuration VPN IPsec - Phase 1 - pfSense - Provya


Nous cliquons sur le bouton "Save" pour enregistrer les changements.



3/4. Configuration des Phases 2


Sur la page des tunnels VPN IPsec (sur laquelle vous devez être actuellement), pour notre entrée P1 que nous venons de créer, nous cliquons successivement sur les boutons "Show Phase 2 Entries (0)", puis sur "+ Add P2".

Les éléments à configurer sont les suivants :

  • Disabled : cocher cette case permet de désactiver cette phase 2 du VPN IPsec
  • Mode : nous laissons le mode par défaut "Tunnel IPv4"
  • Local Network : le réseau-local joignable par l'hôte distant sur ce VPN IPsec. Dans notre cas, nous choisissons "LAN subnet".
  • NAT/BINAT translation : si l'on souhaite configurer du NAT sur le tunnel IPsec. Ceci peut être très utile si le plan d'adressage est le même sur les deux sites distants que nous souhaitons interconnecter. Ce n'est pas notre cas dans notre exemple. Nous laissons donc la valeur à "None".
  • Remote Network : l'adresse IP ou le sous-réseau du site distant. Dans notre cas, nous renseignons ici le premier sous-réseau, soit 192.168.10.0/24 ; puis nous créerons une seconde phase 2 en précisant cette fois le second sous-réseau du site distant (192.168.20.0/24).
  • Description : champ facultatif de commentaire (mais que nous conseillons de remplir pour une meilleure lisibilité)
  • Protocol : nous choisissons ESP. AH est rarement utilisé en pratique. Techniquement, le protocole ESP permet de chiffrer l'intégralité des paquets échangés, tandis qu'AH ne travaille que sur l'entête du paque IP sans offrir la confidentialité des données échangées.
  • Encryption Algorithms : Algorithmes de chiffrement. Comme pour la phase 1, si les deux parties supportent l'AES-GCM, nous recommandons l'utilisation d'AES256-GCM ou d'AES128GCM ; ce qui permettra de bénéficier d'un bon niveau de chiffrement et sera compatible avec l'accélération cryptographique offert par AES-NI. Autrement, choisir AES avec une longueur de clé de 256 bits dans l'idéal. Enfin, nous conservons SHA256 pour fonction de hachage et 14 ou 16 pour la valeur du groupe Diffie-Hellman (PFS key group).
  • Lifetime : nous laissons la valeur par défaut, soit 3600 secondes
  • Automatically ping host : une adresse IP à pinguer sur le site distant afin de conserver le tunnel actif. Ce peut être l'adresse IP du firewall sur le site distant par exemple ; nous indiquons 192.168.10.1 dans notre cas.

Exemple de résultat obtenu :

Exemple configuration VPN IPsec - Phase 1 - pfSense - Provya


Nous cliquons sur le bouton "Save" pour sauvegarder notre configuration. Puis nous créeons une nouvelle phase 2 en indiquant cette fois, pour le champ "Remote Network", le second sous-réseau du site B (LAN 2 : 192.168.20.0/24) et choisissons, bien sûr, une adresse IP dans ce sous-réseau pour le champ "Automatically ping host".

Une fois ces configurations effectuées, nous obtenons le résultat suivant :

Exemple de configuration complète d'un tunnel VPN IPsec sous pfSense - Provya


Il ne nous reste plus qu'à cliquer sur le bouton "Apply Changes" pour appliquer nos configurations.

À ce stade, le VPN IPsec doit être monté. Il ne nous reste plus qu'à configurer nos règle de filtrage afin d'autoriser le trafic.



4/4. Règles de filtrage


Il y a au moins deux règles de filtrage à implémenter : celles autorisant le trafic depuis le LAN vers les réseaux du site distant ; et celles autorisant le trafic depuis les deux sous-réseaux du site distant vers le LAN.

Soit, pour l'interface LAN, voici un exemple de règles :

Exemple règles de filtrage du LAN vers le VPN IPsec sous pfSense - Provya



Et pour l'interface IPsec, voici un exemple de règles :

Exemple règles de filtrage du VPN IPsec vers le LAN sous pfSense - Provya



Ces règles sont, en l'état, très permissives. Nous vous recommandons de les affiner afin qu'elles apportent une meilleure sécurité et qu'elles soient en conformité avec votre politique de filtrage.

Dernier élément, si vous avez modifié les options avancées accessibles depuis le menu System > Advanced, onglet Firewall/NAT et que vous avez coché la case "Disable all auto-added VPN rules", alors vous devrez créer des règles de filtrage sur l'interface WAN afin d'autoriser le trafic IPsec avec l'hôte distant. IPsec utilise les ports UDP 500 et 4500, ainsi que le protocole ESP (ou AH, le cas échéant).

La configuration est terminée et doit être fonctionnelle. Pour visualiser les logs associés au VPN IPsec, cela se passe dans le menu Status > System Logs, onglet Firewall.

Dans un autre article nous détaillons quelle procédure suivre pour dépanner et déboguer un tunnel IPsec qui ne fonctionne pas comme voulu.



Pour aller plus loin


[pfSense] Monter un VPN IPsec natté (Overlap network)
[pfSense] Les pannes courantes et leurs solutions sur un VPN IPsec
[pfSense] Comprendre et analyser les logs de son VPN IPsec
[pfSense] Monter un accès OpenVPN site-à-site
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre et analyser ses règles de routage

icon 28/01/2020 - Aucun commentaire

Lorsque l'on essaie de diagnostiquer un problème de routage d'un flux réseau, l'une des premières choses à faire est de vérifier les routes connues par pfSense.

Dans cet article, nous présentons le fonctionnement de la table de routage sous pfSense et les détails à connaître pour un diagnostique efficace.



Visualiser les routes


Pour commencer, si vous n'êtes pas à l'aise avec cette notion de routes ou de table de routage, nous vous conseillons la lecteur du court article Table de routage sur Wikipédia.

Sous pfSense, il y a deux manières de visualiser les routes présentes dans la table de routage : via l'interface graphique ou en ligne de commande.

Pour visualiser la table de routage, nous nous rendons dans le menu Diagnostics > Routes :

Menu Diagnostics > Routes - pfSense - Provya


Le résultat obtenu en ligne de commande est exactement le même que celui obtenu via l'interface graphique. La commande à saisir est :

netstat -rWn

Exemple de résultat obtenu :

table de routage de pfSense - Provya


L'explication du contenu de chaque colonne est la suivante.


Destination


Cette colonne contient l'hôte de destination (désigné par son adresse IP) ou le réseau de destination (désigné par son adresse IP et son masque de sous-réseau associé).

La destination default correspond à la route par défaut du pfSense. C'est vers la passerelle (gateway) associée que seront envoyés les flux destinés à un réseau qui n'est pas directement connu de pfSense.


Gateway


Une passerelle (gateway) est un routeur vers lequel le flux est envoyé afin qu'il soit routé vers une certaine destination. Si la colonne indique un lien comme link#1, alors cela signifie que le réseau est directement joignable sur l'interface du pfSense et qu'aucun routage complémentaire ne sera nécessaire pour acheminer le flux réseau.

Enfin, si c'est une adresse MAC qui est indiquée, cela signifie qu'il s'agit d'un hôte local directement joignable.


Flags


La signification de chaque flag (encore appelé indicateur ou drapeau en français) est la suivante :

  • 1 (RTF_PROTO1) : routage spécifique au protocole flag #1
  • 2 (RTF_PROTO2) : routage spécifique au protocole flag #2
  • 3 (RTF_PROTO3) : routage spécifique au protocole flag #3
  • B (RTF_BLACKHOLE) : suppression des paquets lors des mises à jour
  • b (RTF_BROADCAST) : représente une adresse de broadcast
  • D (RTF_DYNAMIC) : créée dynamiquement par redirection
  • G (RTF_GATEWAY) : la destination est joignable via une gatway
  • H (RTF_HOST) : entrée spécifique à un hôte (ou un réseau)
  • L (RTF_LLINFO) : protocole de validation pour la translation d'adresse physique (ex : pour arp)
  • M (RTF_MODIFIED) : modifiée dynamiquement par redirection
  • R (RTF_REJECT) : hôte ou réseau injoignable
  • S (RTF_STATIC) : entrée ajoutée manuellement
  • U (RTF_UP) : route utilisable
  • X (RTF_XRESOLVE) : un processus externe prend en charge la translation d'adresse physique

Par exemple, une route disposant des flags UGS signifie qu'elle est utilisable (U), que les paquets sont envoyés à une passerelle (G) et qu'elle a été ajoutée manuellement (S).


Use


Cette colonne est une compteur représentant le nombre total de paquets qui ont été envoyés via cette route. C'est très utile pour déterminer si une route est actuellement utilisée ; si c'est le cas, le nombre va continuer à s'incrémenter au fur et à mesure que des paquets réseaux passent par cette route.


MTU


La MTU configurée pour cette route.


Netif


L'interface réseau utilisée pour cette route (ex : igb0 ; igb1.10 ; ovpns1 ; ...).


Expire


Ce champ ne concerne que les entrées dynamiques. Il indique le délai au bout duquel la route va expirer si elle n'est plus utilisée.



Utiliser la commande traceroute


L'utilitaire traceroute est très pratique pour vérifier la bonne configuration de ses routes, notamment dans un environnement multi-WAN. Cet utilitaire présente le cheminement d'un flux réseau de routeur en routeur jusqu'à sa destination.

Sous pfSense, un traceroute peut être effectué depuis le menu Diagnostics > Traceroute :

menu Diagnostics > Traceroute - pfSense - Provya


Pour davantage d'informations sur le fonctionnement de cet utilitaire, vous pouvez lire le chapitre Fonctionnement de l'utilitaire traceroute sur Wikipédia.

Utilisé depuis son ordinateur (commande tracert sous les systèmes Windows) ou depuis pfSense, traceroute permettra de s'assurer qu'un flux réseau est dirigé vers la bonne gateway (le cas échéant, vers la bonne interface pour un environnement multi-WAN).



Routes et VPN


En fonction du type de VPN utilisé, une route peut être présente ou non dans la table de routage de pfSense. Par défaut, IPsec n'utilise pas la table de routage. IPsec maintient sa propre table de routage avec des entrées SPD (security policy database). Ainsi, la configuration manuelle d'une route statique sous pfSense ne permettra jamais de rediriger du trafic à travers un tunnel VPN IPsec. Il faut bien avoir cet élément en tête dans la configuration de sa stratégie de routage et dans la configuration de son tunnel VPN IPsec.

OpenVPN, quant à lui, utilise la table de routage de pfSense (pour être exact, il s'agit en fait de la table de routage de FreeBSD). Ainsi les réseaux joignables via un lien OpenVPN seront visualisables dans la table de routage.

De la même manière, il faut garder en tête que contrairement à OpenVPN, un tunnel IPsec lui-même n'a pas d'adresse IP. Ainsi, lors d'un traceroute, un timeout sera affiché pour le saut correspondant au tunnel IPsec.



Pour aller plus loin


[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un VPN IPsec site à site
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez du matériel ou un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur

icon 27/11/2019 - 1 commentaire

English version: [pfSense] Limit maximum bandwidth per users with Limiters

Les limiters sont une évolution des technologies de priorisation de trafic existante sur pfSense.
D'une façon générale, les limiters permettent de définir une bande-passante maximale pour un usage. Un limiter peut être utilisé pour limiter le trafic d'une adresse IP spécifique ou d'un sous-réseau, pour limiter le trafic pour un type de service spécifique (ex : e-mail, web, ...) ou encore pour répartir de manière équitable le trafic entre plusieurs utilisateurs.

Les usages classiques des limiters sont les suivants :
  • limiter l'utilisateur X à 100 kbps de bande-passante Internet ;
  • répartir équitablement 1 Mbps de bande-passante entre tous les utilisateurs du réseau "LAN" ;
  • limiter le réseau "OPT" à 5 Mbps de bande-passante au total ;
  • limiter le protocole FTP à 2 Mbps de bande-passante Internet

Si vous vous reconnaissez dans ces usages ou ces besoins, alors le présent article est fait pour vous. Si vous souhaitez mettre en place une solution de gestion de priorisation de trafic plus globale, alors notre article [pfSense] Configurer la priorisation de trafic avec CBQ est fait pour vous.

Les limiters permettent de définir une bande-passante maximale pour un usage. À l'inverse, la priorisation de trafic permet de garantir une bande-passante minimale.

Dans cet article, nous allons mettre en place des limiters afin de répartir équitablement la bande-passante de notre connexion Internet entre tous les usagers de notre réseau local.



Généralités sur les limiters


Tout comme pour la priorisation de trafic, la mise en place des limiters se fait en 2 étapes consistant à créer les limiters d'une part et à définir les règles d'affectation du trafic dans ces limiters d'autre part :
  • Limiters : le limiter associé à un débit maximum et ses règles d'application globale ou par groupe d'adresses IP
  • Rules : "règle d'affectation" définissant le limiter par laquelle un trafic spécifique va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.

Les limiters se créent généralement par paire : un limiter pour le trafic entrant (Download) et un limiter pour le trafic sortant (Upload).

Les limiters s'organisent de manières hiérarchiques. C'est-à-dire que l'on définit un limiter root (également appelé pipe), pour lequel on va généralement définir un débit et une latence, et des limiters enfants (appelés queues), pour lesquels on va généralement définir un poids (c'est-à-dire une priorité).



Cas d'usage : répartir équitablement la bande-passante Internet


Dans cet article nous partons du cas d'école suivant : nous disposons d'une connexion Internet ADSL offrant un débit descendant (download) de 20 Mbps et un débit montant (upload) de 1 Mbps.
Nous souhaitons que cette bande-passante soit automatiquement et dynamiquement partagée équitablement entre tous les utilisateurs.

C'est-à-dire que si nous avons 2 utilisateurs connectés en même temps, ils disposeront chacun de 10 Mbps en download et 0,5 Mbps en upload au maximum.
Si nous avons 10 utilisateurs connectés en même temps, ils disposeront chacun de 1 Mbps en download et 100kbps en upload au maximum.

pfSense gérera cette répartition équitable automatiquement et dynamiquement au fil de l'eau.

Notre schéma réseau est le suivant :

Schéma réseau pfSense LAN et WAN


Démarrons la configuration sans plus attendre !



1. Création du limiter pour l'upload


Nous allons créer 2 limiters root : un pour l'upload et un pour le download.
La création s'effectue depuis le menu Firewall > Traffic Shaper :

menu pfSense Firewall > Traffic Shaper


Cliquer sur l'onglet Limiters, puis sur le bouton "+ New Limiter".

Les éléments à configurer sont les suivants :

  • Enable : case à cocher pour activer le limiter root et ses queues
  • Name : le nom de votre limiter root (caractères alphanumériques, tiret et underscore uniquement). Dans notre cas, nous l’appellerons "Upload"
  • Bandwidth : la bande-passante de votre limiter root. Il est à noter que l'on peut définir une bande-passante en fonction d'un calendrier (option "Schedule"). Dans notre cas, nous choisissons "1 Mbps"
  • Mask : ce paramètre permet de définir comment la limitation va s'appliquer sur le trafic. 3 choix sont possibles :
  1. none : la limitation s'appliquera à tout le trafic comme un ensemble unique. Dans notre cas, c'est ce que nous choisissons pour le limiter root "Upload" (on veut que l'ensemble du trafic soit limité à 1 Mbps).
  2. Source addresses : la limitation s'appliquera par adresse IP source (ou groupe d'adresses IP source, suivant le masque). Ainsi, pour effectuer une limitation par adresse IP d'un réseau, on choisira "Source addresses" et préciserons un masque /32. C'est cette valeur que nous choisirons lorsque nous configurerons la queue de notre limiter root d'Upload.
  3. Destination addresses : la limitation s'appliquera par adresse IP destination (ou groupe d'adresses IP destination, suivant le masque). Ainsi, pour effectuer une limitation par adresse IP d'un réseau de destination, on choisira "Destination addresses" et préciserons un masque /32. C'est cette valeur que nous choisirons lorsque nous configurerons la queue de notre limiter root de Download.
  • Description : champ de description, purement informatif
  • Advanced Options : permet de définir des paramètres avancés comme la latence ou le taux de perte de paquets. Ces paramètres sont utiles pour simuler des connexions Internet limitées ou de mauvaises qualités (ou pour faire une mauvaise blague à un collègue...). Nous ne l'utiliserons pas dans notre cas, mais le nom de chaque champ parle de lui-même

Exemple de résultat obtenu :

Configuration limiter root pfSense


Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration.

À ce stade, nous avons un limiter root qui va nous permettre de limiter notre trafic à une bande-passante maximale de 1 Mbps.
L'étape suivante est de créer une queue rattachée à ce limiter root et préciser que cette queue sera applicable par utilisateur. C'est-à-dire par adresse IP source avec un masque à /32.
C'est comme si virtuellement, autant de queues étaient dynamiquement créées pour chaque utilisateur, avec les mêmes caractéristiques (le même poids) et qu'elles allaient se répartir la bande-passante du limiter root auquel elles sont rattachées (1 Mbps).

En bas de la page du limiter que nous venons de créer, nous cliquons sur le bouton "+ Add new Queue".

Les éléments à configurer sont les suivants :

  • Enable : nous cochons cette case pour activer la queue que nous sommes en train de créer
  • Name : le nom de notre queue. Dans notre cas, nous l'appellerons "LAN_Upload"
  • Mask : le maque à appliquer, fonctionnant sur le même principe que pour le limiter root. Dans notre cas, nous choisissons "Source addresses" afin d'appliquer une limite sur le trafic en upload, donc quittant notre réseau local avec une adresse IP source locale. Nous souhaitons que cette limitation s'applique pour chaque utilisateur, c'est-à-dire par adresse IP ; nous choisissons donc "32" comme taille du masque.
  • Description : champ de description, purement informatif
  • Weight : le poids de la queue allant de 1 (priorité la plus faible) à 100 (priorité la plus forte). Pour une répartition équitable de la bande-passante du limiter root, on peut laisser ce champ vide. Si l'on souhaite donner davantage de bande-passante à certains utilisateurs qu'à d'autres, alors il faut jouer sur cette valeur. Dans notre cas, nous laissons le champ vide (la répartition sera équitable).
  • Advanced Options : les autres options permettent de simuler des connexions limitées ou de mauvaises qualités. Nous laissons ces champs vides.

Exemple de résultat obtenu :

Configuration du limiter queue pfSense


Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration. Puis sur "Apply Changes" pour que la nouvelle configuration soit prise en compte par pfSense.

Nos limiters (limiter root et queue) sont prêts pour le trafic sortant (upload). Il nous reste à faire la même configuration pour le trafic entrant (download).



2. Création du limiter pour le download


Nous cliquons sur le bouton "+ New Limiter". La configuration est la même que pour l'upload. Il faut simplement penser à choisir le bon débit (dans notre cas, 20 Mbps) et à changer son nom (dans notre cas, nous l'appellerons "Download").

Exemple de résultat obtenu :

Configuration du limiter root pour le download pfSense


Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration.
Comme pour la partie upload, nous allons créer une queue, pour cela, nous cliquons sur le bouton "+ Add new Queue".

La configuration est presque la même que pour la queue d'upload. La différence réside dans le choix "Destination addresses" pour l'option "Mask".
En effet, nous souhaitons ici que virtuellement des queues soient créées dynamiquement pour le trafic entrant (download) à destination d'adresses IP locales.

Exemple de résultat obtenu :

Configuration du limiter queue pour le download pfSense


Nous pensons bien-sûr à cliquer sur le bouton "Save" pour sauvegarder notre configuration. Puis sur "Apply Changes" pour que la nouvelle configuration soit prise en compte par pfSense.

Nos limiters sont créés :

liste limiters pfSense


Il ne nous reste plus qu'à adapter nos règles de filtrage pour les mettre en application.



3. Création des règles d'application


La dernière étape consiste à configurer le firewall pour lui indiquer quel trafic va passer par quel limiter.

Cette configuration se fait depuis le menu Firewall > Rules.

menu Firewall > Rules - pfSense


Choisir l'onglet LAN et éditer les règles de filtrage.
Sur chaque règle, se rendre dans les options avancées (bouton "Display Advanced") :

Display Advanced pfSense


En bas de page, pour l'option "In / Out pipe", choisir "LAN_Upload" pour la première liste déroulante et "LAN_Download" pour la seconde :

Configuration limiters firewall pfSense


Attention : il est nécessaire de faire cette manipulation sur toutes les règles de filtrage de votre interface LAN (ou de vos interfaces locales d'une façon générale) pour l'accès à Internet.

Pour être sûr d'affecter le bon limiter au bon champ In ou Out, il faut avoir en tête que ces champs représentent la vue depuis le firewall. C'est-à-dire que le champ IN correspond au trafic qui entre (incoming) sur cette interface, soit dans notre cas au trafic qui provient d'un utilisateur du LAN et va vers Internet ou un autre réseau.
C'est donc le limiter d'upload qu'il faut assigner à ce champ.

A contrario, le champ Out correspond au trafic qui sort (outgoing) par cette interface, soit dans notre cas le trafic qui provient d'Internet ou d'un autre réseau et qui est à destination d'un ordinateur du LAN.
C'est donc le limiter de download qu'il faut assigner à ce champ.


La limitation de trafic par utilisateur est en place !



4. Vérifier le bon fonctionnement


Pour vérifier que les limiters fonctionnent correctement, il faut se rendre dans Diagnostics > Limiter Info.
Chaque root limiter et ses queues sont présentés au format texte avec leurs paramètres et leurs valeurs.



Pour aller plus loin


[pfSense] Comprendre la priorisation de trafic
[pfSense] Configurer la priorisation de trafic avec CBQ
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Votre interface est parfois lente ? C'est peut-être lié à ce bug non-corrigé

icon 26/11/2019 - 4 commentaires

Vous avez peut-être déjà rencontré des problèmes de grosses lenteurs d'accès au dashboard de pfSense ?
Nous aussi !

Ces lenteurs apparaissent lorsque pfSense n'arrive plus à se connecter à Internet ou, pour être plus précis, n'arrive plus à joindre un serveur de Netgate.

Edit : ce bug est maintenant corrigé.

Nous avons cherché à comprendre le problème et à le corriger. En parallèle de ce travail, nous avons constaté que cette anomalie avait déjà été rapportée et qu'un ticket était ouvert sur le redmine de pfSense.
Nous pensions initialement que le problème serait corrigé rapidement. Mais comme ce n'est visiblement pas le cas, nous avons pensé qu'il pouvait être utile de partager la solution de contournement et d'en profiter pour présenter la méthodologie d'analyse que nous avons suivie.

Dans cet article, nous partageons la méthodologie d'analyse suivie afin de comprendre l'origine du problème rencontré et, bien-sûr, trouver la solution au problème.



1. Le problème : le tableau de bord est lent lorsque pfSense n'a plus accès à Internet


Le contexte est généralement le suivant : vous disposez d'une interface WAN active, mais non-connectée à Internet.
Les raisons à ce type de situations sont nombreuses : perte de la connexion Internet, serveurs DNS inaccessibles, règles d'Outbound NAT mal configurées, cas où pfSense est configuré en tant que firewall de cœur de réseau n'ayant pas vocation à avoir accès à Internet, etc.

Mais le problème peut également survenir alors que votre connexion Internet est parfaitement fonctionnelle.

Le problème : l'interface d'administration de pfSense semble devenir très lente uniquement sur certaines pages. Et notamment lors de l'accès au tableau de bord (c'est-à-dire la page principale, le Dashboard). La page met alors une bonne minute à se charger. Seule cette page serait concernée par ce phénomène de lenteur à l'affichage. Mais, en pratique, d'autres pages sont également concernées lorsque l'on effectue une modification (lorsque l'on fait une modification quelconque depuis la page System > General Setup, par exemple).

La version de pfSense concernée : 2.4.4

Note : il semblerait que le problème ne soit présent que si votre interface WAN est configurée avec une adresse IP fixe.

Note 2 : pour être précis, en fait le problème ne se produit pas lorsque pfSense n'a plus accès à Internet, mais lorsque pfSense n'arrive pas à joindre un serveur hébergé chez Netgate (l'éditeur du logiciel pfSense).

tl;dr : dans la section suivante, nous partageons la méthodologie d'analyse que nous avons suivie pour trouver l'origine du problème. Si vous le souhaitez, vous pouvez vous rendre directement à la dernière section "3. Solution" si vous souhaitez connaître le problème exact et la solution de contournement proposée.



2. Méthodologie d'analyse


Nous avons appliqué une méthodologie visant à cibler la source exacte du problème et avons suivi les étapes ci-dessous :

2.1. Serait-ce un widget qui n'arrive pas à se charger ?


Nous avons d'abord pensé que la source du problème était un widget présent sur la page d'accueil qui faisant une requête vers un serveur web externe qui était inaccessible (la suite nous montrera que nous avions vu juste...).
La première étape de la démarche de recherche a donc consisté à faire le tour des différents widgets présents sur la page d'accueil et à les supprimer les uns après les autres afin de voir si une amélioration était constatée.

Dashboard vide de pfSense - Provya

Difficile d'avoir un dashboard plus épuré...


=> Résultat obtenu : aucune amélioration. Même sans aucun widget sur le dashboard, le problème est toujours présent. Le problème semble donc, à première vue, ne pas venir d'un widget en particulier.


2.2. Serait-ce lié aux serveurs DNS ?


Nous avons ensuite soupçonné un problème de résolution DNS (le délai d'environ une minute avant que la page ne se charge ressemblait fortement à un délai de timeout).
Nous avions toujours dans l'idée que le problème pouvait être lié à un serveur web externe inaccessible.
Nous avons donc essayé de modifier ou de supprimer les serveur DNS renseignés sur l'interface d'administration du pfSense (menu System > General Setup). Peut-être étaient-ils à l'origine de cette lenteur.

Menu System > General Setup - gestion des DNS - pfSense - Provya

Même sans serveur DNS de configuré, le résultat est toujours le même


=> Résultat obtenu : aucune amélioration.


2.3. Désactivons l'interface WAN !


Nous avons alors essayé de désactiver l'interface WAN. Nous nous rendons pour cela dans le menu Interfaces > Wan, et nous décochons la case "Enable interface".

Désactiver l'interface WAN sous pfSense - Provya



=> Résultat obtenu : ça marche ! Il n'y a plus aucune lenteur !

Il semble donc que ce soit lié au fait que l'interface WAN soit active, mais déconnectée, ou tout du moins que le problème se produit lorsque l'interface WAN est active et n'arrive pas à joindre un serveur web externe. À noter, pour être exact, que la suite de nos tests nous a permis de constater que c'est précisément lorsque l'interface WAN est à l'état "UP" que le problème peut survenir.

À ce stade nous avons compris (au moins partiellement) quelle était la configuration à l'origine du problème. Problème qui devient donc maintenant reproductible.
En revanche, nous ne savons toujours pas quelle est la cause. Que se passe-t-il exactement ? Pourquoi le fait de perdre son accès à Internet entraîne une lenteur uniquement sur la page principale (Dashboard) ?
Dégainons notre meilleure arme pour essayer de comprendre ce qu'il se passe : faire une capture réseau et analyser !


2.4. Lançons un tcpdump sur l'interface WAN


Nous réactivons l'interface WAN et nous laçons une commande tcpdump sur celle-ci. Cette commande peut être exécutée depuis le menu Diagnostics > Packet Capture.

Nous utilisons Wireshark pour analyser nos paquets capturés.

Extrait capture tcpdump depuis wireshark - bug pfSense - Provya

Requête DNS pour l'enregistrement ews.netgate.com


Sur la capture d'écran, nous constatons qu'il y a une requête DNS pour un domaine particulier : ews.netgate.com

Pour les plus curieux, la série de requêtes ICMP visible sur la capture d'écran correspond à la supervision de sa passerelle par défaut (10.10.10.1) par pfSense (10.10.10.10).

Nous avons alors ajouté une entrée DNS statique sur pfSense afin que le domaine ews.netgate.com soit résolu par une adresse IP locale (127.0.0.1 ou 0.0.0.0) et, bingo plus aucune lenteur ! (Nous expliquons dans le dernier paragraphe comment reproduire cette solution).

À ce stade, nous avons l'élément à l'origine du problème de lenteur. Il reste à déterminer pourquoi pfSense demande à son serveur DNS de résoudre le domaine ews.netgate.com et pourquoi lorsque cette résolution n'aboutit pas ou que le serveur ews.netgate.com est injoignable, le chargement du tableau de bord est ralenti.

Bonne nouvelle, pfSense est open-source ! Nous allons donc pouvoir étudier le code source pour comprendre quelles pages font appel à ce domaine et que cherchent-elles à récupérer sur ce domaine.


2.5. Analyse du code source


Le code source de pfSense est accessible sur le site GitHub : https://github.com/pfsense/pfsense.

Une recherche sur le nom de domaine ews.netgate.com sur le dépôt pfSense nous permet de comprendre pourquoi une requête est effectuée vers ce nom de domaine :

Recherche bug pfSense sous GitHub - Provya


Lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il n'a pas été mis à jour depuis au moins 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.

Le code est ainsi fait (requête cURL en PHP) que cette requête est bloquante pour le chargement du reste de la page.

Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)



3. Solution


Edit : comme rappelé en début d'article, ce bug est maintenant corrigé.

Pour résumer, le problème est le suivant : depuis pfSense 2.4.4, lorsque l'on charge la page d'accueil (index.php), si le fichier copyright n'existe pas où qu'il a pas été mis à jour depuis plus de 24 heures, pfSense cherche à le télécharger via https://ews.negate.com/copyright.

Si lors de cette mise à jour, pfSense n'arrive pas à joindre le serveur ews.netgate.com, alors le chargement de la page est bloquée jusqu'au timeout DNS (d'environ 60 secondes) de la requête de résolution de nom.

Un rapport de bug a été rédigé. Il est consultable ici : https://redmine.pfsense.org/issues/8987. La solution n'est pas triviale. Si vous avez une idée de solution et que vous souhaitez contribuer, vous savez ce qu'il vous reste à faire... ;-)

Le nom de domaine ews.netgate.com est utilisé pour trois choses :

  • télécharger la licence applicable à pfSense
  • télécharger les informations liées au Support
  • rechercher les mises à jour disponibles

Aussi, une solution de contournement que nous proposons (nous en proposons également deux autres en fin d'article) est d'ajouter une entrée DNS pour le domaine ews.netgate.com sur le résolveur de pfSense afin qu'il pointe vers son adresse IP de localhost.

Pour cela, se rendre dans le menu Services > DNS Resolver :

Menu Services > DNS Resolver sous pfSense - Provya


Nous ajoutons une entrée de type Host overrides (en bas de page) en cliquant sur le bouton "+Add" :

Ajouter une entrée DNS (host overrides) sous pfSense - Provya


Les champs à compléter sont les suivants :

  • Host : le nom de l'hôte, sans la partie domaine. Soit, dans notre cas : ews
  • Domain : le domaine parent de l'hôte. Soit, dans notre cas : netgate.com
  • IP Address : l'adresse IP correspondante. Dans notre cas : 127.0.0.1
  • Description : une description facultative

Exemple de résultat obtenu :

Exemple de l'ajout d'une entrée DNS (host overrides) sous pfSense - Provya


Nous cliquons sur "Save", puis "Apply Changes" pour valider nos changements.

Attention : comme le fait très justement remarqué Albirew en commentaire, en procédant ainsi, nous bloquons également les recherches de mises à jour par pfSense. En effet, pfSense recherche les mises à jour en effectuant une requête vers https://ews.netgate.com/pfupdate.

La solution proposée est donc bien une solution de contournement temporaire. Ce n'est pas une solution idéale.

Deux autres solutions moins impactantes sont également possibles :

1. Modifier le code source du fichier index.php pour supprimer la recherche liée à la licence (il suffit de commenter la ligne « require_once("copyget.inc"); » (ligne 469) du fichier « /usr/local/www/index.php »).

2. Ajouter une tâche cron mettant à jour le fichier « /cf/conf/copyright » (ex : « touch /cf/conf/copyright ») exécutée toutes les 20 heures, par exemple. Merci à Albirew pour cette proposition.


Voilà, vous ne devriez plus rencontrer ce problème de lenteur lors du chargement du tableau de bord de pfSense lorsque le serveur ews.netgate.com est inaccessible !



Pour aller plus loin


[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)

icon 24/11/2019 - 72 commentaires

English version: [pfSense] Multiple WAN Connections

Nous allons voir dans cet article comment configurer pfSense pour disposer de deux connexions Internet (ou plus encore) utilisables en loadbalancing ou en fail-over.

Ces configurations permettent d'accroître le débit disponible pour l'accès Internet ou d'assurer une continuité de service en cas de panne du lien principal, par exemple.



Avant de commencer, les questions à se poser...


Combien peut-on avoir de connexions Internet en simultané ?


Il n'y a pas de limites théoriques.
Nous avons de très nombreux exemples d'installations disposant de 2, 3 ou 4 connexions Internet.
Le déploiement le plus important que nous avons rencontré est de 12 connexions Internet simultanées.


Une haute-disponibilité peut-elle être assurée via deux connexions Internet du même type chez le même opérateur


Généralement, la réponse est plutôt non. Il faut privilégier des connexions Internet chez des opérateurs différents. En effet, lorsqu'un opérateurs rencontre une panne (sur son DSLAM, par exemple), la panne est présente sur tous ses liens arrivant au même endroit.
Disposer de plusieurs connexions chez le même opérateur peut être une bonne approche si l'objectif recherché est d'accroître son débit.


Vaut-il mieux une connexion Internet disposant d'un bon débit ou de plusieurs connexions Internet disposant d'un débit moindre


La réponse va dépendre du prix et de la garantie de temps de rétablissement dont vous disposez sur chaque lien. Ce sont les deux principaux critères de décision.



Principe de fonctionnement


Dans notre article nous prendrons l'exemple suivant : une entreprise disposant de 2 connexions ADSL de débit similaire, sur lesquels nous souhaitons mettre en place de la répartition de charge (load-balancing).
Le schéma réseau serait le suivant :

schéma réseau dual-wan


La configuration de la haute-disponibilité ou du failover des liens Internet se fait au niveau de la gestion des passerelles et des groupes de passerelles.
Nous allons donc configurer pfSense pour qu'il utilise telle ou telle passerelle (et donc telle ou telle connexion Internet) en fonction de priorité que nous définirons.
Pour cela, nous créerons un groupe de passerelles dans lequel nous définirons quelles connexions Internet utiliser, avec quelles priorités et le cas échéant selon quelles règles de bascule de l'une à l'autre.

Il faut avoir en tête que la configuration du routage sur pfSense se fait de 3 façons, de la priorité la plus forte à la moins forte :
  1. Forcer la gateway dans les règles de firewall : permet de forcer le routage pour une règle de firewall précise (cela se configure dans les options avancées des règles de firewall) - dans cette configuration, on peut choisir une passerelle ou un groupe de passerelles.
  2. Définir une route : permet de forcer le routage pour une adresse IP ou une plage d'adresses IP destination (cela se configure dans le menu System > Routing) - dans cette configuration, on peut choisir une passerelle, mais pas un groupe de passerelles.
  3. Définir une passerelle par défaut : par défaut, tous les flux sortants utiliseront cette passerelle (plus exactement, tous les flux à destination d'un réseau inconnu de pfSense) - dans cette configuration, on peut choisir une passerelle, mais pas un groupe de passerelles.



Les pré-requis [1/2] : disposer d'interfaces WAN fonctionnelles


Dans notre exemple, le premier lien Internet est connecté sur l'interface "WAN", le second lien Internet est connecté sur l'interface "WAN2".
Exemple de configuration obtenue :

Interfaces WAN et WAN2 pfSense


La configuration des interfaces WAN et WAN2 n'entrent pas dans le périmètre de cet article. Que ces interfaces soient configurées en adresses IP statiques ou dynamiques (DHCP) n'a pas d'importance.
Ce qui est important est que vous disposiez de 2 interfaces configurées pour vos connexions Internet.



Les pré-requis [2/2] : disposer d'un serveur DNS sur chaque passerelle WAN


En cas de perte d'un des liens Internet, il est important que les requêtes DNS continuent de fonctionner. Pour cela, il faut définir au moins un serveur DNS par gateway WAN.
Cette configuration se fait dans System > General Setup.

menu System > General Setup


La configuration se fait dans la partie "DNS Server Settings". Par exemple, en utilisant les DNS de Google :

Configuration des serveurs DNS pfSense


Nous utilisons les serveurs DNS de Google à titre d'exemple. Il est à noter que si vous ne souhaitez pas utiliser les serveurs DNS de votre fournisseur d'accès, alors il est préférable d'utiliser d'autres serveurs DNS que ceux de Google, comme ceux de French Data Network (80.67.169.12 et 80.67.169.40) ou de Quad9 (9.9.9.9).

Les pré-requis étant levés, passons maintenant à la configuration.



1. Créer un groupe de passerelles


Nous allons créer un groupe de passerelles comprenant la passerelle de l'interface WAN et la passerelle de l'interface WAN2.

La création s'effectue depuis le menu System > Routing.

Création d'un groupe de gateway


Se rendre dans l'onglet Gateway Groups.
Puis cliquer sur le bouton "+ Add".

Les éléments à configurer sont les suivants :

  • Group Name : le nom du groupe de passerelles. Dans notre exemple, nous choisissons "Groupe_Gateway" (attention, pas d'espace, tiret ou de caractères spéciaux dans le nom).
  • Gateway Priority : pour chaque passerelle, nous donnons une priorité d'utilisation. La priorité la plus faible l'emporte toujours. C'est-à-dire que si pour la passerelle de l'interface WAN, vous choisissez une priorité 1 et pour la passerelle de l'interface WAN2 une priorité 2, alors le trafic s'écoulera exclusivement par la passerelle de l'interface WAN. Le trafic s'écoulera via la passerelle de l'interface WAN2 si et seulement si la passerelle de l'interface WAN est hors-service.
Ainsi, si vous souhaitez faire de la répartition de bande-passante entre vos 2 connexions Internet, il faut choisir le même niveau de priorité.
Si vous souhaitez configurer une connexion Internet en secours d'une principale, alors il faut jouer sur le niveau de priorité.
pfSense gère jusqu'à 5 niveaux de priorités allant de "Tier 1" (priorité la plus forte) à "Tier 5" (priorité la plus faible).
Dans notre cas, nous souhaitons faire de la répartition de charge, nous choisissons donc "Tier 1" pour le WAN et pour le WAN2.
  • Virtual IP : sur chaque interface, vous pouvez choisir l'adresse IP avec laquelle pfSense va émettre ses paquets. Soit c'est l'adresse IP de l'interface, soit c'est une adresse IP virtuelle précédemment créée. Ce peut être utile si vous avez 2 pfSense redondants, par exemple (cf. notre article [pfSense] Configurer un cluster de 2 pfSense redondants (failover)).
  • Trigger Level : permet de définir le déclencheur qui permettra à pfSense de choisir quand basculer vers un lien disposant d'une priorité plus faible. Il existe 4 valeurs possibles :
  1. Member down : lorsqu'une passerelle est considérée comme non-joignable (c'est-à-dire lorsque l'adresse IP de monitoring associée n'est plus joignable par un ping)
  2. Packet Loss : lorsque le taux de perte de paquets maximum configuré pour cette passerelle est atteint
  3. High Latency : lorsque la latence maximale définie pour cette passerelle est atteinte
  4. Packet Loss or High Latency : lorsque le taux de perte de paquets maximum ou la latence maximale est atteint
Ces paramètres (taux de perte de paquets maximum, latence maximale, etc.) se définissent dans la configuration de la passerelle.
Dans notre cas, nous choisissons "Member down".
  • Description : champ optionnel purement cosmétique

Exemple de résultat obtenu :

Exemple configuration multi-WAN pfSense


Nous sauvegardons et cliquons ensuite sur "Apply changes" pour appliquer la configuration.
À ce stade, nous avons créé un groupe de passerelles qui permet de répartir équitablement le trafic Internet sur nos deux connexions. Il nous reste à indiquer à pfSense quel trafic doit utiliser ce groupe de passerelles.



2. Mettre en service le dual-WAN


La (presque) dernière étape consiste à configurer le firewall pour lui indiquer par quelle passerelle (ou plutôt quel groupe de passerelles dans notre cas) faire passer le trafic. Comme vu en début d'article, sans précision de notre part, le firewall utilisera la passerelle par défaut. Il est évidemment possible de définir soi-même quelle est la passerelle par défaut. En revanche, il n'est pas possible de définir qu'il faut utiliser un groupe de passerelles par défaut.

Il nous faut donc préciser dans chacune des règles du firewall que le trafic doit s'écouler par notre passerelle par défaut.

Cette configuration se fait depuis le menu Firewall > Rules.
menu Firewall > Rules


Choisir l'onglet LAN et éditer les règles de filtrage.
Sur chaque règle, se rendre dans les options avancées (bouton "Display Advanced") :

Display Advanced pfSense


En bas de page, préciser le groupe de passerelles dans le champ Gateway :

Préciser la gateway dans les règles de filtrage


Attention : il est nécessaire de faire cette manipulation sur toutes les règles de filtrage de votre interface LAN (ou de vos interfaces locales d'une façon générale) pour l'accès à Internet.

Exemple de résultat obtenu :

Configuration gateway firewall pfSense


Félicitations, votre dual-wan est en place !



3. Configuration des services spécifiques


Configuration du service OpenVPN server



Si un serveur OpenVPN est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du service (normalement "WAN") pour la remplacer par le groupe de passerelle (Groupe_Gateway).
Cette modification s'opère dans "OpenVPN" > "Servers".

Davantage d'informations sur la configuration du service OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.


Configuration du service VPN IPsec


Si un tunnel IPsec est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du VPN IPsec (normalement "WAN") pour la remplacer par le groupe de passerelles (Groupe_Gateway).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.



4. Load-balancing avancé


Il est possible de définir des poids, ou des priorités, à chaque passerelle de sorte que le load-balancing ne soit pas fait obligatoirement suivant un ratio équitable (de type 50%-50% pour du dual-wan ou 33%-33%-33% dans le cas de trois connexions Internet).

Ces poids se définissent de 1 à 30. Par défaut, le poids de chaque passerelle est de 1.
Le mode de fonctionnement des poids est le suivant :
  • s'il y a 2 passerelles et qu'elles disposent chacune d'un poids de 1, alors la répartition de bande passante sera de 1/2 pour chacune, soit 50%.
  • si l'une dispose d'un poids de 1 et la seconde d'un poids de 2, alors la première prendra 1/(1+2) = 33% du trafic et la seconde 2/(1+2) = 67% du trafic.
  • si l'une dispose d'un poids de 5 et l'autre d'un poids de 12, alors la première prendre 5/(5+12) = 30% du trafic et la seconde 12/(5+12) = 70% du trafic.

Il est ainsi donc possible de définir des rapports de répartition du trafic sortant jusqu'à un rapport de 1 à 30.

Cette personnalisation s'opère dans la configuration de la passerelle depuis le menu System > Routing.
Il faut modifier la passerelle (icône en forme de crayon) et se rendre dans les options avancées (Display Advanced), puis modifier le champ "Weight".

Cette fonctionnalité est très pratique si l'on veut coupler 2 connexions ne disposant du même débit (une connexion ADSL et une connexions SDSL, par exemple).



5. Vérifier le bon fonctionnement


Une manière simple de vérifier que le trafic passe bien maintenant par les 2 connexions Internet est de se rendre dans Status > Traffic Graph.
En sélectionnant les interfaces WAN et WAN2, vous devriez voir le trafic s'écouler via les 2 liens.

Ensuite, pour tester le bon fonctionnement de la haute-disponibilité de vos liens, plusieurs tests peuvent être réalisés. En voici quelques exemples :
  • débrancher et rebrancher successivement le câble réseau de l'interface WAN puis WAN2
  • télécharger un fichier ou lancer des requêtes ping lorsque que vous ferez la manipulation précédente afin de constater la bonne bascule du trafic sur un lien Internet puis l'autre

À ce stade, pensez à faire une sauvegarde de la configuration de votre pfSense ("Diagnostics" > "Backup & Restore") ;-)



Pour aller plus loin


[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer ses VLAN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comment bien choisir sa carte Wi-Fi

icon 22/11/2019 - Aucun commentaire

pfSense supporte depuis de nombreuses années des fonctionnalités de gestion du Wi-Fi lui permettant d'agir comme un point d'accès sans-fil ou de se connecter à un point d'accès existant.

Pour pouvoir profiter pleinement de toutes les fonctionnalités offertes par pfSense dans la gestion du Wi-Fi, il est important de bien choisir sa carte Wi-Fi afin qu'elle soit pleinement compatible.

Dans cet article, nous faisons un tour d'horizon des caractéristiques supportées par pfSense pour la gestion des réseaux sans-fil et détaillerons comment bien choisir sa carte Wi-Fi et où l'acheter au meilleur prix !

Attention : plusieurs utilisateurs rapportent des instabilités du Wi-Fi depuis la dernière version de pfSense (2.4.5-RELEASE-p1). Aussi, pour le moment, nous ne recommandons pas d'utiliser pfSense comme point d'accès Wifi pour les nouveaux déploiements ou en environnement professionnel.



[Introduction] L'ensemble de normes 802.11


Le fonctionnement des réseaux Wi-Fi est normalisé à travers l'ensemble de normes 802.11.

Cet ensemble de normes comporte plusieurs protocoles, dont les principaux sont les suivants :
  • 802.11a : offre un débit jusqu'à 54 Mbps sur la bande des fréquences des 5 GHz
  • 802.11b : offre un débit jusqu'à 11 Mbps sur la bande des fréquences des 2,4 GHz
  • 802.11g : offre un débit jusqu'à 54 Mbps sur la bande des fréquences des 2,4 GHz
  • 802.11n : offre un débit théorique jusqu'à 450 Mbps par multiplexage "MIMO" sur les bandes des fréquences 2,4 et 5 GHz
  • 802.11 ac : offre un débit théorique en Gbps sur la bande des fréquences des 5 GHz

Pour en savoir plus sur le fonctionnement des réseaux sans-fil et de ces normes, nous vous recommandons la lecture de l'article Wi-Fi n, ac, ad, ax… : tout savoir sur le réseau sans fil et ses débits du site FrAndroid.

Il est important de savoir qu'il existe plusieurs protocoles et d'identifier quels protocoles sont supportés par pfSense ou par sa carte Wi-Fi afin d'être certain de faire le bon choix en fonction de ses besoins.



Support du 802.11b, 802.11g, 802.11n


Les versions actuelles de pfSense supportent ces 3 protocoles sur une variété de matériels.

Il est difficile de dresser la liste exhaustive des matériels supportés. D'autant que certains matériels peuvent fonctionner, mais à des débits très faibles...
C'est pourquoi, avant de choisir une carte Wi-Fi, il vaut mieux s'assurer qu'elle soit effectivement annoncée comme étant compatible pfSense par le fabricant ou le revendeur (qui l'aura donc préalablement testée).



Support du 802.11ac


C'est très simple, il n'y a actuellement aucun support du 802.11ac sous pfSense.



Fréquences radio et dual-band


Certaines cartes Wi-Fi supportent les fréquences sur la bande des 2,4 Ghz et sur la bande des 5 GHz. Cependant, actuellement il n'y a aucune carte qui puisse fonctionner sous pfSense en opérant à la fois dans la bande des fréquences des 2,4 GHz et des 5 GHz.

L'idée d'utiliser 2 cartes différentes dans le même boîtier (afin d'en configurer une qui fonctionnerait sur la bande des 2,4 GHz et la seconde sur la bande des 5 GHz) est à proscrire car cela créerait inévitablement des interférences radio.

Aussi, s'il est nécessaire de disposer d'un point d'accès supportant ce fonctionnement dual-band (pour des raisons de compatibilité avec des terminaux spécifiques, notamment), alors nous recommandons clairement l'utilisation d'un point d'accès externe dédié.



Point d'accès multi-SSID


Une fonctionnalité très utile est la capacité à pouvoir diffuser plusieurs SSID (plusieurs réseaux Wi-Fi) indépendants dans leur configuration et dans leur mode de fonctionnement (l'un avec authentification par clé WPA/WPA2, l'autre avec une authentification par portail captif, ...) depuis la même carte Wi-Fi.

Un exemple concret d'utilisation serait que notre pfSense diffuse un réseau Wi-Fi pour les collaborateurs de l'entreprise et en parallèle diffuse également un second réseau Wi-Fi "invité" (sur lequel on pourra d'ailleurs configurer un portail captif depuis pfSense) pour les personnes externes à l'entreprise de passage dans les locaux.

pfSense supporte pleinement cette fonctionnalité. Cependant, toutes les cartes Wi-Fi ne peuvent pas fonctionner avec ce mode... Si cette fonctionnalité vous intéresse, il est donc nécessaire que la carte Wi-Fi que vous choisirez la supporte.


Nous avons fait le tour des éléments à prendre en considération dans le choix de sa carte Wi-Fi.



Est-ce une bonne idée de faire porter par pfSense le point d'accès Wi-Fi de son réseau ?


C'est une question fréquente. Dans la même logique, une question qui revient souvent est de se demander s'il est pertinent de faire supporter par pfSense plusieurs fonctionnalités (firewall, serveur DHCP, point d'accès WiFi, ...).

Nous profitons de cet article pour y apporter notre réponse.
Cette réponse va dépendre principalement du contexte et de la taille de la structure concernée. De notre point de vue, il faut distinguer 2 cas :


1. Cas d'un usage SOHO / TPE / PME


Dans le cas d'un usage personnel ou pour une petite structure (de l'ordre de moins d'une vingtaine d'utilisateurs), il apparaît comme tout à fait pertinent de confier à pfSense la gestion de son point d'accès sans-fil.

La totalité des fonctionnalités attendues est normalement pleinement couverte par pfSense et cela permet de bénéficier d'un usage de pfSense de type "BOX professionnelle".

On peut alors voir pfSense comme une BOX s'occupant de délivrer l'ensemble des services réseaux nécessaires : routeur, filtrage firewall, serveur DHCP, serveur ou relais DNS, point d'accès sans-fil, serveur VPN, proxy, portail captif, etc.

C'est un choix rationnel qui permet de centraliser et d'administrer l'ensemble de ces fonctionnalités réseau à travers une seule interface et sur un produit open-source dans lequel on a pleinement confiance.

C'est également un choix économiquement intéressant car il n'y a alors qu'un seul matériel à acquérir (la "BOX" pour pfSense).

Enfin, sachez qu'il existe de très nombreux retours d'expérience probants quant à l'utilisation de pfSense en point d'accès quels que soient les équipements se connectant dessus (Mac, iPhone, Android, Windows, Xbox, ...).


2. Cas d'un usage grosse entreprise type ETI / Grand Compte


Dans les plus gros environnements de production, cela a beaucoup moins de sens de vouloir faire porter par pfSense le rôle de point d'accès sans-fil.
La fonctionnalité première de pfSense est de garantir la sécurité des flux sur le réseau de l'entreprise.

Sans parler des problématiques de sécurité du fait de vouloir faire porter trop de fonctionnalités par un seul équipement (défense en profondeur, notamment), il y a de nombreux cas d'utilisation où pfSense ne sera pas le plus adapté.
En particulier pour les déploiements répondant à des exigences telles que le support du 802.11ac, la possibilité de fonctionner en simultanée sur la bande des 2,4 et des 5 GHz ou les réseaux sans-fil maillés, etc.
Il faut également réfléchir à la localisation du point d'accès car bien souvent le firewall n'est pas placé au meilleur endroit pour diffuser un réseau sans-fil.

Enfin, les besoins pour ce type d'environnement sont très différents et pfSense n'est pas une solution adaptée pour y répondre : gestion des réseaux sans-fil étendu, cartographie, ... sont autant de fonctionnalités que n'offre pas pfSense pour la gestion d'un réseau Wi-Fi de grande envergure.

Si vous êtes dans ce cas d'usage et que vous avez un besoin Wi-Fi, nous recommandons l'utilisation des solution d'Ubiquiti Networks ou d'autres solutions spécialisées.



On résume : comment choisir sa carte Wi-Fi


Si vous souhaitez utiliser pfSense en point d'accès Wi-Fi ou en client Wi-Fi dans le cadre d'un usage particulier ou petite entreprise, c'est tout à fait possible.

Les éléments à prendre en compte sont :
  • s'assurer que la carte Wi-Fi soit compatible pfSense et supporte les protocoles 802.11b/g/n
  • s'assurer que la carte Wi-Fi puisse fonctionner sous pfSense aussi bien en mode client qu'en mode point d'accès
  • s'assurer que la carte Wi-Fi supporte la possibilité de diffuser plusieurs réseaux Wi-Fi (plusieurs SSID) en parallèle
  • s'assurer du débit offert par la carte Wi-Fi en fonctionnant sous pfSense


Il faut avoir conscience des limitations suivantes :
  • pfSense ne supporte par le protocole 802.11ac
  • aucune carte Wi-Fi ne peut actuellement fonctionner sous pfSense en diffusant à la fois dans la bande des 2,4 et des 5 GHz
  • pfSense n'est clairement pas adapté pour servir de point d'accès Wi-Fi dans le cadre d'un réseau sans-fil d'envergure


D'une façon générale, nous recommandons uniquement les cartes Atheros. Et uniquement elles.
Les appareils sans-fil les plus couramment utilisés par les développeurs et les utilisateurs de FreeBSD ou pfSense sont ceux qui utilisent des pièces fabriquées par Atheros.



Où acheter sa carte Wi-Fi ?


Netgate propose sur sa boutique en ligne la carte WLE200NX (chipset Atheros AR9280) : https://store.netgate.com/WLE200NX-80211nabg-miniPCIe-Card-P1763.aspx. Cette carte répond normalement à tous les pré-requis vu précédemment.

Nous proposons sur notre boutique en ligne la carte Atheros AR9287. Cette carte répond à tous les pré-requis vu précédemment. Elle est garantie 3 ans.

Il existe, bien évidemment, beaucoup d'autres endroits ailleurs sur Internet où acheter une carte Wi-Fi. Nous vous recommandons de vous assurer que la carte que vous choisirez dispose bien d'un chipset Atheros, qu'elle supporte les fonctionnalités détaillées dans cet article et que le revendeur communique les débits attendus en fonctionnement sous pfSense.



Pour aller plus loin


[pfSense] Bien choisir et dimensionner son firewall
[pfSense] Configurer son point d'accès Wi-Fi

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfsense] NAT / filtrage - Comprendre l'ordre des traitements appliqués par pfSense

icon 19/11/2019 - 13 commentaires

Comprendre l'ordre dans lequel les règles de NAT et de filtrage sont appliquées est important lorsque l'on configure son firewall.

Dans cet article nous détaillons l'ordre dans lequel pfSense applique ses règles de filtrage, de translation de port et de NAT et l'impact que cela a sur l'écriture de nos règles.



1. L'ordre de traitement - schéma global


Un bon schéma étant souvent plus parlant qu'un long texte, l'ordre de traitement des paquets réseaux par pfSense peut se résumer par le schéma suivant :

Schéma de traitement NAT et filtrage par pfSense - Provya


Ce schéma de fonctionnement présente le cheminement suivi pour le trafic sortant (quittant le réseau local à destination d'Internet) et pour le trafic entrant (depuis Internet vers le réseau local ou une DMZ). Le cheminement est exactement le même dans les deux sens.

Pour chacune des étapes, si aucune règle n'existe, alors celle-ci sera simplement ignorée et pfSense passera à la suivante.

Prenons le cas d'un paquet réseau quittant le LAN à destination d'Internet. En suivant les numéros présents sur notre schéma, l'ordre de traitement détaillé est le suivant :

  1. tcpdump : réalisé sur l'interface LAN (accessible via l'outil "Packet Capture" du menu "Diagnostics" de pfSense). Lorsque la capture est effectuée sur l'interface LAN (pour un paquet quittant le LAN à destination d'Internet), aucun traitement n'a encore été effectué par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet "brut" tel qu'il est émis par l'ordinateur. Le détail du fonctionnement de l'outil Packet Capture fera l'objet d'un prochain article.
  2. Port forward ou 1:1 NAT configurés sur l'interface LAN. On configure rarement des règles de redirection de ports (port forward) ou de NAT 1 pour 1 (1:1 NAT) sur l'interface LAN, mais nous rencontrerons des règles de NAT équivalentes lorsque nous utilisons un proxy ou des redirecteurs DNS. Dans ces cas-là, on parle également de "DNAT" pour Destination NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP de destination.
  3. Règles de filtrage configurées pour l'interface LAN. Les règles de filtrage sont appliquées dans l'ordre suivant : règles de floating, règles de groupe d'interfaces, puis finalement les règles de l'interface elle-même.
  4. 1:1 NAT ou règles d'Outbound NAT configurés sur l'interface WAN. Dans ce cas-là, on parle de "SNAT" pour Source NAT ; c'est-à-dire des règles de NAT qui s'appliquent par rapport à l'adresse IP source. C'est à cette étape que le paquet réseau prend comme adresse IP source l'adresse IP de l'interface WAN de pfSense.
  5. Règles de filtrage de type floating dans le sens "out" pour l'interface WAN. C'est un cas très spécifique. Pour un usage de base, c'est rarement utilisé. Ces règles de floating peuvent être très utiles lorsque l'on souhaite configurer de la priorisation de trafic sur un environnement multi-VLAN. Il faut garder en tête qu'à cette étape, le NAT sortant (Outbound NAT) a déjà été appliqué et que les adresses IP source des paquets ne sont donc plus les adresses IP privées du LAN, mais l'adresse IP de l'interface WAN (ou celle qui a été configurée dans les règles d'Outbound NAT).
  6. tcpdump : réalisé sur l'interface WAN. À ce stade, tous les traitements ont été effectués par pfSense (NAT, filtrage, routage, etc.). Nous capturons donc le paquet tel qu'il est transmis vers Internet (ou vers le routeur de l'opérateur, par exemple)

L'outil tcpdump est toujours le premier et le dernier à voir le trafic, en fonction de l'interface sur laquelle il est effectué et de la direction du trafic.
Ainsi, dans le cas d'un trafic du LAN vers le WAN, un tcpdump exécuté sur l'interface LAN verra les paquets réseaux tel qu'ils sont émis par l'ordinateur
Un tcpdump exécuté sur l'interface WAN verra les paquets modifiés par pfSense tel qu'ils sont transmis en sortie de pfSense.
Il s'agit donc d'un outil de diagnostique très pratique dans le suivi de l'acheminement et du traitement des paquets réseaux.

Nous avons pris dans notre exemple le cas d'une architecture simple avec une interface LAN et une interface WAN. Le principe de fonctionnement est exactement le même sur une architecture disposant d'un plus grand nombre d'interfaces réseaux. Les étapes suivies seront toujours les mêmes.



2. Impact sur la configuration de ses règles


Ainsi, pour une interface donnée, les règles de NAT s'appliquent toujours avant les règles de filtrage. C'est la raison pour laquelle il faut adapter ses règles de filtrage avec les bonnes adresses IP sources/destinations.

Prenons un exemple : nous souhaitons rediriger le trafic arrivant sur le port 80 de l'adresse IP publique de notre firewall vers le port 80 d'un serveur local. Le schéma réseau ressemble à celui-ci :

Schéma réseau de redirection d'un port entrant sous pfSense - Provya


Dans cet exemple, nous allons créer une règle de redirection de port (port forward) depuis le menu Firewall > NAT, puis onglet Port Forward (onglet par défaut) :

Menu Firewall > NAT - Port Forward - pfSense - Provya


Nous cliquons sur le bouton "Add" ; les champs à compléter sont les suivants :

  • Disabled : permet de désactiver la règle sans la supprimer. Nous laissons cette case décochée.
  • No RDR (NOT) : permet de désactiver la redirection pour le trafic correspondant à cette règle. Cette option sera très peu utilisée dans la pratique. On préférera filtrer/affiner nos règles de redirection via des règles de filtrage.
  • Interface : l'interface d'arrivée des paquets. Dans notre exemple, il s'agit de l'interface WAN.
  • Protocol : le protocole concerné. Dans notre exemple, nous choisissons TCP.
  • Source : il est rarement nécessaire de préciser la source sur une redirection de port pour du trafic entrant. Nous laissons ces champs vides.
  • Destination : l'adresse IP de destination sur laquelle le trafic externe arrive. Soit, dans notre cas, l'adresse IP de notre WAN. Nous choisissons donc "WAN Address".
  • Destination port range : le port réseau de destination. Dans notre cas, nous souhaitons rediriger le trafic arrivant sur le port 80. Nous pouvons ainsi choisir "HTTP" dans la liste déroulante ou choisir "Other" et indiquer 80 dans le champ Custom.
  • Redirect target IP : il s'agit de l'adresse IP privée vers laquelle nous souhaitons rediriger le trafic. Dans notre exemple : 192.168.1.10.
  • Redirect target port : le port d'écoute de la machine locale. Il s'agit généralement du même port que celui indiqué précédemment. Dans notre cas "HTTP".
  • Description : un champs purement informatif.
  • No XMLRPC Sync : cocher cette case pour ne pas synchroniser cette règle vers les autres membres CARP.
  • NAT reflection : il s'agit d'un mode avancé permettant à un client interne d'accéder à une ressource interne en passant par son adresse IP externe. Notre exemple ne porte pas sur cet usage, nous laissons la valeur par défaut, "Use system default", ce qui revient à choisir "Disable".
  • Filter rule association : cette option permet de laisser pfSense générer la règle de filtrage nécessaire pour le fonctionnement de notre redirection de port. Pour un utilisateur avancé, nous recommandons de choisir "None" et de configurer par soi-même la règle de filtrage afin d'être certains de la positionner là où on le souhaite parmi nos autres règles et de pouvoir la personnaliser si nécessaire. Par simplicité, pour notre exemple, nous laissons le choix par défaut "Add associated filter rule".

Exemple de résultat obtenu :

Exemple de configuration d'une redirection de port sous pfSense - Provya


Sur notre interface WAN, une règle a été créée (si nous avons choisi "None" pour l'option Filter rule association, alors il faut créer soi-même cette règle) :

Exemple d'une règle de filtrage pour une redirection de port sous pfSense - Provya


Nous constatons que l'adresse IP Destination de notre règle de filtrage est l'adresse IP privée (ici, 192.168.1.10). La raison est que le NAT est appliqué avant le filtrage. Ainsi, l'adresse IP de destination du paquet réseau a été modifiée par le firewall et correspond à ce stade à l'adresse IP privée de destination. Le filtrage doit donc bien porter sur l'adresse IP privée de destination.

Il nous reste à penser à cliquer sur "Apply Changes" aussi bien sur la page de gestion des règles de filtrage que sur celle de gestion des règles de NAT.
La redirection de port est en place.

Voila, vous savez maintenant parfaitement l'ordre que suit pfSense pour le traitement des paquets réseaux (NAT, filtrage, routage, etc.).
Nous verrons dans un prochain article la puissante de l'outil "packet capture" intégré à pfSense et la méthodologie d'utilisation que nous proposons pour faire ses analyses réseau.



Pour aller plus loin


[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Tout comprendre aux alias

icon 05/11/2019 - Aucun commentaire

Sous pfSense, et sous la plupart des firewall modernes, il est possible de définir des alias. Ces alias nous seront utiles dans l'implémentation de nos règles de filtrage, de NAT, de redirection de ports, etc.
C'est un outil pratique qui permet de gagner en lisibilité sur nos règles.



Qu'est-ce qu'un alias ?


Sous pfSense, un alias permet de définir un groupe de ports réseaux, d'hôtes ou de sous-réseaux.
Ces alias peuvent ensuite être utilisés dans les règles de filtrage, les règles de redirection de ports, les règles de NAT, etc. Utiliser des alias est une bonne pratique pour disposer de règles claires, courtes, simples et lisibles sur notre firewall.

Il est à noter que certains firewall obligent en la création d'alias pour l'écriture des règles de filtrage (il est impossible de spécifier une adresse IP, il faut avoir préalablement créé un alias contenant cette adresse IP). pfSense n'impose pas ce mode de fonctionnement strict.



Les différents types d'alias


Les alias sont configurables depuis le menu Firewall > Aliases :

Menu Firewall > Aliases - pfSense - Provya


Il existe cinq catégories d'alias.


Host


Ce type d'alias peut contenir des adresses IP seules et des noms d'hôtes (hostname). Ces alias s'ajoutent depuis l'onglet "IP".

Exemple d'un alias de type host ou IP - pfSense - Provya


Lorsque l'on renseigne un nom de domaine, pfSense va le résoudre à intervalle régulier. Par défaut, la fréquence de mise à jour est de 5 minutes. Il est possible de modifier cette fréquence depuis le menu System > Advanced, onglet Firewall & NAT. Il faut personnaliser la valeur du champ "Aliases Hostnames Resolve Interval" :

Personnaliser la fréquence de rafraîchissement d'un alias - pfSense - Provya




Network


Ce type d'alias peut contenir des sous-réseaux en notation CIDR, des noms d'hôtes, des plages d'adresses IP ou des adresses IP seules.
Il est également possible de renseigner un intervalle d'adresses IP. Par exemple : 192.168.0.10-192.168.0.30. Il faut laisser le masque sur /32.
Cet intervalle sera traduit en autant de sous-réseaux nécessaires au format CIDR.

Par exemple, si l'on renseigne l'intervalle 10.3.0.100-10.3.0.200 :

Exemple intervalle adresses IP alias - pfSense - Provya


Une fois sauvegardé, il sera traduit par pfSense en autant de sous-réseaux :

Exemple intervalle adresses IP alias - pfSense - Provya




Port


Ce type d'alias peut contenir une liste de ports réseaux ou une plage de ports réseaux pour TCP et UDP.

Le protocole (TCP, UDP) n'est pas renseigné dans l'alias. Il faudra le préciser (TCP, UDP ou les deux) dans les règles de filtrage ou de NAT qui feront appel à cet alias.



URL


Cet alias est construit à partir du fichier fourni par l'URL indiquée. Attention, ce fichier n'est lu qu'une seule fois lors de la création de l'alias. Il n'est ensuite pas mis à jour automatiquement.
Le fichier doit être au format txt et contenir une information par ligne (une adresse IP par ligne, par exemple).

Exemple alias d'URL d'adresses IP - pfSense - Provya


Chaque URL peut pointer vers un fichier disposant de 3 000 entrées maximum.



URL Table


Cet alias est construit à partir du fichier fourni par l'URL indiquée. Cet alias est mis à jour automatiquement en retournant chercher le fichier fourni par l'URL indiquée. La fréquence de mise à jour se défini en nombre de jours.

Contrairement aux alias de type "URL", il n'y a pas de limite au nombre d'entrées pour chaque fichier (il peut en contenir plusieurs dizaines de milliers).

Techniquement, le package pfBlocker utilise ce type d'alias pour la gestion de ses listes d'adresses IP par pays, par exemple.

Exemple alias d'URL d'adresses IP table - pfSense - Provya


Sur la capture d'écran ci-dessus, l'alias est configuré pour être mis à jour tous les 3 jours.



Fonctionnalités avancées sur les alias


Imbrication d'alias


Il est possible d'imbriquer un alias dans un autre alias à condition que les deux alias soient du même type.

Par exemple, si l'on créé un alias "web_server" contenant l'adresse de notre serveur web, un alias "smtp_server" contenant l'adresse de notre serveur SMTP, il est possible de créer un troisième alias contenant les deux alias précédents :

Imbrication d'alias sous pfSense - Provya


Sur la capture d'écran ci-dessus, l'alias "all_servers" contient les deux alias "web_server" et "smtp_server".



Utilisation des noms d'hôtes dans des alias


Des noms d'hôtes peuvent être utilisés dans des alias. Chaque nom d'hôte sera résolu périodiquement par pfSense pour vérifier son adresse IP correspondante. Si un nom d'hôte dispose de plusieurs adresses IP, alors toutes les adresses IP seront ajoutées à l'alias.

Attention, cette option n'est pas efficace si nous cherchons à autoriser ou interdire l'accès à un site web en particulier (comme par exemple facebook.com). Ces gros sites web disposent bien souvent de mécanismes de répartition de charge par round-robin DNS, ce qui ne permet pas de garantir que pfSense disposera de la totalité des adresses IP associées au nom de domaine concerné.
Cette solution peut donc fonctionner pour des petits sites web, mais pas pour les plus gros.



Alias et IPv6


pfSense supporte pleinement IPv6. Il en est logiquement de même pour les alias.
Il est également possible de mixer la présence d'adresses IPv4 et IPv6 au sein d'un même alias.



Taille maximale des alias


Il n'existe pas de taille maximale théorique. Il faut simplement s'assurer de deux éléments :
1. Être sûrs que la taille des alias n'excède pas la moitié du nombre maximum d'entrées dans la table du firewall (qui est de 200 000, par défaut).
2. Disposer de suffisamment de mémoire-vive sur son firewall. Grosso-modo, en prenant de la marge, il faut compter 1K par entrée.



Utilisation des alias


Les alias peuvent s'utiliser dans les règles de filtrage et de NAT. Ils peuvent être saisis à la place d'une adresse IP ou d'un nom d'hôte.

Par exemple, dans la création de votre règle de filtrage, choisir, pour source ou destination, "Single host or alias" et renseigner le nom de l'alias :

Utilisation des alias dans les règles de filtrage sous pfSense - Provya


On peut voir sur la capture d'écran ci-dessus que pfSense propose une aide à la saisie par auto-complétion.

Une fois la règle de filtrage saisie, il est possible de visualiser le contenu de l'alias en positionnant le curseur de la souris dessus :

Visualisation des alias dans les règles de filtrage sous pfSense - Provya



Voilà ! Vous connaissez tout ce qu'il faut savoir sur la gestion des alias sous pfSense.



Pour aller plus loin


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 un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Bien choisir et dimensionner son firewall

icon 16/10/2019 - 4 commentaires

Le choix du bon matériel pour accueillir pfSense est toujours délicat. Il n'est pas évident de dimensionner correctement son firewall par rapport à son besoin, ni de choisir les bons composants lorsque l'on souhaite assembler son matériel soi-même.

Nous présentons dans cet article les éléments à prendre en considération pour le dimensionnement de son firewall, ainsi que les points de vigilance à avoir dans le choix des composants.



[Intro] Dimensionner son firewall, qu'est-ce que cela signifie ?


Avant de rentrer dans le vif du sujet, il est important de donner la définition du terme "dimensionner". Dans le choix d'un firewall, il va être important de définir les paramètres suivants :

  • Débit attendu : élément essentiel du choix du matériel. Quel débit maximal souhaitons-nous que le firewall puisse supporter ?
  • Mémoire-vive : de quelle quantité de mémoire-vive le firewall a-t-il besoin et quel est l'impact des services ou packages que j'active sur la consommation de mémoire ?
  • Processeur : comment choisir correctement son processeur pour être sûr qu'il ne soit pas le goulet d'étranglement de mon firewall ?
  • Disque-dur : quelle taille de disque-dur prévoir ? Faut-il opter pour un disque-dur SSD ?

Ces éléments sont les principales caractéristiques de dimensionnement à prendre en compte dans le choix de son firewall.



1. Quel débit ?


Le premier élément à prendre en considération est le débit souhaité. Est-ce 100 Mbps ? 1 Gbps ? 10 Gbps ? Ou davantage ?
Il faut également se poser la question de la connectique attendue : Ethernet (RJ45), Fibre Optique, WiFi, ... ?

Le débit standard actuel des réseaux modernes pour des entreprises de type TPE/PME est de 1 Gbps.
C'est un débit suffisant pour offrir de bonnes conditions de travail tout en répondant aux besoins d'évolutivité des débits des prochaines années. C'est donc le débit qu'il conviendra de retenir dans l'immense majorité des usages.
Ainsi, il nous paraît indispensable que votre firewall soit équipé de ports RJ45 Gigabits.
De plus, si votre firewall dispose de plusieurs ports réseaux 1 Gbps, il vous sera possible de faire de l'agrégation de liens afin d'accroître le débit offert (par exemple : 2x1 Gbps, 4x1 Gbps, ...).

Il est important de préciser ici que si votre firewall dispose de ports Gigabits, mais que vos switch disposent uniquement de ports Fast Ethernet (c'est-à-dire fonctionnant au maximum à 100 Mbps), alors le débit maximum que pourra offrir votre firewall sur chacune de ses interfaces connectée au switch sera de 100 Mbps.

Pour un usage intensif, de type très grande entreprise ou Centre de données (data center), il conviendra de prévoir une connectique fibre optique offrant des débits de 10 Gbps ou davantage.

Dans tous les cas, il est parfaitement inutile de voir trop large et de choisir des débits largement surdimensionnés ; cela augmentera sensiblement vos coûts d'acquisition sans aucun bénéfice à l'appui.

Dans l'article [pfSense] Comment bien choisir sa carte Wi-Fi, nous détaillons comment choisir sa carte WiFi pour pfSense afin d'être certain de faire le bon choix.

Enfin, et pour conclure sur le débit, il est important d'avoir conscience que ce n'est pas parce que votre firewall dispose de ports Gigabits que le débit maximum délivré sera d'1 Gbps sur chaque port !
En effet, si les autres composants matériels ne sont pas correctement dimensionnés (CPU trop faible, par exemple), si vous utilisez un VPN à haut niveau de chiffrement sans disposer d'accélération cryptographique ou si vous faites de l'inspection de trafic par exemple, alors le débit risque très fortement d'être ralenti.

D'une façon générale, les modules faisant de l'inspection de trafic (comme squidGuard, Snort, Suricata, ...) vont forcément légèrement ralentir le débit.
La plupart des autres modules disponibles sur pfSense ne vont pas ralentir le débit, mais vont principalement augmenter le besoin en ressource processeur ou en mémoire-vive.



2. L'impact des fonctionnalités sur le dimensionnement


Fonctionnement de base de pfSense


Pour fonctionner correctement, pfSense nécessite dans son installation par défaut de disposer de 256 à 512 Mo de mémoire-vive.

Ensuite, dans le fonctionnement de pfSense (et dans le fonctionnement de n'importe quel autre matériel de type stateful), chaque connexion est suivie dans la table d'état.
Pour chaque connexion, il y a 2 états de stockés dans la table : une pour la connexion entrante sur le firewall, l'autre pour la connexion sortante.

Un exemple simple d'une connexion est un ordinateur connecté sur le réseau local (sur le LAN) qui consulte le site web google.fr.
Attention : si l"utilisateur consulte en parallèle le site wikipedia.fr, alors il consomme une deuxième connexion, etc. Il ne faut donc pas penser qu'un ordinateur = une connexion qui sera stockée dans la table d'état. C'est potentiellement beaucoup plus.

La table d'état est stockée en mémoire-vive. Sa taille a donc un impact sur la mémoire-vive nécessaire. Il faut considérer que la consommation en mémoire-vive est la suivante :

  • 50 000 connexions = 100 000 états = ~ 100 Mo de RAM
  • 500 000 connexions = 1 000 000 états = ~ 1 Go de RAM


VPN


D'une façon générale, les VPN IPsec offrent un meilleur débit que les VPN OpenVPN.

L'impact du VPN sur le débit maximal possible va dépendre du choix du chiffrement. Si le matériel ne dispose pas d'accélération cryptographique, les débits vont très rapidement s'effondrer. En revanche, si le matériel supporte le jeu d'instruction AES (également appelé AES-NI), alors l'impact sur le débit sera extrêmement minime.

Ainsi, notre recommandation est clairement d'opter pour un processeur supportant l'AES-NI que vous utilisiez ou non la fonctionnalité VPN.


Snort/Suricata


Les modules Snort et Suricata vont avoir une consommation de mémoire-vive de l'ordre de 1 à 2 Go.
Leur impact sur le débit est très dur à quantifier et va dépendre principalement du processeur et du nombre d'instructions d'inspection de trafic qui sera configuré.


Squid


Squid utilise beaucoup le disque-dur (contrairement à pfSense qui, dans son usage par défaut, est très peu consommateur d'espace disque).
La quantité d'espace disque nécessaire va dépendre de la quantité de données que l'on souhaite conserver en cache et se paramètre dans la configuration de squid.

Pour le choix du type de disque-dur, on considère que jusqu'à environ une centaine d'utilisateurs, n'importe quel disque-dur (disposant d'une vitesse de rotation de 7 200 tour/min, qui est le standard) fera l'affaire.

Au-delà, le choix d'un disque SSD est clairement à privilégier. Si vous faites le choix d'un disque-dur SSD, il est indispensable de choisir un disque-dur SSD de qualité, autrement le nombre élevé de lecture-écriture produit par le proxy va provoquer une fin de vie rapide de votre SSD...

Concernant la mémoire-vive consommée par squid, il faut compter environ 15 Mo de mémoire-vive pour 1 Go de cache sur le disque-dur.
Soit, pour un cache de 100 Go, il faut compter 1,5 Go de mémoire-vive.



3. Bien choisir son matériel


Une fois le dimensionnement de son firewall défini, il est important de bien choisir son matériel afin qu'il soit pleinement compatible avec pfSense et pleinement évolutif.

Nos principales recommandations sont :

  • Architecture 64 bits : les architectures 32 bits ne sont officiellement plus supportées à la fin du mois d'octobre 2018. Il est indispensable de choisir une architecture 64 bits ;
  • Support de l'AES-NI : AES-NI permet une amélioration conséquente des débits offerts sur les connexions VPN. Il est indispensable de choisir un firewall équipé d'un processeur supportant la technologie AES-NI.

Si vous achetez un firewall déjà assemblé pour pfSense :

  • Acheter son matériel en France et bénéficiant d'un remplacement/échange sous 24-48h : en cas de panne de votre firewall vous vous retrouvez bloqués (plus d'accès à Internet, plus d'accès distants, plus de VPN, etc.) ; pour les installation critiques, la mise en place de pfSense en haute-disponibilité est très fortement conseillée ; pour les autres installations, il est indispensable de pouvoir obtenir un matériel de remplacement rapidement ;
  • Disposer d'une garantie matérielle d'au moins 3 ans : c'est la garantie que les composants sont tous de qualité ;
  • Éviter les plateformes type Ebay, alibaba, etc. : les délais de livraisons sont très longs, vous risquez d'avoir à régler des droits de douane et des frais de dédouanement et la garantie sera compliquée à mettre en œuvre si votre matériel tombe en panne après plusieurs mois de fonctionnement ;
  • Choisir un revendeur de confiance : il vous proposera du matériel de qualité et un service après-vente performant en cas de besoin.



Où acheter son firewall pour pfSense ?


De notre expérience, nous estimons qu'il existe aujourd'hui 2 solutions :

1/ Acquérir du matériel officiel vendu par la société Netgate (éditeur du logiciel pfSense). L'avantage est que vous bénéficiez du matériel officiel avec la garantie absolue qu'il est totalement supporté par l'éditeur. Les inconvénients principaux à nos yeux sont : les durées de garantie extrêmement courtes, le temps nécessaire pour un échange, le prix.
Boutique en ligne Netgate : https://store.netgate.com

2/ Acquérir du matériel vendu par Provya : face au besoin de disposer de matériel fiable et économique et au manque de solutions qui étaient disponibles sur le marché, nous avons décidé de façonner notre propre matériel, avec des composants de qualité et au meilleur coût. L'assemblage, le support et la garantie sont effectués par nos soins depuis la France ; tous nos matériels sont garantis 3 ans avec remplacement/échange en 24-48h, et les composants sont choisis avec soin pour fonctionner au mieux et durablement avec pfSense (support AES-NI, disque SSD de qualité, ...).
Boutique en ligne Provya : https://store.provya.fr


Vous avez maintenant toutes les cartes en main pour dimensionner correctement votre firewall pour pfSense !



Pour aller plus loin


[pfSense] Comment bien choisir sa carte Wi-Fi
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 un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Gardez son firewall toujours à l'heure avec une puce GPS

icon 15/10/2019 - Aucun commentaire

En informatique, il est important d'avoir ses équipements (ordinateurs, serveurs, routeurs, switch, etc.) qui soient toujours à l'heure. Pour cela, il est possible d'utiliser le protocole NTP et envoyer ses requêtes vers un serveur NTP public ou bien alors d'utiliser une puce GPS !

Dans cet article, nous présenterons comment installer et utiliser une clé GPS avec pfSense afin qu'il soit toujours à l'heure et l'intérêt de cette méthode par rapport à d'autres.



Être à l'heure : pourquoi ?


Tout équipement informatique dispose d'un horloge matérielle ou logicielle à laquelle il fait référence pour horodater des fichiers, des transactions, des courriers électroniques, des baux DHCP, des autorisations d'accès, etc.
Cette horloge, aussi précise soit-elle va dériver dans le temps comme toute montre ordinaire. Ceci va poser des problèmes de sécurité, notamment en terme de traçabilité et d'auditabilité. Ainsi que des problèmes de contrôles des accès.

Pour pallier ce problème, il est possible d'utiliser des serveurs de temps de référence qui seront interrogés via le protocole NTP. De nombreux serveurs NTP sont accessibles en libre accès sur Internet et il est également possible d'implémenter son propre serveur NTP.

pfSense peut parfaitement servir de serveur NTP interne pour vos équipements. Pour garder notre serveur pfSense à l'heure, il est nécessaire soit de le synchroniser avec un autre serveur NTP de référence (accessible via Internet), soit de lui ajouter une clé GPS afin qu'il se synchronise par satellite. Cette seconde solution offre généralement une meilleure précision sur le temps fourni et permet surtout d'être indépendant de tous serveurs NTP externes.

La solution GPS, généralement peu connue du grand public et des PME, est celle majoritairement adoptée par les Grands comptes et par les Datacenters.



Activer le service NTP et la clé GPS sur pfSense


La première étape consiste à activer le service NTP pour que pfSense joue le rôle de serveur NTP pour les équipements du réseau. Pour cela, nous nous rendons dans le menu Services > NTP :

Service > NTP - pfSense - Provya


Nous sommes redirigés par défaut sur l'onglet Settings. Les paramètres à configurer sont les suivants :

  • Interface : précise la ou les interfaces sur laquelle pfSense va agir en tant que serveur NTP. Dans notre exemple, nous choisissons les interfaces LAN et WIFI. Il est à noter que pour des raisons de sécurité, il ne faut pas rendre accessible par Internet le service NTP de pfSense.

  • Time Servers : la liste de serveurs NTP avec lesquels pfSense pourra se synchroniser. Après avoir installé la clé GPS, ces serveurs serviront de serveurs de secours en cas de panne ou de défaillance de la clé GPS. Dans notre cas, nous utilisons le pool de serveurs par défaut 0.pfsense.pool.ntp.org. Si vous choisissez d'autres serveurs NTP, veillez à ajouter un pool ou une liste d'au moins 4 ou 5 serveurs.

Il reste à cliquer sur le bouton "Save" en bas de page.

Exemple de résultat obtenu :

Configuration service NTP pfSense - Provya


Nous basculons sur l'onglet "Serial GPS". Les paramètres à configurer sont les suivants :

  • GPS Type : sélectionnez votre modèle de GPS s'il figure dans la liste. Dans notre cas, il n'apparaît pas, nous choisissons donc Default.

  • Serial Port : le port sur lequel le GPS est connecté. S'il s'agit d'un port série, le nom du port aura pour forme cuau (cuau0, cuau1, ...). S'il s'agit d'un port USB, le nom aura pour forme cuaU (cuaU0, cuaU1, ...). Dans notre cas, notre clé GPS étant connectée sur un port USB, nous choisissons cuaU0.

  • Fudge Time 2 : ce champ permet de préciser un offset pour notre clé GPS. Si votre GPS est branché sur un port série, il faut laisser ce champ vide. En revanche, si vous utilisez un GPS connecté sur un port USB, alors il est nécessaire de préciser un offset de 0,5 seconde afin de compenser la latence introduite par le port USB. Dans notre cas, notre clé GPS étant connectée sur un port USB, nous indiquons la valeur 0.5.

  • Flags : s'assurer que la case "Prefer this clock" soit bien cochée (par défaut).

Il reste à cliquer sur le bouton "Save" pour valider sa configuration et c'est tout ! Notre clé GPS est prête à fonctionner.

Exemple de résultat obtenu :

Configuration GPS service NTP pfSense - Provya




Vérifier le bon fonctionnement


Pour vérifier le bon fonctionnement du service NTP, se rendre dans le menu Status > NTP.

Exemple dans notre cas :

Status GPS service NTP pfSense - Provya


On peut voir que la clé GPS est le peer actif pour servir de référence de temps à pfSense.
On peut voir que le pool 0.pfsense.pool.ntp.org comporte bien plusieurs serveurs de temps joignables (4 sur la capture d'écran) prêts à prendre le relais en cas de problème avec la puce GPS.
On peut également voir la localisation (latitude et longitude) de sa clé GPS, avec un lien vers Google Maps.

Sur la capture d'écran suivante, on peut constater un problème avec la clé GPS (statut False Ticker) et qu'un serveur NTP tiers à pris le relais :

Status GPS - False Ticker service NTP pfSense - Provya


Cela arrive si votre clé GPS n'arrive pas à capter correctement le signal satellitaire ou si vous avez oublié de saisir un offset de 0,5 seconde pour un GPS connecté en USB.



Comment choisir sa clé GPS compatible pfSense


Pour le choix de sa clé GPS, il est indispensable de s'assurer que celle-ci soit compatible avec le logiciel pfSense et qu'elle dispose d'un câble suffisamment long. Ce qui n'est pas le cas de toutes les puces GPS...

Nous proposons sur notre boutique en ligne une clé GPS connectable en USB et 100% compatible avec les systèmes pfSense, FreeBSD et Linux. D'autres choix sont bien-sûr possibles. Il faut simplement s'assurer que la clé GPS choisie soit bien compatible.



Pour aller plus loin


[pfSense] Bien choisir et dimensionner son firewall
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer un cluster de 2 pfSense redondants (failover)

icon 02/10/2019 - 64 commentaires

English version: [pfSense] Configuring High Availability.

Dans cet article, nous allons voir comment configurer deux serveurs pfSense en mode cluster afin d'assurer un service en haute-disponibilité.

Il est à noter que pfSense est l'une des rares solutions open-source offrant des techniques de haute-disponibilité permettant de garantir que le firewall ne puisse pas être un point individuel de défaillance (SPOF).

Dans cet article, nous nous baserons sur l'architecture suivante pour réaliser nos configurations :

Schéma réseau pfSense redondants

pfSenseA - WAN : 172.25.46.101
pfSenseB - WAN : 172.25.46.102
@IP virtuelle - WAN : 172.25.46.100

pfSenseA - LAN : 192.168.0.11
pfSenseB - LAN : 192.168.0.12
@IP virtuelle LAN : 192.168.0.10



Principe de fonctionnement


pfSense communique sur les réseaux LAN & WAN avec ses adresses IP virtuelles ; il n'utilise jamais l'adresse IP assignée à son interface.
En cas de défaillance de pfSenseA (pfSense primaire), pfSenseB (pfSense secondaire) prend le relais sans aucune interruption de service. La bascule de pfSenseA vers pfSenseB est totalement transparente.

Afin d'assurer la réplication du serveur pfSenseA vers le serveur pfSenseB, 3 éléments doivent être configurés : CARP, pfsync et XML-RPC.


CARP


CARP (Common Address Redundancy Protocol) est un protocole permettant à plusieurs hôtes présents sur un même réseau de partager une adresse IP.

Ici, nous utilisons CARP afin de partager une adresse IP WAN et une adresse IP LAN sur nos serveurs pfSense.
C'est cette adresse IP virtuelle que pfSense va utiliser pour sa communication sur le réseau. Ainsi, en cas de défaillance du pfSense primaire (pfSenseA), le pfSense secondaire (pfSenseB) prendra le relais de manière transparente au niveau réseau (reprise de l'adresse IP virtuelle).


pfsync


pfsync est un protocole permettant de synchroniser entre deux serveurs pfSense l'état des connexions en cours (et de manière plus large entre deux serveurs exécutant le firewall Packet Filter). Ainsi, en cas de défaillance du serveur primaire, l'état des connexions en cours est maintenu sur le serveur secondaire. Il n'y a donc pas de coupure liée à la bascule des services du pfSenseA vers le pfSenseB.

Il est recommandé d'effectuer cette synchronisation sur un lien dédié entre les deux serveurs pfSense. À défaut, le lien LAN peut être utilisé.
La réplication peut se faire d'un serveur primaire vers un ou plusieurs autres serveur(s).


XML-RPC


XML-RPC est un protocole permettant la réplication de données d'un serveur vers un autre. Il est utilisé dans pfSense afin de répliquer la configuration du serveur primaire vers le serveur secondaire.
Pour garantir son bon fonctionnement, il est important qu'il utilise la même interface que celle utilisée par le protocole pfsync.



1. Configurer les adresses IP virtuelles


Afin de fonctionner, chaque serveur pfSense doit disposer d'une adresse IP sur son interface, ainsi qu'une adresse IP virtuelle qui sera partagée entre les deux serveurs pfSense. De ce fait, nous utilisons 3 adresses IP par réseau.

Pour configurer l'adresse IP virtuelle, se rendre dans "Firewall" > "Virtual IPs" :

menu Firewall Virtual IPs sous pfSense - Provya


Cliquer sur l'icône "+ Add" pour ajouter une adresse IP virtuelle.
Les éléments à configurer sont les suivants :
  • Type : ici, nous avons quatre possibilités :
  1. IP Alias
  2. CARP
  3. Proxy ARP
  4. Other
Nous choisissons "CARP". Nous ne rentrons pas ici dans le détail de l'usage de chaque option. Pour plus d'informations, nous vous invitons à lire l'article What are Virtual IP Addresses - EN.
  • Interface : l'interface sur laquelle la VIP doit être configurée. Nous configurons la première sur l'interface WAN, puis la seconde sur l'interface LAN.
  • Address(es) : l'adresse VIP et le masque du subnet de l'interface. Dans notre exemple : 172.25.46.100 et /24
  • Virtual IP Password : mot de passe permettant de sécuriser les échanges au sein du groupe d'hôtes se partageant la VIP. Ce mot de passe devra être re-saisi sur le pfSense secondaire.
  • VHID Group : Virtual Host Identifier. Un serveur peut faire parti de plusieurs groupes de VIP. Afin d'identifier chaque groupe, un ID unique lui est assigné. Nous laissons la valeur par défaut.
  • Advertising Frequency : la valeur du champ "Skew" à 0 désigne le master (pfSense primaire). Une valeur plus élevée désignera l'esclave (pfSense de secours). La valeur de "Base" correspond au timeout en seconde au bout duquel l'hôte sera considéré comme inaccessible. Nous recommandons de laisser la valeur par défaut : 1.

Exemple de résultat obtenu :

Configuration adresse IP virtuelle CARP pfSense


Nous procédons à la même configuration sur l'interface LAN.
Enfin, nous réalisons les mêmes configurations sur les interfaces WAN et LAN du serveur de secours (pfSenseB), en pensant bien à passer la valeur du champ "Skew" à 1.

Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :

menu Status > CARP (failover) - pfSense



Dans le cas présent, les deux adresses VIP créées ont bien le statut "master" sur le pfSenseA :

Statut des adresses VIP pfSense




2. Forcer l'utilisation des adresses IP virtuelles


Les adresses VIP sont déclarées, mais non-utilisées. Il reste à configurer pfSense pour qu'il utilise les adresses VIP plutôt que les adresses IP attribuées à ses interfaces logiques.
Pour cela, nous devons configurer pfSense pour qu'il utilise l'adresse VIP WAN sur le trafic sortant, l'adresse VIP LAN pour le trafic entrant et configurer les différents services pour qu'ils travaillent avec l'adresse VIP LAN comme adresse par défaut (pour les configuration OpenVPN ou DHCP, par exemple).


Configuration du NAT


Nous allons dans le menu Firewall > NAT. Dans l'onglet Outbound, nous cochons la case "Hybrid Outbound NAT rule generation. (Automatic Outbound NAT + rules below)".
Nous modifions les règles ou en ajoutons une afin que le trafic sortant utilise l'adresse VIP. Les champs à configurer sont les suivants :
  1. Disabled : cocher cette case pour désactiver la règle sans devoir la supprimer.
  2. Do not NAT : cocher cette case permet de désactiver le NAT pour le trafic correspondant à cette règle. Il est très rare de devoir cocher cette case.
  3. Interface : l'interface logique sur laquelle nous souhaitons définir notre règle de NAT. Dans notre cas, nous choisissons "WAN".
  4. Protocol : les protocoles concernés par cette règle de NAT. Nous choisissons "any"
  5. Source : le réseau source. Dans notre cas, il s'agit du réseau local, nous saisissons donc "192.168.0.0" et "/24" pour le masque.
  6. Destination : le réseau de destination. Dans notre cas, nous choisissons "any".
  7. Address : l'adresse à utiliser lors du NAT. Nous choisissons l'adresse VIP créée précédemment, soit "172.25.46.100 (VIP WAN)".
  8. Port : nous laissons ce champ vide.
  9. No XMLRPC Sync : cocher cette case pour ne pas copier la règle sur le pfSense secondaire. Nous laissons cette case non-cochée.
  10. Description : un champ informatif

Exemple de résultat obtenu :

Configuration règle de NAT sortant


Cette configuration n'est à faire que sur le pfSense primaire. La configuration sera dupliquée automatiquement sur le pfSense secondaire.


Configuration du service DHCP


Si pfSense fait office de serveur DHCP, nous allons dans le menu "Services" > "DHCP Server". Nous modifions le champ "Gateway" pour y préciser l'adresse VIP (192.168.0.10). Autrement, le serveur DHCP de pfSense va continuer à indiquer aux clients du service DHCP l'adresse IP de l'interface LAN du pfSense.
Nous pouvons également compléter le champ "Failover peer IP" en renseignant l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12). Cette configuration optionnelle permet de partager les leases DHCP entre le pfSense primaire et le pfSense secondaire.
Attention, si ce champ est renseigner, il est nécessaire de modifier la valeur du "skew" du pfSense secondaire pour le passer à un nombre supérieur à 20.

Davantage d'informations sur la configuration du service DHCP : [pfSense] Configurer son serveur DHCP.


Configuration du service OpenVPN server


Si un serveur OpenVPN est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du service (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "Servers".

Davantage d'informations sur la configuration du service OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.


Configuration du service VPN IPsec


Si un tunnel IPsec est configuré sur le pfSense, il est nécessaire de modifier l'interface d'écoute du VPN IPsec (normalement "WAN") pour la remplacer par l'adresse VIP (172.25.46.100).
Cette modification s'opère dans "VPN" > "IPsec". La modification s'effectue sur la phase 1.

Davantage d'informations sur la configuration du service VPN IPsec : [pfSense] Configurer un VPN IPsec site à site.



3. Configurer la haute-disponibilité


Il nous reste à configurer la haute-disponibilité. Pour cela, se rendre dans "System" > "High Avail. Sync" :

menu System > High Avail. Sync - pfSense


Depuis cette page, il y a 2 éléments à configurer : la partie pfsync (pour la synchronisation d'état) et XMLRPC Sync (pour la synchronisation de la configuration).


State Synchronization Settings (pfsync)


Les éléments à configurer sont les suivants :
  • Synchronize States : cocher cette case pour activer pfsync (cette configuration est à faire sur le pfSense primaire et sur le pfSense secondaire)
  • Synchronize Interface : l'interface de synchronisation. Si nous disposons d'une interface dédiée à la synchronisation, nous la choisissons ; autrement, nous choisissons "LAN".
  • pfsync Synchronize Peer IP : sur le pfSense primaire, saisir l'adresse IP du serveur pfSense de secours (192.168.0.12). Si pour le choix de l'interface (ci-dessus) nous avons choisi "LAN", nous indiquons l'adresse IP de l'interface LAN du pfSense secondaire (192.168.0.12) ; si nous avons choisi une interface dédiée alors nous indiquons l'adresse IP de l'interface dédiée du pfSense secondaire. Par défaut, si aucune adresse IP n'est saisie, pfSense diffusera en multicast sur l'interface choisie préalablement. Sur le pfSense secondaire, on indique l'adresse IP du pfSense primaire (192.168.0.11)


Configuration Synchronization Settings (XMLRPC Sync)


  • Synchronize Config to IP : sur le serveur pfSense primaire, saisir l'adresse IP du serveur pfSense secondaire (comme précédemment, il faut saisir l'adresse IP de l'interface choisie). Ce doit être la même adresse IP que celle renseignée dans le champ "pfsync Synchronize Peer IP". Ce champ doit être laissé vide sur le serveur pfSense secondaire.
  • Remote System Username : sur le serveur pfSense primaire, saisir le nom d'utilisateur utilisé pour se connecter sur le WebGUI du pfSense de secours ("admin" par défaut). Ce champ doit être laissé vide sur le serveur pfSense de secours.
  • Remote System Password : sur le serveur pfSense primaire, saisir le mot de passe du compte utilisateur saisi ci-dessus. Ce champ doit être laissé vide sur le serveur pfSense de secours.

Puis, nous choisissons les services que nous souhaitons synchroniser en cochant les cases appropriées. Par défaut, nous recommandons de tout cocher (Toggle All).

Exemple de résultat obtenu :

Configuration de la haute-disponibilité sous pfSense



Autoriser les flux de réplication au niveau des règles du firewall


Il nous reste à autoriser les flux de réplications sur les firewall. La configuration se passe dans "Firewall" > "Rules".
Si la réplication se fait via l'interface LAN, les règles de firewall sont à appliquer sur cette interface ; si nous utilisons une interface dédiée, les règles seront à appliquer sur celle-ci.

Il y a deux flux réseau à autoriser :
  • le flux pour la synchronisation XML-RPC qui s'effectue via le port 443
  • le flux pour la synchronisation du protocole pfsync

Sur le firewall primaire, nous créons donc une première règle de firewall (en cliquant sur le bouton "Add") avec les paramètres suivants :
  • Action : nous choisissons "Pass"
  • Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
  • Address Family : nous laissons "IPv4"
  • Protocol : nous choisissons "TCP"
  • Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez consulter notre article dédié [pfSense] Tout comprendre aux alias, ou vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
  • Destination : nous choisissons "This firewall (self)"
  • Destination port range : choisir "HTTPS (443)"

Exemple de résultat obtenu :

Règle de firewall autorisant la réplication


Sur le firewall primaire toujours, nous créons une seconde règle de firewall avec les paramètres suivants :
  • Action : nous choisissons "Pass"
  • Interface : nous choisissons l'interface dédiée à la réplication si le pfSense en possède une. Autrement, nous choisissons "LAN"
  • Address Family : nous laissons "IPv4"
  • Protocol : nous choisissons "PFSYNC"
  • Source : nous indiquons un alias qui contiendra les adresses IP des interfaces de synchronisation de chaque pfSense (dans notre cas, cet alias contiendra les adresses IP "192.168.0.11" et "192.168.0.12"). Si cette notion d'alias n'est pas claire pour vous, vous pouvez choisir l'ensemble du réseau rattaché à l'interface de synchronisation (dans notre cas, ce serait "LAN net")
  • Destination : nous choisissons "This firewall (self)"

Exemple de résultat obtenu :

Règle de firewall autorisant le protocole pfsync


Ces deux règles de firewall ont été répliquées automatiquement sur le pfSense secondaire.



4. Vérifier le bon fonctionnement de la haute-disponibilité


L'ensemble doit, à ce stade, être opérationnel. Vérifions !


Vérifier le statut du CARP (adresse VIP)


Nous pouvons vérifier l'état de nos adresses IP virtuelles depuis le menu "Status"> "CARP (failover)" :

menu Status > CARP (failover)


Les adresses VIP doivent avoir le statut "MASTER" sur le pfSense primaire et "BACKUP" sur le pfSense secondaire.


Vérifier la réplication


Nous pouvons naviguer dans le menu "Firewall" > "Rules" et "Firewall" > "NAT" et vérifier que les règles créées sur le pfSense primaire sont bien présentes également sur le pfSense secondaire.


Faire des tests !


Avant toute chose, à ce stade, il est important de faire une sauvegarde de vos serveurs pfSense ("Diagnostics" > "Backup & Restore").

Ensuite, pour tester le bon fonctionnement de la haute-disponibilité, plusieurs tests peuvent être réalisés. En voici quelques exemples :
  • arrêter le pfSense primaire
  • débrancher le câble réseau de l'interface LAN ou WAN du pfSense primaire
  • désactiver le service CARP sur le pfSense primaire ("Status" > "CARP (failover)")
  • télécharger un fichier ou lancer des requêtes ping lors de la bascule du primaire vers le secondaire



Pour aller plus loin


[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
[pfSense] Tout comprendre aux alias
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Faire un pont réseau (bridging) entre deux interfaces

icon 01/10/2019 - Aucun commentaire

English version: [pfSense] Bridging interfaces

Dans son mode de fonctionnement par défaut, chaque interface de pfSense dispose de son propre plan d'adressage qui doit être unique.

Il est parfois nécessaire de disposer du même plan d'adressage sur plusieurs interfaces. C'est pratique pour disposer d'un seul sous-réseau pour son LAN et son Wi-fi, pour disposer du même réseau multicast ou encore pour mettre en place un firewall transparent sur un réseau sans avoir à modifier le plan d'adressage existant (en faisant un pont entre l'interface LAN et WAN, par exemple).

Il est très facile de mettre en œuvre un pont réseau entre plusieurs interfaces sur pfSense et de continuer à disposer, si on le souhaite, de règles de filtrage entre ces interfaces.

Dans cet article nous configurerons un pont réseau entre notre interface LAN et notre interface Wi-fi. Ainsi, ces deux interfaces disposeront du même plan d'adressage IP et du même domaine de broadcast.



1. Préparation des interfaces membres du pont-réseau


Chaque interface que nous souhaitons ajouter à notre pont réseau doit être créée et ne pas avoir d'adresse IP. Ce point est important. Ainsi, si nous souhaitons ajouter notre interface LAN à un pont réseau, il est indispensable de faire les configurations depuis une autre interface (depuis l'interface WAN, par exemple, sur laquelle nous aurons temporairement autorisé l'accès à l'interface d'administration du pfSense).

Exemple de configuration pour les interfaces LAN et WIFI :

Configuration des interfaces LAN et WIFI pour un bridge - pfSense - Provya


Pour rappel : [pfSense] Configurer son point d'accès Wi-Fi



2. Configuration du pont-réseau


Une fois ces deux éléments de configuration réalisés, nous nous rendons dans le menu Interfaces > Assignments, puis onglet Bridges :


Menu Interfaces > Assignments > Bridges - pfSense - Provya


Nous cliquons sur le bouton "+Add". La configuration est la suivante :

  • Member Interfaces : les interfaces membres du pont-réseau. Dans notre cas, LAN et WIFI
  • Description : une description facultative
  • Advanced Options : suivant votre configuration, il peut être pertinent d'activer le protocole Spanning Tree (RSTP/STP). Pour un pont entre un réseau filaire et sans-fil, cela n'est pas forcément nécessaire. Dans notre cas, nous ne modifions pas les options avancées.

Exemple de résultat obtenu :

Création d'une interface bridge - pfSense - Provya


Nous cliquons sur le bouton "Save" pour valider notre configuration. Et notre port réseau BRIDGE0 est créé. Il nous reste à lui associer une interface logique afin de pouvoir le configurer (pour rappel, pour bien comprendre la différence entre ports réseaux, interfaces logiques, interfaces virtuelles, etc. vous pouvez consulter notre article dédié : [pfSense] Comprendre la gestion des interfaces réseaux.

Nous retournons dans l'onglet Interface Assignments, puis nous cliquons sur le bouton "+Add" après avoir pris soin de sélectionner notre interface BRIDGE0 :

Associer une interface à un pont réseau sous pfSense - Provya


Il nous reste à configurer cette interface en lui précisant son adresse IP et en lui donnant un nom.
Exemple de résultat obtenu :

Configurer son interface sous pfSense - Provya


Point d'attention : vous pouvez remarquer que sur la capture d'écran, nous avons configuré le champ "MAC Address". La raison est que si ce champ est laissé vide, l'adresse MAC d'une interface "pont-réseau" est générée aléatoirement à la création de l'interface et lors du redémarrage du firewall. Le problème est que les ordinateurs qui tournent sous un Windows récent (Vista et suivants) utilisent l'adresse MAC de la gateway comme identifiant du réseau. Ainsi, si l'adresse MAC change, les ordinateurs Windows estimeront qu'il s'agit d'un nouveau réseau et demanderont à leurs utilisateurs de le paramétrer en précisant s'il s'agit d'un réseau privé/public/etc. En forçant l'adresse MAC, nous évitons ce problème.

Notre pont-réseau est créé. La configuration des services devra être effectuée pour cette interface (dans notre cas "LANFI") : DHCP, firewall, DNS, NTP, etc.

Il reste une dernière subtilité importante : le filtrage.



3. Configuration du filtrage (subtilité à connaître)


Par défaut, pfSense applique les règles de filtrage uniquement sur les interfaces des membres du pont-réseau et non pas sur l'interface du pont-réseau elle-même.

Cela signifie que, dans notre cas, par défaut, uniquement les règles de filtrage définies sur les interfaces LAN et WIFI sont prises en compte par pfSense. Les règles que nous pourrions créer sur l'interface LANFI seront ignorées !

Ce comportement par défaut permet d'avoir des règles de filtrages différentes pour chaque interface membre du pont.
Il est possible de modifier ce comportement afin que les règles de filtrage définies sur l'interface du pont-réseau soient prises en compte.
Cette modification s'opère depuis le menu System > Advanced, onglet System Tunables :

Menu System > Advanced - onglet System Tunables - pfSense - Provya


  • le paramètre net.link.bridge.pfil_member : active le filtrage sur l'interface de chaque membre du pont-réseau lorsqu'il est positionné à 1
  • le paramètre net.link.bridge.pfil_bridge : active le filtrage sur l'interface du pont-réseau lui-même lorsqu'il est positionné à 1

règles de filtrage pour bridge - pfSense - Provya


Il faut donc positionner la valeur du paramètre net.link.bridge.pfil_bridge à 1 si nous souhaitons appliquer nos règles de filtrage sur l'interface du pont-réseau.

Enfin, il faut garder en tête que seul le pont-réseau dispose d'une adresse IP sur son interface. Ainsi si nous souhaitons appliquer des règles de filtrages directement sur chaque interface membre du pont, nous pouvons travailler avec les valeurs LANFI_net et LANFI_address, mais pas LAN_net, WIFI_net, LAN_address et WIFI_address (car celle-ci ne sont pas définies).



4. Les limites


Il existe quelques limites à l'utilisation d'un pont-réseau sous pfSense. Les principales limites ou contraintes sont les suivantes :

Portail captif


Pour que le portail captif fonctionne correctement, il est important que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Ainsi, il n'est pas possible de mettre en œuvre un portail captif sur un pfSense où le LAN et le WAN seraient liés en un pont-réseau.


Haute-disponibilité


Il est plutôt déconseillé d'utiliser des pont-réseaux dans un environnement en haute-disponibilité. Cela peut créer des dysfonctionnements ou des boucles réseaux. Si vous souhaitez absolument utiliser un environnement pfSense en haute-disponibilité avec des pont-réseaux, il est indispensable que le protocole Spanning Tree soit activé sur vos switch et sur le pont-réseau.


Multi-WAN


Comme pour le portail captif, il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. Autrement, vous risquez de rencontrer un problème de routage asymétrique.


Proxy transparent


Idem. Il faut s'assurer que la passerelle par défaut des clients soit l'adresse IP de l'interface du pont-réseau. De plus, un package comme Squid ne peut pas fonctionner dans un scénario de firewall transparent où les interfaces LAN et WAN sont liées sur un même pont-réseau.


Voilà ! Notre pont réseau est fonctionnel et vous connaissez les subtilités à connaître pour sa configuration.



Pour aller plus loin


[pfSense] Configurer son point d'accès Wi-Fi
[pfSense] Comprendre la gestion des interfaces réseaux
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] La gestion des certificats pour les connexions OpenVPN

icon 17/09/2019 - 2 commentaires

Il existe plusieurs méthodes pour monter un tunnel VPN site-à-site avec OpenVPN. Les deux principales consistent en l'utilisation de clés partagées ou en l'utilisation de certificats (X.509).

Après notre premier article sur la configuration d'OpenVPN avec clé partagée, nous abordons ici sa configuration avec la gestion des certificats.

Article mis à jour le  : 17/09/2019

À noter : nous ne détaillons pas dans cet article tous les détails de configuration d'OpenVPN. Nous nous concentrons sur la création, l'utilisation et la révocation des certificats. Il existe déjà un article dédié à la configuration d'OpenVPN : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement


Le client et le serveur OpenVPN sont authentifiés à l'aide de certificats. Pour cela, ces certificats doivent être émis par une autorité de certification reconnue comme sûre aussi bien par le serveur que par le client.

Dans notre cas, nous créerons une autorité de certification (appelée "CA" pour Certificate Authority) sur le pfSense faisant office de serveur. Puis nous créerons deux certificats : un certificat client (qui sera utilisé côté Client) et un certificat serveur (qui sera utilisé côté Serveur). Ces deux certificats seront signés par l'autorité de certification que nous aurons créé précédemment.

Pour signer un certificat, il est nécessaire de disposer de la clé privée de l'autorité de certification.
Pour valider la signature d'un certificat, il est nécessaire de disposer de la clé publique de l'autorité de certification.



Création d'une autorité de certification - CA


Actions à effectuer coté serveur OpenVPN

Pour commencer, nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  2. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, côté serveur, nous créerons une nouvelle autorité de certification (Create an internal Certificate Authority). Côté client, nous importerons la clé publique de l'autorité de certification créée côté serveur (Import an existing Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Autres champs : l'ensemble des champs suivants sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Ils peuvent être laissés vides ou complétés.

Exemple de résultat obtenu :

exemple création autorité de certification (CA) pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre autorité de certification est créée.



Création d'un certificat serveur


Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 4 méthodes sont possibles :
  1. Create an internal Certificate : permet de créer une nouveau certificat
  2. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
  4. Sign a Certificate Signing Request : permet de signer un fichier de requête
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (10 ans)
  • Common Name : le nom du certificat sans espaces, ni caractères spéciaux ou accentués. Ce nom doit être unique.
  • Autres champs : l'ensemble de ces champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Ils peuvent être laissés vides ou complétés.
  • Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
Dans notre cas, nous choisissons "Server Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat serveur OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le serveur OpenVPN est créé.



Création d'un certificat client


Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :

Exemple de configuration certificat client OpenVPN - pfSense - Provya


Nous validons notre configuration en cliquant sur le bouton "Save".

Notre certificat pour le client OpenVPN est créé.



Configuration du serveur OpenVPN


Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Nous conseillons de la cocher. La clé TLS sera générée automatiquement. Il restera à la copier côté client.
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat serveur OpenVPN Provya (Server: Yes, CA: CA Provya)")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration serveur OpenVPN avec certificat sur pfSense - Provya


La configuration coté serveur OpenVPN est terminée. Il reste à faire la configuration côté client.



Export des certificats


Nous devons exporter le certificat de l'autorité de certification (c'est-à-dire sa clé publique), ainsi que le certificat et la clé privée du client OpenVPN.

Pour cela, nous retournons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA" de l'autorité de certification que nous avons créée précédemment :

Export du certificat d'une autorité de certificat sous pfSense - Provya



Puis, dans l'onglet "Certificates", nous cliquons successivement sur les icônes "Export Certificate" et "Export Key" du certificat client que nous avons créé précédemment :

Export clé et certificat client pour OpenVPN - pfSense - Provya


La configuration côté serveur OpenVPN est terminée.

Maintenant, nous procédons à l'import des clés publiques/privées et à la configuration côté client OpenVPN.



Import de la clé publique du CA sur le pfSense client OpenVPN


Actions à effectuer coté client OpenVPN

Nous nous rendons dans le menu System > Cert Manager :

menu Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur le bouton "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Nous allons importer la clé publique du CA que nous avons créé sur le serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("CA Provya")
  • Method : nous choisissons "Import an existing Certificate Authority"
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Certificate Private Key (optional) : si l'on souhaite importer la clé privée (.key), elle est à copier dans ce champ. Dans notre cas, nous le laissons vide. En effet, nous ne souhaitons pas signer de nouveaux certificats (nécessite la clé privée de l'autorité de certification), nous souhaitons seulement valider la signature du certificat qu'utilise le serveur OpenVPN (nécessite la clé publique de l'autorité de certification)
  • Serial for next certificate : ce champ est à remplir uniquement si l'on importe une clé privée. Dans ce cas, il est important que chaque certificat créé par un CA dispose d'un numéro de série unique (autrement, nous risquons de rencontrer des problèmes en cas de révocation de certificat). Il faut donc choisir une valeur suffisamment grande (supérieure au nombre de certificat déjà créé par ce CA) afin d'éviter toute collision.

Exemple de résultat obtenu :

Import du certificat d'une autorité de certification sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Import de la clé publique et de la clé privée du certificat client OpenVPN


Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Nous cliquons sur le bouton "+ Add/Sign" se trouvant en bas à droite de la liste des certificats existants.

Nous allons importer la clé publique et la clé privée du certificat client que nous avons créé sur le pfSense serveur OpenVPN.
Les champs à remplir sont les suivants :
  • Method : on choisit "Import an existing Certificate"
  • Descriptive name : le nom que l'on souhaite donner à notre certificat. Nous gardons le même que celui qui a été donné sur le serveur OpenVPN ("Certificat client OpenVPN Provya")
  • Certificate data : on copie dans ce champ le contenu de la clé publique (.crt)
  • Private key data : on copie dans ce champ le contenu de la clé privée (.key)

Exemple de résultat obtenu :

Import d'un certificat client OpenVPN sous pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Configuration du client OpenVPN


Le détail de la configuration du client OpenVPN se trouve dans l'article [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Peer to Peer (SSL/TLS)"
  • TLS Configuration : cocher la case "Use a TLS Key" pour davantage de sécurité. Décocher la case "Automatically generate a TLS Key", et copier dans le champ "TLS Key" la clé TLS qui a été généré côte serveur OpenVPN.
  • Peer Certificate Authority : choisir l'autorité de certification importée précédemment ("CA Provya")
  • Client Certificate : choisir le certificat client importé précédemment ("Certificat client OpenVPN Provya")
  • DH Parameters Length : Nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Exemple de configuration client OpenVPN avec certificat sur pfSense - Provya


Nous validons en cliquant sur le bouton "Save".



Révocation de certificat


Le dernier élément, pour être complet sur la gestion des certificats, est la liste de révocation de certificats ou "Certificate Revocation Lists" (CRLs).

Cette liste de révocation contient les certificats qui ne doivent plus être considérés comme sûrs (car ils ont été compromis ou pour n'importe quelle autre raison).
Pour les connexions OpenVPN, la CRL peut être utilisée par le serveur pour vérifier les certificats utilisés par les clients OpenVPN.

Une CRL est signée par un CA. Ainsi, pour générer une CRL, il est nécessaire de disposer de la clé privée du CA.

Généralement, une seule CRL est maintenue par CA. Cependant, pfSense peut en maintenir davantage.
Néanmoins, une seule CRL pourra être sélectionnée par instance OpenVPN.
Ce fonctionnement permet, par exemple, d'empêcher un certificat de se connecter à une instance OpenVPN, mais de l'autoriser à se connecter à une autre instance.

Une CRL peut être soit créée, soit importée. La configuration se fait dans le menu System > Cert Manager depuis l'onglet "Certificate Revocation" (troisième onglet).

Pour ajouter une nouvelle CRL, nous cliquons sur le bouton "+ Add or import CRL" correspondant au CA qui signera cette CRL (dans notre cas, "CA Provya"). Les champs à renseigner sont les suivants :
  • Method : deux méthodes sont possibles :
  1. Create an internal Certificate Revocation List : permet de créer une nouvelle CRL (nécessite de disposer de la clé privée du CA)
  2. Import an existing Certificate Revocation List : permet d'importer une CRL générée depuis un serveur tiers (disposant de la clé privée du CA)
  • Descriptive name : le nom de notre CRL. On y inclut généralement une référence au nom du CA et/ou l'usage de cette CRL
  • Certificate Authority : le CA qui a signé ou va signer cette CRL
  • Lifetime : la durée de vie de la CRL (10 ans par défaut)
  • Serial : le numéro de série de la CRL (0 par défaut pour la première)

Exemple de résultat obtenu :

Création d'une CRL (Certificate Revocation Liste) sous pfSense - Provya


Notre CRL est créée. On peut maintenant lui ajouter les certificats à révoquer. Pour cela, cliquer sur l'icône "Edit CRL" :

Modifier CRL sous pfSense - Provya


Il reste à choisir le certificat à révoquer, la raison de la révocation (ce champ est purement informatif) et cliquer sur le bouton "ADD".

Enfin, dans la configuration de notre serveur OpenVPN, nous devons ajouter cette CRL (champ "Peer Certificate Revocation List").


Voilà ! Notre serveur OpenVPN est prêt à fonctionner avec des certificats.



Pour aller plus loin


[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la gestion des interfaces réseaux

icon 03/09/2019 - 6 commentaires

English version: [pfSense] How network interfaces work

La gestion des interfaces réseaux sous pfSense peut être quelque peu déroutante pour un débutant. Nous présentons ici les rappels de base et les cas d'utilisation de chaque type d'interface.

Article mis à jour le  : 03/09/2019


Il existe 3 types d'interfaces sous pfSense :

  • interface physique : correspond aux interfaces physiques réelles du serveur sur lequel tourne pfSense. Ces interfaces sont généralement nommées re0, re1 (pour des interfaces Realtek), igb0, igb1 (pour des interfaces Intel Gbps), etc.
  • interface virtuelle : ces interfaces sont automatiquement créées lors de la création d'un VLAN, d'un serveur OpenVPN, etc. Elles sont donc associées à un service.
  • interface logique : ce sont les interfaces que nous pouvons configurer (attribution d'adresse IP, règle de filtrage du firewall, etc.). Ces interfaces sont associées à une interface physique ou virtuelle.

Les deux premiers types d'interfaces (interface physique et interface virtuelle) sont appelés "ports réseaux".

Une interface logique doit être associée à un port réseau.

Un port réseau (c'est-à-dire une interface physique ou virtuelle) ne peut être associé qu'à une seule interface logique (c'est-à-dire configurable).



Interfaces physiques


Une interface physique correspond à une carte réseau du serveur pfSense.
Ces interfaces sont nommées en fonction de leur driver. Par exemple : re0, re1, igb0, igb1, ath0, etc. Elles sont identifiées par leur adresse MAC.

Lors de l'installation de pfSense, il est proposé de configurer les interfaces. Ce sont des interfaces logiques. Elles sont créées, configurées et associées aux interfaces physiques.
Ainsi, dans le cas d'un pfSense disposant de deux interfaces (une interface LAN et une interface WAN), on pourrait avoir l'association suivante :

WAN [interface logique] = igb0 [port réseau]
LAN [interface logique] = igb1 [port réseau]

Il est également possible de retrouver cette association depuis le menu Interfaces > Assignments :

menu Interfaces > Assignement - pfSense - Provya




Interfaces virtuelles


Ces interfaces sont créées lors de l'activation de certains services (VLAN, OpenVPN).

La configuration d'un serveur OpenVPN entraîne automatiquement la création d'une interface virtuelle associée à cette instance serveur OpenVPN. L'interface virtuelle sera nommée ovpns1, ovpns2, etc...

Cette interface n'est pas configurable en l'état : ce n'est qu'un port réseau. Il est nécessaire de l'associer à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.

Lorsque nous procédons à cette association, nous obtenons l'exemple suivant :

association interfaces réseau - pfSense - Provya


Dans la capture d'écran ci-dessus, nous voyons que l'interface logique "OPT2" est associée à l'interface virtuelle "ovpns1" qui a été créée lors de la configuration du serveur OpenVPN "VPN Provya".

De la même façon, la création d'un VLAN entraîne la création d'une interface virtuelle (qui sera nommée VLAN1, VLAN2, etc.).
Cette interface virtuelle devra être associée à une interface logique afin de pouvoir lui associer des règles de firewall ou de NAT spécifiques.



Interfaces logiques


Les interfaces logiques sont les interfaces configurables. Ce sont ces interfaces que nous allons pouvoir configurer : associer une adresse IP ; activer un serveur DHCP ; configurer des règles de firewall ou de NAT ; etc.

Ainsi, lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.

Les interfaces logiques les plus connues sont LAN et WAN.

Une interface logique est obligatoirement associée à un port réseau (c'est-à-dire à une interface physique ou virtuelle).



Groupe d'interfaces


Un groupe d'interfaces rassemble plusieurs interfaces logiques.
Ce groupe est donc un groupe logique auquel on peut appliquer des règles de firewall ou de NAT.

L'utilisation d'un groupe d'interfaces est utile si l'on dispose de plusieurs interfaces logiques sur lesquelles nous souhaitons appliquer exactement les mêmes règles.
Ainsi, les règles de firewall définies pour ce groupe s'appliqueront à toutes les interfaces du groupe.

La création de groupe d'interfaces se fait dans le menu Interfaces > Assignments, puis l'onglet "Interface Groups" :

menu Interface Groups - pfSense - Provya


L'ajout se fait en cliquant sur le bouton "+ Add".

Nous renseignons le nom du groupe d'interfaces, une description (facultative) et la liste des interfaces faisant partie du groupe :

création groupe interfaces - pfSense - Provya


Ce groupe d'interfaces sera visible dans les onglets du firewall :

règles de filtrage pour groupe interfaces - pfSense - Provya


Il est à noter qu'au niveau du firewall, ce sont les règles du groupe d'interfaces qui sont vérifiées, avant les règles de l'interface logique.

D'une façon générale, les règles de vérification du firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques



Cas particulier : OpenVPN


Lors de la création d'une instance serveur ou client OpenVPN, hormis les interfaces virtuelles (ovpns1 ou ovpnc1), un groupe d'interfaces nommé "OpenVPN" est automatiquement créé.

Les configurations réalisées sur ce groupe "OpenVPN" s'appliquent à l'ensemble des services OpenVPN (c'est-à-dire tous les serveurs ou tous les clients OpenVPN configurés).

Si nous souhaitons une granularité de configuration par instance OpenVPN, alors nous devons créer une interface logique pour chaque interface virtuelle OpenVPN existante.



Cas d'application


Lors de la configuration d'un service (DHCP, OpenVPN, Portail Captif, etc.) les interfaces proposées seront toujours les interfaces logiques.
Pour les services dont la configuration peut se faire pour plusieurs interfaces (une règle de firewall, par exemple), il sera également proposé les groupes d'interfaces.

Il existe deux cas particuliers à noter : la configuration des clients ou serveurs OpenVPN et IPsec.
Pour ces services, le choix de l'interface sera :
  1. les interfaces logiques
  2. les groupes de gateway
  3. les adresses VIP
  4. l'interface localhost
  5. toutes les interfaces logiques existantes (choix "any")
Les groupes d'interfaces ne seront pas proposés.


Nous voila maintenant armés pour bien comprendre et configurer correctement les services sur les bonnes interfaces réseau !



Pour aller plus loin


Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Bien choisir et dimensionner son firewall
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer la priorisation de trafic avec CBQ

icon 28/08/2019 - 27 commentaires

English version: [pfSense] Configuring traffic shaping with CBQ

pfSense offre plusieurs mécanismes de priorisation de trafic. Après notre premier article présentant le mode de fonctionnement des trois principaux mécanismes de priorisation ([pfSense] Comprendre la priorisation de trafic), nous procédons dans cet article à sa mise en application à l'aide du protocole CBQ.

Article mis à jour le  : 28/08/2019

Si nos besoins en règles de priorisation de trafic sont des besoins traditionnels, il est conseillé de travailler avec CBQ.

Nous ne détaillerons pas ici le mode de fonctionnement de CBQ, ni ses avantages ou inconvénients. Nous traiterons d'un cas pratique de mise en application sous pfSense et des bonnes pratiques à respecter.
Le mode de fonctionnement de CBQ est présenté dans notre article dédié : [pfSense] Comprendre la priorisation de trafic



Généralités sur la priorisation de trafic


Pour la mise en place de la priorisation de trafic, nous allons configurer d'un côté des queues (file d'attente) et de l'autre des rules (règles d'affectation des paquets dans ces files d'attente) :
  • Queues : "file d'attente" à laquelle est associée une priorité de traitement et une bande passante
  • Rules : "règle d'affectation" définissant la queue par laquelle un paquet va transiter. Ces règles sont les mêmes que pour la configuration du firewall : filtrage par port et adresse IP source, port et adresse IP de destination, protocole utilisé, etc.

La priorité de traitement la plus forte doit toujours être donnée aux applications nécessitant un traitement temps-réel. Typiquement, la VoIP.

La priorité suivante doit toujours être donnée aux acquittements TCP (ACK). Les ACK correspondent à des sortes d'accusé de réception sur les données transmises en TCP. Il est important que ces paquets soient prioritaires car autrement l'émetteur considérera que les paquets envoyés n'ont pas été correctement reçus et procédera à leur réémissions. Ce qui, par effet boule de neige, augmentera la charge sur la ligne Internet.

On considère que la bande passante nécessaire pour les ACK est de 10 à 15% du débit maximum offert en dowload (nous verrons en fin d'article comment affiner ce réglage).

Enfin, par convention de nommage, les queues commencent toujours par la lettre "q" (ex : qVoIP, qACK, qDefault, ...).
Pour le nommage des queues, et afin de facilité la lisibilité, nous recommandons l'utilisation du lowerCamelCase.



Cas d'application


Nous partirons du cas d'application suivant : une entreprise disposant d'une connexion Internet SDSL de 3Mbps sur laquelle transite sa téléphonie (VoIP) vers son opérateur SIP et le reste de sa data (surf, messagerie, etc.).

Le besoin est de prioriser sa téléphonie afin de garantir la qualité des communications et de disposer d'une répartition dynamique de sa bande passante.

Nous respecterons le principe KISS et mettrons en place les trois queues suivantes :
  • qVoIP : ce sera la queue réservée à la téléphonie
  • qACK : ce sera la queue réservée aux paquets ACK
  • qDefaut : la queue par défaut par laquelle nous ferons passer le reste du trafic

Il est important de démarrer avec un nombre de queues réduit et sur des règles d'affectation simples. Puis, de procéder à du fine-tuning si nécessaire.

La queue qVoip disposera de la priorité la plus forte et d'une bande passante de 1Mbps (ce qui correspond environ à 10 appels simultanés avec le codec G.711)
La queue qACK disposera de la priorité suivante et d'une bande passante de 10% du débit max en download, soit 300Kbps.
Enfin, la queue qDefaut disposera d'une priorité assez faible (et du reste de la bande passante) permettant l'ajout ultérieur de queues avec des priorités intermédiaires en cas de besoin.



Configuration des queues


Nous commençons par la configuration des queues sur l'interface WAN.

Se rendre dans le menu Firewall > Traffic Shaper :

menu Firewall > Traffic Shaper pfSense - Provya


Dans l'onglet « By Interface » (celui par défaut), cliquer sur « WAN » :

création file de priorisation de trafic pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface WAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en upload diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic pfSense - Provya


À noter : ne pas tenir compte pour le moment du message nous invitant à appliquer les changements. Nous le ferons lorsque nous aurons fini de configurer l'ensemble des queues.

Nous allons maintenant créer les queues. Pour cela, se repositionner sur l'interface "WAN" :

création file de priorisation de trafic pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qVoIP"
  • Priority : on choisit "7"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1000 Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qVoIP QoS pfSense - Provya


Notre première queue est créée. Pour la création de la suivante, nous nous repositionnons sur l'interface WAN (l'icône a pris la forme d'un dossier) :

dossier queue wan QoS pfSense - Provya


Puis cliquer sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qACK"
  • Priority : on choisit "6"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : laisser vide
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "300Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qACK QoS pfSense - Provya


Notre seconde queue est créée. Pour la création de la troisième et dernière queue (la queue par défaut), nous nous repositionnons sur l'interface WAN.
Puis nous cliquons sur le bouton "Add new Queue".

Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la file d'attente
  • Queue Name : le nom de la file d'attente. Ici, ce sera "qDefaut"
  • Priority : on choisit "2"
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • Scheduler options : cocher la case "Default Queue"
  • Description : une description optionnelle
  • Bandwidth : la bande passante allouée à la queue. Dans notre exemple, "1400Kbps"
  • Scheduler specific options : cocher cette case afin d'activer le partage dynamique de bande-passante pour cette queue

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

création file qDefaut QoS pfSense - Provya


L'ensemble de nos queues côté WAN est créé. Nous disposons de 3 queues :
  1. qVoIP : pour le trafic à destination ou en provenance du fournisseur SIP
  2. qACK : pour le trafic ACK (acquittement TCP)
  3. qDefaut : pour le reste du trafic

Nous allons maintenant activer la priorisation de trafic sur l'interface LAN. Cliquer sur « LAN » :

création file de priorisation de trafic QoS pfSense - Provya


Renseigner les champs comme suit :
  • Enable/Disable : cocher la case pour activer la priorisation de trafic sur l'interface LAN
  • Scheduler Type : choisir "CBQ"
  • Bandwidth : indiquer le débit max en download diminué de 10% (soit 2700Kbps)
  • Queue Limit : laisser vide (sauf si l'on souhaite modifier la taille du buffer de paquets)
  • TBR Size : laisser vide

Cliquer sur le bouton "Save" pour valider la configuration.

Exemple de résultat obtenu :

détails configuration priorisation de trafic QoS pfSense - Provya


Nous allons maintenant dupliquer les queues créées sur l'interface WAN vers l'interface LAN. Se rendre dans l'onglet "By Queue" :

menu By Queue QoS pfSense - Provya


Sélectionner la queue "qVoIP", puis, dans la section "LAN", choisir "Clone Shaper on this interface" :

cloner QoS entre interfaces pfSense - Provya


Procéder de la même manière avec les queues "qACK" et "qDefaut".

Nos queues sont toutes créées :

afficher liste des queues QoS pfSense - Provya


Nous validons l'ensemble de ces paramétrages en cliquant sur le bouton "Apply Changes" :

Bouton Apply changes pfSense - Provya




Configuration des rules


Nous allons maintenant créer les règles d'affectation du trafic dans ces queues.
La configuration s'effectue au niveau des règles du Firewall. Elle peut s'effectuer directement depuis les règles existantes, ou en créant des règles génériques sur l'interface "Floating".

Les règles de vérification du Firewall s'opèrent dans l'ordre suivant :
  1. Règles définies en Floating
  2. Règles définies sur les groupes d'interfaces
  3. Règles définies sur les interfaces logiques

Pour un rappel sur le mode de fonctionnement des interfaces réseaux ou groupe d'interfaces sous pfSense, se référer à l'article dédié [pfSense] Comprendre la gestion des interfaces réseaux.

Dans notre cas, nous ne toucherons pas aux règles de filtrage en place sur nos interfaces ou groupe d'interfaces, mais nous créerons des règles spécifiques d'affectation du trafic depuis l'interface "Floating".
C'est ce que nous recommandons de faire systématiquement. Ainsi, nous ne mélangeons pas la partie "filtrage firewall" de la partie "règles de priorisation de trafic".

Pour cela, se rendre dans le menu "Firewall" > "Rules", puis sur l'onglet "Floating" :

menu Firewall Rules Floating pfSense - Provya


La méthode de création des règles de firewall depuis l'onglet "Floating" est exactement la même que pour n'importe quelle interface. La seule différence est la présence de l'action "Match".

L'action "Match" signifie qu'aucune décision ne sera prise quant à l'acceptation (Pass) ou au refus (Block ou Reject) du paquet, mais que s'il correspond (="match") aux critères définis (adresse IP source ou destination, port source ou destination, système d'exploitation, protocole, etc.), alors il se verra appliquer les options définies dans les "Advanced Options" (comme les queues d'affectation ou la gateway, par exemple).

Si nous reprenons notre exemple, nous devons créer les règles suivantes :
  1. Une première règle pour diriger le trafic en provenance de l'opérateur de VoIP vers la queue "qVoIP"
  2. Une seconde règle pour diriger le trafic à destination de l'opérateur de VoIP vers la queue "qVoIP"
  3. Une dernière règle pour diriger tous les paquets ACK du trafic TCP vers la queue "qACK"

Nous créons notre première règle en cliquant sur le bouton "Add" et renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "in" (c'est-à-dire arrivant sur l'interface WAN)
  • Protocol : nous choisissons "UDP" (les protocoles de VoIP SIP et RTP utilisant UDP)
  • Source : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur

Exemple de résultat obtenu :

règle de floating QoS pfSense - Provya


Puis, dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced" et localisons en bas de page la ligne "Ackqueue / Queue". La première liste déroulante correspond à la queue d'acquittement (paquets ACK), la seconde liste déroulante correspond à la queue en tant que telle.

On ne peut choisir une "Ackqueue" (première liste déroulante), que si on a choisi une queue (seconde liste déroulante).

Ici, nous choisissons la queue "qVoIP" et nous laissons l'Ackqueue à "none" (les protocoles de VoIP SIP et RTP utilisant UDP).

Exemple de résultat obtenu :

advanced options pour règle de floating QoS pfSense - Provya


Enfin, nous cliquons sur "Save" pour valider la règle.
Voila notre première règle créée :

exemple règle floating qVoIP pour QoS pfSense - Provya


Nous créons une nouvelle règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons l'interface "WAN"
  • Direction : nous choisissons "out" (c'est-à-dire sortant par l'interface WAN)
  • Protocol : nous choisissons "UDP"
  • Destination : nous choisissons "Single host or alias" et renseignons l'adresse IP du serveur VoIP de l'opérateur
Dans la section "Advanced Options", nous cliquons sur le bouton "Display Advanced", puis localisasons la ligne "Ackqueue / Queue".
Nous laissons la première liste déroulante à "none", et choisissons "qVoIP" pour la seconde.

Exemple de résultat obtenu :

exemple 2 règle floating qVoIP pour QoS pfSense - Provya


Nous cliquons sur "Save" pour valider la règle.

Nous créons enfin la dernière règle en cliquant sur le bouton "Add".

Nous renseignons les champs comme suit :
  • Action : nous choisissons "Match"
  • Interface : nous choisissons les interfaces "WAN" et LAN
  • Protocol : nous choisissons "TCP"
Dans la section "Advanced features", nous cliquons sur le bouton "Advanced" se trouvant sur la ligne "Ackqueue/Queue".
Nous choisissons "qACK" dans première liste déroulante à "none", et choisissons "qDefaut" dans la seconde.

On clique sur "Save" pour valider la règle.

Exemple de résultat obtenu :

exemple règle floating qACK et qDefaut pour QoS pfSense - Provya


Nos trois règles d'affectation sont créées. Nous cliquons sur "Apply changes" pour valider la configuration.

exemple complet priorisation de trafic QoS pfSense - Provya




Remise à zéro de la table d'état


Les règles de priorisation de trafic ne s'appliquent que sur les nouvelles connexions. Les connexions en cours (visibles dans la table d'état) ne sont pas impactées par les règles que nous venons de créer.
Aussi, pour que ces règles soient prises en compte totalement, il est nécessaire de vider la table d'état.

Pour cela, se rendre dans le menu "Diagnostics" > "States".
Cliquer sur l'onglet "Reset States", puis sur le bouton "Reset" :

Reset table d'états pfSense - Provya


À noter : la page va charger sans fin. Ce comportement est normal : l'état de la connexion entre notre navigateur et le pfSense vient d'être réinitialisé.
Il suffit de rafraîchir la page pour continuer.



Analyse et Debug


Les statistiques d'utilisation des queues se trouvent dans le menu "Status" > "Queues" :

menu Status Queues pfSense - Provya


Si l'on voit des "drops" de paquets (avant-dernière colonne du tableau) dans une des queues prioritaires (qVoIP ou qACK), cela signifie que la bande passante qui leur est allouée est trop faible et qu'il faut, a priori, l'augmenter.

En revanche, avoir du drops de paquets dans les queues disposant d'une priorité faible (qDefaut) est normal : en cas de saturation de la ligne Internet, ces queues ne sont pas prioritaires.


La priorisation de trafic est maintenant en place sur notre pfSense !



Pour aller plus loin


[pfSense] Comprendre la priorisation de trafic
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Mettre à jour son serveur pfSense

icon 20/08/2019 - Aucun commentaire

English version: [pfSense] Upgrading pfSense (how-to)

Il est important de conserver une version de pfSense à jour sur ses firewall en production.
Nous présentons ici la procédure que nous utilisons lors de la mise à jour d'un pfSense standalone ou d'un cluster de pfSense.

Article mis à jour le  : 20/08/2019

Avant de commencer, si votre système de fichiers est ZFS, pensez à créer un point de restauration avant de lancer la mise à jour.



1. Procédure de mise à niveau pour un pfSense seul


Dans le cas d'un serveur pfSense fonctionnant de manière autonome, la mise à jour va s'effectuer en 3 étapes :
  1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
  2. Mise à jour du serveur pfSense
  3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure


Sauvegarde de la configuration


Se rendre dans le menu Diagnostics > Backup/Restore :

menu Diagnostics > Backup & Restore pfSense - Provya


Dans le champ "Backup configuration" > "Backup area" choisir "ALL", laisser coché la case "Do not backup RRD data", et décoché les deux autres cases, puis cliquer sur "Download Configuration as XML" :

Exemple configuration backup pour pfSense - Provya



Mise à jour du serveur pfSense


Naviguer dans le menu System > Update :

menu System Update pfSense - Provya


Puis cliquer sur "Upgrade now" pour lancer la mise à jour.

Lors de la mise à jour, une coupure de service est à prévoir (redémarrage du serveur pfSense possible).


Sauvegarde de la configuration après la mise à jour


Refaire une sauvegarde en suivant la procédure décrite précédemment.

La mise à jour du serveur pfSense est terminée !



2. Procédure de mise à niveau d'un cluster de pfSense


Dans le cas de serveurs pfSense fonctionnant en redondance, la mise à jour va s'effectuer de la manière suivante :
  1. Faire une sauvegarde du pfSense secondaire
  2. Lancer la mise à jour du pfSense secondaire
  3. Une fois la mise à jour du pfSense secondaire complète, faire une sauvegarde du pfSense primaire
  4. Désactiver CARP sur le pfSense primaire => les adresses VIP vont basculer sur le pfSense secondaire
  5. Lancer la mise à jour du pfSense primaire


Sauvegarde de la configuration du pfSense secondaire


Se rendre dans le menu Diagnostics > Backup/Restore :

menu Diagnostics > Backup & Restore pfSense - Provya



Dans le champ "Backup configuration" > "Backup area" choisir "ALL", cocher la case "Do not backup RRD data", décocher les deux autres cases, puis cliquer sur "Download Configuration" :

Exemple configuration backup pour pfSense - Provya



Mise à jour du serveur pfSense secondaire


Naviguer dans le menu System > Update :

menu System Update pfSense - Provya


Puis cliquer sur "Upgrade now" pour lancer la mise à jour.


Sauvegarde de la configuration du pfSense primaire


Une fois la mise à jour terminée sur le pfSense secondaire, effectuer une sauvegarde du pfSense primaire en suivant la procédure détaillée à l'étape précédente.


Désactivation CARP du pfSense primaire


Avant de mettre à jour le pfSense primaire, nous basculons les adresses VIP sur le pfSense secondaire afin de ne pas perturber le service.

Pour cela, se rendre dans dans Status > CARP (failover) :

menu Status CARP Failover pfSense - Provya


Puis cliquer sur "Enter Persistent CARP Maintenance Mode" :

désactiver or disabled carp failover on pfSense - Provya


Les adresses VIP vont basculer sur le serveur pfSense secondaire.


Mise à jour du serveur pfSense primaire


Nous pouvons maintenant mettre à jour tranquillement le serveur primaire. La procédure est toujours la même que celle décrite aux étapes précédentes.


Une fois la mise à jour du serveur primaire terminée, la VIP ne va pas re-basculer d'elle-même sur le serveur pfSense primaire. Il faut la réactiver. Pour cela, nous nous rendons dans le menu Status > CARP (failover) et cliquons sur "Leave Persistent CARP Maintenance Mode" :

réactiver or enabled carp failover on pfSense - Provya



Il ne reste plus qu'à faire une sauvegarde du serveur pfSense primaire afin d'avoir une sauvegarde de la dernière configuration à jour.

La mise à jour du cluster de pfSense est terminée !



3. Vérifier et corriger la mise à jour des packages


Les packages peuvent parfois être une source de problème lors d'une mise à jour. Si des packages semblent ne plus fonctionner correctement après une mise à jour, il est recommandé de désinstaller le ou les packages concernés, puis de les réinstaller.



Pour aller plus loin


Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN

icon 13/08/2019 - 24 commentaires

Un cas fréquent lorsque l'on souhaite connecter deux sites en VPN est que ces deux sites soient sur le même plan d'adressage. Dans ce cas, une bonne solution peut être de recourir au NAT pour la mise en place d'un VPN natté.

Article mis à jour le  : 13/08/2019

Par exemple, si l'on souhaite connecter deux sites utilisant le sous-réseau 192.168.1.0/24, ceux-ci ne pourront pas communiquer l'un vers l'autre à travers le VPN car le plan d'adressage du réseau distant est le même que celui du réseau local.

Afin d'y remédier, nous proposons d'utiliser le NAT pour communiquer d'un réseau à l'autre. C'est le principe du VPN natté (overlap network).

À noter : nous ne détaillons pas dans cet article comment configurer OpenVPN. Il existe déjà un article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement


Pour chaque sous-réseau commun sur les sites distants, nous utiliserons un nouveau sous-réseau disponible associé à du 1:1 NAT.

Nous allons prendre l'exemple de deux sites (A et B) disposant tous deux du même plan d'adressage 192.168.1.0/24 :

Schéma réseau overlap openVPN pfSense - Provya


Afin de pouvoir relier ces deux sites en VPN, nous allons translater l'intégralité du plan d'adressage réseau du site B afin qu'il soit joignable depuis le site A à travers le VPN. Et nous ferons de même du plan d'adressage réseau du site A afin qu'il soit joignable depuis le site B à travers le VPN.

Le trafic à destination du site A sera translaté en 192.168.100.0/24.
Le trafic à destination du site B sera lui translaté en 192.168.200.0/24.

Une entrée 1:1 NAT sera ajoutée pour chaque sous-réseau afin de translater l'intégralité du /24.
Ainsi, pour joindre le site A depuis le site B, on utilisera une adresse IP du type 192.168.100.x et pour joindre le site B depuis le site A, on utilisera une adresse IP du type 192.168.200.x.

Grâce au 1:1 NAT, on conservera le dernier octet de l'adresse réseau de chaque site. C'est-à-dire que pour joindre l'adresse IP 192.168.1.10 du site A, depuis le site B on utilisera l'adresse IP 192.168.100.10. Et pour joindre l'adresse IP 192.168.1.50 du site B, depuis le site A on utilisera l'adresse IP 192.1168.200.50.



Configuration du VPN natté


Sur le serveur pfSense du site A, nous nous rendons dans menu Firewall > NAT, puis sur l'onglet 1:1 :

menu firewall > NAT > 1 to 1 pfSense - Provya


Nous cliquons sur le bouton "Add". Les champs à configurer sont les suivants :

  • Interface : l'interface de notre tunnel VPN OpenVPN
  • External subnet IP : le sous-réseau utilisé pour le NAT. Soit, pour le site A : 192.168.100.0
  • Internal IP : le sous-réseau local que nous souhaitons translater. Dans notre cas : LAN net
  • Destination : Any

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Nous procédons de la même manière sur le serveur pfSense du site B, en adaptant le champ "External IP" qui passe à 192.168.200.0 dans notre cas.

Exemple de résultat obtenu :

Configuration 1 to 1 NAT pfSense - Provya



Enfin, dans la configuration du client et du serveur OpenVPN, le champ "IPv4 Remote network(s)" doit correspondre aux plages d'adresses IP nattées.

C'est-à-dire que sur le pfSense du site A, le champ "IPv4 Remote network(s)" est renseigné à "192.168.200.0/24". Sur le pfSense du site B, le champ "IPv4 Remote network(s)" est quant à lui renseigné à "192.168.100.0/24".

La configuration est terminée.

Pour davantage d'information sur la configuration OpenVPN sur pfSense, voir l'article dédié sur le sujet : [pfSense] Monter un accès OpenVPN site-à-site.

Le VPN natté est en place !



Pour aller plus loin


[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Monter un VPN IPsec natté (Overlap network)
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer son serveur DHCP

icon 06/08/2019 - 5 commentaires

pfSense peut être utilisé comme serveur DHCP ou relai DHCP.

Nous allons configurer ici pfSense en tant que serveur DHCP pour des adresses IPv4.

Article mis à jour le : 06/08/2019



Activer le service DHCP


Pour commencer, se rendre dans le menu "Services" > "DHCP Server" :

menu Services > DHCP Server pfSense Provya


On choisi l'interface sur laquelle nous souhaitons activer le serveur DHCP. Dans notre cas, ce sera "LAN".

Pour commencer, nous cochons évidemment la case "Enable DHCP server on LAN interface".



Configuration du serveur DHCP


Les éléments pouvant être configurés sont les suivants :

  • BOOTP : cocher cette case permet de désactiver la prise en charge des requêtes BOOTP. Le protocole BOOTP est en quelque sorte l'ancêtre du protocole DHCP.

  • Deny unknown clients : cette option permet de filtrer les requêtes DHCP.
Par défaut (option non-cochée), pfSense attribue une adresse IP à n'importe quel terminal connecté sur le réseau qui fait une demande d'adresse IP. C'est, à priori, le mode souhaité dans la plupart des cas. Cependant, il est possible, dans des environnements plus restrictifs, de n'autoriser la distribution d'adresses IP qu'aux terminaux connus (c'est-à-dire dont l'adresse MAC a été renseignée dans pfSense) ; dans ce cas, cette case doit être cochée. Il est à noter que cette option se défini par plage d'adresses.

  • Ignore denied clients : cocher cette case permet d'ignorer les requêtes DHCP des clients interdits plutôt que de leur renvoyer une réponse explicite de refus. Cette option n'est pas compatible avec une configuration de pfSense en haute-disponibilité.

  • Ignore client identifiers : permet d'ignorer l'UID du client. Cette option peut être intéressante si l'on souhaite qu'un ordinateur disposant d'un dual-boot conserve la même adresse IP lorsqu'il bascule d'un système d'exploitation à l'autre. Cependant, activer cette option revient à ne pas respecter les spécification officielles du fonctionnement du protocole DHCP.

  • Subnet : cette ligne rappelle l'adresse du réseau.

  • Subnet mask : cette ligne rappelle le masque de sous-réseau.

  • Available range : cette ligne donne la plage maximale sur laquelle des adresses IP peuvent être attribuées. Cette information est bien pratique pour les réseaux n'étant pas en /24.

  • Range : permet de définir la plage d'adresses IP qui sera utilisée.
Par défaut, pfSense propose la plage d'adresse allant de 100 à 199 (soit, par exemple, 192.168.1.100 à 192.168.1.199). Nous sommes libres de la modifier dans la limite de la taille maximale rappelée à la ligne précédente (available range).
Si nous souhaitons définir plusieurs plages d'adresses IP différentes (soit pour filtrer les terminaux connus des terminaux inconnus, soit pour d'autres raisons liées à notre architecture réseau), il est possible de définir plusieurs plages d'adresses IP (section Additional Pools juste en-dessous).

Pour ajouter une seconde plage d'adresses IP, cliquer sur le bouton "+ Add pool" de la section "Additional Pools". Cela aura pour effet d'ouvrir une nouvelle fenêtre permettant de définir l'ensemble des paramètres propres à cette plage d'adresses IP.

Évidemment, cette option n'est utile que si nous disposons d'un serveur WINS sur notre réseau. Les serveurs WINS n'ont pas forcément besoin d'être sur le même sous-réseau (dans ce cas, il faut veiller à bien configurer les règles de routage et de filtrage au niveau du firewall).
Dans le cas où nous n'utilisons pas de serveur WINS (ce qui doit être le cas de la quasi-totalité des réseaux modernes), nous laissons ces champs vides.

  • DNS servers : ce champ peut être renseigné ou resté vide. Si l'on souhaite passer au client la même configuration DNS que celle configurée dans pfSense, alors il faut laisser ces champs vides. En revanche, si l'on souhaite passer au client d'autres serveurs DNS que ceux configurés dans pfSense, ou si l'on souhaite que ce soit pfSense qui agisse comme serveur DNS, il faut renseigner les adresse IP correspondantes ici.
Pour les réseaux locaux avec des terminaux Windows et un serveur Active Directory, il est conseillé d'indiquer l'adresse du serveur Active Directory.

  • Gateway : si pfSense est la passerelle pour ce réseau, ce champ peut être laissé vide. Dans le cas contraire, nous indiquons ici l'adresse IP de la passerelle.

  • Domain name : permet d'indiquer aux clients le nom de domaine correspondant au réseau et donc qu'ils devront utiliser pour former leur FQDN. Si rien n'est indiqué, c'est le nom de domaine renseigné dans la configuration gloable de pfSense qui sera passé aux clients.

  • Domain search list : cette information est utile dans le cas où l'on dispose de plusieurs domaines.
Lors d'une recherche sur un nom d'hôte sur le réseau, le client concaténera le nom d'hôte au nom de domaine. Chaque domaine doit être séparé par un point-virgule. Cette information est passée au client via l'option DHCP 19. Donc, dans le cas où il n'y a qu'un seul domaine local, ce champ doit être laissé vide (lorsque qu'un client fera une recherche sur un nom d'hôte, la concaténation se fera avec le nom de domaine défini à la ligne précédente).

  • Default lease time et Maximum lease time : ces deux options permettent de contrôler la durée des baux DHCP.
Default lease time est utilisée quand un client ne demande pas de durée spécifique d'enregistrement pour son bail. Si le client demande une durée de bail qui est supérieure à Maximum lease time, la durée de bail donnée sera celle définie dans Maximum lease time. Ces valeurs sont définies en secondes.
Si les champs sont laissés vides, les valeurs par défaut sont de 7.200 secondes (2h) pour la durée de bail par défaut et 86.400 secondes (1 jour) pour la durée de bail max.

  • Failover peer IP : si vous possédez deux serveurs pfSense configurés en failover, renseignez ici l'adresse IP physique (pas l'adresse virtuelle) du second serveur pfSense. Autrement, laissez ce champ vide.

  • Static ARP : cette option est l'exact opposé de "Deny unknow clients" : elle permet de lister les machines capables de communiquer avec pfSense sur le réseau. Ainsi, tous les terminaux n'étant pas référencés (c'est-à-dire dont l'adresse MAC est connue et référencée dans pfSense) ne pourront pas communiquer avec pfSense. Il faut faire très attention lorsque l'on manipule cette option ! De plus, lorsqu'elle est cochée, cette option reste active même si le service DHCP est arrêté.

  • Time format change : par défaut, les durées de baux DHCP sont affichées au format UTC. En cochant cette option, elles sont formatées au fuseau horaire local. C'est une option d'affichage purement esthétique.

  • Statistics graphs : cocher cette option permet d'activer les graphiques RRD. Cette option est désactivée par défaut.

  • Dynamic DNS : cette option permet de définir un serveur DNS dynamique (à saisir dans le champ correspondant). Dans le cas où pfSense est configuré en mode "DNS forwarder", cette option ne devrait pas être cochée, et le DNS forwarder devrait être configuré en conséquence.

  • MAC Address Control : cette option permet de filtrer les accès au serveur DHCP par adresses MAC.
Le premier champ permet de définir les adresses MAC autorisées. Le second champ, les adresses MAC interdites. Ces adresses MAC peuvent être saisies partiellement (par exemple, saisir 01:E5:FF autorisera ou interdira, suivant le champ dans lequel elle aura été saisie, toutes les adresses MAC commençant par cette séquence).
Les adresses MAC (ou adresses MAC partielles) doivent être séparées par une virgule, sans espace. Ces champs peuvent être laissés vides si l'on ne souhaite pas appliquer de contrôle sur les adresses MAC des terminaux.

Il est important de comprendre qu'à partir du moment où une adresse MAC (ou adresse MAC partielle) est saisie dans le champ des adresses autorisées, toutes les autres adresses MAC seront interdites d'accès ; et inversement, si l'on saisi une ou des adresses MAC dans le champ des adresses interdites, toutes les autres adresses MAC seront autorisées.

Un exemple d'utilisation de cette fonctionnalité est la séparation des téléphones IP et des ordinateurs sur un même réseau sans utilisation de VLAN. En admettant que tous les téléphones IP disposent d'une adresses MAC commençant par aa:bb:cc, alors sur la plage d'adresses réservées aux ordinateurs, nous interdirons les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses interdites) ; et sur la plage d'adresse réservées à la VoIP, nous autoriserons uniquement les adresses MAC commençant par aa:bb:cc (en saisissant cette séquence dans le champ des adresses autorisées).


  • TFTP server : permet de saisir l'adresse IP ou le nom d'hôte d'un serveur TFTP. Cette option est principalement utilisée pour l'auto-provisioning pour la téléphonie sur IP. Elle correspond à l'option DHCP 66.

  • LDAP : permet d'envoyer l'URI d'un serveur LDAP aux clients en faisant la demande. Cela correspond à l'option DHCP 95. Le format saisi doit être celui d'une URI LDAP tel que ldap://ldap.example.com/dc=example,dc=com.

  • Network booting : pour activer cette fonctionnalité, il faut cocher la case correspondante (Enables network booting), saisir l'adresse IP du serveur ainsi que le nom du fichier d'image disque bootable. L'ensemble de ces champs doit être complété pour que cette option fonctionne correctement.

  • Additional BOOTP/DHCP Options : permet de pousser n'importe quelle option DHCP (dont nous détaillons le paramétrage au paragraphe suivant).

Une fois l'ensemble des configurations effectué, il ne reste plus qu'à cliquer sur Save !



Les options avancées du serveurs DHCP


L'une des grandes forces du serveur DHCP de pfSense est qu'il offre une interface de configuration simple pour la plupart des fonctionnalités DHCP. De plus, il permet également de délivrer l'intégralité des options DHCP. La liste des options DHCP possibles est disponible sur le site de l'IANA.

Plusieurs formats sont disponibles pour ces options DHCP. Les noms de ces formats pouvant être peu intuitifs, nous les détaillons ici :

Text : texte libre de forme.
String : une suite de chiffres hexadécimaux séparés par le caractère deux-points ":" (ex : 00:a8:c9)
Boolean : la valeur true ou la valeur false
Unsigned 8, 16, or 32-bit Integer : un nombre entier positif (supérieur à zéro), jusqu'à 86400
Signed 8, 16, or 32-bit Integer : un nombre entier positif ou négatif, jusqu'à -512
IP address or host : une adresse IP (ex : 192.168.1.2) ou un nom d'hôte (ex : www.example.com)



Exemple de configuration avancée : serveur DHCP pour ordinateurs et téléphones IP


Nous prendrons l'exemple d'une configuration où les postes téléphoniques et les ordinateurs se trouvent sur le même réseau (sans séparation par VLAN). Nous souhaitons regrouper les adresses IP des postes téléphoniques et celles des ordinateurs.

Dans notre exemple, nous utiliserons le plan d'adressage suivant : 192.168.2.0/24 ; le serveur pfSense dispose de l'adresse IP 192.168.2.1 ; le serveur de téléphonie de l'adresse IP 192.168.2.2.
Sur ce réseau, nous avons une vingtaine de postes informatiques et autant de postes téléphoniques.

Dans notre exemple, les téléphones IP ont tous une adresse MAC commençant par la séquences AA:BB:CC.

Nous souhaitons attribuer des adresses IP de 192.168.2.10 à 192.168.2.99 aux téléphones IP ; et des adresses IP de 192.168.2.100 à 192.168.2.199 aux autres terminaux (ordinateurs, imprimantes, etc.).


Le schéma de notre réseau est donc le suivant :

schéma réseau pfSense ordinateurs téléphones Provya



Nous configurons pfSense avec une première plage (champ Range) allant de 192.168.2.10 à 192.168.2.99 pour laquelle nous autorisons uniquement les adresses MAC (premier champ de l'option MAC Address Control) commençant par AA:BB:CC :

configuration DHCP voip pfSense Provya



Nous ajoutons ensuite une seconde plage (bouton "+ Add" de la section "Additional Pools") allant de 192.168.2.100 à 192.168.2.199 pour laquelle nous interdisons les adresses MAC (second champ de l'option MAC Address Control) commençant par AA:BB:CC :

configuration DHCP ordinateurs pfSense Provya


Notre configuration est terminée :

configuration deux pools DHCP pfSense Provya


Dernière étape : si un serveur d'auto-provisioning des téléphones IP est présent sur le réseau, on pourrait ajouter ce paramètre au serveur DHCP.



Pour aller plus loin


[pfSense] Configurer ses VLAN
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 un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Monter un accès OpenVPN site-à-site

icon 31/07/2019 - 25 commentaires

English version: [pfSense] Configuring a Site-to-Site OpenVPN Instance.

Nous allons voir dans cet article comment monter un VPN site-à-site entre deux environnements pfSense en nous reposant sur le logiciel OpenVPN.

Article mis à jour le : 31/07/2019


VPN site-à-site


OpenVPN permet de monter un VPN site-à-site de manière très simple et efficace.

L'un des sites est configuré comme client et l'autre site comme serveur.

Pour monter notre VPN, nous utiliserons ici le système de clés partagées.
Si avez peu de liens VPN site-à-site à monter, il est recommandé d'utiliser des clés partagées. Au delà de 5 à 6 liens VPN site-à-site, il peut être judicieux d'utiliser la gestion de certificat (SSL/TLS - PKI) par simplicité d'administration.



IPsec vs OpenVPN


Faut-il monter son VPN site-à-site avec OpenVPN ou IPsec ? Vaste question à laquelle nous ne répondrons pas ici ! :-)

Nous préciserons simplement qu'IPsec et OpenVPN peuvent tous les deux être actifs et en service en parallèle sur un même serveur pfSense. La seule contrainte étant, évidemment, de ne pas utiliser les mêmes sous-réseaux sur vos lien OpenVPN et IPsec.



OpenVPN Client & Serveur


OpenVPN est basé sur un mode de fonctionnement client-serveur. Qu'un pfSense soit défini comme client ou comme serveur ne changera strictement rien d'un point de vue réseau. Cependant, si vous souhaitez connecter plusieurs sites distants sur un site principal, le plus logique est bien-sûr de définir le site principal comme "serveur" et les sites distants comme "clients".

Dans cet article, nous prendrons l'exemple de configuration suivant :

Schéma réseau OpenVPN pfSense - Provya


Le pfSense du site A sera configuré comme serveur OpenVPN. Le pfSense du site B sera configuré comme client OpenVPN.



Configurer OpenVPN côté "serveur"


Sur le pfSense du site A, se rendre dans le menu VPN > OpenVPN. Vous serez par défaut dirigé sur l'onglet Servers :

menu VPN > OpenVPN - pfSense Provya


Cliquer sur le bouton "+ Add" pour ajouter un serveur VPN.

Les champs à configurer sont les suivants :

  • Server Mode : ici, nous avons cinq possibilités :
  1. Peer to peer (SSL/TLS) : pour monter un VPN site-à-site en utilisant une authentification par certificat.
  2. Peer to peer (Shared Key) : pour monter un VPN site-à-site en utilisant une authentification par clé partagée.
  3. Remote Access (SSL/TLS) : pour monter un accès distant pour clients nomades en utilisant une authentification par certificat.
  4. Remote Access (User Auth) : pour monter un accès distant pour clients nomades en utilisant une authentification par login/password.
  5. Remote Access (SSL/TLS + User Auth) : pour monter un accès distant pour clients nomades en utilisation une authentification par certificat et par login/password.
Nous choisissons Peer to peer (Shared Key).

  • Protocol : nous choisissons "UDP on IPv4 only".
L'utilisation du protocole TCP n'est pas adaptée à un environnement VPN, car en cas de pertes de paquets ceux-ci devront être retransmis. Ce qui n'est pas forcément souhaité. La conséquence serait un ralentissement du lien VPN à cause d'une forte ré-émission de paquets.
TCP est en revanche particulièrement intéressant si vous devez passer au travers d'une connexion particulièrement restrictive. Dans ce cas, l'utilisation du port 443 (correspondant au port HTTPS) est particulièrement judicieux (il est rare que le port 443 soit bloqué en sortie d'un réseau vers Internet). Attention toutefois, si vous choisissez le port 443, assurez-vous d'abord que le WebGUI de pfSense ne tourne pas déjà sur ce port !

  • Device Mode : nous choisissons tun
TUN travaille avec des frames IP.
TAP travaille avec des frames Ethernet.
  • Interface : l'interface sur laquelle le serveur va recevoir les connexions entrantes. Généralement WAN ou OPT1. Il est également possible de choisir "any" et dans ce cas le serveur sera en écoute sur toutes les interfaces.
  • Local port : port d'écoute du serveur OpenVPN. Par défaut, c'est le 1194. Il est à noter que chaque serveur VPN doit disposer de son propre port d'écoute. De la même manière, il est important de s'assurer qu'aucun autre service ne soit déjà en écoute sur le port choisi... y'en a qui ont essayé ils ont eu des problèmes :-)
  • Description : nom que l'on souhaite donner à ce serveur VPN. C'est ce nom qui apparaîtra dans les listes déroulantes de sélection de VPN se trouvant aux différents endroits du WebGUI pfSense. Dans notre cas, nous saisissons "VPN Provya".
  • Shared Key : nous conseillons de laisser coché la case "Automatically generate a shared key". La clé sera à copier/coller côté client.
  • Encryption algorithm : ce paramètre doit être le même côté client et côté serveur si l'une des deux parties ne supporte pas le protocole NCP. N'importe quel algorithme travaillant avec une clé d'au moins 128 bits sera bon. 256 bits sera encore mieux. CAST/DES/RC2 sont moins sécurisés, et donc à bannir. Notre choix se porte sur AES 256 bits CBC
  • Enable NCP : cocher la case permet d'activer le protocole NCP pour que le client et le serveur négocie le protocole de chiffrement le plus approprié. Nous laissons la case cochée.
  • NCP Algorithms : Les algortithmes de chiffrement que nous souhaitons supporter côté serveur.
  • Auth digest algorithm : nous laissons la valeur par défaut SHA256.
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique.
  • IPv4 Tunnel Network : réseau utilisé pour le tunnel VPN. N'importe quel réseau privé inutilisé dans l'espace d'adressage de la RFC 1918 peut être utilisé. Pour une connexion site-à-site, l'utilisation d'un /30 est suffisant (inutile d'utiliser un /24). Dans notre cas, nous utilisons le sous-réseau 10.0.8.0/30.
  • IPv4 Remote network(s) : désigne le ou les réseaux distants accessibles par le serveur. Il convient d'utiliser la notation CIDR (ex : 192.168.1.0/24). Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par une virgule. Dans notre cas, nous indiquons le réseau utilisé sur le site B, soit 192.168.2.0/24.
  • Concurrent connections : précise le nombre de connexion client possible en simultanée sur ce serveur. Dans le cas d'un VPN site-à-site, ce paramètre peut être renseigné à 1.
  • Compression : permet d'activer la compression LZO/LZ4 sur l'ensemble des flux transitant par ce tunnel VPN. Si les données transitant dans ce tunnel VPN sont principalement des données chiffrées (HTTPS, SSH, etc.), cocher cette option ne fera qu'ajouter un overhead inutile aux paquets.
  • Custom options : permet de passer des paramètres avancés à OpenVPN. Cela peut notamment être utile si l'on décide de faire du VPN natté (entre deux sites ayant le même plan d'adressage) ou pour pousser des routes spécifiques. Nous ne rentrerons pas dans le détail ici.

Une fois la configuration renseignée, nous cliquons sur "Save" pour valider notre configuration.

Exemple de résultat obtenu :

exemple configuration OpenVPN clée partagée pfSense Provya


La configuration openVPN est terminée côté serveur. Il faut maintenant ajouter les règles de filtrage pour rendre accessible le serveur openVPN.



Configuration du Firewall


Il est maintenant nécessaire d'autoriser le flux VPN au niveau du firewall. Pour cela, se rendre dans le menu Firewall > Rules :

menu Firewall > Rules pfSense Provya


Sur l'interface sur laquelle le serveur OpenVPN est en écoute (WAN, dans notre exemple), créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

Dans notre exemple, nous travaillons sur l'interface WAN, l'adresse IP du pfSense sur le site A est 109.190.190.10, et l'adresse IP publique du site B est 108.198.198.8. Ce qui donne la configuration suivante :

  • Interface : WAN
  • Protocol : UDP
  • Source : si l'adresse IP publique du site distant n'est pas connue on laisse any, sinon on la renseigne en choisissant le type "Single host or alias"
  • Destination : type "Single host or alias", address à 109.190.190.10
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN, soit 1194 dans notre cas.

Ce qui nous donne la règle suivante :

règle firewall openVPN server pfSense Provya



La configuration côté serveur est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN. Pour cela, se rendre dans Firewall > Rules > OpenVPN pour créer ses règles.

Exemple de règle à configurer sur l'interface LAN du pfSense du site A :

règle firewall openVPN pour trafic LAN vers LAN pfSense Provya


Exemple de règle à configurer sur l'interface OpenVPN du pfSense du site A :

règle firewall openVPN pour trafic LAN vers LAN pfSense Provya



Passons à la configuration côté client.



Configurer OpenVPN côté "client"


Sur le pfSense du site "client", se rendre dans VPN > OpenVPN, puis dans l'onglet "Clients".

Cliquer sur l'icône "+ Add" pour ajouter un client VPN.

Les champs à configurer sons sensiblement les mêmes que ceux côté serveur :

  • Server Mode : ici, nous avons deux possibilités :
  1. Peer to peer (SSL/TLS)
  2. Peer to peer (Shared Key)
Nous choisissons Peer to peer (Shared Key), conformément à ce que nous avons configuré côté OpenVPN serveur.

  • Protocol : choisir le même protocole que celui choisi côté serveur (soit UDP on IPv4 only)
  • Device mode : choisir tun
  • Interface : l'interface via laquelle le client OpenVPN va joindre le serveur. Dans notre cas, ce sera WAN
  • Local port : si ce champ est laissé vide, un port aléatoire sera choisi
  • Server host or address : l'adresse IP publique du site distant, c'est-à-dire l'adresse IP publique du site A dans notre cas (109.190.190.10)
  • Server port : port d'écoute du serveur OpenVPN distant (ici, 1194)
  • Proxy host or address : adresse du proxy si le pfSense client nécessite de passer par un proxy
  • Proxy port : idem ci-dessus
  • Proxy Authentification : idem ci-dessus
  • Description : le nom que vous souhaitez donner à votre tunnel VPN (ici, VPN Provya)
  • Auto generate / Shared Key : décochez la case "Auto generate" et copier/coller la clé générée côté OpenVPN serveur
  • Encryption algorithm : renseigner le même algorithme que celui saisi côté OpenVPN serveur (AES-256-CBC). Cet algorithme sera utilisé uniquement si NCP n'est pas activé ou supporté
  • NCP Algorithms : les mêmes que ceux sélectionnés côté serveur
  • Auth digest algorithm : on laisse la valeur par défaut, soit SHA256
  • Hardware Crypto : précise si le serveur dispose d'un support cryptographique
  • IPv4 Tunnel Network : même réseau que celui renseigné côté OpenVPN serveur, soit 10.0.8.0/30
  • IPv4 Remote Network(s) : on renseigne le réseau du site distant. Il convient d'utiliser la notation CIDR. Dans le cas où l'on souhaite indiquer plusieurs réseaux, il faut les séparer par une virgule. Dans notre cas, cela donne : 192.168.1.0/24
  • Limit ourgoing bandwidth : bande-passante maxi allouée à ce tunnel VPN. Laisser vide pour ne pas fixer de limite.
  • Compression : doit être similaire à la configuration côté OpenVPN serveur
  • Advanced : permet de passer des paramètres avancés à OpenVPN. Nous ne rentrerons pas dans le détail ici.

Exemple de résultat obtenu :

exemple configuration openVPN client clée partagée pfSense Provya



La configuration côté client est terminée. Il nous reste simplement à penser à autoriser ou filtrer nos flux transitant à travers notre nouvelle interface OpenVPN.

Exemple de règle à configurer sur l'interface LAN du pfSense du site B :

règle firewall openVPN pour trafic LAN vers LAN pfSense Provya


Exemple de règle à configurer sur l'interface OpenVPN du pfSense du site B :

règle firewall openVPN pour trafic LAN vers LAN pfSense Provya




Debug


Pour disposer d'informations sur vos liens OpenVPN (état, date de début de mise en service, volume entrant/sortant, etc.), se rendre dans Status > OpenVPN.

Pour les logs du firewall, se rendre dans Status > System logs > Firewall.



Pour aller plus loin


[pfSense] La gestion des certificats pour les connexions OpenVPN
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN
[pfSense] Configurer un VPN IPsec site à site
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Best practices / Recommandations pour la configuration de votre firewall

icon 25/06/2019 - 1 commentaire

Nous présentons dans cet article les meilleures pratiques pour la configuration des règles de filtrage sur un firewall. Nous prendrons comme exemple la configuration d'un firewall pfSense, mais l'ensemble de ces recommandations est applicable aux autres firewall du marché.

Pour l'écriture de cet article, nous nous sommes basés sur les recommandations émises par l'ANSSI à travers ses publications Recommandations pour la définition d’une politique de filtrage réseau d’un pare-feu et Recommandations et méthodologie pour le nettoyage d’une politique de filtrage réseau d’un pare-feu.



Recommandations générales


La définition d'une politique de gestion d'un pare-feu doit être structurée et normée afin que tous les intervenants manipulant la configuration de l'équipement disposent d'un référentiel de travail clair et d'une manière de procéder qui soit uniforme.

Pour cela, nous recommandons l'application des principes suivants :


1. La configuration se fait sur l'interface d'arrivée du paquet


Lorsque l'on configure des règles de filtrage sur un pare-feu, deux approches sont possibles : appliquer le filtrage lorsque le paquet réseau arrive sur le pare-feu, on parle alors de filtrage de type ingress, ou appliquer le filtrage lorsque le paquet réseau quitte le pare-feu, on parle alors de filtrage de type egress.

C'est-à-dire que pour filtrer du trafic allant, par exemple, du réseau LAN vers Internet ou le réseau WAN, la configuration doit être effectuée sur l'interface LAN.
Ce mode de fonctionnement est d'ailleurs le seul proposé sur pfSense (filtrage sur l'interface d'arrivée des paquets).

Pour être tout à fait précis, pfSense peut faire un filtrage sur l'interface de sortie du pare-feu depuis les règles de floating ; mais ce n'est clairement pas le but premier des règles de floating.


2. Il faut être le plus précis possible


Dans l'écriture des règles de filtrage, il faut toujours être le plus précis possible. Plus une règle sera précise et mieux cela sera. D'une part car l'on sera certain que seul le trafic voulu correspondra à cette règle, et d'autre part cela facilitera grandement la lecture et la compréhension des règles de filtrage.

Ainsi, dès que l'on connaît l'adresse IP, le réseau source ou le réseau destination, le port de destination, le protocole (TCP, UDP, ...), il faut le préciser dans sa règle.

Dans l'organisation de sa politique de filtrage, il est également important de classer les règles des plus précises aux plus larges.
Les règles très précises (concernant seulement quelques postes, par exemple) seront placées avant les règles plus larges (concernant tout le réseau local, par exemple).


3. Toujours préciser la source pour les interface internes


Il est important de systématiquement préciser l'adresse IP source ou le réseau source lorsque les paquets à filtrer proviennent du réseau local. En effet, dans ce cas, les adresses IP sources ou le réseau source sont connus. Il n'y a donc pas de raison de laisser la source en "any" ou *.

Pour rappel, dans les règles de filtrage de pfSense, la valeur "LAN address" correspond à l'adresse IP du firewall sur son interface LAN (192.168.1.1, par exemple) et la valeur "LAN net" correspond à tout le sous-réseau de l'interface LAN (192.168.1.0/24, par exemple).


4. Préciser la destination lorsqu'elle est connue


Dès qu'il est possible d'identifier la destination d'un flux réseau, il est important de ne pas laisser une destination générique dans ses règles de filtrage.
Par exemple, si l'on souhaite autoriser le trafic DNS à destination des serveurs Quad9, il n'y aucune raison de ne pas préciser les adresses IP des serveurs Quad9 dans la règle de filtrage associée.
De la même manière pour les envois d'e-mails, il n'y a pas de raisons d'autoriser le trafic SMTP vers une autre destination que son serveur relais de courriels.

Être le plus précis possible dans ses règles de filtrage est un gage de sécurité pour le réseau, les utilisateurs et les données.
L'utilisation d'une destination générique (any ou *) doit être réservée uniquement pour le trafic dont on ne peut réellement pas connaître la destination.


5. Utiliser des alias


L'utilisation d'alias permet un gain notable en lisibilité et permet de regrouper sur une seule règle de filtrage des adresses IP ou des ports associés.
Il est à noter que certains firewall obligent à l'utilisation d'alias dans l'écriture de leurs règles : il n'est pas possible de saisir une règle de filtrage comportant des adresses IP ou des ports réseaux ; il faut forcément qu'ils aient été préalablement renseignés dans des alias. pfSense n'impose pas ce mode de fonctionnement.

Sous pfSense, la création des alias se fait depuis le menu Firewall > Aliases :

menu Firewall - Aliases pfSense - Provya


Les alias sont à regrouper par domaine fonctionnel. On peut, par exemple, créer un alias pour le surf Web contenant les ports HTTP et HTTPS.

Exemple, sous pfSense :

Création d'un alias sous pfSense


Il faudra, bien sûr, penser à sauvegarder puis appliquer les changements.


6. Ventiler et regrouper ses règles


La plupart des firewall modernes offrent la possibilité d'utiliser des séparateurs ou des couleurs pour ventiler et/ou regrouper les règles entre elles. Si votre firewall ne dispose pas de cette fonctionnalité, pensez à migrer vers pfSense. ;-)

Cette ventilation et organisation permet une plus grande lisibilité des règles et permet une administration de la solution beaucoup plus rapide.


7. Commenter, commenter, commenter


Pour conserver une compréhension de l'historique de l'implémentation des règles, il est indispensable de compléter le champ commentaire afin d'y faire figurer des informations utiles.

Dans le champ commentaire, nous pouvons par exemple faire figurer les informations suivantes :
  • le succinct descriptif fonctionnel à l'origine de la création de la règle ;
  • la date d'implémentation de la règle (cette information est gérée automatiquement par pfSense) ;
  • la référence de la demande (n° de ticket ou code projet) ;
  • le nom ou le matricule de la personne qui a créé ou modifié la règle (cette information est gérée automatiquement par pfSense, à condition que tout le monde n'utilise pas le compte "admin" par défaut...)



Ordre des règles de filtrage


Une fois les recommandations générales appliquées, nous classons nos règles de filtrage suivant l'ordre présenté ci-dessous.


1/5. Règles d'autorisation des flux à destination du pare-feu (administration ; services hébergés sur pfSense)


Dans l'idéal, le firewall doit être administré depuis une interface dédiée. S'il ne dispose pas d'une interface dédiée, il faut, a minima, définir les adresses IP sources autorisées.
Une bonne manière de faire peut être de prendre la main sur un serveur de rebond (serveur TSE, par exemple), puis se connecter sur le firewall. Dans ce cas, seul le serveur de rebond est autorisé à accéder à l'interface d'administration du pare-feu.

Le nombre de flux ouverts doit être limité au strict minimum (HTTPS + SSH - si nécessaire - dans le cas de pfSense)

On trouvera également les règles autorisant la supervision du firewall (snmp par exemple) et les services hébergés sur le firewall (Squid, OpenVPN, DHCP, NTP, ...).
Pour ces règles, les adresses IP sources et destinations seront précisées.

On activera les logs pour ces règles afin de pouvoir retrouver a posteriori tout accès anormal ou frauduleux.

Exemple de la mise en place de ces règles pour pfSense :

exemple de règles d'accès au firewall pfSense pour l'administration



2/5. Règles d'autorisation des flux émis par le pare-feu (pfSense n'est pas concerné)


On y retrouve : les règles autorisant l'envoi des logs du firewall vers le serveur de journalisation (un serveur syslog, par exemple), les règles autorisant les services d'alerte de la passerelle (alerte par e-mail, smtp, etc.), les règles autorisant les services qui permettent le MCO de la passerelle (les flux de sauvegardes - ssh par exemple).

Dans tous les cas, la destination doit être précisée (on n'utilisera pas une destination "any" ou *).

On activera les logs pour ces règles également.

/!\ pfSense n'est pas concerné par ces règles. En effet, pfSense effectue un filtrage sur les paquets arrivant sur ses interfaces. Ainsi, les paquets émis par le firewall ne sont pas filtrés.

Si l'on souhaite filtrer le trafic émis par pfSense, on peut utiliser des règles floating sur lesquelles seront appliquées un filtrage dans le sens OUT.
Attention cependant, si on applique un filtrage par ce biais, on va également filtrer le trafic issu du LAN qui aurait pris l'adresse IP du firewall (SNAT / Outbound NAT). Il faudrait alors procéder à un marquage des paquets pour identifier plus précisément leur origine. Mais ce sujet n'est pas le propos de cet article.


3/5. Règles de protection du pare-feu (règles spécifiques)


Dans la logique de tout ce qui n'est pas explicitement autorisé doit être interdit, il convient de placer une règle de filtrage interdisant tous les services depuis toutes les sources à destination de toutes les interfaces du firewall.
Cela permet de rendre le firewall invisible et bloquer tous les services inutiles.

On activera les logs pour cette règle.

exemple de règles interdisant l'accès au firewall pfSense



4/5. Règles d'autorisation des flux métiers


Il est recommandé d'organiser ses règles suivant une logique métier. Plusieurs approches sont possibles :
  • une organisation par entité métier (regroupement des règles du service comptabilité, des ressources humaines, du service achat, etc.) ;
  • une organisation par fonctions & services offerts : accès aux bases de données, accès à l'intranet, accès au serveur de messagerie, accès à Internet, etc.

Ces règles doivent être adaptées au contexte et conserver une logique entre elles (il ne faut pas passer d'une logique d'entité à une logique de fonctions en cours de route, par exemple).
Les adresses sources, destinations et les services doivent impérativement être précisés dans ces règles.
Ces règles constituent l'essentiel de la politique de filtrage.

Exemple de résultat obtenu sur un pfSense :

exemple de règles d'autorisations métier



5/5. Règle d'interdiction finale (inutile pour pfSense)


Tout ce qui n'a pas explicitement été autorisé précédemment doit être bloqué.
C'est le mode de fonctionnement par défaut de pfSense : default deny.
Il n'est donc pas nécessaire d'ajouter une règle spécifique pour pfSense.

Par défaut, ces paquets sont loggués par pfSense, ce qui permet de garder une trace de ces flux non légitimes (ou d'aider à faire du troubleshooting en cas d'erreur ou d'anomalie dans la configuration des règles précédentes).


En appliquant cette stratégie, nous obtenons l'exemple complet suivant :

exemple de règles de filtrage sur un firewall pfSense


Nous vous recommandons de suivre ces principes d'organisation de vos règles de filtrage. La maintenance de votre firewall en sera facilitée, ainsi que vos sessions de troubleshooting et analyses !



Pour aller plus loin


[pfSense] Troubleshooting / Dépannage de ses règles de filtrage
[pfSense] Bien choisir et dimensionner son firewall
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Comprendre la priorisation de trafic

icon 05/06/2019 - 16 commentaires

Dans pfSense, il existe 3 principaux mécanismes de priorisation de flux :

- CBQ - Class Based Queueing
- PRIQ - Priority Queueing
- HFSC - Hierarchical Fair-Service Curve

PRIQ est un protocole de priorisation très simple (simpliste ?) mais nécessitant de faire très attention dans sa configuration.

CBQ est sans doute le protocole à utiliser dans la plupart des cas pour une entreprise souhaitant une gestion de la priorisation de trafic simple et efficace.

HFSC est sans conteste le protocole le plus évolué permettant un niveau de souplesse avancé, au prix d'une forte complexité...


Nous nous proposons ici de passer en revue ces différents mécanismes.
Dans un prochain article, nous verrons comment les mettre en œuvre dans pfSense.



CBQ - Class Based Queueing


CBQ est un algorithme permettant de diviser la bande passante d'une connexion en multiples queues ou classes.
Le trafic est assigné à l'une des queues, en fonction du protocole source/destination utilisé, du numéro de port, de l'adresse IP, etc.

Chaque queue se voit attribuer une bande passante et une priorité.

Les queues CBQ sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Il est également possible d'autoriser une queue à utiliser la bande passante de sa queue parente si celle-ci est sous-utilisée.


Exemple :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
	- Queue 2 (2Mbps)
	- Queue 3 (1Mbps)

La somme de la bande passante attribuée aux queues filles ne peut pas être supérieure à la bande passante totale de la queue mère.
Ainsi, dans notre exemple, la somme des bandes passantes des queues 1, 2 et 3 ne peut être supérieure à la bande passante de la queue Root.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Pour chacune de ces queues, on peut activer l'emprunt ("borrow") de bande passante à sa queue mère :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps - borrow)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Dans l'exemple ci-dessus, la queue VoIP dispose d'une bande passante de 1Mbps. Cependant, elle peut potentiellement utiliser jusqu'à 2Mbps (bande passante allouée à sa queue mère - Queue 1) si la queue SSH n'est pas pleine.

Une priorité est attachée à chaque queue. La priorité la plus forte sera préférée en cas de congestion. Si deux queues ont la même priorité, la distribution s'opère suivant un processus de type round-robin.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps - borrow, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)

Dans notre exemple ci-dessus, la queue 1 et la queue 2 ayant la même priorité, aucune des deux queues ne sera priorisée l'une par rapport à l'autre. Durant le temps où la queue 1 sera traitée, les queues filles seront traitées en même temps. La queue VoIP sera traitée en priorité par rapport à la queue SSH (en cas de congestion).
Il est à noter qu'uniquement les queue fille de la même queue mère sont comparées entre-elles (c'est-à-dire que la priorité de la queue VoIP sera comparée à la priorité de la queue SSH, mais ne sera pas comparée à la queue HTTP par exemple).


Davantage d'informations sur le protocole CBQ : CBQ sur openbsd.org - EN



PRIQ - Priority Queueing


PRIQ est un protocole permettant de définir plusieurs queues attachées à une interface et d'y affecter une priorité. Une queue avec une priorité supérieure sera toujours traitée avant une queue avec une priorité plus faible.
Si deux queues ont à la même priorité, la distribution se fera suivant le processus round-robin.

La construction des queues PRIQ est plate (il n'y a pas de notion de queue mère et de queue fille) - il n'est pas possible de définir une queue au sein d'une autre queue.

Une queue "ROOT" (racine) est définie, qui sera la bande passante totale de la connexion. Les autres queues sont définies sous la queue ROOT.

Exemple :

Root Queue (2Mbps)
	- Queue 1 (priorité 2)
	- Queue 2 (priorité 1)

La queue Root est définie comme disposant de 2Mbps. La queue 1 disposant de la plus forte priorité, l'ensemble de ses paquets seront traités en priorité. Tant qu'il existe des paquets dans la queue 1, la queue 2 ne sera pas traitée.
Dans chaque queue, les paquets sont traités dans l'ordre FIFO (First IN First OUT).

/!\ Attention : il est bien important de comprendre que dans le processus PRIQ, les paquets se trouvant dans les queues disposant de la priorité la plus élevée sont toujours traités avant les paquets des autres queues.
Ainsi, si une queue disposant d'une priorité élevée reçoit un flux de paquet continu, les queues disposant d'une priorité plus faible seront peu, voire pas traitées.


Davantage d'informations sur le protocole PRIQ : PRIQ sur openbsd.org - EN



H-FSC


HFSC est un algorithme évolué de traitement hiérarchique permettant de répartir la bande passante d'un lien et de contrôler l'allocation de ressources en fonction de la bande passante et de la latence.

Tout comme dans l'algorithme CBQ, les queues HFSC sont organisées de manière hiérarchique. Au sommet, nous retrouvons la queue "ROOT" (racine).
Chaque queue fille partage la bande passante de sa queue mère.

Chaque queue fille peut elle-même avoir des queues filles :

Root Queue (5Mbps)
	- Queue 1 (2Mbps)
		Queue VoIP (1Mbps)
		Queue SSH (1Mbps)
	- Queue 2 (2Mbps)
		Queue HTTP (800Kbps)
		Queue VNC (200Kbps)
	- Queue 3 (1 Mbps)

Une priorité est donnée à chaque queue. Les priorités vont de 0 (priorité la plus faible) à 7 (priorité la plus forte). Comme pour CBQ, ces priorités ne sont appliquées qu'en cas de saturation du lien.

Root Queue (5Mbps)
	- Queue 1 (2Mbps, priorité 1)
		Queue VoIP (1Mbps, priorité 5)
		Queue SSH (1Mbps, priorité 3)
	- Queue 2 (2Mbps, priorité 1)
		Queue HTTP (800Kbps, priorité 1)
		Queue VNC (200Kbps, priorité 2)


Qlimit


Chaque queue se voit attribuée en plus un paramètre "Qlimit". Qlimit correspond à un buffer (tampon) qui va se remplir lorsque la bande passante attribuée à la queue sera saturée : plutôt que de rejeter les nouveaux paquets arrivant, ceux-ci vont être mis en file d'attente dans ce buffer.

La valeur de Qlimit (la taille du buffer donc) est exprimée en nombre de paquets. Par défaut, sa valeur est de 50.

Un fois que le buffer définit par Qlimit est saturé, les nouveaux paquets sont supprimés (drop).

Il n'est pas nécessaire, et sûrement contre-productif, de définir une valeur trop grande pour Qlimit : cela ne solvera pas un problème de saturation de bande-passante. Une trop grande valeur peut entraîner un "buffer bloat".

Pour calculer la bonne valeur de Qlimit, il faut se demander combien de temps nous souhaitons garder un paquet dans le buffer.

Si le concept de MTU ou de latence ne vous est pas familier, lisez tout d'abord les liens cités précédemment.

Si l'on souhaite qu'un paquet reste bufferisé au maximum 0,5 seconde (ce qui est déjà long), le calcul à effectuer pour connaître la valeur de Qlimit est le suivant :

(BP / 8) / MTU = nb paquets/sec.
Avec :
BP : bande passante (en bits/s)
MTU : MTU du lien (en bytes)

Par exemple, si nous disposons d'un lien offrant 10Mbps en upstream ayant une MTU de 1500 bytes :

(10.000.000 / 8) / 1500 = 833 pq/sec

Soit, si l'on souhaite une bufferisation de 0,5 sec sur notre lien : 833x0,5 = 416 paquets (=valeur de notre Qlimit)

Si vous ne souhaitez pas vous lancer dans de tels calculs, laissez la valeur par défaut de Qlimit (50 paquets).


realtime


Ce paramètre permet de définir la bande-passante minimale garantit en permanence à la queue.


upperlimit


Le paramètre upperlimit permet de définir une limite haute de bande passante que la queue ne pourra jamais dépasser.
Cela permet, par exemple, de limiter l'usage fait de la bande passante pour un type de service ou d'utilisateurs.


linkshare


Ce paramètre remplit la même fonctionnalité que le paramètre "bandwith" définit plus haut. C'est-à-dire qu'il permet de définir la bande-passante disponible pour une queue ; cette bande-passante pouvant être empruntée à d'autres queues.

Aussi, si nous définissons le paramètre "bandwith" ET le paramètre "link share (m2)", c'est le paramètre "linkshare m2" qui sera pris en compte.


Ainsi, nous avons les paramètres suivants :
  1. realtime : bande-passante minimale garantie à une queue
  2. linkshare : bande-passante globale attribuée à la queue (utilisée une fois que realtime est plein)
  3. upperlimit : bande-passante maximale que la queue ne pourra jamais dépassée
  4. bandwith : redondant avec linkshare. Peut être utilisé si l'on ne souhaite pas utiliser le mécanisme NLSC.

Il est important de comprendre que le paramètre "linkshare" n'est utile que si l'on souhaite activer le mode NLSC (non linear service curve). Autrement, seul le paramètre "bandwith" peut être utilisé dans le paramétrage des queues.


NLSC


NLSC est un mécanisme permettant de définir une bande-passante initiale, puis après un certain temps, une bande-passante définitive.
Ainsi, on va pouvoir définir une bande-passante qui va évoluer dans le temps.

Il existe 3 paramètres pour la configuration de NLSC :
  1. m1 : bande passante initiale attribuée à la queue
  2. m2 : bande passante définitive attribuée à la queue
  3. d : durée (en ms) durant laquelle la bande passante attribuée à la queue est la bande passante initiale (m1), avant de devenir la bande passante définitive (m2)

NLSC est principalement utilisé dans le but d'offrir un maximum de bande-passante sur un certain laps de temps, puis de brider cette bande-passante. Ainsi, ce "bridage" n'impacte que les gros fichiers transitant dans la queue concernée.

NLSC est activable aussi bien sur les directives realtime, upperlimit et linkshare.
Si l'on ne souhaite pas faire évoluer la bande-passante dans le temps, seul le paramètre m2 doit être défini.


Options


Il existe plusieurs options que l'on peut définir sur nos queues. Actuellement, elles sont au nombre de quatre :
  1. Default queue : permet de définir la queue par défaut. Il ne peut y avoir qu'une seule queue par défaut par interface.
  2. Explicit Congestion Notification (ECN) : ECN permet d'envoyer une notification de congestion sur le réseau afin de limiter le "drop" de paquets. N'est utilisable qu'entre deux équipements le supportant.
  3. Random Early Detection (RED) : utilisé avec ECN, offre un mécanisme de détection de congestion (avant qu'elle n'ait lieu).
  4. Random Early Detection In and Out (RIO) : idem RED.

Nous ne recommandons pas l'usage des paramètres RED, RIO et ECN.

Une fois tous ces paramètres appliqués, si nous reprenons notre exemple de queues définit précédemment :

Root Queue (5Mbps)
	- Queue 1 (2Mbps, upperlimit: 3Mbps, realtime: 1Mbps)
		Queue VoIP (1Mbps, realtime: 1Mbps, qlimit: 500)
		Queue SSH (1Mbps, qlimit 500)
	- Queue 2 (2Mbps, upperlimit: 3Mbps, default)
		Queue HTTP (800Kbps, realtime: 500Kbps)
		Queue VNC (200Kbps, qlimit: 500)


Nous venons de passer en revu les 3 principaux mécanismes de priorisation de trafic proposés dans pfSense.

Dans un prochain article, nous verrons comment les configurer et les activer dans pfSense.



Pour aller plus loin


[pfSense] Configurer la priorisation de trafic avec CBQ
[pfSense] Utiliser les limiters pour contrôler la bande-passante par utilisateur
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer ses VLAN

icon 18/05/2019 - 21 commentaires

Dans cet article, nous allons voir comment configurer ses VLAN avec pfSense. Nous aborderons la terminologie associée (trunk port, tagged / untagged port, etc.), puis nous prendrons un exemple concret de configuration de VLAN.



Intérêt des VLAN


L'utilisation de VLAN apporte un certain nombre d'avantages que nous ne détaillerons pas ici. Pour une bonne compréhension des VLAN, nous proposons la lecture de l'article VLAN - Réseaux virtuels sur commentcamarche.net

Les utilisations principales de VLAN sont :
  • séparation logique des réseaux Voix & Data
  • séparation logique des services d'une entreprise
  • mise en place d'un réseau invité différent du réseau local



Mode de fonctionnement des VLAN


Lorsque nous créons un VLAN, nous définissons deux éléments :
  • le subnet associé (ex : 192.168.1.0/24)
  • l'ID du VLAN (allant de 1 à 4094)

Les terminaux se trouvant sur un VLAN ne pourront communiquer qu'avec les autres terminaux se trouvant sur le même VLAN. S'ils souhaitent communiquer avec les terminaux d'un autre VLAN, les paquets passeront par pfSense. Cela nous permet de configurer au niveau de pfSense des règles fines de filtrage d'un VLAN à un autre.
Il est à noter que le routage d'un VLAN à l'autre peut également se faire au niveau du switch via la mise en place d'ACL (cas que nous n'aborderons pas dans le présent article).

Les VLANs doivent être déclarés et configurés côté pfSense d'une part, et sur les switches d'autre part (qui doivent bien-sûr être des switches supportant les VLAN).
La configuration des switches est le point le plus délicat. La terminologie employée n'étant pas toujours la même chez les constructeurs.



Terminologie


Lorsque nous souhaitons configurer les VLAN sur notre switch, nous avons deux possibilités de configuration :

  • tagged port (= trunk port chez Cisco)
  • untagged port (= access port chez Cisco)


Tagged port


Un port de switch configuré en "tagged" signifie que l'équipement branché derrière est capable de traiter les tags 802.1q et qu'il est configuré pour les traiter. C'est-à-dire qu'il faudra indiquer dans la configuration de l'équipement qu'il doit marquer ses paquets réseau avec son VLAN d'appartenance.


Untagged port


Un port de switch configuré en "untagged" signifie que la notion de VLAN est totalement transparente pour l'équipement branché derrière. C'est-à-dire qu'il ignore son VLAN de rattachement. C'est le switch qui utilise l'id VLAN associé pour son traitement interne pour la distribution des paquets sur ses ports. Les paquets ne sont pas taggués 802.1q en entrée et sortie des ports du switch configurés en "untagged".

Un switch ne peut avoir sur un port donné qu'un seul VLAN configuré en "untagged" (access). Il peut y avoir, sur ce même port, plusieurs VLANs configurés en "tagged" (trunk).



Cas concret : séparation VLAN voix / VLAN data


Un cas concret et classique d'utilisation des VLAN va être de séparer le réseau VoIP du réseau Data.

Nous prendrons l'exemple du réseau local suivant :

  • pfSense fait office de routeur/firewall et de serveur DHCP pour l'ensemble des VLAN
  • Les ordinateurs (et tous les autres équipements sauf téléphones) disposent d'une adresse IP sur la plage 192.168.1.0/24 - VLAN 10 (ce sera notre VLAN par défaut - configuré en untagged)
  • Les postes téléphoniques disposent d'une adresse IP sur la plage 192.18.2.0/24 - VLAN 20 (VLAN dédié à la téléphonie - configuré en tagged)
  • Le switch de cœur de réseau est un switch supportant les VLAN
  • Tous les ordinateurs sont branchés derrière un téléphone. C'est-à-dire que sur chaque port du switch il y aura généralement deux équipements branchés : un téléphone (dans le VLAN 20) et un ordinateur (VLAN 10) branché derrière

Le schéma réseau est le suivant :

Schéma réseau




Configuration du pfSense


Sur le pfSense, nous configurerons donc deux VLANs :
  • VLAN "LAN Data"
  • VLAN "LAN VoIP"

Pour commencer, nous allons dans le menu "Interface" > "(assign)" :

menu Interfaces > Assignments


Puis, nous nous rendons dans l'onglet "VLANs" et cliquons sur l'icône en forme de "+" se trouvant en bas à droite.

Les éléments de configurations sont les suivants :

  1. Parent interface : l'interface physique à laquelle sera rattachée le VLAN
  2. VLAN tag : l'ID du VLAN (la valeur doit être comprise entre 1 et 4094)
  3. VLAN Priority : la priorité à appliquer au VLAN (la valeur doit être comprise entre 0 et 7)
  4. Description : champ optionnel de description du VLAN

Exemple de résultat obtenu :

Configuration VLAN pfSense


Et une fois nos deux VLANs créés, nous disposons de deux interfaces virtuelles :

Exemples VLAN pfSense


Afin de configurer nos VLANs, nous devons maintenant associer ces interfaces virtuelles à des interfaces logiques.
Pour cela, nous retournons dans l'onglet "Interface assignments", puis nous cliquons sur l'icône en forme de "+" se trouvant un bas à droite afin d'ajouter une nouvelle interface logique.

Par défaut, l'interface logique créée porte le nom "OPT1" (ou OPT2, OPT3, etc.). Nous associons cette interface logique à l'interface virtuelle du VLAN que nous avons créée précédemment :

Création interface logique pfSense


Pour modifier l'interface logique créée (et la renommer), nous cliquons sur son nom. Les éléments de configuration sont les suivants :

  1. Enable Interface : cocher cette case pour activer l'interface
  2. Description : nom de l'interface
  3. IPv4 Configuration Type : la configuration IPv4 de cette interface. Dans notre cas, nous choisissons "Static IPv4"
  4. IPv6 Configuration Type : la configuration IPv6 de cette interface. Dans notre cas, nous choisissons "None"
  5. MAC controls : par défaut, c'est l'adresse MAC de l'interface physique qui est utilisée. Elle peut être personnalisée ici
  6. MTU : la MTU pour cette interface. 1500 octets par défaut
  7. MSS : "Maximum Segment Size", devrait être inférieur au MTU. Nous laissons vide
  8. Speed and duplex : nous laissons le choix par défaut

Enfin, nous appliquons les paramètre de configuration IP (adresse IP de l'interface et masque réseau associé).
Exemple de résultat obtenu :

Configuration interface logique pfSense


Sur cette interface, nous activons le service DHCP. Pour davantage de détails sur la manière de procéder pour l'activation du service DHCP, se référer à notre article dédié : [pfSense] Configurer son serveur DHCP.

Enfin, nous créons une règle de firewall sur notre nouvelle interface logique ("VLAN_voix") afin d'autoriser le trafic.

La configuration côté pfSense est terminée. Il reste à procéder à la configuration côté Switch.



Configuration du Switch


La configuration des VLAN sur le switch dépend du constructeur. Cependant, les étapes à suivre seront toujours les mêmes :

  1. Déclaration des VLAN sur le switch - sur la plupart des switches, il faut déclarer les VLANs avant de pouvoir les configurer sur n'importe quel port (dans notre cas, nous déclarons 2 VLAN : vlan_data avec l'ID 10 et vlan_voix avec l'ID 20)
  2. Configuration du port du switch sur lequel est branché le pfSense en mode trunk (ou tagged) sur les VLAN 10 et 20
  3. Configurer les ports du switch sur lesquels seront branchés les PC en mode access (ou untagged) - dans notre cas sur le VLAN 10
  4. Configurer les ports du switch sur lesquels seront branchés les téléphones en mode trunk (ou tagged) - dans notre cas sur le VLAN 20

Exemple sur un switch Cisco :

Déclaration des VLANs :
sw# vlan database
sw(vlan)# vlan 10 name "vlan_data"
sw(vlan)# vlan 20 name "vlan_voix"
sw(vlan)# exit

Configuration du port trunk :
sw# configure terminal
sw(config)# interface FastEthernet0/24
sw(config-if)# switchport mode trunk

Ajouter les ports au VLAN :
sw# configure terminal
sw(config)# interface FastEthernet0/12
sw(config-if)# switchport mode access
sw(config-if)# switchport access vlan 20


Nos VLANs sont configurés et prêts à fonctionner.



Peut-on configurer un VLAN sur le port LAN ?


Réponse succincte : oui.

Sur les anciennes versions de pfSense (antérieures à la version 2.4.5), il était très fortement recommandé par l'éditeur de ne pas configurer un VLAN sur un port réseau qui était déjà associé à une interface logique.
Si les notions de port réseau, interface physique, interface virtuelle et interface logique ne vous sont pas familières, nous vous invitons à consulter notre article [pfSense] Comprendre la gestion des interfaces réseaux.

Cette configuration entraînait des anomalies de fonctionnement pour un certain nombre de services (dont le portail captif).

Ce n'est plus du tout le cas aujourd'hui. On peut donc tout à fait configurer ses VLAN sur un port réseau déjà associé à une interface logique !



Pour aller plus loin


[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban

icon 14/05/2019 - Aucun commentaire

Héberger son serveur Asterisk sur un cloud public, ou d'une façon générale rendre son serveur Asterisk accessible sur Internet peut être une nécessité ou une facilité d'usage, mais cela implique de le sécuriser avec la plus grande précaution afin d'éviter les mauvaises surprises...

Bonne nouvelle, il est possible de se protéger très facilement en adoptant une démarche pragmatique, en réalisant une simple configuration d'Asterisk et en adoptant les outils fail2ban et iptables.

Cet article est dédié à la sécurisation d'un serveur Asterisk.
Cet article n'est pas un tuto détaillé sur la configuration du logiciel Asterisk.



fail2ban & iptables, qu'est-ce que c'est ?


iptables est un outil accessible en ligne de commande sur n'importe quel serveur GNU/Linux permettant de configurer des règles de filtrage des flux réseaux entrants et sortants d'un serveur. C'est un véritable pare-feu intégré à la machine.
Pour être tout à fait précis, iptables est une interface utilisateur au framework Netfilter qui implémente un pare-feu au sein du noyau Linux.

fail2ban est un outil d'analyse de journaux (log) dont l'objectif premier est de détecter des tentatives d'intrusions ou de connexions infructueuses sur un service et de bannir les adresses IP à l'origine de ces tentatives d'intrusion.

Le trio d'une configuration d'Asterisk pragmatique + fail2ban + iptables va nous permettre de nous mettre en sécurité contre la quasi-totalité des attaques que peut subir notre serveur Asterisk.



[1/4] Pour commencer : soyons pragmatiques


Pour sécuriser Asterisk, il est important d'adopter une approche logique et pragmatique. Pour cela, nous respecterons deux règles très simples :
  1. n'autoriser que ce qui est nécessaire. C'est-à-dire que l'on n'activera pas les services que l'on n'utilise pas d'une part, et que l'on appliquera des filtrages par adresse IP lorsque cela est possible d'autre part.
  2. ne pas utiliser un identifiant et/ou un mot de passe simple. Jamais. Il ne faut pas utiliser d'identifiant trivial comme : "100", "abc", "demo", "Pierre", "test", "temporaire", etc. Idem pour les mots de passe.


Filtrer l'authentification SIP par adresse IP


Dans la configuration de nos comptes SIP (fichier sip.conf et dérivés) il est possible de préciser l'adresse IP ou les adresses IP autorisées à s'enregistrer sur les comptes SIP de notre Asterisk.
Cette configuration se fait par compte SIP (ou trunk SIP). Elle permet donc d'être très souple.

Dans la configuration de chaque compte SIP, nous ajoutons les paramètres suivants :
deny=0.0.0.0/0.0.0.0
permit=33.12.13.14/255.255.255.255
La première ligne interdit toutes les adresses IP.
La second ligne autorise exclusivement l'adresse IP 33.12.13.14

Si nous devons autoriser plusieurs adresses IP ou plages d'adresses IP, nous pouvons ajouter autant de lignes permises que nécessaire. Exemple :
deny=0.0.0.0/0.0.0.0
permit=33.12.13.14/255.255.255.255
permit=33.22.23.24/255.255.255.255
Dans cet exemple, les adresses IP 33.12.13.14 et 33.22.23.24 seront autorisées.



Appliquer une sécurité de base sur notre configuration SIP


Il y a deux paramètres indispensables à faire figurer dans notre contexte general de notre configuration SIP :
[general]
...
allowguest=no
alwaysauthreject=yes
...

La signification de ces deux paramètres est la suivante :
  • allowguest=no : bloque la possibilité de passer un appel sans être préalablement enregistré
  • alwaysauthreject=yes : configure Asterisk pour qu'il renvoi le même message d'erreur générique lors d'une tentative de connexion erronée, que l'identifiant soit valide ou non



Utiliser un bon identifiant et un bon mot de passe


Un bon identifiant SIP est un identifiant faisant au moins 8 caractères. Plus il sera long, mieux ce sera. C'est un identifiant que vous n'avons pas à retenir.
Si l'utilisateur Pierre dispose d'un compte SIP dont l'identifiant est aB7ytWxEd, rien n'empêche qu'il soit joignable sur l'extension 100. Il faut bien distinguer l'identifiant SIP et le numéro ou l'extension d'appel.
Par exemple, pour faire correspondre l'extension 100 au compte SIP aB7ytWxEd, alors dans notre fichier de configuration extensions.conf nous aurons quelque chose comme cela :

; Appel vers l'extension 100
exten => 100,1,Dial(SIP/aB7ytWxEd,25,rtT)
   same => n,Voicemail(100@mycontext,u)
   same=> n,Hangup()

Bien évidemment, l'identifiant SIP et le mot de passe SIP doivent être différents. Nous recommandons d'utiliser des mots de passe composés d'au-moins 20 caractères.



[2/4] Bye-bye script-kiddies ou comment réduire le nombre d'attaques d'environ 99%


Pour réduire le nombre d'attaques d'au-moins 99%, une configuration très simple mais malheureusement trop rarement appliquée consiste à paramétrer le service Asterisk pour qu'il soit en écoute sur un autre port que le port SIP standard 5060.

Cette configuration n'est pas un élément de sécurité à proprement parler, et il ne faut pas considérer être en sécurité juste parce qu'on applique cette mesure, mais elle nous permettra d'échapper à l'immense majorité des script-kiddies qui scannent le port 5060 des serveurs.

Pour modifier le port SIP d'écoute d'Asterisk, ouvrir le fichier /etc/asterisk/sip.conf et dans la section [general] ajouter ou modifier la valeur de l'option bindport :
[general]
bindport=5872

Dans l'exemple ci-dessus, nous avons configuré notre serveur Asterisk pour que son port SIP d'écoute soit le 5872. Vous pouvez choisir une autre valeur (en fait, nous vous encourageons à choisir une autre valeur).

L'ensemble des configurations réalisées jusqu'à présent permet de réduire la surface d'attaque. Nous allons maintenant voir comment filtrer et sécuriser les services restant actifs.

Nous insistons sur le fait que d'après nos statistiques internes, simplement en changeant le port SIP d'écoute d'Asterisk, on peut passer de plusieurs dizaines de tentatives d'intrusions par force brute par jour à un chiffre compris entre zéro et dix par an.
Ceci étant, il ne faut pas croire que cette configuration soit suffisante pour sécuriser un serveur Asterisk.



[3/4] Configurer fail2ban pour Asterisk


fail2ban est inclus dans toutes les distributions GNU/Linux. Pour l'installer :
Debian/Ubuntu/Mint : apt-get install fail2ban
CentOS/RedHat : yum install fail2ban (s'il ne trouve pas le paquet fail2ban, le faire précéder d'un yum install epel-release)

Dès que fail2ban est installé, il est immédiatement opérationnel pour le port SSH. Nous allons le configurer pour Asterisk.


3.1 - Créons un fichier de log Asterisk pour fail2ban


Dans son mode de fonctionnement, fail2ban lit un fichier de log pour y repérer les tentatives d'intrusions. Nous allons créer un fichier de log Asterisk spécifique pour fail2ban.
Commençons par ouvrir avec notre éditeur de texte préféré le fichier de configuration des logs d'Asterisk /etc/asterisk/logger.conf pour y ajouter la ligne suivante en fin de fichier :
fail2ban => notice,security

On recharge la configuration de journalisation d'Asterisk, en saisissant la commande suivante :
myserver# asterisk -rx 'logger reload'

Cette action a permis la création d'un fichier de log spécifique se situant à l'emplacement /var/log/asterisk/fail2ban (sauf si vous avez modifié le répertoire par défaut de stockage des logs d'Asterisk, bien-sûr) qui contiendra uniquement les informations de type "notice" et "security".
Nous allons maintenant configurer fail2ban pour Asterisk.


3.2 - Créons un "jail" pour Asterisk


Créons un fichier du nom de notre choix dans le répertoire /etc/fail2ban/jail.d/. Dans notre exemple, nous nommerons ce fichier provya.conf ; et ajoutons le code suivant dans le fichier :
[asterisk-provya]
enabled  = true
ignoreip = 127.0.0.1 1.2.3.4
filter   = asterisk
action   = iptables-allports[name=asterisk, protocol=all]
logpath  = /var/log/asterisk/fail2ban
findtime  = 10m
maxretry = 3
bantime  = 360m

Détaillons ligne-par-ligne :
  • [asterisk-provya] : nom de notre jail (prison)
  • enabled = true : permet d'activer ce jail ; c'est-à-dire cette règle
  • ignoreip = 127.0.0.1 1.2.3.4 : la liste des adresses IP sources qui ne doivent pas être prises en compte par fail2ban. Il s'agit généralement des adresses IP légitimes comme l'adresse IP de notre connexion Internet ou d'un serveur VPN, par exemple. Il est recommandé de toujours laisser l'adresse 127.0.0.1. Chaque adresse IP doit être séparée par un simple espace.
  • filter = asterisk : le nom du filtre qui contient l'expression régulière qu'utilisera fail2ban pour détecter les tentatives d'intrusion. Le filtre "asterisk" est un filtre déjà pré-existant avec fail2ban. Il est bien fait. Nous l'utilisons.
  • action = iptables-allports[name=asterisk, protocol=all] : l'action qui sera exécutée par fail2ban lorsque les critères de déclenchement s'activeront. Dans le cas présent, nous indiquons à fail2ban d'utiliser l'action "iptables-allports" qui est une action pré-existante qui va créer une règle iptables de filtrage. La règle de filtrage iptables comportera le mot clef "asterisk" (ce qui nous permettra de la repérer facilement) et bloquera tous les ports de notre serveur pour l'adresse IP source incriminée (protocol=all).
  • logpath = /var/log/asterisk/fail2ban : le nom du fichier de log que fail2ban devra lire pour détecter les tentatives d'intrusion. Il s'agit du fichier de log Asterisk que nous avons créé à l'étape précédente.
  • findtime = 10m : la durée sur laquelle le nombre de tentatives de connexion va être prise en compte par fail2ban. Ici, 10 minutes.
  • maxretry = 3 : le nombre de tentatives de connexions à partir de laquelle notre filtrage va se déclencher. Ici, 3 tentatives.
  • bantime = 360m : la durée de bannissement. Ici, 360 minutes, soit 6 heures. Si vous souhaitez bannir une adresse IP plus d'une journée, il vous faudra personnaliser la valeur de "dbpurgeage" du fichier fail2ban.conf

Ainsi donc, dans cette configuration, nous bannissons pour 6 heures toute adresse IP ayant effectué 3 tentatives de connexions erronées sur notre serveur en moins de 10 minutes.
Attention : pensez à bien configurer le champ "ignoreip" si vous ne voulez pas vous retrouver coupé de votre serveur suite à une mauvaise manipulation... ;-)


3.3 - [Optionnel] Personnalisons le filtre pour Asterisk


Le filtre pour Asterisk fourni par défaut avec fail2ban est bien fait et il n'est pas forcément nécessaire de le changer.
Nous avons seulement déjà remarqué qu'une des règles du filtre peut avoir tendance à créer des faux-positifs. Il s'agit de la ligne :
^Call from '[^']*' \(<HOST>:\d+\) to extension '[^']*' rejected because extension not found in context

Le problème de cette règle est que si un utilisateur compose à 3 reprises en moins de 10 minutes un faux numéro (relativement peu probable, certes, mais cas déjà rencontré), alors son adresse IP va se faire bannir par fail2ban.
De plus, cette règle est inutile si vous avez défini le paramètre allowguest=no dans le fichier sip.conf comme indiqué en début d'article.

Nous commentons donc cette ligne en ajoutant un dièse (#) devant.

Il ne nous reste plus qu'à recharger fail2ban et le tour est joué !

systemctl reload fail2ban


3.4 - Les commandes utiles pour fail2ban


Quelques commandes utiles pour fail2ban :

  • fail2ban-client status : liste tous les « jails » configurés
  • fail2ban-client status asterisk-provya : affiche le statut du jail spécifié (ici, asterisk-provya) et précise le nombre d'adresses IP bannies
  • systemctl restart fail2ban : redémarre le service fail2ban
  • fail2ban-client set asterisk-provya banip 1.2.3.4 : permet de bannir manuellement l'adresse IP 1.2.3.4 dans le jail asterisk-provya
  • fail2ban-client set asterisk-provya unbanip 1.2.3.4 : permet de dé-bannir manuellement une adresse IP qui a été précédemment bannie
  • fail2ban-regex /var/log/asterisk/fail2ban /etc/fail2ban/filter.d/asterisk.conf : permet de tester le bon fonctionnement d'un filtre fail2ban sur un fichier de log
  • fail2ban-client get dbpurgeage : affiche la durée maximum durant laquelle les adresses IP bannies seront conservées
  • fail2ban-client get asterisk-provya bantime : affiche la durée de bannissement du jail indiqué

La configuration de fail2ban est terminée. Passons à la configuration du filtrage avec iptables.



[4/4] Configurer iptables pour Asterisk


Dernière étape dans notre stratégie de sécurisation de notre serveur Asterisk, la configuration des règles de filtrage des flux réseaux avec iptables.

La démarche va consister à définir le plus précisément possible la liste du trafic réseau que nous souhaitons autoriser, puis interdire le reste du trafic réseau.
Pour cela, nous devons définir quels services tournent sur notre serveur Asterisk et sur quels ports ces services sont joignables.

Par exemple :
  • serveur Asterisk (SIP) : port UDP/5060 (ou celui que vous aurez configuré précédemment !)
  • serveur Asterisk (flux audio RTP) : ports UDP/10.000-20.000
  • serveur SSH : port TCP/22
  • interface d'administration web (si installée) : port TCP/443
  • ICMP (si l'on souhaite que son serveur réponde au ping) : icmp

Si l'on utilise une distribution Asterisk packagée (type Wazo, Xivo, Elastix, ...), il faut aussi prendre en compte les services spécifiques de ces distributions. Pour Wazo, la liste des flux réseaux est présentée dans la documentation en ligne.

Nous faisons le même travail pour les flux sortant du serveur ; c'est-à-dire les flux réseaux émis par le serveur.

Par exemple :
  • mise à jour (HTTP/HTTPS) : ports TCP/80, TCP/443
  • flux NTP : port UDP/123
  • flux DNS : port UDP/53
  • flux trunk SIP : port UDP/5060 (ou celui configuré par votre opérateur SIP)
  • flux RTP : ports UDP/10.000-20.000

Par simplicité, il est possible de n'appliquer aucune restriction sur les flux sortants, et de ne filtrer que les flux entrants. C'est un choix à faire en terme de sécurité.

Nous devons ensuite définir pour chacun de ces services, dans la mesure du possible, quelles adresses IP sont autorisées à joindre les services hébergés sur le serveur Asterisk (trafic entrant) et quelles adresses IP sont autorisées à être contactées par le serveur Asterisk (trafic sortant).

Cette étape est importante. Si les adresses IP sources sont connues, il n'y a aucune raison de laisser le serveur Asterisk joignable sans aucune restriction par adresse IP source. C'est la base de la sécurisation du serveur. Et cela évite de se reposer uniquement sur fail2ban pour filtrer les tentatives de connexions mal-intentionnées. Les rôles d'iptables et fail2ban sont complémentaires.

Pour l'exemple d'implémentation de nos règles de filtrage, nous partirons sur le cas suivant :
  • Nous autorisons l'accès aux services d'administration du serveur (SSH et HTTPS, par exemple) uniquement pour l'adresse IP de la connexion Internet de notre entreprise : 188.10.11.12
  • Nous n'appliquons pas de filtrage par adresse IP pour les services Asterisk (SIP & RTP) afin de permettre l'accès par les utilisateurs nomades
  • Nous autorisons la plage d'adresses IP utilisées par notre opérateur SIP : 51.5.6.0/24

Ce qui nous donnera en terme de filtrage des flux entrants les règles suivantes :
iptables -A INPUT -s 51.5.6.0/24 -p udp -m udp --dport 5060 -m comment --comment "Opérateur SIP - flux SIP" -j ACCEPT
iptables -A INPUT -s 51.5.6.0/24 -p udp -m udp --dport 10000:20000 -m comment --comment "Opérateur SIP - flux RTP" -j ACCEPT
iptables -A INPUT -s 188.10.11.12/24 -p tcp -m tcp --dport 443 -m comment --comment "Administration - IP du bureau" -j ACCEPT
iptables -A INPUT -s 188.10.11.12/24 -p tcp -m tcp --dport 22 -m comment --comment "Administration - IP du bureau" -j ACCEPT
iptables -A INPUT -m comment --comment "filtrage fail2ban" -j asterisk-provya
iptables -A INPUT -p udp -m udp --dport 5060 -m comment --comment "Flux SIP Open" -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 10000:20000 -m comment --comment "Flux RTP Open" -j ACCEPT
iptables -A INPUT -p icmp -m comment --comment "si l'on souhaite autoriser les PING" -j ACCEPT
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m comment --comment "On bloque tout le reste" -j DROP

iptables -A asterisk-provya -j RETURN

Il faut bien évidemment adapter cet exemple à votre configuration réelle et aux services que vous souhaitez filtrer.

Et pour le filtrage des flux sortants :
iptables -A OUTPUT -d 51.5.6.0/24 -p udp -m udp --dport 5060 -m comment --comment "Opérateur SIP - flux SIP" -j ACCEPT
iptables -A OUTPUT -d 51.5.6.0/24 -p udp -m udp --dport 10000:20000 -m comment --comment "Opérateur SIP - flux RTP" -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 10000:20000 -m comment --comment "Flux RTP Open" -j ACCEPT
iptables -A OUTPUT -p udp -m tcp --dport 80,443 -m comment --comment "Flux HTTP/HTTPS" -j ACCEPT
iptables -A OUTPUT -p udp -m udp --dport 123 -m comment --comment "Flux NTP" -j ACCEPT
iptables -A OUTPUT -d 9.9.9.9/32 -p udp -m udp --dport 53 -m comment --comment "Flux DNS vers Quad9" -j ACCEPT
iptables -A OUTPUT -p icmp -m comment --comment "si l'on souhaite autoriser les PING" -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m comment --comment "On bloque tout le reste" -j DROP

Encore une fois, il faut bien évidemment adapter cet exemple à votre configuration réelle et aux flux que vous souhaitez filtrer.


Commandes utiles pour iptables[/u]


Quelques commandes utiles pour iptables :

  • [b]iptables -L -n : liste toutes les règles iptables (l'option -n permet l'affichage des adresse IP au format numérique)
  • iptables -L --line-numbers : affiche le numéro de ligne de chaque règle
  • iptables -D OUTPUT 2 : supprime la règle numéro 2 de la chaîne OUTPUT
  • iptables-save > provya.txt : fait une sauvegarde des règles iptables vers le fichier provya.txt
  • iptables-restore < provya.txt : restaure les règles contenues dans le fichier provya.txt


Vous avez toutes les armes en main pour sécuriser correctement et efficacement votre serveur Asterisk.
Il faut bien évidemment adapter ces recommandations à votre usage, à votre besoin et à la localisation du serveur Asterisk (hébergement public type Cloud, hébergement privé derrière un firewall, etc.).
D'une façon générale, au plus vous serez précis dans vos règles de filtrage et mieux ce sera.
Enfin, il faut aussi rester pragmatique et implémenter la solution correspondant aux besoins réels avec les contraintes associées sans chercher à faire trop, ni tomber dans la fainéantise du pas-assez. Bref, à vous de trouver le juste équilibre ! ;-)



Pour aller plus loin


fail2ban est-ce vraiment utile ? Partage d'expérience
[Asterisk] Les commandes utiles pour Asterisk
[Asterisk] Connaître son nombre d'appels simultanés
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

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

icon 02/05/2019 - Aucun commentaire

Des difficultés pour comprendre pourquoi sur votre pfSense telle ou telle règle de filtrage ne fonctionne pas comme prévu ?
Alors, cet article est fait pour vous ! ;-)

En nous inspirant de la page Firewall Rule Troubleshooting (en anglais) issue de la documentation officielle de pfSense, nous proposons ici un guide rapide et en français sur la méthodologie à suivre pour le dépannage des règles de filtrage de pfSense.



Activer et vérifier les logs !


La première chose à faire est d'activer la journalisation (log) sur la ou les les règle(s) posant problème. Pour cela, éditez votre règle de filtrage et dans la partie "Extra Options" cochez la case Log packets that are handled by this rule.

log packets firewall pfSense


Pensez à sauvegarder, puis à appliquer le changement.


Pour visualiser les logs, se rendre dans le menu Status > System Logs, puis cliquez sur l'onglet Firewall.

Vous visualiserez tous les paquets correspondants à une règle de firewall pour laquelle la journalisation est activée, ainsi que les paquets bloqués par défaut par pfSense (car ils ne correspondaient à aucune règle d'autorisation de trafic).

Exemple :

firewall logs pfSense


Si vous cliquez sur l'icône d'action ( action block pfSense ou action pass pfSense ) tout à gauche de la ligne, cela affichera un popup vous indiquant quelle règle a autorisé ou interdit ce paquet.

Exemple :

détails logs rules pfSense


Sur cette capture d'écran, on peut voir que c'est une règle présente sur l'interface re1 qui autorise le trafic TCP depuis le réseau 192.168.0.0/24 vers n'importe quelle destination sur le port 443 et que la description associée à cette règle est "Trafic Web HTTPS".



S'assurer que la règle est configurée sur la bonne interface


Pour choisir l'interface sur laquelle configurer une règle de filtrage, il faut raisonner du point de vue du firewall et comprendre qu'il applique ses règles de filtrage sur l'interface sur laquelle il reçoit les paquets.
Par exemple, pour configurer un filtrage d'un flux réseau provenant du LAN et à destination du WAN, alors le firewall va recevoir les paquets réseaux sur son interface LAN ; c'est donc sur l'interface LAN qu'il faut configurer le filtrage voulu.

Pour filtrer les flux réseaux en provenance d'Internet et à destination de votre LAN, alors le firewall va recevoir les paquets réseaux sur son interface WAN ; c'est donc sur l'interface WAN qu'il faut configurer le filtrage voulu.

Techniquement, pfSense réalise un filtrage de type ingress.



Vérifier l'ordre de ses règles


Les règles de filtrage sont appliquées dans un ordre bien précis. Les règles sont analysées les unes après les autres du haut vers le bas. La première règle qui correspond à tous les critères qui l'emporte : l'action associée est appliquée et les règles suivantes sont ignorées (sauf pour les règles "floating").

La vérification des règles de filtrage est réalisée dans l'ordre suivant :
  1. Règles "floating" : ce sont les règles analysées en premier ;
  2. Règles de groupe d'interfaces : second jeu de règles à être analysé. Cela comprend le groupe "IPsec" et "OpenVPN" ;
  3. Règles de l'interface : les règles configurées sur l'interface (LAN, WAN, OPT1, ...) ne sont analysées qu'en dernier.

Il est important d'avoir cet ordre en tête car si vous recherchez quelle règle va s'appliquer à quel trafic réseau, vous devrez suivre ce cheminement.

L'interface floating a un mode de fonctionnement particulier : l'analyse des règles suit le processus de la dernière règle qui correspond à tous les critères l'emporte (alors que pour les groupes d'interfaces et pour les interfaces, c'est le fonctionnement inverse : la première règle qui correspond à tous les critères l'emporte).

Pour avoir un mode de fonctionnement suivant la logique de la première règle correspondant à tous les critères qui l'emporte sur l'interface floating, il est nécessaire de cocher la case "Quick" des règles concernées.

Enfin, pour être exhaustif, l'ordre de traitement complet (mais simplifié) des paquets réseau par pfSense est le suivant :
  • règles d'Outbound NAT
  • règles de translation de ports (Port Forwards)
  • règles de NAT pour le load-balancing
  • règles reçues dynamiquement par les clients OpenVPN et par RADIUS pour IPsec
  • règles automatiques internes (obtenues par diverses sources comme snort, DHCP, ...)
  • règles définies par l'utilisateur (sur l'interface floating, sur les interfaces de groupes et pour chaque interface)
  • règles automatiques pour les VPN



Vérifier le protocole


Dans la configuration des règles de filtrage, il faut définir le protocole de transport utilisé. Il s'agit généralement de TCP, UDP ou ICMP.
Vous pouvez rencontrer d'autres protocoles également si vous administrez des VPN ou avez une configuration pfSense en haute disponibilité.

Une erreur classique est de configurer une règle avec le protocole UDP à la place de TCP ou inversement.
Dans le doute, vous pouvez essayer de configurer votre règle avec la valeur TCP/UDP.



Translation de port & NAT


Lorsque l'on configure des règles de NAT entrant (port forward et 1:1 NAT), il faut se rappeler que le NAT s'applique avant les règles de filtrage. Ainsi, les règles de filtrage sont à appliquer sur les adresses IP privées de destination.



Port source et port destination


Quand vous configurez vos règles de filtrage, il faut garder en tête que généralement uniquement le port source ou le port destination doit être précisé, rarement les deux.
Dans la majorité des cas, le port source n'a pas d'intérêt.
Par exemple, pour configurer un accès SSH à un serveur, vous devrez uniquement préciser le port destination : 22 / TCP. Le port source du client sera aléatoire.



Penser à réinitialiser la table d'état si nécessaire


Si une nouvelle règle bloquant du trafic vient tout juste d'être créée, il est possible qu'un état existant dans la table d'état permette toujours au trafic de passer.

Pour être certain d'éliminer cette hypothèse, il faut réinitialiser la table d'état depuis le menu Diagnostics > States, onglet Reset States.

Dans la même logique, il est important de procéder à une réinitialisation de la table d'état lorsque l'on configure des règles de priorisation de trafic. Voir à ce sujet notre article dédié : [pfSense] Configurer la priorisation de trafic avec CBQ.



Trafic ne pouvant pas être filtré


Le trafic réseau entre deux équipements se trouvant sur le même réseau (sur le LAN, par exemple) ne pourra pas être filtré par le firewall car le trafic entre ces deux équipements ne passera jamais par le firewall. Ce trafic est transmis directement d'un équipement à l'autre par le switch.
Si vous avez besoin de mettre en place du filtrage entre deux équipements se trouvant sur votre réseau local, alors vous devrez créer 2 réseaux locaux distincts (soit physiquement, soit logiquement par la mise en place de VLAN). Ce sera souvent le cas pour séparer son réseau de téléphonie sur IP du reste de son réseau local ou encore pour isoler des serveurs du reste du LAN (en créant une DMZ, par exemple).



Règle "pass" automatiquement associée au Port Forward


Par défaut, lorsque l'on crée une règle de translation de port (Port Forward), pfSense propose de créer une règle d'autorisation du trafic. Cela va entrainer un bypass des autres règles de filtrage.
D'une façon générale, nous déconseillons de laisser cette option de création d'une règle automatique. Il vaut mieux la créer manuellement afin de bien comprendre comment et où la créer dans sa stratégie de filtrage complète.



Routage asymétrique


Dernier cas que nous souhaitions aborder : le routage asymétrique. Le routage asymétrique se produit dans le cas où le chemin aller est différent du chemin retour (ex : aller via A > B > C ; puis retour via C > D > A).
Ce cas peut se repérer à travers la présence de trafic comme TCP:A, TCP:SA, ou TCP:RA qui se retrouve bloqué dans les logs.
Si vous rencontrez un problème de routage asymétrique avec votre pfSense, nous vous recommandons la lecture de la documentation officielle sur le sujet : Troubleshooting Blocked Log Entries due to Asymmetric Routing.

Vous avez maintenant toutes les armes en main pour faire un troubleshooting efficace de vos règles de filtrage !



Pour aller plus loin


Best practices / Recommandations pour la configuration de votre firewall
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Configurer ses VLAN
[pfSense] Comprendre la gestion des interfaces réseaux
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Sécurisez l'accès distant de vos collaborateurs nomades avec OpenVPN

icon 18/04/2019 - 6 commentaires

English version: [pfSense] Secure remote access for your home-office workers with OpenVPN.

Il est de plus en plus souvent nécessaire de pouvoir offrir des solutions d'accès distants à ses utilisateurs nomades.
Ces accès se doivent d'être sécurisés et fiables.

Bonne nouvelle, pfSense et OpenVPN forment la solution idéale pour ce besoin ! :-)



OpenVPN = la solution idéale pour les utilisateurs nomades


OpenVPN est une solution facile à mettre en œuvre et efficace pour les utilisateurs nomades.

OpenVPN propose des clients pour tout type de plate-forme (Windows, MAC, Android, iOS) :

Plateformes supportées par OpenVPN


De plus, pfSense propose un mode d'export des configurations des clients pour encore plus de facilité.


À noter :
Cet article ne traite pas de la configuration d'OpenVPN serveur en mode site-à-site (clé partagée ou X.509).
Cet article traite uniquement de l'accès nomade. Nous ne rentrerons pas dans les détails de configuration d'OpenVPN côté serveur pfSense. Nous nous concentrons sur les spécificités de l'accès nomade.

Il existe plusieurs articles dédiés à la configuration d'OpenVPN en environnement pfSense : [pfSense] Monter un accès OpenVPN site-à-site.



Principe de fonctionnement


Le but est d'offrir une solution de VPN pour les utilisateurs nomades leur permettant de disposer d'un accès sécurisé au réseau local de l'entreprise.
Ces utilisateurs peuvent utiliser un ordinateur ou un smartphone pour se connecter.
Dans tous les cas, ils utiliseront un client OpenVPN.

Dans notre exemple de mise en application, nous partirons sur l'infrastructure suivante :

- le sous-réseau LAN est 172.31.54.0/24
- le sous-réseau OpenVPN est 172.31.55.0/24

accès nomade OpenVPN avec pfSense


Pour l'identification et l'authentification des utilisateurs, nous utiliserons un certificat couplé à un login et un mot de passe.
Le certificat sera commun pour tous les utilisateurs. Le login et le mot de passe seront privatifs.


Passons maintenant à la configuration !



Configuration du serveur OpenVPN


Côté serveur OpenVPN, nous devons créer les éléments suivants :
  1. une autorité de certification, sauf si nous en disposons déjà d'une
  2. un certificat serveur
  3. un certificat client
  4. les accès utilisateurs (login et mot de passe)
  5. le serveur OpenVPN en tant que tel
  6. les règles de firewall et de NAT idoines
  7. la configuration des clients nomades



1. Création d'une autorité de certification


Cette étape n'est nécessaire que si nous ne disposons pas déjà d'une autorité de certification existante.
Si nous en avons déjà créé une lors de la mise en place d'une connexion VPN site-à-site ([pfSense] La gestion des certificats pour les connexions OpenVPN), nous pouvons réutiliser celle-ci plutôt que d'en recréer une nouvelle.

Autrement, nous nous rendons dans le menu System > Cert Manager :

menu System > Cert. Manager - pfSense - Provya


Dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "+ Add" se trouvant en bas à droite de la liste des CAs existants.

Les champs à renseigner sont les suivants :
  • Descriptive name : le nom que l'on souhaite donner à notre autorité de certification
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate Authority : permet d'importer le certificat (clé publique + clé privée) d'une autorité de certification existante
  2. Create an internal Certificate Authority : permet de créer une nouvelle autorité de certification
  3. Create an intermediate Certificate Authority : permet de créer une autorité de certification intermédiaire. Cette autorité de certification intermédiaire doit être rattachée à une autorité de certification existante
Dans notre cas, nous créons une nouvelle autorité de certification (Create an internal Certificate Authority).
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Lifetime : la durée de vie de l'autorité de certification. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (3650 jours, soit 10 ans)
  • Country Code : le code ISO du pays. Dans notre cas : FR
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit être unique.

Exemple de résultat obtenu :

Exemple de configuration d'un C.A. pfSense - Provya


Notre autorité de certification est créée.

Nous devons exporter la clé publique du certificat. Pour cela, dans l'onglet "CAs" (l'onglet par défaut), nous cliquons sur l'icône "Export CA" de l'autorité de certification que nous avons créée précédemment :

Exporter un CA pfSense - Provya




2. Création d'un certificat serveur


Nous restons dans le menu System > Cert Manager et basculons sur l'onglet "Certificates" (deuxième onglet).
Pour créer un nouveau certificat (client ou serveur), nous cliquons sur l'icône "+ Add" se trouvant en bas à droite de la liste des certificats existants.

Les champs à renseigner sont les suivants :
  • Method : 3 méthodes sont possibles :
  1. Import an existing Certificate : permet d'importer la clé publique et la clé privée d'un certificat existant
  2. Create an internal Certificate : permet de créer une nouveau certificat
  3. Create a certificate Signing Request : permet de créer un fichier de requête qui pourra être envoyé à un CA tiers pour être signé. Cela peut être utile pour obtenir un certificat d'un CA root de confiance.
Dans notre cas, nous créons un nouveau certificat (Create an internal Certificate).
  • Descriptive name : le nom que l'on souhaite donner à notre certificat serveur
  • Certificate authority : l'autorité de certification qui signera le certificat que nous sommes en train de créer. Dans notre cas, nous choisissons le CA que nous venons de créer, soit "CA Provya"
  • Key length : la longueur de la clé de chiffrement du certificat. Plus elle est longue, plus elle sera sécurisée (mais plus la charge CPU sera grande également...). Nous gardons la valeur par défaut : 2048
  • Digest Algorithm : la fonction de hachage qui sera utilisée. Nous gardons la valeur par défaut : SHA256
  • Certificate Type : le type de certificat. Il existe 2 valeurs possibles :
  1. User Certificate : pour définir un certificat pour un client
  2. Server Certificate : pour définir un certificat pour un serveur
Dans notre cas, nous choisissons "Server Certificate".
  • Lifetime : la durée de vie du certificat. Si nous n'avons pas de raison de réduire sa durée de vie, nous laissons la valeur par défaut (3650 jours, soit 10 ans)
Les autres champs sont principalement cosmétiques et doivent permettre d'identifier l'organisation émettrice du certificat. Par défaut, l'ensemble des champs sont pré-complétés avec les informations issues du CA. Le seul élément important est le "Common name" dans lequel il ne doit pas y avoir d'espace et qui doit rester unique

Exemple de résultat obtenu :

Exemple de création d'un certificat pfSense - Provya


Notre certificat pour le serveur OpenVPN est créé.



3. Création d'un certificat client


Il nous reste à créer un certificat pour nos clients nomades.
Nous procédons exactement de la même manière que pour la création d'un certificat serveur. Le seul élément distinctif est le champ Certificate Type pour lequel nous choisissons "User Certificate".

Exemple de résultat obtenu :

Création d'un certificat pour pfSense - Provya


Notre certificat pour les clients OpenVPN est créé.

Nous exportons la clé privée et la clé publique (qui nous sera nécessaire pour les clients nomades).
Pour cela, nous cliquons successivement sur les icônes "Export certificat" et "Export key" du certificat client que nous avons créé précédemment :

Export du certificat et de la clef - pfSense - Provya




4. Création des utilisateurs


La création et la gestion des utilisateurs se passent dans le menu System > User Manager :

menu System > User Manager - pfSense - Provya


Nous commençons par créer un groupe : se rendre sur l'onglet "Groups", puis cliquer sur l'icône "+ Add" se trouvant en bas à droite de la liste des groupes.

Nous renseignons les champs comme suit :
  • Group name : le nom du nouveau groupe. Ce nom ne doit pas contenir d'espace. Dans notre cas, nous indiquons "OpenVPN-user"
  • Scope : la portée du groupe. Nous laissons la valeur par défaut "Local"
  • Description : une description facultative
  • Group Memberships la liste des membres du groupe. Dans notre cas, nous la laissons vide pour le moment

Exemple de résultat obtenu :

Création d'un groupe pfSense - Provya


Si nous souhaitons assigner des privilèges aux membres du groupe, il faut l'éditer en cliquant sur l'icône en forme de crayon se trouvant à sa droite.
Dans notre cas, les utilisateurs n'ayant pas besoin de se connecter à pfSense, nous ne leur attribuons aucun droit particulier.


Nous nous rendons ensuite dans l'onglet "Users" pour créer notre premier utilisateur en remplissant les champs comme suit :
  • Disabled : permet de désactiver un utilisateur sans le supprimer
  • Username : le nom d'utilisateur (sans espace ni caractères spéciaux)
  • Password : le mot de passe
  • Full name : Le nom de l'utilisateur associé à ce compte
  • Expiration date : La date d'expiration du compte. Elle doit être saisie au format américain, c'est-à-dire mm/jj/aaaa (mois/jour/année). Si ce champ est laissé vide, le compte n'expirera jamais.
  • Group Memberships : c'est ici que nous définissons le groupe auquel nous rattachons l'utilisateur. Dans notre cas, nous choisirons "OpenVPN-user"
  • Certificate : si l'on souhaite créer par la même occasion un certificat pour l'utilisateur (ce que nous ne ferons pas)
  • Authorized keys : si l'on souhaite définir la clé autorisée pour la connexion de l'utilisateur (nous ne cochons pas cette case)
  • IPsec Pre-Shared Key : utiliser pour les connexions en VPN IPsec ; ce qui n'est pas notre cas (nous laissons donc ce champ vide)

Exemple de résultat obtenu :

Création d'un utilisateur pfSense - Provya




5. Création du serveur OpenVPN


Le détail de la configuration du serveur OpenVPN se trouve dans l'article dédié [pfSense] Monter un accès OpenVPN site-à-site.

Les différences au moment de la configuration sont les suivantes :
  • Server Mode : choisir "Remote Access (SSL/TLS + User Auth)"
  • TLS Authentication : cocher la case "Enable authentication of TLS packets" pour davantage de sécurité. Nous ne conseillons pas de la cocher
  • Peer Certificate Authority : choisir l'autorité de certification créée précédemment ("CA Provya (ca-provya)")
  • Server Certificate : choisir le certificat serveur créé précédemment ("Certificat Serveur (certif-serveur-provya)")
  • DH Parameters Length : nous laissons la valeur par défaut (1024 bits)

Exemple de résultat obtenu :

Configuration du serveur OpenVPN




6. Configuration du firewall et du NAT


Se rendre dans Firewall > Rules :

menu Firewall > Rules


Sur l'interface sur laquelle le serveur OpenVPN est en écoute ("WAN", très sûrement), créer une règle autorisant le trafic à atteindre l'adresse IP et le port du serveur OpenVPN.

  • Interface : WAN
  • Protocol : UDP
  • Source : choisir "any"
  • Destination : WAN address
  • Destination port range : port choisi lors de la configuration du serveur OpenVPN (1194 dans notre exemple)

Exemple de résultat obtenu :

Exemple d'une règle de filtrage


Si nous avons besoin de faire une redirection d'adresse (cas où le port public utilisé serait différent du port configuré pour le serveur OpenVPN), nous créons une règle de NAT dans Firewall > NAT.
Les éléments à renseigner sont :

  • Interface : WAN
  • Protocol : UDP
  • Src. addr & Src. port : choisir "any"
  • Dest. addr : l'adresse IP WAN
  • Dest. ports : le port d'écoute du serveur OpenVPN
  • NAT IP : l'adresse IP du pfSense sur l'interface WAN
  • NAT Ports : le porte d'écoute du serveur OpenVPN (1194, dans notre exemple)



7. Configuration des clients nomades


Il ne reste plus qu'à mettre en route OpenVPN client sur les postes nomades.

Les clients Windows, Mac, Android ou iOS sont téléchargeables directement sur le site d'OpenVPN ou sur les stores associés : iPhone et Android.

3 fichiers nous serons nécessaires :
  • la clé publique et la clé privée du certificat client créé précédemment
  • un fichier de configuration d'OpenVPN à créer manuellement

La documentation d'OpenVPN fournit un fichier de configuration d'exemple. Il est reproduit ci-dessous.

Les éléments à configurer sont :
  • remote my-server 1194 => à remplacer par l'adresse IP publique (ou le nom de domaine associé) et par le bon port d'écoute
  • ca ca-provya.crt => la clé publique de l'autorité de certification
  • cert provya-client.crt => la clé publique du certificat client
  • key provya-client.key => la clé privée du certificat client

##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Windows adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote my-server 1194


# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
;user nobody
;group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca ca-provya.crt
cert provya-client.crt
key provya-client.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
;ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
;comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
;mute 20

# Autentification par login et mot de passe
auth-user-pass


Le fichier de configuration d'OpenVPN et les clés publiques & privées sont à stocker dans un même répertoire.


La configuration est terminée.

pfSense propose également un outil d'export (ce qui évite de devoir créer un fichier .ovpn manuellement). Cet outil est accessible en installant le package "OpenVPN Client Export Utility".



Analyse et Debug


Pour voir si un client est connecté, ça se passe dans le menu "Status" > "OpenVPN".

Les logs de connexion sont eux accessibles dans "Status" > "System logs", puis onglet "OpenVPN".



Pour aller plus loin


[pfSense] Monter un accès OpenVPN site-à-site
[pfSense] Monter un VPN natté (Overlap network) avec OpenVPN
[pfSense] La gestion des certificats pour les connexions OpenVPN
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Implémenter DNS sur TLS (chiffrement des requêtes DNS)

icon 08/04/2019 - Aucun commentaire

Le nouveau service DNS de Cloudfare a suscité beaucoup d'attention et de commentaires.

En nous inspirant de l'article DNS over TLS with pfSense, nous proposons ici un guide rapide et en français sur la configuration de vos serveurs DNS sur pfSense et plus particulièrement sur la configuration du DNS sur TLS.

Edit : cet article n'est plus à jour.

Dans ce mini-guide, nous utiliserons les serveurs DNS de Cloudfare, mais ce guide est également applicable avec les serveurs DNS Quad9.

À noter : cet article n'est plus à jour pour pfSense 2.5.x. Une mise à jour de cet article est à paraître prochainement.

À noter : dans ce guide nous travaillerons avec le mode "DNS resolver" actif et le mode transfert (DNS Query Forwarding) doit être désactivé puisque notre configuration va créer sa propre zone de transfert. Il s'agit de la configuration par défaut de pfSense.



1. Utiliser les serveurs DNS Cloudfare (ou Quad9)


La première étape consiste à configurer pfSense pour qu'il utilise les serveurs DNS de Cloudfare. Pour cela, se rendre dans le menu System > General Setup (ou Système > Configuration générale si votre interface est en français) :

pfSense menu System - General Setup


Les serveurs DNS à configurer sont :

  • 1.1.1.1
  • 1.0.0.1

Exemple de résultat obtenu :

pfSense - configuration DNS


Cliquer sur le bouton Save (ou Sauvegarder) en bas de page pour enregistrer les modifications.

Si nous avions souhaité utiliser les serveurs DNS de Quad9, les serveurs DNS à configurer auraient été les suivants :

  • 9.9.9.9
  • 149.112.112.112



2. Activer DNS sur TLS


Il nous reste à configurer pfSense pour lui dire de contacter ces serveurs DNS sur TLS.
Pour cela, se rendre dans le menu Services > DNS Resolver (ou Services > Résolveur DNS) :

pfSense - Services - DNS Resolver


Dans l'onglet General Settings (Paramètres généraux), descendre jusqu'à la zone "Custom options" (il faut cliquer sur le bouton "Display Custom Options" pour l'afficher).

Dans cette zone de texte, copier-coller la configuration suivante :

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 1.1.1.1@853
forward-addr: 1.0.0.1@853

Pour utiliser les serveurs DNS de Quad9 à la place de ceux de Cloudfare, il suffit d'adapter la valeur des lignes forward-addr. La configuration serait alors :

server:
forward-zone:
name: "."
forward-ssl-upstream: yes
forward-addr: 9.9.9.9@853
forward-addr: 149.112.112.112@853

Exemple de résultat obtenu :

pfSense - DNS custom options


Cliquer sur Save (Enregistrer) pour sauvegarder les modifications. Puis appliquer les changements en cliquant sur "Apply Changes" (Appliquer les modifications).

La configuration est terminée !



Pour aller plus loin


[pfSense] Configurer un dual-WAN (plusieurs connexions Internet)
[pfSense] Configurer un cluster de 2 pfSense redondants (failover)
[pfSense] Monter un accès OpenVPN site-à-site
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

fail2ban est-ce vraiment utile ? Partage d'expérience

icon 04/04/2019 - 10 commentaires

fail2ban est un outil d'analyse de journaux (log) dont l'objectif premier est de détecter des tentatives d'intrusion ou de connexions infructueuses sur un service et de bannir les adresses IP à l'origine de ces tentatives d'intrusions.

Mais est-ce vraiment utile d'implémenter ce logiciel (ou un logiciel similaire) sur son serveur GNU/Linux ? Et dans quels cas est-ce utile ou inutile ?

Nous répondrons à ces questions dans cet article, ou du tout moins, nous donnerons notre point de vue sur fail2ban en nous basant sur notre expérience de la sécurisation de serveurs et en partageant un retour d'expérience quant à l'implémentation de fail2ban.


fail2ban, est-ce bien utile ?


Non, fail2ban n'est pas utile ; fail2ban est absolument indispensable.

Soyons parfaitement clair, il nous paraît totalement inconcevable d'avoir un serveur GNU/Linux hébergeant un service accessible sur le réseau (que ce soit un réseau public comme Internet ou privé comme un réseau local) sans que ne soit implémenté fail2ban ou un outil similaire.

À partir du moment où votre serveur est allumé et connecté à un réseau, il devient de facto une cible d'attaques ; qu'il soit connecté à Internet ou non, et que vous en ayez conscience ou non.

Le premier type d'attaque que l'on rencontre le plus fréquemment est la tentative d'intrusion par force brute (brute-force). Ces attaques peuvent cibler un serveur SSH, un CMS Wordpress, un service Asterisk, etc. fail2ban protège efficacement contre ce type d'attaque en identifiant les tentatives de connexions infructueuses et en bloquant (via iptables, par exemple) les adresses IP à l'origine de ces tentatives d'intrusions.

Le second type d'attaque est la tentative de déni de service. fail2ban peut protéger couramment contre ce type d'attaque en identifiant rapidement les adresses IP à l'origine de trop nombreuses requêtes.



Pas convaincu de la nécessité de fail2ban ? Partage d'un retour d'expérience


Pour se convaincre de l'utilité d'implémenter un service comme fail2ban, nous avons réalisé l'expérience suivante : nous avons configuré fail2ban sur trois serveurs hébergeant les services suivants :

  • serveur 1 : SSH (port 22) et Asterisk (port 5060)
  • serveur 2 : SSH (port 22) et Apache (port 80)
  • serveur 3 : SSH (port 22) et Apache (port 443)

Nous avons mesuré le nombre de tentatives d'intrusions sur le port SSH sur chacun de ces serveurs et nous sommes demandés si le fait d'avoir d'autres services en écoute avait une incidence sur ce nombre.

Dans le cadre de ce test, nous avons configuré fail2ban pour superviser uniquement le port SSH et bannir les adresses IP faisant 3 tentatives de connexions infructueuses en moins de 10 minutes. La durée de bannissement a été défini à 15 jours. Le test a duré 15 jours. Ainsi, au cours de ces 15 jours, nous sommes certains de ne pas avoir banni plusieurs fois la même adresse IP.

Le graphique ci-dessous présente en bleu l'évolution heure par heure du nombre d'adresses IP bannies pour les trois serveurs ; la courbe rouge représente la courbe de tendance au démarrage de la mesure (attention à l'échelle) :

adresses IP bannies par fail2ban - provya


1° constat : au bout de 15 jours, chaque serveur a banni plus de 6 000 adresses IP uniques !
2° constat : la progression est continue au cours des 5 à 8 premiers jours, avant de commencer à décliner par la suite.
3° constat : le serveur hébergeant un service Asterisk est nettement plus attaqué que ceux hébergeant un serveur Apache (+30% d'attaques environ)
4° constat : le serveur hébergeant un service Asterisk a banni plus de 3 000 adresses IP les 3 premiers jours, tandis que les deux autres serveurs en ont banni environ 1 750 sur les 3 premiers jours ; soit +70% d'attaques environ sur le serveur Asterisk lors des 3 premiers jours.


Le graphique ci-dessous présente en bleu le nombre d'adresses IP bannies heure par heure ; la courbe rouge représente la courbe de tendance (attention à l'échelle) :

adresses IP bannies par fail2ban heure par heure - provya


1° constat : le nombre de tentatives d'intrusions baisse clairement au fil du temps ; la plus forte baisse étant constatée sur le serveur 1 (SSH + Asterisk), qui était le serveur enregistrant le plus d'attaques. Le serveur 2 (SSH + Apache) est celui qui a la tendance la plus stable.
2° constat : sur les 15 jours, il y a eu en moyenne 21 tentatives d'intrusion par heure sur le serveur 1 (SSH + Asterisk), 16 sur le serveur 2 (SSH + Apache) et 17 sur le serveur 3 (SSH + Apache). La valeur médiane pour les serveurs 2 et 3 est équivalente à leur moyenne à moins d'un point près (valeur médiane à 16 pour tous les deux) ; pour le serveur 1, la valeur médiane est de 18.
3° constat : il y a plus de tentatives d'intrusions la nuit (créneau 20h - 08h), que le jour (créneau 08h - 20h) ; 35 % en moyenne.
4° constat : nous n'avons pas vu d'augmentation significative du nombre d'attaques durant le week-end. De notre point de vue et de notre expérience, un serveur qui essuie une attaque par force-brute durant le week-end (à partir du vendredi soir, bien souvent...) a généralement déjà été testé de manière beaucoup moins virulente durant la semaine ; dans le cadre de ce test, notre script bannissant directement pour 15 jours, cela empêche l'attaquant d'effectuer un repérage en semaine avant de lancer une attaque durant le week-end.



Conclusion : fail2ban, c'est indispensable !


Il est extrêmement simple d'installer fail2ban sur n'importe quel serveur GNU/Linux. Il est inclus dans toutes les distributions.
Debian/Ubuntu/Mint : apt-get install fail2ban
CentOS/RedHat : yum install fail2ban (s'il ne trouve pas le paquet fail2ban, le faire précéder d'un yum install epel-release)

Dès qu'il est installé, il est immédiatement opérationnel pour le port SSH.
fail2ban incorpore un nombre important de règles prédéfinies pour énormément de logiciel, ce qui facilite grandement sa mise en œuvre.
Il ne vous reste plus qu'à le personnaliser pour mettre vos adresses IP en withelist par exemple ou pour modifier la durée du bannissement.
Il existe de nombreux tutos sur Internet pour chaque service que vous souhaiterez superviser par fail2ban.

fail2ban est également indispensable pour les serveurs internes (non-accessibles depuis Internet) car vous n'êtes pas à l'abri d'une personne mal-intentionnée ou qu'un ordinateur de votre réseau local soit infecté par un bot ou un ver informatique.
À noter que vous pouvez configurer fail2ban pour qu'il vous envoie un e-mail dès qu'il détecte un nombre important de tentatives d'intrusions. Nous recommandons l'utilisation de cette option d'alerte par e-mail pour les serveurs accessibles uniquement en interne.

À noter : si votre fail2ban est amené à bloquer un très grand nombre d'adresses IP, alors l'hébergeur Octopuce propose de coupler fail2ban à IPset plutôt que iptables. Vous pouvez lire leur article : IPSET & filtrages des attaques sur les serveurs. Ils partagent le code source de leurs scripts sur leur espace GitHub.



Et vous, utilisez-vous fail2ban ?

Dans l'article [Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban, nous présentons comment sécuriser simplement et efficacement un serveur Asterisk avec un peu de bon sens, fail2ban et iptables.



Pour aller plus loin


[Asterisk] Sécuriser efficacement et simplement son serveur avec iptables et fail2ban
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer son point d'accès Wi-Fi

icon 21/03/2019 - 2 commentaires

pfSense peut être utilisé pour servir de point d'accès Wi-Fi. Ainsi, c'est pfSense qui diffuse le réseau Wi-Fi, qui gère sa sécurité et ses modalités d'accès et qui filtre le trafic.

Dans cet article, nous détaillerons comment configurer un point d'accès Wi-Fi sur pfSense.
Il faut que la carte Wi-Fi de votre pfSense soit pleinement supportée. Nous ne détaillerons pas dans cet article comment bien choisir sa carte Wi-Fi pour pfSense. Si ce sujet vous intéresse, nous vous invitons à lire notre article complet [pfSense] Comment bien choisir sa carte Wi-Fi.

Attention : plusieurs utilisateurs rapportent des instabilités du Wi-Fi depuis la dernière version de pfSense (2.4.5-RELEASE-p1). Aussi, pour le moment, nous ne recommandons pas d'utiliser pfSense comme point d'accès Wifi pour les nouveaux déploiements ou en environnement professionnel.



1. Créons une interface sans-fil


Nous commençons par créer une interface sans-fil, que nous associerons ensuite à une interface logique que nous pourrons configurer. Si cette notion d'interface logique, virtuelle ou physique n'est pas claire pour vous, nous vous invitons à relire notre article détaillé : [pfSense] Comprendre la gestion des interfaces réseaux.

Se rendre dans le menu Interfaces > Assignments :
menu Interfaces > Assignments (pfSense)


Puis se rendre dans le sous-menu Wireless :
Onglet Wireless pfSense


Nous cliquons sur l'icône "+ Add" située sur la droite de la page.
Nous choisissons notre carte Wi-Fi depuis le menu déroulant "Parent Interface" (ath0, par exemple), le mode et remplissons si nous le souhaitons une description
Pour le mode, 3 choix nous sont proposés :
  • Infrastructure (BSS) : permet de se connecter à un réseau Wi-Fi existant ;
  • Ad-Hoc (IBSS) : permet de se connecter à un Wi-Fi existant en mode point-à-point ;
  • Access Point : permet de créer et diffuser un nouveau point d'accès Wi-Fi.

Dans notre cas, nous choisissons le mode "Access Point".
Exemple de résultat obtenu :

configuration interface wifi pfSense


Nous cliquons sur l'icône "Save" pour sauvegarder nos changements.

Cette interface sans-fil va pouvoir être associée à une interface logique afin d'être configurée.



2. Configurons l'interface Wi-Fi


Nous retournons dans le sous-menu Interface Assignments, nous choisissons notre interface sans-fil dans le menu "Available network ports:" et cliquons sur le bouton "+ Add" associé :
creation interface logique wifi pfSense


Puis nous cliquons sur notre nouvelle interface afin de la configurer. Les principaux paramètres à personnaliser sont les suivants :
  • Enable : cocher cette case pour activer l'interface, bien-sûr.
  • Description : le nom de notre interface. Nous choisissons tout simplement "wifi".
  • IPv4 Configuration Type : la configuration IPv4 à appliquer sur cette interface. Les choix parlent d'eux-mêmes. Nous choisissons "Static IPv4" pour donner à cette interface une adresse IP statique.
  • IPv6 Configuration Type : la configuration IPv6 à appliquer sur cette interface. Dans notre cas, nous ne travaillerons pas avec IPv6, nous choisissons donc "None".
  • MAC Address : ce champ est à compléter si l'on souhaite modifier l'adresse MAC de notre carte Wi-Fi. Ce ne sera pas notre cas ici, nous laissons donc ce champ vide.
  • MTU : permet de personnaliser la valeur du MTU, qui correspond à la taille maximale d'un paquet pouvant être transmis en une seule fois sans être fragmenté. Dans notre cas, nous laissons ce champ vide afin de garder la valeur par défaut, soit 1 500 octets.
  • MSS : permet de personnaliser la taille du MSS pour les connexions TCP. Si vous décidez de personnaliser cette valeur, pfSense la diminuera automatiquement de 40 octets (ce qui correspond à la taille de l'en-tête TCP/IP). Dans notre cas, nous laissons ce champ vide afin de garder la valeur par défaut.
  • Speed and Duplex : permet de définir la vitesse de fonctionnement de l'interface. Le menu déroulant présente toutes les configurations supportées par votre carte Wi-Fi. Nous restons sur le choix par défaut.
  • IPv4 Address : l'adresse IPv4 de notre interface Wi-Fi
  • IPv4 Upstream gateway : nous laissons la valeur à None.
  • Persist common settings : cocher cette case permet de conserver les configurations effectuées même lorsque l'interface logique est supprimée. Nous laissons cette case décochée.
  • Standard : la déclinaison du standard 802.11 avec lequel nous souhaitons travailler. Les choix proposés dépendent de votre carte Wi-Fi. Dans notre cas, nous choisissons 802.11 ng.
  • Channel : le canal Wi-Fi qui sera utilisé par pfSense. Il est recommandé d'opter pour le 1, le 6 ou le 11. Dans notre cas, nous choisissons le 6.
  • Mode : nous choisissons "Access Point".
  • SSID : l'identifiant de notre réseau Wi-Fi. Vous pouvez choisir ce que vous souhaitez. Dans notre exemple, nous l'avons nommé Point-Acces-pfSense.
  • Enable WME : cocher cette case.
  • WAP - Enable : cocher cette case.
  • WPA mode : pour des raisons de sécurité, choisir WPA 2 exclusivement.

Exemple de résultat obtenu :

configuration complete interface wifi pfsense


La configuration de l'interface est terminée. Il nous reste à activer le service DHCP et autoriser les flux réseau.



3. Activons le serveur DHCP


Se rendre dans le menu Services > DHCP Server et configurer le serveur DHCP pour l'interface wifi.

menu Services > DHCP pfSense



Les options à configurer son assez parlantes, il ne paraît pas pertinent de les détailler ici.
Si vous avez besoin d'assistance pour la configuration de votre serveur DHCP, vous pouvez vous appuyer sur notre article complet : [pfSense] Configurer son serveur DHCP.



4. Créons une règle de firewall


Par défaut, tout le trafic est systématiquement bloqué sur chaque interface de pfSense (sauf l'interface LAN où une règle d'autorisation est créée automatiquement par pfSense).
Pour autoriser le trafic, se rendre dans le menu Firewall > Rules, puis sur l'onglet du nom de l'interface que nous venons de créer ("wifi", dans notre cas).
L'ajout d'une règle se fait depuis l'un des 2 boutons "Add".

Si vous ne souhaitez appliquer aucun filtrage spécifique, alors, lors de la création de votre règle, modifiez la valeur de "Protocol" et indiquez "any". Sauvegardez, puis cliquez sur le bouton "Apply changes".

À noter : nous ne recommandons pas de ne configurer aucun filtrage.

Exemple de résultat obtenu :

Création d'une règle de firewall sous pfSense



Votre réseau Wi-Fi est maintenant prêt et fonctionnel !



5. Debug / Dépannage


Vérifier l'état de son interface Wi-Fi


Se rendre dans le menu Interfaces > Status. Vous pourrez visualiser l'état de toutes les interfaces de pfSense. Exemple de résultat obtenu pour notre interface Wi-Fi :

État de l'interface wifi - pfSense


On constate que l'interface est bien up et qu'elle diffuse le SSID "Point-Acces-pfSense".


Voir les autres réseaux Wi-Fi à proximité


Se rendre dans le menu Status > Wireless. Si aucun point d'accès n'est listé, cliquez sur le bouton Rescan. Vous pourrez alors visualiser la liste des autres points d'accès disponibles :

Scanner les autres réseaux wifi visibles (pfSense)



Pour terminer, si vous souhaitez approfondir le sujet sur la configuration du Wi-Fi sur pfSense, vous pouvez consulter la documentation officielle Netgate (en anglais) : https://docs.netgate.com/pfsense/en/latest/wireless/index.html



Pour aller plus loin


[pfSense] Comment bien choisir sa carte Wi-Fi
[pfSense] Comprendre la gestion des interfaces réseaux
[pfSense] Configurer son serveur DHCP
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Asterisk] Mettre à jour son serveur Asterisk

icon 04/12/2018 - Aucun commentaire

Il est important de maintenir à jour sa version d'Asterisk en production.
Si Asterisk a été installé depuis les dépôts d'une distribution, la mise à jour se fait via les mises à jour classiques de la distribution (apt-get update/upgrade ou équivalent).

En revanche, si Asterisk a été installé directement depuis les sources téléchargées sur le site asterisk.org, nous devons faire les mises à jour manuellement.

Nous détaillerons ici la procédure pour une mise à jour de version mineure au sein d'une branche (ex : mise à jour d'Asterisk 11.10.2 vers 11.14.1), mais pas la procédure pour une mise à jour vers une version majeure d'une branche à l'autre (ex : mise à jour d'Asterisk 11.10.2 vers 13.0.1).

Dans notre cas, nous prendrons l'exemple d'une mise à jour d'Asterisk 11.10.2 vers 11.14.1.



Les étapes de la mise à jour


Comme pour toute mise à jour, nous procédons en 3 étapes :
  1. Sauvegarde de la configuration : permettra un retour-arrière rapide en cas de problème
  2. Mise à jour du serveur Asterisk
  3. Sauvegarde de la configuration après la mise à jour : permet de bénéficier d'une sauvegarde à jour de la configuration en cas de panne ultérieure



Sauvegarder ses fichiers de configuration Asterisk


Les répertoires à sauvegarder sont les suivants :
  • /etc/asterisk : le répertoire de configuration d'Asterisk
  • /var/spool/asterisk/voicemail/ : le répertoire des messageries vocales d'Asterisk
  • /var/lib/asterisk/sounds/ : le répertoire contenant les fichiers sons

Si les CDR sont stockés sous forme de fichier csv, il faut aussi en faire une sauvegarde :
/var/log/asterisk/cdr-csv/ : répertoire contenant les CDR au format CSV

Si les CDR sont stockés en base de données, il faut faire un dump de la base.
Par exemple, dans notre cas, les CDR sont stockés dans une base MySQL nommée "asteriskcdr" et nous souhaitons faire une sauvegarde que nous stockons dans le fichier "/sauvegarde/asterisk.sql" :

mysqldump -u root -p -r/sauvegarde/asterisk.sql asteriskcdr

Toutes nos sauvegardes étant faites, nous pouvons maintenant mettre à jour sereinement notre version d'Asterisk.



Connaître la dernière version d'Asterisk


La liste des versions d'Asterisk à jour se trouve à l'URL suivante : http://www.asterisk.org/downloads/asterisk/all-asterisk-versions

D'une façon générale, la dernière version d'Asterisk d'une branche (dans notre cas, nous travaillons avec la 11) se trouve toujours à l'URL suivante :

http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz => pour la 11
http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz => pour la 13
...



Télécharger la dernière version d'Asterisk


On se place dans le dossier /usr/src :

cd /usr/src

On télécharge la dernière version :

wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-11-current.tar.gz

On décompresse :

tar -zxvf asterisk-11-current.tar.gz

Cela crée un nouveau dossier portant le numéro de la dernière version téléchargée (ex : asterisk-11.14.1).

On se déplace dans le dossier qui vient d'être créé :

cd asterisk-11.14.1



Mettre à jour sa version d'Asterisk


Les étapes sont les mêmes que pour l'installation d'une nouvelle version d'Asterisk :

./configure
make menuselect
make
make install

Nous ne détaillons pas ces étapes : ce sont exactement les mêmes que celles suivies lors de l'installation ; elles sont donc a fortiori déjà connues.


Il ne reste plus qu'à vérifier le bon fonctionnement de son service Asterisk ; par exemple, en se connectant à la console et en passant un appel !


Enfin, nous pensons à refaire une sauvegarde des fichiers de configuration d'Asterisk suite à la mise à jour.



Pour aller plus loin


[Asterisk] Les commandes utiles pour Asterisk
[Asterisk] Connaître son nombre d'appels simultanés
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Passer outre un filtrage réseau (firewall/proxy) grâce à un tunnel SSH

icon 24/09/2018 - Aucun commentaire

Il arrive parfois que l'on se connecte à Internet derrière une connexion non-sûre (wifi public), filtrant le contenu (proxy) ou très restrictive et n'autorisant guère plus que les ports 80 (http) et le 443 (https).

Dans ces cas-là, une solution s'impose pour pouvoir surfer en toute liberté : le tunnel SSH !

Nous allons voir comment monter un tunnel SSH vers un serveur accessible par Internet. Ce serveur nous servira de porte de sortie vers un Internet non-bridé.


Principe de fonctionnement


Le principe de fonctionnement est le suivant :
Schéma tunnel VPN


Nous ouvrons depuis notre ordinateur un tunnel SSH vers un serveur de confiance. Puis, nous redirigeons nos flux réseau vers ce tunnel SSH qui nous servira de passerelle de sortie.
Afin d'être le plus efficace possible, nous utiliserons un serveur disposant d'un port SSH en écoute sur le port 443.


Mettre en écoute son serveur SSH sur le port 443


Par défaut, un serveur SSH écoute sur le port TCP 22. Ce qui peut poser problème si l'on se trouve derrière une connexion Internet n'autorisant pas le trafic sur ce port.
Le port TCP 443 (HTTPS) étant très rarement filtré, nous allons faire écouter notre serveur SSH sur ce port.

Pour cela, nous modifions le fichier de configuration de notre serveur OpenSSH (pour Debian/Ubuntu) :

myserver# vim /etc/ssh/sshd_config

Nous recherchons les lignes suivantes :

# What ports, IPs and protocols we listen for
Port 22

Et nous y ajoutons la ligne indiquant à OpenSSH d'être en écoute sur le port 443 :

Port 443

Ce qui nous donne, une fois la modification saisie, les trois lignes suivantes :

# What ports, IPs and protocols we listen for
Port 22
Port 443

Enfin, nous effectuons un rechargement de la configuration du serveur SSH :

myserver# /etc/init.d/ssh reload

/!\ Attention /!\ : si nous avons également un serveur Apache qui tourne sur le même serveur, nous devons d'abord nous assurer qu'il n'est pas déjà en écoute sur le port 443.

D'une façon générale, pour vérifier simplement si un port TCP est en écoute sur un serveur, un petit coup de telnet suffit :

telnet mon-serveur-cible mon-port-cible

Ce qui, dans notre cas, donne :

telnet myserver.mydomain.tld 443

Si notre serveur est en écoute, nous obtiendrons un message du type :

Trying myserver.mydomain.tld...
Connected to myserver.mydomain.tld.
Escape character is '^]'.

Si notre serveur n'est pas en écoute, nous obtiendrons alors un message du type :

Trying myserver.mydomain.tld...
telnet: Unable to connect to remote host: Connection refused

À ce stade, nous disposons d'un serveur SSH en écoute sur le port TCP 443. Il ne nous reste plus qu'à monter notre tunnel !


Monter le tunnel SSH - Solution Windows


Nous commençons par télécharger Putty.

Nous lançons le logiciel, puis, dans l'onglet session, nous renseignons les champs "Host name" et "Port" correspondant à notre serveur SSH :

Connexion SSH avec Putty


Ensuite, nous nous rendons dans l'onglet SSH > Connection > Tunnels.
Dans le champ "Source port", nous saisissons 1234, et nous choisissons les options "Dynamic" et "Auto", puis nous cliquons sur le bouton "Add" :

Activer le port forwarding sous Putty


Il nous reste à cliquer sur "Open", ce qui lance une connexion classique sur notre serveur distant.

Si vous êtes derrière un proxy
Si nous nous trouvons derrière un proxy (en entreprise, par exemple), il nous faut renseigner les informations du proxy au niveau des paramètres de Putty. Ça se passe dans Connection > Proxy.

Il reste à choisir le type de proxy (généralement HTTP), renseigner l'URL du proxy et le port d'écoute (souvent le 8080).

Si un username & password sont nécessaires pour l'accès au proxy, nous renseignons ces éléments sur cette même page :

Configurer le proxy de Putty


Notre tunnel SSH est prêt. Il nous reste à rediriger nos flux vers ce tunnel.


Monter le tunnel SSH - Solution Linux


Sous GNU/Linux, la mise en place du tunnel se résume en une seule ligne de commande :

ssh -D port-local nomutilisateur@nomhôte -p port-distant

Soit, par exemple :
ssh -D 1234 root@myserver.mydomain.tld -p 443

Notre tunnel SSH est prêt.
Et pour éviter les timeout, nous pouvons ajouter une option de keep alive (option "ServerAliveInterval" avec sa valeur à préciser en seconde) :
ssh -o ServerAliveInterval=2 -D 1234 root@myserver.mydomain.tld -p 443

Il nous reste à rediriger nos flux vers ce tunnel.


Rediriger ses flux réseaux à travers le tunnel VPN


Notre tunnel SSH est monté. Nous souhaitons dorénavant l'utiliser pour rediriger nos flux à travers ce tunnel.
Pour cela, nous utiliserons ce tunnel SSH comme un proxy. C'est d'ailleurs la raison pour laquelle nous avons configuré un port d'écoute local (le port 1234).

Ainsi, pour utiliser ce proxy, nous devons configurer nos logiciels avec les informations suivantes :

- adresse du serveur proxy : localhost (ou 127.0.0.1)
- port du serveur proxy : 1234

Exemple pour Firefox :

Se rendre dans Édition > Préférences > Avancé > Réseau (ou Outils > Options > Avancé > Réseau)
Cliquer sur le bouton "Paramètres...", puis choisir "Configuration manuelle du proxy" et renseigner les paramètres comme suit :
Type : SOCKS5
URL : 127.0.0.1
Port : 1234

Configurer serveur Proxy sous Firefox


Voilà !



Pour aller plus loin


Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Postfix] Installer et configurer Postfix pour envoyer ses e-mails depuis un serveur dédié

icon 23/07/2018 - 4 commentaires

Nous décrivons succinctement dans cet article l'installation et la configuration du service postifx.
Le but de cet article n'est pas de rentrer dans le détail, mais de servir de pense-bête.

Dans notre cas, nous travaillons sur un serveur Ubuntu ou Debian hébergé chez OVH.

Les étapes pour l'installation et la configuration d'un serveur postfix sont les suivantes :

Étape 1 - Installation de postfix


On installe le service postfix :

myserver# apt-get install postfix

Par simplicité et habitude, pour le choix de la configuration nous sélectionnons "Site Internet" :

Installation de postfix


Dans le champ "Nom du courrier", nous laissons l'hostname de la machine (proposé par défaut).

Étape 2 - Modification du fichier main.cf


On édite le fichier de configuration principal (/etc/postfix/main.cf) pour y modifier ou ajouter les lignes suivantes :

relayhost = ns0.ovh.net:587	# on précise le serveur relay ainsi que le port d'écoute

smtp_sasl_auth_enable = yes	
smtp_sasl_password_maps = hash:/etc/postfix/sasl/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_generic_maps = hash:/etc/postfix/generic

Forcer l'utilisation d'IPv4 (le cas échéant) :

inet_protocols = ipv4

La valeur de relayhost est évidemment à adapter à la configuration de chacun.

Étape 3 - Création du fichier generic


Pour la translation du courriel, on crée le fichier /etc/postfix/generic et on y place :
utilisateur	adresse@email.fr

On crée le hash :

myserver# postmap hash:/etc/postfix/generic
Cette commande crée le fichier generic.db

Étape 4 - Création du fichier sasl_passwd


On crée le fichier /etc/postfix/sasl/sasl_passwd dans lequel nous y stockons les informations de connexion au relai SMTP :
ns0.ovh.net adresse@email.fr:mot_de_passe
Évidemment, le nom de l'hôte est à adapter à la configuration de chacun.

On crée le hash :

myserver# postmap hash:/etc/postfix/sasl/sasl_passwd
Cette commande crée le fichier sasl_passwd.db

Le fichier sasl_passwd contenant les informations de connexion en clair peut être supprimé.

Étape 5 - Reload + test


On recharge la configuration de postfix :
myserver# /etc/init.d/postfix restart

Il reste a essayer d'envoyer un e-mail en ligne de commande (méthode de votre choix).

Pour voir l'état de la file d'attente :
mailq
Elle devrait être vide si l'envoi s'est bien passé.

Pour vider la file d'attente des e-mails :
myserver# /etc/init.d/postfix stop
myserver# postsuper -d ALL
myserver# /etc/init.d/postfix start

That's all folks! :-)



Pour aller plus loin


fail2ban est-ce vraiment utile ? Partage d'expérience
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Asterisk] Les commandes utiles pour Asterisk

icon 24/06/2018 - 7 commentaires

En cas de problème sur Asterisk, il est pratique de connaître les commandes de base à utiliser pour établir un premier diagnostique.

Nous présentons ici les principales commandes utiles et les explications pour bien les comprendre.



Connexion à la console Asterisk


Nous partons du principe que le service Asterisk tourne en tâche de fond sur nos serveurs.

Pour se connecter à la console Asterisk, la commande est la suivante :
root@asterisk1:~# asterisk -rvvv

Une fois connecté à la console, pour connaître la liste des commandes disponibles il suffit de saisir « ? ».



Lister tous les comptes SIP


Pour lister toutes les entités SIP, c'est-à-dire tous les téléphones et les trunks SIP, la commande est la suivante :
asterisk*CLI> sip show peers

Cette commande précise notamment le username SIP, l'adresse IP associée, l'état de l'entité et le ping SIP.

Le résultat de la commande ressemble à ceci :
Name/username      Host              Dyn   Forcerport        Comedia           ACL         Port        Status            Description
1001/s             Unspecified       D     Yes               Yes                           11475       UNKNOW            
1002/s             192.168.11.1      D     Yes               No                A           1024        OK (29 ms)            
1003/s             192.168.11.2      D     Yes               No                            5060        OK (14 ms)            
3 sip peers [Monitored: 2 online, 1 offline Unmonitored: 0 online, 0 offline]

La lecture du résultat de la commande est la suivante :
  • Le poste « 1001 » n'est pas enregistré sur le serveur Asterisk :
  • Son adresse IP n'est pas connue : elle vaut « Unspecified »
  • Son état est à « UNKNOW »
  • Le poste « 1002 » est bien enregistré sur le serveur Asterisk :
  • Son état est à « OK »
  • Son adresse IP est 192.168.11.1
  • Sa latence SIP est de « 29ms »
  • Le poste « 1003 » est bien enregistré sur le serveur Asterisk :
  • Son état est à « OK »
  • Son adresse IP est 192.168.11.2
  • Sa latence SIP est de « 14ms »

La commande nous renseigne aussi sur le fait qu'il y a 3 comptes SIP de créés sur le serveur Asterisk, dont 2 qui sont connectés et 1 qui ne l'est pas.



Détailler les paramètres d'un compte SIP


La commande suivante permet de lister les paramètres détaillés d'un compte SIP :
asterisk*CLI> sip show peer 1001



Voir les communications en cours


Pour visualiser les communications en cours :
asterisk*CLI> core show channels

Le résultat de la commande ressemble à ceci :
Channel              Location   State   Application(Data)
SIP/1001-00009867  s@user:36  Up      Dial(SIP/1002,15,hHtT)
SIP/1002-00009876  (None)     Up      AppDial((Outgoing Line))
2 active channels
1 active call
4012 calls processed

La lecture du résultat est la suivante :
  • Les postes « 1001 » et « 1002 » sont en communication (l'un avec l'autre)
  • C'est le poste « 1001 » qui appelle l'autre poste (la dernière application lancée étant « Dial(SIP/1002,15,hHtT) » qui se traduit par « appeler le poste SIP 1002, laisser sonner 15 secondes avant de passer à l'étape suivante du dialplan s'il ne décroche pas »).
  • On observe qu'il y a 1 appel en cours (1001 vers 1002) et qu'il y a eu 4012 appels passés depuis que le service Asterisk est démarré.



Connaître le détail d'une communication en cours


Pour connaître le détail d'une communication en cours, la commande est la suivante :
asterisk*CLI> core show channel SIP/1001-00009867

Le résultat de cette commande est très verbeux. Plusieurs parties peuvent nous intéresser.
Les lignes suivantes nous renseigne sur le codec utilisé :
NativeFormats: (alaw)
WriteFormat: alaw
ReadFormat: alaw

Les variables CDR nous renseigne notamment sur la durée de l'appel (peut être très utile pour détecter les appels fantômes, c'est-à-dire mal raccrochés) :
level 1: start=2015-06-09 15:44:26
level 1: answer=2015-06-09 15:44:47
level 1: duration=774
level 1: billsec=753



Observer la perte de paquets sur une communication


La commande suivante est utile pour s'assurer qu'il n'y a pas de pertes de paquets RTP (c'est-à-dire de paquets audios) lors d'une communication :
asterisk*CLI> sip show channelstats

Le résultat est de la forme suivante :
Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
192.168.11.1     4d67bf4946f           0000002619  0000000000 ( 0.00%) 0.0000 0000002626  0000000000 ( 0.00%) 0.0001
192.168.11.2     3560b15a896  00:02:22 0000007095  0000000000 ( 0.00%) 0.0000 0000007096  0000000000 ( 0.00%) 0.0001
192.168.10.1     2f10b98f723  00:43:18 0000000129K 0000000001 ( 0.00%) 0.0000 0000000129K 0000000003 ( 0.00%) 0.0000
3 active SIP channels

La lecture du résultat est la suivante :
  • Il n'y a pas de perte de paquets sur ces appels concernant les peer SIP 1001 et 1002 (que ce soit pour les paquets reçus (Recv Pack Lost) comme pour les paquets émis (Send Pack Lost))
  • Le peer 1003 rencontre très peu de perte de paquets (quantité totalement négligeable)
  • La variation de la latence (Jitter) est faible : cela signifie que la qualité du lien réseau est stable.



Saisir les commandes Asterisk directement depuis le SHELL Linux


Il est à noter que l'ensemble des commandes présentées peuvent être saisies directement depuis un shell Linux de la manière suivante :
root@asterisk1:~# asterisk -rx 'ma commande Asterisk'

Cette possibilité s'avère particulièrement utile pour combiner le résultat d'une commande Asterisk avec d'autres commandes SHELL.
Par exemple, pour lister tous les postes SIP connectés depuis un site dont le sous-réseau est 192.168.11.x :

root@asterisk1:~# asterisk -rx 'sip show peers' | grep 192.168.11.

Exemple de résultat :
1002/s             192.168.11.1      D     Yes               No                A           1024        OK (29 ms)            
1003/s             192.168.11.2      D     Yes               No                            5060        OK (14 ms)  

Seuls les postes 1002 et 1003 ressortent.



Dans un prochain article, nous aborderons les clés de lecture nécessaires à l'analyse des fichiers de log Asterisk.



Pour aller plus loin


[Asterisk] Connaître son nombre d'appels simultanés
[Asterisk] Mettre à jour son serveur Asterisk
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Asterisk] Connaître son nombre d'appels simultanés

icon 17/06/2018 - 2 commentaires

Il est utile de connaître le nombre d'appels simultanés transitant sur sa plateforme Asterisk.
Nous présentons dans cet article comment connaître son nombre d'appels simultanés en temps réel, ainsi que le nombre exact d'appels simultanés qu'il y a eu sur une plage de temps donnée.



Nombre d'appels simultanés en temps réel


Connaître son nombre d'appels simultanés en temps réel est très simple : Asterisk fournit directement une commande pour ça :

asterisk*CLI> core show channels

Le résultat de la commande ressemble à ceci :

Channel              Location   State   Application(Data)
SIP/1001-00009867  s@user:36  Up      Dial(SIP/1002,15,hHtT)
SIP/1002-00009876  (None)     Up      AppDial((Outgoing Line))
2 active channels
1 active calls
4012 calls processed

Cette commande permet de lister les appels en cours. Elle précise également le nombre d'appels passés depuis le démarrage du service Asterisk. Dans notre exemple, on y apprend qu'il y a un appel en cours (1 active calls).

Dans notre cas, l'information que nous cherchons à récupérer est simplement la valeur de la ligne "active calls". Pour cela, nous proposons de passer par un script SHELL :

root@asterisk1:~# asterisk -rx 'core show channels' | grep 'active calls' | cut -f 1 -d ' '

Dans le code ci-dessus, si l'on détaille chaque étape (séparée par un pipe), nous avons :

asterisk -rx 'core show channels'
Exécute la commande "core show channels" et retourne le résultat dans le SHELL

grep 'active calls'
Ne récupère que la ligne comportant la mention "active calls" (c'est uniquement elle qui nous intéresse).

cut -f 1 -d ' '
Permet de découper l'affichage en prenant les espaces comme marque de délimitation (option -d ' ') et de n'afficher que le premier segment (option -f 1).

Pour reprendre notre exemple, le résultat de la commande sera alors :

root@asterisk1:~# asterisk -rx 'core show channels' | grep 'active calls' | cut -f 1 -d ' '
1



Nombre d'appels simultanés sur une période donnée


Pour obtenir le nombre d'appels simultanés sur une période de temps donnée, nous proposons d'utiliser la ligne de commande fournie par Jean du forum asterifk-france.org.

La commande est la suivante :

awk 'BEGIN{FS=",\""} /ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s %03d\n", $1, cpt);}'

Cette commande filtre le contenu du fichier Master.csv sur chaque changement du nombre d'appels simultanés. Le résultat est affiché dans la console. Il est de la forme suivante :

2015-06-11 08:38:19 004
2015-06-11 08:38:30 005
2015-06-11 08:38:55 004
2015-06-11 08:39:10 003
2015-06-11 08:39:13 004
2015-06-11 08:39:42 003
2015-06-11 08:41:42 002
2015-06-11 08:42:35 001
2015-06-11 08:42:46 002
2015-06-11 08:43:50 001

Le premier champ indique la date, le second l'horaire auquel le changement du nombre d'appels simultanés a eu lieu et le troisième le nombre d'appels simultanés.


Limiter le résultat à un contexte


Si l'on souhaite, nous pouvons également limiter le résultat à un contexte en particulier. Exemple :

awk 'BEGIN{FS=",\""} /monContexte/*/ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s;%03d\n", $1, cpt);}'

Le décompte ne se fera alors que sur le nombre d'appels simultanés du contexte "monContexte".


Écrire le résultat dans un fichier pour l'exploiter


Plutôt que d'afficher les résultats à l'écran, nous les écrivons dans un fichier texte :

awk 'BEGIN{FS=",\""} /ANSWERED/{split($11, a, "\""); split($12, b, "\"");printf ("%s,1\n%s,-1\n", a[1],b[1]); }' /var/log/asterisk/cdr-csv/Master.csv | sort | awk -F , '{cpt=cpt+$2; printf ("%s %03d\n", $1, cpt);}' > monFichier.csv

Ce fichier peut ensuite être importé dans un tableur type LibreOffice ou Excel, en précisant que la séparation des champs se fait sur les espaces :

Dans LibreOffice :

Import CSV LibreOffice



Dans Excel :

Import CSV Excel



On peut ensuite faire des tris ou appliquer des filtres sur ces données !



Pour aller plus loin


[Asterisk] Les commandes utiles pour Asterisk
[Asterisk] Mettre à jour son serveur Asterisk
Tous nos articles classés par thème
Voir un article au hasard


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

[Asterisk] Superviser son service

icon 10/06/2018 - 3 commentaires

Un service Asterisk qui tombe, ça peut arriver. C'est la panne et il faut le relancer.

Nous proposons un script shell qui s'occupe de vérifier à intervalle régulier l'état du service Asterisk. Si le service est DOWN, celui-ci est relancé et un e-mail d'alerte est envoyé.

Vérifier l'état du service


Une première solution peut consister à s'assurer que le service soit bien lancé. Cela s'opère depuis la commande suivante :
myserver# ps ax | grep 'asterisk

Si le service Asterisk tourne, il nous est retourné quelque chose comme :
12039 ?        Ssl    7:13 /usr/sbin/asterisk

De notre expérience, cette vérification ne suffit pas : nous avons déjà rencontré des services Asterisk qui était lancé (service UP), mais qui était en défaut de fonctionnement (impossible de connecter à la console, impossible d'enregistrer un peer, etc.).
Pour cette raison, nous préférons utiliser la commande suivante qui a pour intérêt de se connecter à la console Asterisk :
asterisk -rx 'test'

Si le service Asterisk est démarré et pleinement fonctionnel, le message suivant est retourné :
No such command 'test' (type 'core show help test' for other possible commands)

Si le service est arrêté ou qu'il ne répond plus, nous recevrons le message suivant :
Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)


On script !


On crée un script shell qui vérifie si le service Asterisk est OK ou KO :

#!/bin/bash
#
# Commande Asterisk
testAsterisk=$(asterisk -rx 'test')

# On compte le nombre de caractères retournés
nombre=${#testAsterisk}
case $nombre in
        81)
                #Asterisk OUT, on le redémarre
                /etc/init.d/asterisk restart
                ;;
        79)
                #Asterisk est OK
                ;;
esac

Ce script pose néanmoins deux problèmes :

  1. Que se passe-t-il si Asterisk retourne autre chose que l'un des deux messages prévus ?
  2. Il peut être intéressant d'être prévenu par e-mail !

On améliore donc tout ça...


Script final


On ajoute la possibilité que le message retourné puisse être autre chose que ceux prévus. On alerte par e-mail :
#!/bin/bash
#
# Fonctionnement :
# Vérification de l'état du service Asterisk - toutes les minutes (job cron)
# 1) Asterisk est KO : on redémarre et on envoie un e-mail au support
# 2) Asterisk est OK : on ne fait rien...
# 3) On ne sait pas : on envoie un e-mail au support

# Commande Asterisk
testAsterisk=$(asterisk -rx 'test')

# On compte le nombre de caractères retournés
nombre=${#testAsterisk}
case $nombre in
        81)
                #Asterisk OUT, on le redémarre
                /etc/init.d/asterisk restart

                SUBJECT="[URGENT] Serveur Asterisk KO"
                EMAIL="support@example.com, john.doe@example.com, paul.smith@example.com"
                EMAILMESSAGE="/tmp/emailmessage.txt"
                echo "Le service Asterisk est KO" > $EMAILMESSAGE
                echo "Il vient d'être redémarré automatiquement..." >> $EMAILMESSAGE
                echo "Merci de vérifier !" >> $EMAILMESSAGE
                echo "Bonne journée" >> $EMAILMESSAGE
                echo "--" >> $EMAILMESSAGE
                echo "La commande asterisk -rx 'test' a renvoyée le message suivant :" >> $EMAILMESSAGE
                echo $testAsterisk >> $EMAILMESSAGE
                mail -s "$SUBJECT" "$EMAIL" < $EMAILMESSAGE
                ;;
        79)
                #Asterisk est OK
                ;;
        *)
                #Retour inattendu
                SUBJECT="Serveur Asterisk -> État inconnu"
                EMAIL="support@example.com"
                EMAILMESSAGE="/tmp/emailmessage.txt"
                echo "L'état du service Asterisk n'est pas connu." > $EMAILMESSAGE
                echo "La commande asterisk -rx 'test' a renvoyée le message suivant :" >> $EMAILMESSAGE
                echo $testAsterisk >> $EMAILMESSAGE
                echo "Bonne journée" >> $EMAILMESSAGE
                mail -s "$SUBJECT" "$EMAIL" < $EMAILMESSAGE
                ;;
esac

On automatise l'exécution de ce script
On édite le fichier /etc/crontab pour y ajouter les lignes suivantes :
# Verifie que le service Asterisk soit bien OK - toutes les minutes
* * * * *       root /home/supervision/verifAsteriskStart.sh > /dev/null 2> /dev/null


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :

Mon premier article - Welcome

icon 27/03/2014 - 1 commentaire

Mise en place de ce blog dans le but de partager des tutoriaux et des astuces principalement sur pfSense et Asterisk.

Retrouvez nos services et firewall pour pfSense


Formation pfSense     Formation OPNsense     Liste de filtrage des IP malveillantes     Firewall pro-Large pour pfSense et OPNsense     Firewall pro-Xtend pour pfSense et OPNsense     Firewall pro-Xtra-SFP+ pour pfSense et OPNsense    

store.provya.fr

icon Tags de l'article :