www.provya.net
Open in
urlscan Pro
51.38.176.160
Public Scan
Submitted URL: http://www.provya.net/
Effective URL: https://www.provya.net/
Submission: On November 10 via api from US — Scanned from FR
Effective URL: https://www.provya.net/
Submission: On November 10 via api from US — Scanned from FR
Form analysis 1 forms found in the DOM
GET index.php
<form action="index.php" method="get" id="search">
<input id="q" name="q" type="search" size="20" value="" placeholder="Rechercher" accesskey="f">
<input class="silver-square" id="input-rechercher" type="submit" value="Rechercher">
</form>Text Content
PROVYA
EXPERTISE PFSENSE
Sommaire des articles - Liens & Actualités - Firewall pour pfSense
≡ Menu
NOS FIREWALL
STORE.PROVYA.FR
DERNIERS ARTICLES
* [pfSense] Maintenir son firewall à jour avec les patches
* pfsense 2.7.0 est disponible
* [pfSense] Je n'ai plus accès à mon firewall, comment faire ?
* Filtrer les adresses IP à risque
* [pfSense] Bien choisir et dimensionner son firewall
Tous les articles
--------------------------------------------------------------------------------
RECHERCHER
« novembre 2023 123456789101112131415161718192021222324252627282930
--------------------------------------------------------------------------------
TAGS
* Alias (1)
* Asterisk (5)
* Auto-provisioning (1)
* CBQ (2)
* Certificats (1)
* Debug (2)
* DHCP (1)
* DNS (1)
* Dual-wan (1)
* Email (1)
* Failover (1)
* Filtrage (1)
* Haute-disponibilité (1)
* HFSC (1)
* Interfaces réseaux pfSense (2)
* Ip (1)
* IPsec (4)
* IPv6 (1)
* Limiters (1)
* Linux (3)
* Matériel (2)
* Mettre à jour asterisk (1)
* Mise à jour (3)
* Mise à jour OPNsense upgrade (1)
* Mise à jour pfSense (10)
* Multi-wan (1)
* NAT (4)
* Nombre d'appels simultanés (1)
* OpenVPN (5)
* OPNsense (3)
* Packages (1)
* Passerelles (1)
* PfSense (52)
* PfSense Plus (1)
* PfSense redondant (1)
* Postfix (1)
* Priorisation de trafic (2)
* PRIQ (1)
* QoS (2)
* Répartition bande-passante (1)
* Routage (1)
* Sauvegarder son pfSense (2)
* Script (1)
* Sécurité (8)
* SSH (1)
* Supervision (1)
* TLS (1)
* Tunnel SSH (1)
* Upgrade (4)
* Utilisateurs nomades (1)
* VLAN (1)
* VPN (8)
* VPN nomade (1)
* Wi-Fi (2)
* WireGuard (1)
* X.509 (1)
--------------------------------------------------------------------------------
DERNIERS COMMENTAIRES
* Guillaume sur [pfSense] Troubleshooting / Dépannage de ses règles de NAT
Bonjour @Ahmat : , Avez-vous ajouté les règles de f…
* Ahmat sur [pfSense] Troubleshooting / Dépannage de ses règles de NAT
Bonjour J'ai un problème de connexion internet dans mon …
* Guillaume sur [pfSense] Configurer un VPN IPsec site à site
Bonjour @SPbest971 :, La première idée que je voyai…
* SPbest971 sur [pfSense] Configurer un VPN IPsec site à site
Bonjour, merci pour ces tutos précis. J'ai une question, …
* Guillaume sur [pfSense] La gestion des utilisateurs
@S4nji : Bonjour, Il existe plusieurs manières …
--------------------------------------------------------------------------------
AUTRES
* Blog
* Liens
* Derniers commentaires
--------------------------------------------------------------------------------
UN ARTICLE AU HASARD
* Un article au hasard ?
--------------------------------------------------------------------------------
FILS RSS
* RSS : Blog
* RSS : Liens
--------------------------------------------------------------------------------
[PFSENSE] MAINTENIR SON FIREWALL À JOUR AVEC LES PATCHES
26/10/2023 - AUCUN COMMENTAIRE
Il est possible de mettre à jour son pfSense avec un système de correctifs
(patches). Ces patches permettent de corriger des failles de sécurité ou bogues
entre deux mises à jour de pfSense.
Dans cet article, nous présentons le mode de fonctionnement des correctifs.
METTRE À JOUR SON FIREWALL PFSENSE
Disposer d'un firewall à jour est une nécessité. Le firewall assurant
généralement la sécurité périmétrique du réseau d'une entreprise, il paraît
indispensable que cet outil soit correctement et régulièrement mis à jour.
Certains firewall proposent des mises à jour très régulièrement. C'est le cas
notamment d'OPNsense : il y a 2 mises à jour majeures par an (en janvier et en
juillet) et une succession de mises à jour intermédiaires (généralement toutes
les deux à trois semaines en moyenne) permettant de corriger les bugs ou failles
de sécurité découverts.
pfSense Plus, la version non open-source et payante de pfSense, propose quant à
elle des mises à jour trois fois par an (janvier, mai et septembre). L'éditeur a
cependant régulièrement un peu de retard dans son cycle de publication (par
exemple, la version bêta de pfSense Plus 23.09 a été publiée mi-octobre 2023
alors que le calendrier de sortie prévoyait une publication de la version finale
en septembre...).
Enfin, pfSense (dans sa version communautaire) propose des mises à jour "quand
c'est prêt". Le temps peut parfois être long entre deux mises à jour du système
(un an à un an et demi, en moyenne).
Cependant, il existe une fonctionnalité plutôt méconnue sur pfSense (ainsi que
sur pfSense Plus) permettant d'installer des correctifs entre deux mises à jour.
Un certain nombre de ces correctifs est recommandé par l'éditeur. Il est donc
conseillé d'appliquer ces correctifs recommandés lorsqu'ils sont disponibles.
PATCHER SON FIREWALL PFSENSE
Pour installer des correctifs, il faudra tout d'abord installer le package
"System Patches". Pour cela, se rendre dans le menu System > Package Manager :
Cliquer sur l'onglet "Available Packages" et faire une recherche sur le mot-clef
"patch". Installer ensuite le package en cliquant sur le bouton "Install" :
Une fois le package System_Patches installé, nous pouvons le retrouver depuis le
menu System > Patches :
Cette page permet d'appliquer des correctifs, que ce soit des correctifs
officiels ou non.
Dans le cas présent, c'est la liste des correctifs recommandés qui nous
intéresse :
Sur la capture d'écran ci-dessus, nous pouvons voir qu'il y a sept correctifs
recommandés pour pfSense 2.7.0, dont un (le dernier) qui a déjà été installé.
Pour installer les correctifs recommandés, nous cliquons simplement sur le
bouton "Apply All Recommended". L'application est immédiate. Aucun redémarrage
n'est nécessaire.
RETIRER UN CORRECTIF INSTALLÉ
Enfin, il est tout à fait possible de retirer un correctif installé. Nous
pouvons soit cliquer sur le bouton "Revert" associé au correctif que l'on
souhaite retirer, soit cliquer sur le bouton "Revert All Recommended". L'action
est immédiate. Aucun redémarrage n'est nécessaire.
Cette page d'application des correctifs offre d'autres possibilités avancées que
nous ne détaillons pas ici. L'objectif était de présenter une bonne pratique
méconnue d'installation de correctifs entre deux mise à jour de pfSense.
Maintenant, il ne vous reste plus qu'à patcher !
POUR ALLER PLUS LOIN
[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en
toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
PFSENSE 2.7.0 EST DISPONIBLE
03/07/2023 - AUCUN COMMENTAIRE
Jeudi 29 juin 2023 est sortie la dernière version de pfSense. La version 2.7.0.
Dans cet article, nous faisons le tour rapide des éléments marquants de cette
mise à jour.
CHANGEMENTS PRINCIPAUX
Les principaux changements ou mises à jour sont les suivants :
* passage de FreeBSD 12 à FreeBSD 14 : bascule de la branche stable/12 vers la
branche current/14. Nous expliquions plus en détails ce changement dans notre
article Évolutions et actualités du logiciel pfSense
* passage de PHP 7.4.x à PHP 8.2.x
* plusieurs anciens algorithmes de chiffrement ou de hachage ont été dépréciés
* il ne sera bientôt plus possible de créer des tunnels OpenVPN à clefs
partagées
* l'outil de capture de paquets a été grandement amélioré
Dans la suite de cet article, nous présentons les autres principales évolutions.
GESTION DES RÈGLES DE FILTRAGE
L'utilisation et la modification des règles de firewall ont été améliorées.
Il est possible de tuer les états liés à une règle de filtrage en particulier :
La duplication d'une règle d'une interface à une autre a également été facilitée
avec un nouveau bouton permettant une copie assistée :
OPENVPN
Mise à jour d'OpenVPN vers la version 2.6.4.
La création de tunnels OpenVPN site-à-site à clef partagée est fortement
déconseillée. Il faut privilégier l'utilisation de certificats.
On peut continuer à créer de nouveaux tunnels à clef partagée, mais cela
générera des alertes dans les logs.
À l'avenir, il faudra migrer ses tunnels à clef partagée vers des tunnels avec
certificats.
Une alerte est affichée si l'on choisi "Peer to peer (Shared Key)"
IPSEC
Le passage de FreeBSD 12 à FreeBSD 14 a entraîné le déclassement d'un certain
nombre d'algorithmes de chiffrement ou de hachage.
Les algorithmes suivants ne sont plus supportés :
* 3DES
* Blowfish
* CAST 128
* MD5
Si vous utilisez ces algorithmes pour vos accès IPsec, il faudra modifier vos
configurations avant de pouvoir mettre à jour vers pfSense 2.7.0.
De toute façon, si vous êtes utilisateurs de ces algorithmes, il est plus que
temps de modifier vos configurations car celles-ci sont considérées comme
non-sûres depuis déjà plusieurs années.
Enfin, il a été ajouté le supporte de l'algorithme ChaCha20-Poly1305 pour les
connexions IPsec.
TROUBLESHOOTING / CAPTURE DE PAQUETS
L'outil de capture de paquets s'est enrichi. C'est tant mieux car il faisait
franchement obsolète lorsqu'on le comparait à celui intégré à OPNsense (note :
il faut bien reconnaître que pfSense en général paraît bien obsolète lorsqu'on
le compare à OPNsense...).
Il est possible d'appliquer davantage de filtres sur ce que l'on souhaite
capturer.
La nouvelle interface ressemble à ceci :
ALIAS
Il s'agit ici principalement de la correction de bugs, dont notamment :
* un bug faisant que certains alias ne se chargeaient pas complètement
lorsqu'ils contenaient un mélange d'adresses IP et de FQDN
* lorsqu'un alias contenait un FQDN non-résolu, cela pouvait casser le contenu
de l'alias (les autres entrées n'étaient pas correctement chargées)
* lors de l'import / export d'alias, les descriptions pouvaient être perdues
* lorsque l'on renommait un alias, cela ne mettait pas forcément à jour les
routes statiques associées ou les instances OpenVPN
UNBOUND
La version d'Unbound embarquée sur pfSense 2.6 était franchement obsolète et
comportait des bugs. La mise à jour corrige ces bugs.
Il y avait notamment un vieux bug qui traînait depuis quelques années qui, dans
certaines configurations avec pfBlockerNG, pouvait faire planter Unbound lors
d'un redémarrage. C'est corrigé.
SÉCURITÉ
Comme pour toute mise à jour, pfSense 2.7.0 apporte son lot de corrections de
sécurité.
La plupart des problèmes de sécurité pouvait déjà être corrigée grâce au system
patch (qui permet l'application de correctifs entre deux mises à jour de
pfSense).
La plupart des failles de sécurité détectées concernait la gestion des alias et
notamment des alias de type URL et URL Table.
Pour un rappel complet sur le fonctionnement des alias, voir notre article
dédié : [pfSense] Tout comprendre aux alias.
Les problèmes étaient des failles de type XSS. Il est à noter qu'il y avait
également d'autres vulnérabilités XSS potentielles sur certaines pages de
l'interface web de pfSense.
Autre point lié à la sécurité : il était possible de contourner la protection
contre les attaques par force brute (sshguard) avec des entêtes particulières.
En simplifiant, il suffisait d'inclure dans ses entêtes la référence à un proxy
pour empêcher que son adresse IP ne puisse être bloquée.
BUGS
Les principaux bugs corrigés sont :
* Il était possible d'utiliser des mots clefs réservés par PF (packet filter)
dans le champ description des interfaces (comme par exemple USER = "{ vtnet2
}" ). Dans son mode de fonctionnement, pfSense crée des alias implicites pour
chaque interface. Utiliser un mot clef réservé faisait que le chargement des
règles de filtrage plantait.
* Lors du démarrage du firewall, les VIP CARP peuvent devenir maîtres trop tôt
ce qui pouvait entraîner le fait d'avoir plusieurs master sur le réseau
pendant quelques dizaines de secondes.
* Lorsque qu'on sortait CARP du mode "persistent maintenance mode", cela
pouvait générer une tempête de broadcast d'événement CARP.
* Si on changeait l'adresse IP et la passerelle d'une interface depuis la
console, il pouvait arriver que la nouvelle passerelle ne soit pas
correctement enregistrée.
* Certains utilisateurs rencontraient des problèmes avec UPnP (notamment pour
les jeux en ligne).
* Pas mal de petits bugs du côté du portail captif ont été corrigés également.
AMÉLIORATIONS
Pas mal d'améliorations. Les principales sont :
* Ajout d'une option sur l'interface graphique pour sélectionner l'algorithme
de hachage du mot de passe utilisateur (on a dorénavant le choix entre bcrypt
[par défaut] et SHA-512).
* Ajout d'une option pour activer/désactiver la sonnerie de la console lorsque
l'on se connecte sur le firewall (avant, il fallait passer les system
tunables et jouer avec la valeur du paramètre kern.vt.enable_bell).
* Lors d'une restauration, il est maintenant possible de restaurer uniquement
l'emplacement des widget sur le tableau de bord.
* Lorsque l'on renouvelle un certificat, il est maintenant proposé une option
pour conserver le numéro de série existant.
* Meilleure lisibilité des baux DHCP : il y a maintenant une distinction entre
les entrées en ligne et les entrées inactives/hors ligne dans la liste des
baux DHCP.
* Le portail captif reposait jusqu'à présent sur IPFW (ipfirewall), il repose
désormais sur PF (Packet Filter).
* Ajout de nouvelles options de destruction de l'état de la passerelle pour un
basculement plus fluide.
AVANT DE METTRE À JOUR
Avant de lancer une mise à jour, il faut impérativement s'assurer sur ses liens
IPsec n'utilisent pas un algorithme de chiffrement déprécié (3DES, Blowfish,
CAST 128, MD5).
Concernant les tunnels OpenVPN à clefs partagées, il est recommandé de les
migrer vers une configuration avec certificats avant de lancer la mise à jour
(ce n'est pas obligatoire, mais fortement recommandé).
PROCESSUS DE MISE À JOUR
Cette nouvelle version est disponible pour les mises à jour et en téléchargement
pour les nouvelles installations.
Si aucune mise à jour ne vous est proposée, il peut être utile de rafraîchir les
dépôts de votre pfSense à l'aide des commandes suivantes (à saisir en console ou
depuis un shell) :
pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade
Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un
point de restauration.
Dans tous les cas, pensez à faire une sauvegarde avant de lancer la mise à jour,
et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.
Enfin, vous pouvez consulter la liste complète des changements en visitant la
page suivante : 2.7.0 New Features and Changes [EN]
POUR ALLER PLUS LOIN
[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en
toute sérénité
[pfSense] Mettre à jour son serveur pfSense
[pfSense] Tout comprendre aux alias
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
[PFSENSE] JE N'AI PLUS ACCÈS À MON FIREWALL, COMMENT FAIRE ?
22/06/2023 - AUCUN COMMENTAIRE
Il peut parfois arriver que l'on se bloque l'accès au firewall pfSense.
Il peut y avoir plusieurs raisons à cela : une mauvaise manipulation, la saisie
d'un trop grand nombre de mots de passe erronés, un firewall qui tourne depuis
des années et dont on a égaré les codes d'accès, etc.
L'objectif de cet article est de traiter ces différents cas où l'on n'a plus
accès à l'interface du firewall, et les solutions associées.
Dans le pire des cas, si l'on dispose d'un accès physique au firewall, alors il
sera toujours possible de reprendre la main dessus.
Il est d'ailleurs important de noter qu'une personne qui dispose d'un accès
physique au firewall pourra contourner la totalité des mesures de sécurité.
MOT DE PASSE ADMIN OUBLIÉ OU PERDU
Si le mot de passe a été perdu ou oublié, la solution la plus efficace est de se
connecter en console (ou de brancher un clavier et un écran) afin de lancer la
réinitialisation du mot de passe admin.
Il faudra choisir l'option 3 :
Cette option permet également de réinitialiser le compte admin s'il est
désactivé ou a expiré.
Le mot de passe admin sera réinitialisé à sa valeur par défaut, c'est-à-dire
pfsense.
MOT DE PASSE OUBLIÉ AVEC L'ACCÈS CONSOLE VERROUILLÉ
L'accès à la console peut être protégé par un mot de passe.
Ce n'est pas le mode par défaut pour pfSense, mais cela peut être activé depuis
le menu System > Advanced en cochant la case "Password protect the console
menu" :
Dans ce cas, un identifiant et un mot de passe sont demandés lors de la
connexion en console ou lorsque l'on branche un clavier et un écran au
firewall :
Heureusement, tout n'est pas perdu !
La procédure pour réinitialiser le mot de passe est la suivante :
* se brancher sur le firewall (en console ou avec un clavier et un écran)
* redémarrer le firewall et choisir Boot Single User option (2) à partir du
menu de chargement avec le logo ASCII
Si on trouve que le menu se déroule trop vite, on peut appuyer sur la touche
"espace" pour l'arrêter.
* appuyer sur Entrée lorsque l'on est invité à choisir le shell /bin/sh :
* Il faut ensuite remonter les partitions. La procédure est différente en
fonction du système de fichier (filesystem) : UFS ou ZFS.
Pour les systèmes de fichier UFS, la commande à saisir sera la suivante :
# /sbin/mount -a -t ufs
Pour les systèmes de fichier ZFS, les commandes à saisir seront les suivantes :
# /sbin/mount -u /
Si cela retourne une erreur, on peut essayer :
# /sbin/zfs set readonly=off pfSense/ROOT/default
Et enfin :
# /sbin/zfs mount -a
Une fois que le système de fichier est monté, saisir la commande suivante et se
laisser guider :
/etc/rc.initial.password
Enfin, il faudra redémarrer le firewall en saisissant la commande suivante :
/sbin/reboot
L'INTERFACE WEB DE PFSENSE NE RÉPOND PLUS...
Il peut y avoir plusieurs raisons à cela.
Une erreur classique est de se tromper de protocole entre HTTP et HTTPS. Si l'un
ne fonctionne pas, on peut essayer l'autre.
Si l'interface graphique n'a pas été configurée correctement, il est tout à fait
possible que le firewall fasse tourner l'interface web sur une combinaison
inattendue de port et de protocole, par exemple :
https://<hostname>:80
http://<hostname>:443
Pour réinitialiser la configuration, on peut se connecter en console (ou
brancher un écran et un clavier), faire le choix 2 permettant de reconfigurer
l'adresse IP de pfSense sur son interface LAN et de réinitialiser le protocole
d'écoute de l'interface web de pfSense.
Une autre possibilité est que l'interface web de pfSense soit plantée. C'est
extrêmement rare, mais ça peut toujours arriver. Si l'on souhaite forcer un
redémarrage de l'interface web, on peut se connecter en console (ou avec un
clavier et un écran) et faire le choix 11 "Restart webConfigurator" :
UNE NOUVELLE RÈGLE DE FILTRAGE BLOQUE L'ACCÈS AU FIREWALL
Si un administrateur distant perd l'accès à l'interface graphique en raison
d'une modification des règles du pare-feu, l'accès peut toujours être obtenu du
côté du LAN.
Par défaut, il n'est pas possible de se couper l'accès à l'interface web de
pfSense depuis le LAN, sauf si la règle "anti-lockout" a été désactivée.
Sinon, il est toujours possible de se connecter en console (ou clavier et écran)
et supprimer la dernière règle de filtrage qui vient d'être créée.
Il s'agit d'une fonctionnalité très pratique de pfSense : à chaque modification,
une sauvegarde locale est effectuée sur le firewall. Ainsi, il est aisé de
revenir en arrière.
Dans notre cas, sur la console, on choisira l'option 15 "Restore recent
configuration" et on choisira la dernière configuration à restaurer :
JE SUIS BLOQUÉ CAR J'AI SAISI TROP DE MOTS DE PASSE ERRONÉS
Si l'on tente de se connecter à l'interface web ou en SSH et qu'on échoue à
plusieurs reprises, notre adresse IP de connexion sera ajoutée à la liste de
blocage.
Pour se débloquer l'accès, il faudra changer l'adresse IP de notre machine pour
se connecter à pfSense, puis se rendre dans le menu Diagnostics > Tables et
sélectionner sshguard dans la liste des alias disponibles pour supprimer
l'adresse IP bloquée.
Il est également possible de faire la même chose en ligne de commande (videra
complètement la table "sshguard") :
pfctl -T flush -t sshguard
ACTIVER L'ACCÈS À L'INTERFACE WEB SUR LE WAN DEPUIS UNE CONSOLE
Le moyen le plus simple (et le plus propre), si l'on connaît son adresse IP
publique est d'utiliser le script shell easyrule pour ajouter une nouvelle règle
de filtrage.
Dans l'exemple suivant, le script easyrule autorisera l'accès sur l'interface
WAN, de 1.2.3.4 (l'adresse IP du client) à 6.7.8.9 (vraisemblablement l'adresse
IP WAN) sur le port TCP 443 :
easyrule pass wan tcp 1.2.3.4 6.7.8.9 443
Dès que la commande aura été saisie, le client (1.2.3.4) pourra se connecter au
firewall (6.7.8.9).
Si l'on ne connaît pas son adresse IP publique, il est techniquement possible de
créer une règle de type "allow all" sur le firewall. Pour cela, la commande à
saisir en console sera la suivante :
pfSsh.php playback enableallowallwan
Une fois que l'administrateur a retrouvé l'accès et corrigé le problème initial
qui l'empêchait d'accéder à l'interface web de pfSense, il faut impérativement
supprimer la règle "allow all" du WAN.
JE NE M'EN SORS PAS, COMMENT DÉSACTIVER LE FIREWALL ?
Il s'agit là d'une solution très dangereuse, mais qui peut s'avérer pratique
dans des cas désespérés (bon dans ces cas-là, il vaut mieux nous appeler plutôt
que de prendre de trop gros risques avec la sécurité de votre réseau ;-)
En mode console, on fera le choix 8 (Shell) et on saisira la commande suivante :
pfctl -d
Le firewall pourra ensuite être réactivé avec la commande :
pfctl -e
Le firewall sera aussi réactivé dès que l'on aura créé ou modifié une règle de
filtrage et cliqué sur le bouton "Apply changes".
LE PROXY SQUID ME BLOQUE L'ACCÈS AU FIREWALL !
Cela peut arriver si l'on configure un peu trop vite squid et qu'on lui attribue
le port d'écoute de l'interface web de pfSense par exemple.
La solution sera toujours la même : se connecter en console (ou avec un écran et
un clavier) afin de reprendre la main.
On fera le choix 8 (Shell) et on saisira la commande suivante :
/usr/local/etc/rc.d/squid.sh stop
Si ça ne fonctionne pas, on pourra plutôt saisir l'une des deux commandes
ci-dessous :
killall -9 squid
squid -k shutdown
Une fois que squid est arrêté, il faudra redémarrer l'interface web de pfSense
en revenant au menu (saisir "exit" depuis le shell) et en faisant le choix 11 :
Il est à noter qu'il faut ensuite agir sans traîner : squid risque de redémarrer
rapidement automatiquement grâce à ses scripts de supervision propres.
LE SERVEUR D'AUTHENTIFICATION EST H.S. - COMMENT FAIRE ?
Si vous vous connectez sur l'interface web de pfSense avec un compte LDAP ou
Radius et que le serveur d'authentification est injoignable, pas de soucis : en
secours, il est toujours possible de s'identifier avec un utilisateur local
(avec le compte admin, par exemple).
Si tous les utilisateurs locaux ont été désactivés ou que les mots de passe ont
été perdus, il faudra se connecter en console et faire le choix 3 pour réactiver
et remettre à sa valeur par défaut le mot de passe admin.
Les identifiants seront alors :
* utilisateur : admin
* mot de passe : pfsense
Nous avons fait le tour des principaux problèmes d'accès qui peuvent exister !
Ce qu'il faut retenir, c'est qu'il est toujours possible de reprendre la main
sur un firewall à partir du moment où l'on dispose d'un accès physique à la
machine.
POUR ALLER PLUS LOIN
[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ou vous
souhaitez approfondir vos connaissances sur pfSense / OPNsense ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : pfSense
OPNSENSE 23.1 EST DISPONIBLE
09/02/2023 - AUCUN COMMENTAIRE
Jeudi 26 janvier 2023 est sortie la dernière version d'OPNsense. La version
23.1, surnommée "Quintessential Quail".
Dans cet article, nous faisons le tour des éléments marquants de cette mise à
jour.
LES INFOS CLEFS EN UN COUP D’ŒIL
Les informations clefs de cette mise à jour sont les suivantes : grosse mise à
jour d'Unbound DNS intégrant des statistiques détaillées sur les requêtes DNS
traitées par OPNsense ; intégration de WireGuard au noyau de FreeBSD (qui
remplace la version déjà proposée qui tournait dans l'espace utilisateur) ;
amélioration de l'outil de capture de paquets (tcpdump) ; passage à PHP 8.1 ;
beaucoup de mises à jour "sous le capot".
Dans la suite de l'article, nous présentons plus en détails les changements et
nouveautés significatifs.
MISE À JOUR D'UNBOUND
Unbound est le résolveur DNS (validateur, cache, récursif) intégré à OPNsense.
Il connaît une grosse mise à jour offrant notamment une nouvelle interface
permettant de voir des statistiques détaillées sur les requêtes DNS traitées par
OPNsense.
Les statistiques sont accessibles depuis le menu Reporting.
Il faudra d'abord activer la collecte locale des statistiques : se rendre dans
le menu Reporting > Settings et cocher la case "Enables local gathering of
statistics." :
La page de statistiques ressemblera à ceci :
Autre mise à jour intégrée à Unbound, le système d'intégration des listes de
blocage DNS a été ré-écrit en python (vs un mix-PHP auparavant).
AMÉLIORATION DE LA GESTION DES INTERFACES
Il y a plusieurs mises à jour notables dans la gestion des interfaces sur les
configurations avancées. Les principales sont :
* Support du stacking de VLAN (802.1ad ou QinQ) ; techniquement, QinQ permet
d'insérer plusieurs tags de VLAN dans la même trame Ethernet, ça permet, par
exemple, de faire passer ses propres VLANs à l'intérieur d'un VLAN fourni par
un opérateur télécom sur un réseau étendu.
* GIF et GRE prennent désormais en charge les configurations IPv6 basées sur
des sous-réseaux au lieu de toujours revenir à une configuration point à
point (/128).
* Plusieurs améliorations sur la gestion d'IPv6 sur les interface GIF, GRE et
PPPoE.
* Il est maintenant possible de filtrer par adresse MAC sur l'outil de capture
de paquets. Cet outil de débogage est vraiment très riche et très performant
surtout si on le compare à ce qui est proposé sur pfSense...
* Quand on crée un groupe d'interfaces, il est maintenant possible de choisir
si ce groupe apparaît uniquement dans les règles de filtrage ou également
parmi la liste des interfaces (dans ce cas, les interfaces ne sont plus
visibles que depuis leur groupe d'appartenance dans le menu Interfaces).
Exemple :
Sur cette capture d'écran, les interfaces "LAN" et "VLAN_VOIP" sont regroupées
sous "Groupe_Local"
ÉVOLUTIONS DIVERSES
Plusieurs améliorations ou évolutions diverses, dont notamment :
* LibreSSL est définitivement abandonné. C'était prévu et annoncé. OPNsense ne
supporte plus qu'OpenSSL.
* Il n'est plus possible de filtrer par système d'exploitation dans la gestion
avancée des règles de filtrage. Tant mieux, cette option était totalement
obsolète.
* OpenVPN : il y aura dorénavant un nom de démon unique pour chaque instance.
Cela facilite le débogage en cas de besoin.
* WireGuard : la version de WireGuard intégrée au noyau FreeBSD est enfin
disponible ! OPNsense proposait jusqu'à présent une version de WireGuard
tournant dans l'espace utilisateur. On va donc pouvoir envisager d'intégrer
réellement WireGuard sur ses firewall en production...
* Pas mal de ré-écritures de codes afin de mettre à jour les pages qui étaient
soit obsolètes (plus utilisées), soit qui n'étaient pas totalement (voire par
du tout) développées suivant une implémentation MVC/API.
PROBLÈMES CONNUS ET POINTS D'ATTENTION
LibreSSL n'est plus proposé. Il faudra donc basculer sur OpenSSL avant de
pouvoir mettre à jour. Il est à noter que c'est OpenSSL qui était déjà utilisé
par défaut par OPNsense. Si vous n'y avez pas touché, il n'y a donc pas beaucoup
de questions à se poser...
La configuration IPsec était jusqu'à présent gérée dans le fichier ipsec.conf ;
elle bascule sur le fichier swanctl.conf. Pour l'immense majorité des tunnels
IPsec cela ne devrait rien changer, mais pour quelques cas particuliers, il
n'est pas impossible de voir apparaître des bugs (des configurations mal reprise
principalement).
Plusieurs corrections rapides (hotfix) ont déjà été publiées (six, pour le
moment). Si vous avez déjà mis à jour votre OPNsense vers la version 23.1, il
peut donc être utile de refaire une vérification afin de vous assurer que vous
disposez des derniers patchs.
Comme d'habitude, si vous n'avez pas appliqué les dernières mises à jour
d'OPNsense, vous devrez d'abord mettre à jour votre OPNsense vers la dernière
ancienne version disponible (soit la 22.7.11_1) avant de pouvoir procéder à la
mise à jour vers la nouvelle version (23.1).
PROCESSUS DE MISE À JOUR
Cette nouvelle version est disponible pour les mises à jour et en téléchargement
pour les nouvelles installations.
Pensez à faire une sauvegarde avant de lancer la mise à jour.
Si votre système de fichiers est ZFS, pensez également à créer un point de
restauration.
Pour la mise à jour, vous pouvez vous appuyer sur notre tuto écrit pour pfSense,
mais facilement adaptable pour OPNsense : [pfSense] Mettre à jour son serveur
pfSense.
La mise à jour d'OPNsense prendra environ 10 minutes.
Enfin, vous pouvez consulter la liste complète des changements en visitant la
page suivante : OPNsense 23.1 released [EN]
POUR ALLER PLUS LOIN
[pfSense / OPNsense] Créer un point de restauration pour des mises à jour et des
retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jour OPNsense upgrade
ÉVOLUTIONS ET ACTUALITÉS DU LOGICIEL PFSENSE
05/10/2022 - 2 COMMENTAIRES
Un certain nombre de gros changements "sous le capot" ont été annoncés
concernant pfSense.
Les deux principaux changements annoncés sont le passage à PHP 8.1 et l'adoption
de FreeBSD 14.
Dans cet article, nous passons en revue ces deux principales évolutions et les
impacts associés qui concerneront pfSense 2.7.
PASSAGE À PHP 8.1
Les dernières versions de pfSense (2.6.0) étaient basées sur PHP 7.4, dont le
support actif arrive à terme fin novembre. Il devenait donc nécessaire de migrer
vers une version plus récente de PHP.
La prochaine version de pfSense embarquera donc PHP 8.1, qui est la dernière
version de PHP et dont le support actif s'étend jusqu'à fin novembre 2024.
Le passage à PHP 8.1 implique de grosses évolutions sur le code qui embarque des
éléments ou des fonctions obsolètes.
Cela entraîne un gros travail de tests de non-régression, de ré-écriture de code
et de renforcement de la sécurité sur la manière dont PHP est exploité par
pfSense. Autant le dire, il y a du travail... :-)
Cette évolution peut également remettre en cause le fonctionnement de pas mal de
packages qui devront également tourner sur PHP 8.1.
ADOPTION DE FREEBSD 14
pfSense tournait jusqu'à présent sur FreeBSD 12-STABLE.
Pour rappel, il y a principalement trois branches actives pour les versions de
FreeBSD :
* stable/12 : la branche la plus ancienne. Ses versions (nommées 12.x-RELEASE)
seront théoriquement supportées jusqu'en juin 2024.
* stable/13 : l'autre branche stable. Ses versions (nommées 13.x-RELEASE)
seront théoriquement supportées jusqu'en janvier 2026.
* current/14 : il s'agit de la version de développement. Le développement sur
cette branche est très actif, au prix d'un risque d'instabilité plus fort
qu'avec les deux autres branches.
L'intérêt évoqué par Netgate (la société éditrice de pfSense) de passer à
FreeBSD 14, qui est la version de développement, est de pouvoir intégrer à
pfSense les toutes dernières fonctionnalités ajoutées à FreeBSD.
De plus, ils considèrent que la branche de développement bénéficie plus
rapidement des corrections de bugs, des corrections de sécurité et des autres
corrections d'une façon générale.
Aussi, lorsque le support d'un nouveau matériel est ajouté à FreeBSD, il est
d'abord intégré à la branche principale (CURRENT).
Ainsi, suivre la branche principale de FreeBSD donne au logiciel pfSense les
pilotes les plus à jour pour une variété de matériel.
Même si ce n'est pas évoqué officiellement, on peut aussi penser au support de
plus en plus important des matériels à base d'architectures ARM.
En effet, Netgate a connu plusieurs fois dans le passé des difficultés à sortir
des mises à jour de pfSense dans les délais car ils rencontraient énormément de
difficultés à faire fonctionner correctement une partie de leurs appliances qui
tournent sur des architectures ARM.
Enfin, Netgate est un contributeur important à l'écosystème FreeBSD. Il est donc
plus simple pour les équipes de développement de travailler sur la version
CURRENT qui est directement intégrée à pfSense. Cela permet de réduire fortement
la dette technique et de voir intégrer plus rapidement leurs contributions à
FreeBSD dans les versions de pfSense.
Il est à noter que Netflix a adopté une stratégie similaire : tous leurs
serveurs qui tournent sous FreeBSD utilisent la branche current.
QUELS IMPACTS POUR LES UTILISATEURS DE PFSENSE ?
En réalité, assez peu.
Le principal impact est que certaines suites cryptographiques jusqu'alors
supportées par pfSense, mais totalement désuètes, ne seront probablement plus
supportées sous pfSense 2.7.
On pense notamment aux algorithmes MD5 ou 3DES, ainsi qu'aux groupes d'échange
de clés Diffie-Hellman disposant d'une taille de clef trop faible.
Enfin, on peut légitimement s'attendre à voir apparaître quelques bugs lors de
la sortie de pfSense 2.7.0
Il ne faudra, bien évidemment, pas se précipiter pour mettre à jour (sauf si
vous souhaitez jouer au bêta-testeur sur votre production) afin de s'assurer que
ces grosses mises à jours n'entraînent pas trop d'effets de bord.
Et il faut espérer que les utilisateurs de pfSense n'auront pas à revivre les
difficultés de pfSense 2.5 qui avait vu la sortie de pas moins de 3 versions à
quelques semaines / mois d'intervalle afin de corriger les très nombreux bugs.
pfSense 2.7.0 ne devrait pas sortir avant la fin de cette année. Aucune date
n'est annoncée pour le moment.
Pour davantage d'informations sur les évolutions du logiciel pfSense, nous
conseillons la lecture de l'article pfSense Software is Moving Ahead, écrit par
le Directeur Technique de Netgate (Jim Thompson).
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : pfSense
OPNSENSE 22.7 EST DISPONIBLE
03/08/2022 - AUCUN COMMENTAIRE
English version: OPNsense 22.7 now available
Jeudi 28 juillet 2022 est sortie la dernière version d'OPNsense. La version
22.7, surnommée "Powerful Panther".
Dans cet article, nous faisons le tour des éléments marquants de cette mise à
jour.
LES INFOS CLEFS EN UN COUP D’ŒIL
Les informations clefs de cette mise à jour sont les suivantes : passage de la
version de FreeBSD 13.0 vers la 13.1 ; passage à PHP 8.0 ; passage à Phalcon 5
(phalcon est le framework PHP utilisé par OPNsense) ; amélioration du support
des VLAN stacké et d'Intel QuickAssist (QAT) ; amélioration de la protection
contre les attaques DDOS ; intégration des nouveaux plugins APCUPSD et du très à
la mode CrowdSec.
Il est également à noter qu'il s'agit sûrement de la dernière version d'OPNsense
intégrant LibreSSL. Les versions suivantes, à partir de la version 23.1 très
sûrement, proposeront uniquement OpenSSL.
Dans la suite de l'article, nous présentons plus en détails les changements et
nouveautés.
AMÉLIORATION DE LA GESTION DE LA MÉMOIRE-VIVE
La gestion de la mémoire-vive a été revue. L'objectif est d'éviter une
saturation de la mémoire-vive par certains processus.
Le changements notables sont les suivants :
* la partition /tmp MFS peut utiliser dorénavant 50% de la mémoire-vive au
maximum ; ce paramètre peut être ajusté si besoin.
* la partition /var MFS devient /var/log MFS and et peut utiliser, elle aussi,
50% de la mémoire-vive au maximum ; ce paramètre peut également être modifié.
* plusieurs améliorations pour éviter que le processus syslog-ng ne soit
impacté par le "out of memory kills" (lorsque la mémoire-vive est saturée,
intervient le processus “Out-of-memory Killer” ou “OOM-Killer” dont le but
est d'éviter le crash du système, ou Kernel Panic, en tuant les processus
jugés trop gourmands. Ce sont des mécanismes de protection que l'on retrouve
également sur toutes les distributions GNU/Linux).
GESTION DES LOGS
Plusieurs améliorations notables au niveau de la gestion et de l'accès aux
fichiers de journalisation (logs) :
* modification du widget (au niveau du tableau de bord) de visualisation des
logs afin de lui ajouter un filtre
* prise en charge de la journalisation des règles NTP (Network Time Protocol)
* ajout des logs concernant l'utilisation des alias
SÉCURITÉ
Les paramètres de clé Diffie-Hellman considérés comme n'étant pas suffisamment
robustes ont été supprimés. C'est une bonne chose d'un point de vue sécurité.
Au niveau de l'IDS/IPS, les règles McAfee qui pointaient vers des liens morts
ont été supprimées.
IPSEC
Plusieurs légères modifications ou améliorations au niveau de la gestion
d'IPsec :
* Ajout du choix "IPv4+6" pour la configuration de la phase 1 pour les IPsec
mobiles
* Mise à jour de l'interface d'administration sur les pages des connexions, SPD
et SAD afin qu'elles utilisent les API
* Quelques autres ajustement de l'interface sur la page d'état des connexions
IPsec
AMÉLIORATIONS DIVERSES
Quelques autres améliorations ou changements notables :
* Amélioration du support de certaines cartes wifi Intel (celles utilisant le
driver iwlwifi)
* Amélioration des performances sur les alias de ports
* Amélioration des performances sur la consultation des logs en temps-réel
(live view)
* Serveur DHCP : il est maintenant possible de lancer le service DHCP Relay sur
les interfaces de type bridge.
* Traduction : retour de l'italien dans la liste des traductions disponibles.
L'italien avait été retiré d'OPNsense 22.1 car son niveau de traduction a été
jugé trop faible. Les traductions pour d'autres langues ont été mises à jour
vers leurs dernières versions disponibles. Il faut encore souligner ici la
qualité de la traduction d'OPNsense comparativement à pfSense (qui est, elle,
particulièrement mauvaise).
PLUGINS
Enfin, la liste des plugins mis à jour :
* Le plugin Crowdsec 1.0 fait son apparition
* Les plugins os-nginx et os-postfix ont été mis à jour pour ajouter des
paramètres Diffie Hellman manquants.
* Plugin os-tayga : mis à jour vers la version 1.2
* Plugin os-apcupsd : mis à jour vers la version 1.0
D'autres ont été retirés :
* os-tor n'est plus disponible avec LibreSSL à cause d'incompatibilités liées
aux dernières versions de Tor.
* os-web-proxy-useracl a été retiré : il n'y avait plus de mise à jour depuis
2017.
* os-boot-delay a également été retiré.
PROBLÈMES CONNUS ET POINTS D'ATTENTION
Le paramètre Diffie-Hellman a été retiré d'OpenVPN, en application de la RFC
7919. Le seul vrai impact est pour les machines les moins puissantes, sur
lesquelles étaient configurées des clés plus petites. Besoin de changer de
firewall ? Pensez à notre boutique en ligne ;-)
Le plugin os-dyndns est toujours disponible (il avait été question de le
supprimer), mais il pourrait disparaître dans les prochaines versions car il
repose sur le paquet ddclient qui ne semble plus mis à jour depuis un certain
temps. Donc, finalement rien de changé pour OPNsense 22.7, mais il est possible
que le plugin soit supprimé à l'avenir.
Si vous lancez la mise à jour de votre firewall en ligne de commande, le
changelog sera dorénavant présenté. Pour le faire défiler, il faut utiliser les
flèches directionnelles de son clavier ou appuyer sur "q" pour quitter et
retrouver le processus de mise à jour habituel.
Le serveur DHCPv6 sur une interface configurée en mode tracking ("suivre
l'interface" sur la version française) requiert que soit définie la plage
d'adresses à utiliser (un peu comme son pendant pour une interface configurée
avec une adresse IP statique). Aussi, si vous utilisez le mode tracking sur une
interface disposant d'un /64 ou inférieur, cela générera une alerte. Il est
possible que le service DHCPv6 refuse de se lancer. Dans ce cas, il suffit
d'adapter / corriger la configuration et ça devrait résoudre le problème.
Enfin, il est à noter que quatre problèmes ont été remontés et qu'ils ont déjà
été corrigés via un patch correctif rapide ("hotfix"). Si vous avez déjà mis à
jour votre OPNsense vers la version 22.7, il peut donc être utile de refaire une
vérification afin de vous assurer de disposer de ce dernier patch.
Comme d'habitude, si vous n'avez pas appliqué les dernières mises à jour
d'OPNsense, vous devrez d'abord mettre à jour votre OPNsense vers la dernière
ancienne version disponible (soit la 22.1.10) avant de pouvoir procéder à la
mise à jour vers la nouvelle version (22.7).
PROCESSUS DE MISE À JOUR
Cette nouvelle version est disponible pour les mises à jour et en téléchargement
pour les nouvelles installations.
Pensez à faire une sauvegarde avant de lancer la mise à jour.
Si votre système de fichiers est ZFS, pensez également à créer un point de
restauration.
Pour la mise à jour, vous pouvez vous appuyer sur notre tuto écrit pour pfSense,
mais facilement adaptable pour OPNsense : [pfSense] Mettre à jour son serveur
pfSense.
Enfin, vous pouvez consulter la liste complète des changements en visitant la
page suivante : OPNsense 22.7 released [EN]
POUR ALLER PLUS LOIN
[pfSense / OPNsense] Créer un point de restauration pour des mises à jour et des
retours arrière en toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jourOPNsenseupgrade
[PFSENSE] FILTRER LES ADRESSES IP À RISQUE
29/03/2022 - AUCUN COMMENTAIRE
Dans cet article nous présentons une solution afin de filtrer les adresses IP
publiques réputées à risques ou hébergeant des malwares ou des contenus
malveillants.
Il s'agit d'une solution intéressante et très rapide à mettre en œuvre sur ses
firewall.
Nous présenterons deux solutions : une gratuite et une payante.
FILTRER LES IP À RISQUE, POURQUOI ?
Une bonne pratique de sécurité informatique est d'empêcher le trafic à
destination ou provenant de sources réputées à risque. C'est-à-dire le trafic
vers ou à destination de serveurs ou d'adresses IP hébergeant des virus, des
malwares, du contenu malveillant ou aux mains de pirates informatiques.
Cela apporte une couche de sécurité pour le trafic internet sortant : en cas de
détournement DNS ou d'infection par un vers ou un malware, du trafic est
généralement émis ou redirigé vers des serveurs frauduleux. Essayer de détecter
ces serveurs et de bloquer le trafic à leur destination est une bonne approche.
De la même manière, lorsqu'une entreprise héberge un service comme un accès
OpenVPN ou un serveur web, il n'est généralement appliqué aucun filtrage sur les
adresses IP publiques pouvant se connecter. Bloquer a minima le adresses IP
connues pour être utilisées par des personnes malintentionnées est donc
également une approche intéressante.
Pour être efficace, ces listes d'adresses IP à risque doivent être mises à jour
très régulièrement afin de coller au plus près des menaces en cours. Elles
doivent éviter de comporter des faux-positifs, c'est-à-dire ne pas répertorier
des adresses IP qui sont en réalité parfaitement légitimes.
Si le taux de faux-positifs est trop fort, alors cela devient complètement
inutilisable en production pour des TPE/PME.
C'est donc un subtile équilibre qu'il faut trouver pour d'une part être efficace
et d'autre part ne pas bloquer du trafic légitime.
Le filtrage des adresses IP publiques réputées à risque fait partie d'une
approche de sécurité de défense en profondeur.
Nous présenterons deux solutions :
Les listes DROP et eDROP de SpamHaus. Ce sont des listes gratuites sans risque
de faux-positifs.
Les listes proposées par nos soins. Ce sont des listes payantes qui permettent
un filtrage beaucoup plus fin et complet que SpamHaus tout en étant très
attentif à éviter les faux-positifs.
L'implémentation se fera ensuite en deux étapes : créer un alias se chargeant de
récupérer les listes d'adresses IP à bloquer, puis créer les règles de filtrage
bloquant le trafic associé à ces alias.
SPAMHAUS - CRÉER UN ALIAS CONTENANT LA LISTE DES ADRESSES IP À FILTRER (GRATUIT)
The Spamhaus Project (SpamHaus) est une organisation internationale non
gouvernementale dont l'objectif est de fournir une protection en temps-réel
contre les pourriels.
SpamHaus fournit un certain nombre d'outils en ce sens, ainsi que plusieurs
listes de filtrage d'adresses IP à risque.
Ces listes de filtrage nommées DROP (Don't Route Or Peer) et EDROP (Extended
DROP) sont composées de blocs réseau qui sont "détournés" ou loués par des
spammeurs professionnels ou utilisés à des fins cybercriminelles (diffusion de
logiciels malveillants, téléchargement de chevaux de Troie, botnet, etc.).
Les listes DROP et EDROP n'incluent pas d'adresses IP uniques, mais seulement
des blocs d'adresses IP. Ainsi, une adresse IP isolée connue pour être
malveillante ne sera jamais bloquée par les listes SpamHaus. Seuls des blocs
d'adresses IP attribués à des LIR seront bloqués par la liste DROP. La liste
EDROP étend un peu le concept en bloquant des sous-réseaux plus fins.
Ainsi, c'est un filtrage grosse-maille qui est proposé par SpamHaus. Le gros
intérêt est que le risque de faux-positif est théoriquement nul. L'inconvénient
est que le filtrage manque de précision, ce qui réduit forcément la sécurité
apportée par ces listes.
Les listes DROP et EDROP sont donc des solutions gratuites que nous recommandons
fortement d'utiliser sur tous les firewall. Même si le filtrage n'est pas
parfait, mieux vaut un filtrage grosse maille qu'aucun filtrage.
SpamHaus propose principalement 3 listes :
* DROP : https://www.spamhaus.org/drop/drop.txt
* EDROP : https://www.spamhaus.org/drop/edrop.txt (à utiliser en complément de
la liste DROP)
* DROPv6 : https://www.spamhaus.org/drop/dropv6.txt (à utiliser uniquement si
nous disposons d'un accès Internet en IPv6)
Nous allons créer trois alias : un pour chaque liste proposée par SpamHaus.
Nous nous rendons dans le menu Firewall > Aliases et cliquons sur le bouton "+
Add" :
Les champs à compléter sont les suivants :
* Name : le nom que nous souhaitons donner à notre alias
* Type : choisir "URL Table (IPs)"
* URL Table (IPs) : saisir l'url d'une des listes de SpamHaus. Le nombre après
le slash indique la fréquence de mise en jour en nombre de jours. 128
signifie que le contenu du fichier sera téléchargé tous les 128 jours. Nous
pouvons, par exemple, choisir "1", les listes de SpamHaus étant mises à jour
moins une fois par semaine en moyenne.
Exemple de résultat obtenu pour la liste DROP :
Nous répétons l'opération pour chacune des trois listes. Ce qui nous donne le
résultat suivant :
Si vous êtes utilisateurs d'OPNsense, l'approche est exactement la même. Il faut
se rendre dans le menu Pare-feu > Alias et cliquer sur le discret bouton "+" :
Compléter les champs de la manière suivante :
* Nom : le nom que nous souhaitons donner à notre alias
* Type : URL Table (IPs)
* Refresh Frequency : la fréquence de rafraîchissement. Une fois par jour est
largement suffisant. Les listes de SpamHaus sont mises à jour plus ou moins
toutes les semaines.
* Contenu : saisir l'url d'une des listes de SpamHaus
Exemple de résultat obtenu pour la liste DROP :
Nous répétons l'opération pour chacune des trois listes.
Nos alias sont prêts. Il nous reste à configurer nos règles de filtrage pour
bloquer le trafic entrant provenant de ces adresses IP, ainsi que le trafic
sortant à destination de ces adresses IP.
PROVYA - CRÉER UN ALIAS CONTENANT LA LISTE DES ADRESSES IP À FILTRER (PAYANT)
Note : dans ce chapitre, nous présentons une solution commerciale payante. Si
vous n'êtes pas intéressé, vous pouvez passer directement au chapitre suivant :
Créer les règles de filtrage associées.
Nous avons décidé de créer notre propre liste de filtrage d'adresses IP
malveillantes.
Pour cela, nous nous appuyons sur une trentaine de sources (dont SpamHaus) que
nous traitons et que nous recoupons afin de comparer les adresses IP présentes.
Cela nous permet de déterminer la fréquence d'apparition d'une adresse IP
détectée. Plus une adresse IP est détectée et plus la probabilité que ce soit
une adresse IP malveillante est forte. A contrario, plus la probabilité de
rencontrer un faux-positif est faible.
Cela permet d'avoir une source unique très complète et efficace avec des sources
fiables et recoupées, tout en conservant un risque de faux-positifs extrêmement
faible.
Nous proposons trois listes :
* strict : cette liste contient les adresses IP que nous avons détectées dans
au mois deux sources de collectes différentes. La probabilité de rencontrer
un faux-positif est faible.
* main : cette liste contient les adresses IP que nous avons détectées dans au
mois trois sources de collectes différentes. La probabilité de rencontrer un
faux-positif est extrêmement faible. C'est cette liste que nous recommandons
d'utiliser.
* soft : cette liste contient les adresses IP que nous avons détectées dans au
mois quatre listes de collectes différentes. La probabilité de rencontrer un
faux-positif est théoriquement nulle.
L'accès à ces listes est payant sous la forme d'un abonnement mensuel ou annuel.
Si vous êtes intéressé, vous pouvez consulter notre boutique en ligne : Liste IP
malveillantes.
Pour découvrir le service, nous proposons une offre de lancement à 1 € H.T. pour
le premier mois.
Passons à l'implémentation. Pour cela, nous allons créer un alias en nous
rendant dans le menu Firewall > Aliases et cliquons sur le bouton "+ Add" :
Les champs à compléter sont les suivants :
* Name : le nom que nous souhaitons donner à notre alias
* Type : choisir "URL Table (IPs)"
* URL Table (IPs) : saisir l'url de la liste que l'on souhaite télécharger (cf.
paragraphe suivant). Le nombre après le slash indique la fréquence de mise en
jour en nombre de jours. Nous indiquons "1".
Pour pouvoir télécharger la liste de votre choix, il faudra disposer d'une clef
de licence valide. L'URL à saisir sera de la forme suivante :
https://provya.fr/download/VERSION.txt?key=VOTRE_CLEF (en remplaçant VERSION par
le fichier choisi et VOTRE_CLEF par la clef de licence que vous aurez reçu par
e-mail).
Ce qui donne l'une des URLs suivantes à utiliser :
* fichier strict : https://provya.fr/download/strict.txt?key=VOTRE_CLEF
* fichier main (recommandé) :
https://provya.fr/download/main.txt?key=VOTRE_CLEF
* fichier soft : https://provya.fr/download/soft.txt?key=VOTRE_CLEF
Exemple de résultat obtenu :
Par défaut, pfSense ne propose une mise à jour des alias de type "URL Table"
qu'au mieux une fois par jour. Ce qui est trop peu pour pouvoir disposer d'une
liste réellement à jour. Nous recommandons de mettre à jour la liste toutes les
heures ou toutes les deux heures.
Pour y remédier, nous suggérons d'installer le package "cron" afin d'effectuer
des mises à jour plus fréquentes.
Pour cela, nous nous rendons dans le menu System > Package Manager, onglet
"Available Packages". Nous faisons une recherche avec le mot-clé "cron" et
cliquons sur l'icône d'installation :
Une fois le package "cron" installé, naviguer dans le menu Services > Cron :
Nous repérons la ligne rc.update_urltables et cliquons sur son icône de
modification (crayon) :
Nous suggérons d'effectuer la mise à jour toutes les heures ou toutes les deux
heures. Il faut modifier le champ "Hour" :
La mise à jour est ici effectuée toutes les deux heures
Si vous êtes utilisateurs d'OPNsense, l'approche est exactement la même. Il faut
se rendre dans le menu Pare-Feu > Alias et cliquer sur le discret bouton "+" :
Compléter les champs de la manière suivante :
* Nom : le nom que nous souhaitons donner à notre alias.
* Type : URL Table (IPs)
* Refresh Frequency : la fréquence de rafraîchissement. Nous recommandons de
faire un rafraîchissement une fois par heure ou une fois toutes les deux
heures.
* Contenu : saisir l'url de la liste que l'on souhaite télécharger (cf.
paragraphe suivant).
Pour pouvoir télécharger la liste de votre choix, il faudra disposer d'une clef
de licence valide. L'URL à saisir sera de la forme suivante :
https://provya.fr/download/VERSION.txt?key=VOTRE_CLEF (en remplaçant VERSION par
le fichier choisi et VOTRE_CLEF par la clef de licence que vous aurez reçu par
e-mail).
Ce qui donne l'une des URLs suivantes à utiliser :
* fichier strict : https://provya.fr/download/strict.txt?key=VOTRE_CLEF
* fichier main (recommandé) :
https://provya.fr/download/main.txt?key=VOTRE_CLEF
* fichier soft : https://provya.fr/download/soft.txt?key=VOTRE_CLEF
Exemple de résultat obtenu :
Avantage d'OPNsense sur pfSense : il est possible de préciser un taux de
rafraîchissement aussi bien en jours qu'en heures (contre uniquement en jours
pour pfSense). Toute l'étape liée à la gestion du cron décrite pour pfSense
n'est donc pas nécessaire sur OPNsense !
La configuration de notre alias est terminée. Il nous reste à configurer nos
règles de filtrage pour bloquer le trafic entrant provenant de ces adresses IP,
ainsi que le trafic sortant à destination de ces adresses IP.
CRÉER LES RÈGLES DE FILTRAGE ASSOCIÉES
Se rendre dans le menu Firewall > Rules et ajouter sur l'interface WAN (ou d'une
façon générale sur les interfaces de vos connexions à Internet) une règle en
haut de liste en cliquant sur le bouton .
Configurer la règle avec les paramètres suivants :
* Action : Block
* Protocol : Any
* Source : "Single host or alias" et saisir le nom de l'alias créé à l'étape
précédente
* Destination : any
Il faut bien sûr adapter avec le nom de l'alias utilisé à l'étape précédente.
Si vous utilisez une liste Provya, une seule liste doit être utilisée (strict,
main ou soft). Il est également inutile d'utiliser une liste SpamHaus en
complément car les adresses IP fournies par SpamHaus sont déjà incluses dans les
listes Provya.
Si vous utilisez SpamHaus, il faudra créer une règle pour chaque alias (DROP et
EDROP). Si vous utilisez la liste DROPv6, il faudra bien penser à choisir IPv6
pour le champ "Address Family" de votre règle de filtrage.
Enfin, nous créons également une règle sur l'interface LAN (ou d'une façon plus
générale sur toutes nos interfaces locales qui disposent d'un accès vers
Internet) que nous plaçons en haut de liste en cliquant sur le bouton .
Les paramètres à saisir sont les suivants :
* Action : Block
* Protocol : Any
* Source : LAN net
* Destination : "Single host or alias" et saisir le nom de l'alias créé à
l'étape précédente
Il faudra bien sûr adapter avec le nom de l'alias utilisé à l'étape précédente.
Si vous utilisez SpamHaus, il faudra encore une fois créer autant de règles que
vous avez créé d'alias.
Voilà, le filtrage des adresses IP à risque est en place.
Il s'agit d'un élément de sécurité essentiel et vraiment simple à mettre en
œuvre afin d'apporter un niveau de sécurité supplémentaire pour le trafic
passant par notre firewall.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : filtrageippfSense
PFSENSE 2.6.0 EST DISPONIBLE
15/02/2022 - 9 COMMENTAIRES
Lundi 14 février 2022 est sortie la dernière version de pfSense. La version
2.6.0.
Dans cet article, nous faisons le tour rapide des éléments marquants de cette
mise à jour.
FILTRAGE / NAT
Plusieurs modifications / corrections apportées, dont notamment :
* Ajout du support d'IPv6 pour les règles easyrule.
* Possibilité d'utiliser un alias pour le champ destination des règles de NAT
1:1
* La copie d'une règle de redirection de port (Port Forward) tient maintenant
compte de la configuration existante pour l'association d'une règle de
filtrage (Filter Rule Association).
* Ajout d'une icône permettant de visualiser le sens du filtrage pour les
règles de l'onglet "Floating".
* Lorsque le nom d'un groupe d'interfaces commençait par un chiffre, cela
générait un XML invalide. C'est corrigé.
IPSEC
Cette version apporte plusieurs modifications importantes à IPsec. Ce sont des
modifications portant sur la stabilité et les performances.
Le nom des interfaces IPsec VTI (IPsec routé) a changé. Les configurations
existantes seront mises à jour automatiquement dans la mesure du possible pour
utiliser les nouveaux noms.
Une fois la mise à jour vers pfSense 2.6.0 réalisée, il est conseillé de
vérifier que les noms des instances VTI configurées ont correctement été repris
pour l'assignation des interfaces. Cette vérification s'opère depuis le menu
Interfaces > Assignments.
Il y a énormément de corrections de petits bugs spécifiques apportés à cette
version de pfSense. Il est compliqué de tous les lister, mais en résumé, si vous
avez des problèmes avec IPsec, mettez à jour !
ZFS
Plusieurs modifications mineures ont été apportées. Notamment le nom du pool ZFS
et les ensembles de données ont été mis à jour.
Ces modifications ne sont pas appliquées lors de la mise à jour pour les pfSense
déjà installés avec ZFS.
Ces changements ne sont pris en compte que pour les nouvelles installations.
Autre changement concernant ZFS : la compression pour les rotations des fichiers
de journalisation est maintenant désactivée, car ZFS effectue sa propre
compression.
Encore une fois, ce paramètre s'applique uniquement pour les nouvelles
installations, mais pas pour les mises à jour. Aussi, si vous êtes sur un
système de fichiers ZFS et que vous mettez à jour, il est conseillé de
désactiver la compression pour les rotations des fichiers de journalisation.
Cette opération s'effectue depuis le menu Status > System Logs, onglet
"Settings".
Pour rappel, ZFS permet, entre autre, de créer des points de restauration
permettant de réaliser des retours en arrière très simplement et très rapidement
en cas de besoin.
SÉCURITÉ
* Le format de hachage des mots de passe pour les utilisateurs locaux a été
modifié de bcrypt à SHA-512.
* Plusieurs corrections ont été apportées à l'interface graphique qui
présentait des vulnérabilités potentielles à des attaques de type cross-site
scripting (XSS).
* Désactivation de l'accès ssh pour les comptes admin et root lorsque le compte
admin est désactivé sur l'interface web.
BUGS / AMÉLIORATIONS
* Il est enfin possible de configurer l'adresse IP WAN avec un /32 depuis le
menu de la console (très utile pour des serveurs pfSense hébergés, par
exemple).
* Diverses améliorations sur la page et sur le processus de déconnexion du
portail captif.
* Correction de plusieurs bugs sur la validation du formulaire de configuration
d'un serveur OpenVPN. Certains paramètres (notamment les paramètres NCP
permettant une négociation des paramètres cryptographiques entre le client et
le serveur) n'étaient pas correctement appliqués.
* Correction d'une erreur qui apparaissait lorsqu'un alias de type "URL Table"
était rechargé mais qu'il était vide.
* Correction de plusieurs bugs qui existaient sur l'imbrication d'alias
(c'est-à-dire un alias faisant référence à un autre alias).
* Correction de bugs d'affichage.
* Le service AutoConfigBackup a été amélioré sur plusieurs points, dont :
amélioration des informations liées à la restauration, précisions sur
l'emplacement des sauvegardes, amélioration de la performance générale du
service.
* Plusieurs corrections liées à CARP. Ces corrections portent principalement
sur le fait de pouvoir modifier le VHID d'une adresse VIP déjà créée (la mise
à jour n'était pas correctement appliquée ou diffusée).
* Corrections de problématiques d'encodage de caractères UTF-8 pour les
certificats créés localement sur pfSense.
* Amélioration de la stabilité d'Unbound qui avait tendance à crasher
facilement sur les installations personnalisées comportant des erreurs.
* Il n'était plus possible d'utiliser le protocole de priorisation de trafic
CBQ sur les interfaces VLAN (cela plantait). C'est corrigé.
PROCESSUS DE MISE À JOUR
Cette nouvelle version est disponible pour les mises à jour et en téléchargement
pour les nouvelles installations.
Si aucune mise à jour ne vous est proposée, il peut être utile de rafraîchir les
dépôts de votre pfSense à l'aide des commandes suivantes (à saisir en console ou
depuis un shell) :
pkg-static clean -ay; pkg-static install -fy pkg pfSense-repo pfSense-upgrade
Si votre pfSense est installé sur un système de fichiers ZFS, pensez à créer un
point de restauration.
Dans tous les cas, pensez à faire une sauvegarde avant de lancer la mise à jour,
et suivez notre tuto complet : [pfSense] Mettre à jour son serveur pfSense.
Enfin, vous pouvez consulter la liste complète des changements en visitant la
page suivante : 2.6.0 New Features and Changes [EN]
POUR ALLER PLUS LOIN
[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en
toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jour pfSensepfSense
[PFSENSE] LA PUISSANCE DE ZFS POUR DES MISES À JOUR ET DES RETOURS ARRIÈRE EN
TOUTE SÉRÉNITÉ
08/02/2022 - 5 COMMENTAIRES
Dans cet article nous présentons l'intérêt de l'utilisation du système de
fichiers ZFS et de ses instantanés lors des mises à jour de pfSense.
Il s'agit d'une solution très efficace pour gérer ses mises à jour et ses
possibilités de retour arrière vers des points de restauration très facilement.
ZFS, C'EST QUOI ? QUEL INTÉRÊT ?
ZFS est un système de fichiers et un gestionnaire de volume open source.
ZFS offre de très nombreuses fonctionnalités. Nous ne les détaillerons pas dans
cet article, nous proposons la consultation de la page Wikipédia qui lui est
dédiée : ZFS.
Pour des firewall tournant sous pfSense, ZFS présente deux gros intérêts : la
facilité d'installation de deux disques en haute-disponibilité (Raid) et la
possibilité de réaliser des instantanés (snapshot).
Dans cet article, nous nous intéressons particulièrement à l'intérêt des
snapshot ZFS lors des mises à jour de pfSense.
En effet, il peut arriver qu'une nouvelle version de pfSense comporte des bugs
et que ceux-ci ne soient pas corriger immédiatement (ex : les versions 2.5.0 et
2.5.1 qui étaient catastrophiques) ; ou qu'il y ait une incompatibilité
matérielle suite à une mise à jour (aucun risque si vous prenez votre matériel
chez Provya ;-) ).
Dans ce cas, il peut être pratique de disposer d'un point de restauration pour
pouvoir faire un retour-arrière rapide vers la version précédente de pfSense
(ex : 2.4.5-p1).
Dans cet article, nous présentons comment créer un point de restauration grâce
aux instantanés. Comment procéder à une restauration si besoin. Et comment
supprimer le point de restauration si la mise à jour s'est bien passée.
Cette stratégie est applicable aussi bien à pfSense qu'à OPNsense.
INSTANTANÉ, SNAPSHOT, QU'EST-CE QUE C'EST ?
Un instantané est une copie en lecture seule d'un système de fichiers ou d'un
volume.
La création d'un instantané est quasiment immédiate.
Initialement, un instantané ne consomme pas d'espace disque supplémentaire.
Toutefois, à mesure que les données contenues dans le jeu de données actif
changent, l'instantané consomme de l'espace disque en continuant à faire
référence aux anciennes données et empêche donc de libérer de l'espace disque.
Snapshot est le terme anglais pour instantané. Les termes "instantané" et
"snapshot" désignent donc la même chose.
PRÉ-REQUIS
1/2. DISPOSER D'UN ACCÈS AU FIREWALL
Il faut disposer d'un accès en mode console au firewall. Il existe trois
possibilités : utiliser la console présente dans l'interface web de pfSense,
activer le serveur SSH de pfSense ou activer le port console (si le firewall est
équipé d'un port console).
Utiliser la console de l'interface web
Il s'agit de la solution la plus simple. pfSense dispose d'un accès console
depuis l'interface web. Pour y accéder, se rendre dans le menu Diagnostics >
Command Prompt :
Il sera possible de saisir les commandes indiquées et de cliquer sur le bouton
"Execute" pour les exécuter. Le résultat de la commande sera affiché à l'écran.
OPNsense n'offre pas d'accès console depuis son interface web. Ceci pour des
raisons de sécurité.
Activer le serveur SSH de pfSense
La deuxième possibilité est de se connecter au firewall via son serveur SSH.
Par défaut, le serveur SSH est désactivé.
Pour l'activer, se rendre dans le menu System > Advanced :
Descendre au niveau de la section "Secure Shell" et cocher la case "Enable
Secure Shell".
Il est également possible de paramétrer la méthode d'authentification (mot de
passe ou certificat) et le port d'écoute (22 par défaut).
Il faudra aussi potentiellement créer une règle de filtrage côté LAN pour
autoriser la connexion sur le port 22 (ou sur le port choisi à l'étape
précédente, s'il a été personnalisé).
Exemple de règle :
Pour OPNsense, le principe est le même : il faut activer le serveur SSH du
firewall. La configuration s'opère depuis le menu Système > Paramètres >
Administration.
Au niveau de la section "Shell Sécurisé", cocher la case "Activer le Shell
sécurisé", autoriser potentiellement le compte root à se connecter si l'on ne
possède pas un autre compte administrateur, autoriser (ou non)
l'authentification par mot de passe et choisir le port d'écoute.
Il est également possible de personnaliser un certain nombre de paramètres de
sécurité.
Activer le port console de pfSense
La troisième et dernière possibilité est de se connecter au firewall par son
port console (ou port série).
Le port console est désactivé par défaut.
Il faudra bien sûr que le firewall soit équipé d'un port console.
Se rendre dans le menu System > Advanced et descendre jusqu'à la section "Serial
Communications".
Cocher la case "Enable serial port" et cocher la case "Password protect the
console menu" afin de protéger la console par un mot de passe.
Par défaut, lorsque le port console est activé, n'importe qui peut se brancher
directement sur le firewall et disposer d'un accès root. Ce qui représente un
risque en terme de sécurité.
Pour OPNsense, la configuration s'opère depuis le menu Système > Paramètres >
Administration :
2/2. DISPOSER D'UN SYSTÈME DE FICHIERS ZFS
Dernier pré-requis, il faut bien sûr que notre firewall soit installé avec le
système de fichiers ZFS.
Pour savoir si notre système de fichiers est ZFS, saisir la commande suivante :
zfs list
S'il s'agit d'un système de fichiers ZFS, nous devrions obtenir un résultat du
type :
NAME USED AVAIL REFER MOUNTPOINT
zroot 900M 12.2G 88K /zroot
zroot/ROOT 886M 12.2G 88K none
zroot/ROOT/default 886M 12.2G 886M /
zroot/tmp 192K 12.2G 192K /tmp
zroot/var 11.4M 12.2G 11.4M /var
Autrement, nous obtenons un résultat du type :
no datasets available
PROCÉDURE
Dans cet article, nous prenons comme exemple la mise à jour de pfSense de la
version 2.5.2 vers la version 2.6.0 (non, la version 2.6.0 n'est pas encore
sortie, mais ce n'est plus qu'une question de jours / semaines ;-) )
Les étapes à suivre sont les suivantes.
1. Voir les environnements de démarrage actuels avec la commande bectl list.
Si nous n'avons jamais trifouillé ces options, nous devrions obtenir quelque
chose comme ceci :
[2.5.2-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE Active Mountpoint Space Created
default NR / 886M 2021-12-17 16:21
* N signifie actif actuellement (Now)
* R signifie actif au prochain redémarrage (Reboot)
2. Ajouter un nouvel environnement de démarrage que l'on appelle "pfsense-2.5.2"
(ce sera notre point de restauration en cas de besoin) :
bectl create pfsense-2.5.2
3. Pour plus de lisibilité, renommer l'environnement de démarrage actuel
(default) en "pfsense-2.6.0" :
bectl rename default pfsense-2.6.0
Une fois ces commande saisies, nous obtenons les environnements de démarrage
suivants :
BE Active Mountpoint Space Created
pfsense-2.5.2 - - 8K 2022-02-07 17:56
pfsense-2.6.0 NR / 886M 2021-12-17 16:21
On peut voir que notre nouvel environnement de démarrage ne prend que très peu
d'espace disque à ce stade (8 Ko).
4. Réaliser un instantané des partitions /var et /tmp :
zfs snapshot zroot/var@pfsense-2.5.2
zfs snapshot zroot/tmp@pfsense-2.5.2
Les partitions /var et /tmp ne sont pas sur le même pool. Il faut donc les
sauvegarder via un instantané. C'est ce que nous venons de faire.
Il est possible d'afficher la liste des instantanés ZFS avec la commande
suivante :
zfs list -t snapshot
Le résultat ressemblera à ceci :
NAME USED AVAIL REFER MOUNTPOINT
zroot/ROOT/pfsense-2.6.0@2022-02-07-17:56:35-0 0 - 886M -
zroot/tmp@pfsense-2.5.2 64K - 192K -
zroot/var@pfsense-2.5.2 88K - 11.4M -
Encore une fois, on voit que les instantanés ne consomment pratiquement pas
d'espace disque supplémentaire au moment de leur création.
C'est tout !
Nous avons créé un deuxième environnement de démarrage (qui est une copie du
premier à ce stade) et un instantané des partitions /var et /tmp.
À ce stade, nous pouvons lancer la mise à jour de pfSense (ou d'OPNsense) de
manière tout à fait classique.
On peut aussi tester la branche de développement, installer des packages, tester
des configurations, etc. En cas de pépin, nous pourrons très rapidement revenir
à notre point de restauration.
Dans notre cas, et pour l'exemple, nous décidons de tester la version 2.6.0 de
pfSense :
Pour mettre à jour notre serveur, n'hésitons pas à nous appuyer sur notre
article dédié : [pfSense] Mettre à jour son serveur pfSense
LA MISE À JOUR S'EST BIEN PASSÉE, COMMENT SUPPRIMER L'INSTANTANÉ ?
Si notre mise à jour s'est bien passée. Nous conseillons de ne toucher à rien
durant les premiers jours / semaines, le temps de s'assurer qu'il n'y ait pas
d'effets de bord et que tous les services fonctionnent tel qu'attendu.
Si c'est le cas, alors nous pouvons supprimer notre point de restauration et nos
instantanés, ce qui permettra de libérer de l'espace sur le disque-dur.
En effet, là où notre point de restauration de notre environnement de démarrage
ne prenait que 8 Ko à sa création, il en consomme maintenant bien plus :
[2.6.0-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE Active Mountpoint Space Created
pfsense-2.5.2 - - 777M 2022-02-07 17:56
pfsense-2.6.0 NR / 1.74G 2021-12-17 16:21
Notre point de restauration de notre environnement de démarrage consomme
maintenant 777 Mo d'espace sur le disque-dur.
Idem pour les instantanés de /var et /tmp :
[2.6.0-RELEASE][root@pfSense.home.arpa]/root: zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
zroot/ROOT/pfsense-2.6.0@2022-02-07-17:56:35-0 777M - 886M -
zroot/tmp@pfsense-2.5.2 160K - 192K -
zroot/var@pfsense-2.5.2 5.05M - 11.4M -
Pour supprimer le point de restauration et les instantanés, les trois commandes
à saisir sont les suivantes :
bectl destroy pfsense-2.5.2
zfs destroy zroot/var@pfsense-2.5.2
zfs destroy zroot/tmp@pfsense-2.5.2
C'est tout.
JE SOUHAITE FAIRE UN RETOUR-ARRIÈRE, COMMENT FAIRE ?
Si la mise à jour s'est mal passée ou si nous souhaitons revenir à l'état
antérieur, il suffit de restaurer les instantanés ZFS et de modifier
l'environnement de démarrage pour choisir notre point de restauration.
Pour activer notre point de restauration au prochain démarrage, la commande à
saisir est la suivante :
bectl activate pfsense-2.5.2
Nous obtenons un message de confirmation. Il est également possible de vérifier
la bonne prise en compte de la configuration via la commande bectl list :
BE Active Mountpoint Space Created
pfsense-2.5.2 R - 886M 2022-02-07 17:56
pfsense-2.6.0 N / 893M 2021-12-17 16:21
Le marqueur R a bien basculé sur notre environnement de démarrage pfsense-2.5.2.
Et pour rétablir les instantanés, les commandes à saisir sont les suivantes :
zfs rollback -R zroot/var@pfsense-2.5.2
zfs rollback -R zroot/tmp@pfsense-2.5.2
Il reste à redémarrer le firewall pour que les changements soient totalement
pris en compte.
Le redémarrage peut être lancé depuis l'interface web ou depuis la ligne de
commande. La ligne de commande à saisir sera :
shutdown -r now
Une fois redémarré, on pourra supprimer les instantanés et l'environnement de
démarrage qui ne sont plus utilisés, soit dans notre exemple :
bectl destroy pfsense-2.6.0
zfs destroy zroot/var@pfsense-2.5.2
zfs destroy zroot/tmp@pfsense-2.5.2
On peut vérifier que les commandes ont bien été prises en compte en listant les
instantanés ZFS :
[2.5.2-RELEASE][root@pfSense.home.arpa]/root: zfs list -t snapshot
no datasets available
Les instantanés ont bien été supprimés.
Puis, en vérifiant les environnements de démarrage disponibles :
[2.5.2-RELEASE][root@pfSense.home.arpa]/root: bectl list
BE Active Mountpoint Space Created
pfsense-2.5.2 NR / 886M 2022-02-07 17:56
Enfin, pour se remettre totalement dans la situation d'origine, on pourrait
renommer l'environnement de démarrage en "default" avec la commande suivante :
bectl rename pfsense-2.5.2 default
Voilà, nous avons fait le tour des éléments à connaître pour créer des points de
restauration super facilement sur pfSense et OPNsense.
C'est une approche que nous recommandons fortement de suivre avant de lancer la
mise à jour de nos firewall.
POUR ALLER PLUS LOIN
[pfSense] Mettre à jour son serveur pfSense
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jourmise à jour pfSenseOPNsensepfSense
OPNSENSE 22.1 EST DISPONIBLE
27/01/2022 - AUCUN COMMENTAIRE
Jeudi 27 janvier 2022 est sortie la dernière version d'OPNsense. La version
22.1.
Il s'agit d'une mise à jour importante, avec notamment la migration
d'HardenedBSD vers FreeBSD 13.
Dans cet article, nous faisons le tour des éléments marquants de cette mise à
jour.
OS : PASSAGE D'HARDENEDBSD À FREEBSD
Il s'agit là d'un changement important : OPNsense s'appuyait jusqu'à présent sur
le système d'exploitation HardenedBSD. OPNsense 22.1 s'appuie dorénavant sur
FreeBSD.
HardenedBSD est un fork de FreeBSD visant à améliorer la sécurité du système en
implémentant des technologies d'atténuation et de durcissement contre
l'exploitation de vulnérabilité informatique.
Beaucoup d'améliorations proposées par HardenedBSD ont été réintégrées à
FreeBSD, notamment FreeBSD 13.
Enfin, lorsque certaines bugs spécifiques à HardenedBSD étaient rencontrés, ils
étaient parfois difficiles à résoudre car la communauté HardenedBSD est beaucoup
plus petite que la communauté FreeBSD.
Les équipes de développement d'OPNsense ont donc jugé qu'il était préférable de
s'appuyer directement sur FreeBSD.
Autre point notable par rapport au système d'exploitation : il y a une
amélioration de la gestion du système de fichiers ZFS.
GESTION DES LOGS
La journalisation circulaire (circular log) a été retirée.
De manière simplifiée, la journalisation circulaire permet de définir une taille
maximale par fichier de journalisation (ex : 100 Ko) et un nombre maximal de
fichiers de journalisation à conserver (ex : 30 fichiers).
La journalisation se définit maintenant en nombre de jours de rétention : un
fichier est conservé par jour et par type de services. On peut choisir la durée
de conservation des fichiers de journalisation.
Le format de stockage des fichiers de journalisation est le suivant :
/var/log/<application>/<application>_[YYYYMMDD].log
Il était déjà possible de désactiver la journalisation circulaire depuis
OPNsense 20.7. Elle est donc maintenant supprimée.
Nouveau fichier de journalisation "latest.log"
Le fichier latest.log contient les derniers logs toutes catégories confondues.
L'utilisation de ce fichier peut être très pratique pour gagner en efficacité
lors de ses sessions de dépannage / troubleshooting, il évite d'avoir à passer
d'un fichier de journalisation à l'autre pour chaque service.
Support de la RFC 5424
Les fichiers de journalisation sont maintenant tous compatibles avec le format
syslog et offrent la possibilité de filtrer par gravité.
GESTION DES INTERFACES
Plusieurs améliorations, dont :
* Amélioration de la gestion des interfaces PPP en environnement
haute-disponibilité : possibilité de désactiver l'interface PPP lorsque CARP
passe en mode backup.
* Meilleure granularité sur le choix de l'adresses MAC pour une interface
donnée : le spoof d'adresse MAC s'applique maintenant uniquement sur
l'interface sélectionnée et pas à ses parents ou enfants : avant, par
exemple, le spoof s'apliquait sur l'interface parente et sur toutes les
interfaces vlan configurées dessus, maintenant, la configuration se fait
uniquement sur l'interface logique choisie.
* Uniformisation et amélioration de la configuration des interfaces bridge
(pont réseau) lorsqu'elles sont connectées au réseau.
* Il est maintenant possible d'associer une adresse IP virtuelle (VIP) à une
interface qui n'est pas configurée ; cette configuration peut s'avérer très
utile dans certains environnements spécifiques comme par exemple la
possibilité d'avoir un cluster de firewall OPNsense avec une interface WAN
qui ne possède qu'une seule adresse IP.
PARE-FEU / ALIAS
* Suppression de l'option obsolète "kill states on gateway failure". Cette
action est effectuée automatiquement pour les passerelles qui sont
surveillées.
* Ajout du support des alias d'hôtes IPv6 dynamiques.
* Il est maintenant possible d'utiliser des alias dans la gestion des Router
Advertisements pour IPv6.
* Priorisation de trafic : ajout de l'option Gbit/s lors de la configuration
des pipes (avant, pour 1 Gbit/s, il fallait saisir 1 000 Mbit/s).
IPSEC
* Lors de la création de nouvelles phases 1 et 2, certains paramètres de
sécurité par défaut ont été remplacés par des paramètres plus modernes et
sécurisés.
* Suppression de certains algorithmes de chiffrement qui ne sont plus supportés
par FreeBSD 13 (dans le détail : MD5, Blowfish, DES, 3DES et CAST128 ne sont
plus pris en charge pour la phase 2).
TRADUCTIONS
Amélioration de la traduction pour plusieurs langues dont le français (sont
concernés dans le détail : français, allemand, italien, japonais, norvégien,
espagnol et turc).
A contrario, l'italien a été rétrogradé au rang de "en cours de développement" à
cause de son faible niveau de traduction.
Il est à noter que la traduction de l'interface d'OPNsense en français est
vraiment très bonne (surtout si on compare à pfSense...).
PLUGINS
Plusieurs plugins ont été mis à jour dont ACME , bind, haproxy, zabbix, ...
PROBLÈMES CONNUS ET POINTS D'ATTENTION
* OPNsense 22.1 contient une nouvelle version majeure du système
d'exploitation. Les mises à jour doivent donc être effectuées avec prudence.
Malgré tous les tests qui ont pu être effectués, il peut toujours subsister
des anomalies ou des changements modifiant le comportement par défaut.
* L'évolution du support des algorithmes de hachage ou de chiffrement sous
FreeBSD 13 peut avoir des impacts sur les VPN IPsec déjà configurés. Si vous
utilisez l'un des algorithmes de hachage obsolètes (MD5, Blowfish, DES, 3DES
ou CAST128), il faut modifier la configuration de votre tunnel IPsec avant de
lancer la mise à jour.
* Si vous utilisez des cartes réseau Realtek (notamment avec des ports 2,5
Gbps), il est recommandé d'installer le plugin os-realtek-re avant de lancer
la mise à jour. En effet, le pilote propriétaire Realtek n'est pas fourni par
défaut sous FreeBSD 13, ce qui a pour conséquence que certaines cartes
Realtek ne sont pas supportées par défaut.
* L'usurpation (spoof) d'adresse MAC ne concerne maintenant que l'interface
configurée et non les autres VLAN configurés sur la même interface ou
l'interface parent. Il faut donc modifier la configuration de ses interfaces
nécessitant une adresse MAC usurpée avant de faire la mise à jour.
* Les valeurs par défaut du service NTPD ont été modifiées pour exclure
l'option "iburst" par défaut. Le paramètre "limited" a été détaché de
l'option "kod". Il faut donc vérifier ces points avant de mettre à jour si
vous êtes concernés.
* Le support GRE link1 a été supprimé et nécessite une route statique pour
fonctionner.
* La prise en charge de la journalisation circulaire a été supprimée. Aucune
action n'est requise.
PROCESSUS DE MISE À JOUR
Cette nouvelle version est disponible pour les mises à jour et en téléchargement
pour les nouvelles installations.
Pensez à faire une sauvegarde avant de lancer la mise à jour.
Si votre système de fichiers est ZFS, pensez également à créer un point de
restauration.
Vous pouvez vous appuyer sur notre tuto écrit pour pfSense, mais facilement
adaptable pour OPNsense : [pfSense] Mettre à jour son serveur pfSense.
Enfin, vous pouvez consulter la liste complète des changements en visitant la
page suivante : OPNsense 22.1 released [EN]
POUR ALLER PLUS LOIN
[pfSense] La puissance de ZFS pour des mises à jour et des retours arrière en
toute sérénité
[pfSense] Mettre à jour son serveur pfSense
Best practices / Recommandations pour la configuration de votre firewall
Tous nos articles classés par thème
Voir un article au hasard
Vous avez aimé cet article ? Vous cherchez du matériel de qualité ? Alors
contactez-nous.
DÉCOUVREZ NOS SERVICES ET FIREWALL POUR PFSENSE, ASSEMBLÉS EN FRANCE, GARANTIE 3
ANS
store.provya.fr
Tags de l'article : mise à jourOPNsenseupgrade
éléments plus anciens »
Provya, tous droits réservés – Publié avec BlogoText