Provya

Expertise pfSense

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

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 :

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] 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 :

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] 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] 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 :