Provya

Sécurité et téléphonie

Articles & Tutoriaux  -  Liens & Actualités

[pfSense] Mettre à jour son serveur pfSense

icon 20/08/2019 - Aucun commentaire

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



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 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 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)


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

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

icon 13/08/2019 - 9 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.1168.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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Configurer son serveur DHCP

icon 06/08/2019 - 1 commentaire

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.

  • [b]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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

Best practices / Recommandations pour la configuration de votre firewall

icon 25/06/2019 - Aucun 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 :

menu Firewall - Aliases pfSense - Provya


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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

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  = 10d

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

Quelques commandes utiles pour iptables :

  • 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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

fail2ban est-ce vraiment utile ? Partage d'expérience

icon 04/04/2019 - 8 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.


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

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.



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 :
Interfaces > assign (pfSense)


Puis se rendre dans le sous-menu Wireless :
wireless submenu 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 service 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 :

alt



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 :

alt


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 :

alt



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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Comment bien choisir sa carte Wi-Fi

icon 22/11/2018 - 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 !



[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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :

[pfSense] Bien choisir et dimensionner son firewall

icon 16/10/2018 - 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. C'est d'ailleurs un pré-requis à pfSense 2.5.


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 est un pré-requis à pfSense 2.5 (qui devrait sortir vraisemblablement en 2019). Il est donc indispensable de choisir un processeur supportant le jeu d'instructions 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


Vous avez aimé cet article ? Vous cherchez un support professionnel ? Alors contactez-nous.

Découvrez nos firewall SSD pour pfSense, garantis 3 ans


           

store.provya.fr

icon Tags de l'article :