Pare-feu par zones UniFi : politiques, migration et IPS

01 / Cadre

Périmètre et prérequis

Depuis UniFi Network 9.0, le pare-feu des passerelles UniFi fonctionne par zones : on regroupe des interfaces (VLAN, WAN, VPN) dans des zones, puis on écrit des politiques entre zones. Ce guide explique le modèle, propose une matrice pour une PME et couvre les fonctions de sécurité associées.

Prérequis documentés : une passerelle UniFi (Cloud Gateway ou passerelle indépendante), UniFi Network 9.0 ou plus récent, passerelle en UniFi OS 4.1 ou plus récent.
Avec UniFi Network 11.0, tous les sites sont migrés automatiquement vers le pare-feu par zones. Un site encore en règles legacy doit donc préparer sa migration dès maintenant.
Prérequis de ce guide : un plan de segmentation déjà posé (voir le guide de conception).

02 / Modèle

Zones intégrées et matrice par défaut

UniFi fournit six zones intégrées, verrouillées : Internal (réseaux de confiance), External (WAN, Internet), Gateway (trafic destiné à la passerelle elle-même : DHCP, DNS, administration), VPN (utilisateurs distants et VPN site à site, Site Magic compris), Hotspot (invités) et DMZ. Vous pouvez créer des zones personnalisées, dans la limite de 30 zones. Chaque réseau appartient à une seule zone.

Matrice par défaut documentée par Ubiquiti (lignes : source, colonnes : destination)
Source \ Destination	Internal	External	Gateway	VPN	Hotspot	DMZ
Internal	Allow All	Policies	Allow All	Allow All	Allow All	Allow All
External	Policies	Policies	Policies	Policies	Policies	Policies
Gateway	Allow All	Allow All	-	Allow All	Allow All	Allow All
VPN	Allow All	Policies	Allow All	Allow All	Allow All	Allow All
Hotspot	Retour seul	Policies	Policies	Retour seul	Block All	Block All
DMZ	Retour seul	Policies	Policies	Retour seul	Block All	Block All

Deux lectures s’imposent. D’abord, tout ce qui est dans Internal se parle librement, y compris entre VLAN différents : regrouper tous les réseaux dans Internal revient à ne pas segmenter. Ensuite, la zone VPN a par défaut un accès complet à Internal : un poste nomade compromis connecté en VPN voit tout le réseau interne. Ces deux points justifient la matrice proposée en section 4.

03 / Modèle

Anatomie d’une politique

Une politique relie une zone source à une zone destination (Settings > Zones ou Settings > Policy Table selon la version). Ses éléments documentés :

Composants d’une politique de pare-feu
Élément	Options	Conseil d’usage
Source / destination	Any, Device, Network, IP, MAC ; ports (Any, Specific, Object) ; App, Domain (« Web ») ou Region	Préférez des objets nommés (groupes d’adresses, de ports) à des IP isolées.
Action	Allow (option « Auto Allow Return Traffic »), Block (abandon silencieux), Reject (refus notifié)	Block vers Internet et les zones non fiables, Reject en interne pour faciliter le diagnostic.
Restrictions	Version IP (IPv4, IPv6, les deux), protocole, état de connexion	Écrivez les politiques pour IPv4 et IPv6 dès qu’IPv6 est actif sur un réseau.
Journalisation	Envoi syslog vers le SIEM configuré dans Integrations	Activez-la sur les politiques de blocage entre zones sensibles.
Planification	Plages horaires	Utile pour un accès prestataire limité aux heures ouvrées.
Ordre	Les politiques personnalisées passent avant les intégrées, après les autres personnalisées	Allow spécifiques en haut, Block génériques ensuite.

Les politiques intégrées, marquées d’un cadenas, ne se modifient pas : on les surclasse en plaçant une politique plus haut. Vers Internet, les zones internes ont par défaut « Block Invalid Traffic » puis « Allow All Traffic » ; depuis Internet, seul le trafic de retour est accepté, le reste est bloqué. D’autres politiques intégrées apparaissent selon les fonctions activées (redirection de ports, serveur VPN, IPTV).

04 / Conception

Matrice de politiques pour une PME

La matrice ci-dessous part du plan de segmentation du guide 1. Elle crée trois zones personnalisées (Serveurs, VoIP, IoT) et sort les serveurs de la zone Internal. C’est une proposition ANYSYS à adapter : listez d’abord les flux réels (exports Traffic Flows, documentation des applications) avant de bloquer.

Matrice de politiques proposée pour une PME (recommandation ANYSYS)
Source \ Destination	Serveurs	Internal (utilisateurs)	VoIP	IoT	Gateway	External
Internal (utilisateurs)	Allow ciblé : AD (DNS, Kerberos, LDAP), SMB, HTTPS applicatif	Allow (ou Reject entre VLAN si non requis)	Allow : provisioning et interface web des postes	Allow ciblé : impression (IPP 631, 9100)	Allow (intégré)	Allow (intégré) + filtrage DNS
Serveurs	Allow	Retour seul + flux d’administration initiés par les serveurs si documentés	Block	Block sauf supervision	Allow	Allow vers mises à jour et services cloud identifiés
VoIP	Allow ciblé : IPBX si hébergé en interne	Block	Allow	Block	Allow : DHCP, DNS, NTP	Allow : trunk SIP opérateur
IoT	Allow ciblé : serveur d’impression, GTB	Block	Block	Reject (intra-zone si besoin)	Allow : DHCP, DNS uniquement	Allow restreint (domaines du fabricant)
VPN	Allow ciblé par groupe d’utilisateurs	Block par défaut, sauf support à distance	Block	Block	Allow limité	Selon politique de tunnel complet
Hotspot (invités)	Block (intégré)	Block (intégré)	Block	Block	DHCP, DNS (intégré)	Allow + filtrage, limite de débit

01
Créez les zones personnalisées et déplacez-y les réseaux concernés (un réseau ne peut appartenir qu’à une zone).
02
Écrivez d’abord les Allow ciblés (ports et destinations précis), puis les Block génériques entre zones. C’est l’ordre que recommande Ubiquiti pour bloquer tout sauf un accès précis.
03
Ne bloquez jamais globalement la zone Gateway : DHCP et DNS en dépendent. Restreignez plutôt l’administration (HTTPS, SSH) de la passerelle au réseau de gestion.
04
Remplacez le « Allow All » par défaut de la zone VPN vers Internal par des autorisations par groupe (voir le guide accès distant).
05
Activez la journalisation sur les politiques de blocage entre Utilisateurs, Serveurs et VPN, puis observez une semaine avant de durcir.

05 / Procédure

Migrer depuis les règles legacy

Sur un site encore en règles « legacy » (LAN_IN, WAN_LOCAL…), la migration se lance depuis Security > Traffic & Firewall Rules, bouton Upgrade. Ubiquiti indique qu’elle prend quelques secondes, sans interruption du trafic. Avec UniFi Network 11.0, elle devient automatique pour tous les sites : mieux vaut la faire vous-même, à une date choisie.

Extrait de la table de correspondance documentée par Ubiquiti
Jeu de règles legacy	Zone source	Zones destination
LAN_IN	Internal	Internal, Hotspot, External, VPN
LAN_LOCAL	Internal, VPN	Gateway
GUEST_IN	Hotspot	Internal, Hotspot, External, VPN
WAN_IN	External	Internal, Hotspot, External, VPN
WAN_LOCAL	External	Gateway

01
Lecture seule d’abord : exportez la liste des règles existantes (captures ou export) et notez celles qui ont un effet réel.
02
Faites une sauvegarde de configuration système (Settings > Control Plane > Backups), qui inclut la configuration de l’OS, de l’application et des équipements.
03
Modification : lancez Upgrade en dehors des heures ouvrées.
04
Testez les flux métier (imprimantes, partages, VoIP, VPN). La migration est volontairement conservatrice : elle peut générer des règles redondantes, que vous supprimerez seulement après les tests.
05
Profitez-en pour sortir les réseaux de la zone Internal vers les zones personnalisées de la matrice.

06 / Sécurité

IDS/IPS, filtrage et restrictions

IDS/IPS

L’IDS/IPS s’active dans Settings > CyberSecure > Protection : choix des réseaux, mode Notify (IDS, alerte seule) ou Notify and Block (IPS), puis catégories de détection. Ubiquiti précise que l’inspection augmente la charge CPU et mémoire, que le nombre de réseaux inspectés simultanément est limité et que le débit maximal peut baisser : vérifiez la fiche technique de votre passerelle.

01
Démarrez en mode Notify sur les réseaux Utilisateurs et Serveurs pendant deux semaines, pour mesurer les faux positifs (le multimédia et le jeu en sont des sources fréquentes selon Ubiquiti).
02
Passez en Notify and Block une fois les exceptions traitées (suppression de signature, liste d’exclusion de sources).
03
Testez avec la commande documentée par Ubiquiti, depuis un poste client, la catégorie « Malicious User Agents » étant activée :

Test IDS/IPS documenté par Ubiquiti

curl -A "BlackSun" http://www.example.com

Lors d’une détection, des métadonnées (horodatage, IP, ports, protocoles, signature) transitent temporairement par le cloud Ubiquiti avant suppression : un point à inscrire dans votre registre de traitements RGPD.

CyberSecure (abonnement)

CyberSecure est un abonnement par site qui étend l’IDS/IPS (signatures Proofpoint, plus de 110 000 sur les modèles haut de gamme) et le filtrage (catégories Cloudflare). La capacité dépend du modèle : 110 000+ signatures sur EFG, 70 000+ sur UCG-Ultra, UCG-Max ou UDM-Pro, 25 000+ sur UDR ou UDM ; l’Express (UX) et l’UXG-Lite ne sont pas pris en charge. L’activation exige l’accès distant, et UniFi Network Server n’est pas pris en charge.

Filtrage de contenu, restrictions géographiques, honeypot

Filtrage de contenu (Settings > CyberSecure > Content Filter) : filtrage de niveau DNS, par réseau ou par client, en mode Basic ou Enhanced (Cloudflare, 100+ catégories), avec listes d’autorisation et de blocage. Pensez à la règle de transfert DNS pour le domaine AD.
Country Restriction : bloque ou autorise des pays, en entrée et en sortie. Pour un client précis, Ubiquiti oriente vers une règle avec critère Region.
Honeypot : une adresse leurre par réseau qui signale tout client qui la scanne. Peu coûteux et très parlant pour détecter un poste compromis dans le réseau Utilisateurs.

07 / Pièges

Pièges et cas limites

Supprimer une zone personnalisée supprime toutes ses politiques. Déplacez d’abord les réseaux et exportez la configuration.
Network Isolation et VPN : la note de version 11.0 corrige un défaut où les réseaux isolés n’isolaient pas le trafic vers la zone VPN. Sur 10.6, ne comptez pas sur l’isolation seule : ajoutez une politique explicite VPN vers le réseau concerné.
Bloquer la zone Gateway casse DHCP et DNS. Bloquez des services précis (HTTPS, SSH d’administration), pas la zone entière.
IPv6 : une politique écrite pour IPv4 seulement laisse passer le même flux en IPv6. Choisissez « les deux » par défaut.
Filtrage DNS contourné : un poste qui utilise DNS over HTTPS échappe au filtrage DNS. Complétez par le filtrage applicatif ou une politique vers les résolveurs publics connus.

08 / Contrôle

Vérification

01
Matrice des zones : vérifiez visuellement chaque case. Aucune ne doit rester en « Allow All » entre Utilisateurs, Serveurs, IoT et VPN sans décision écrite.
02
Tests de flux depuis chaque zone, attendus positifs et négatifs, par exemple sous Windows : Test-NetConnection 10.10.10.5 -Port 445 (doit réussir depuis Utilisateurs, échouer depuis IoT).
03
Traffic Flows (Insights > Flows) : nécessite UniFi Network 9.1+, UniFi OS 4.2.8+ et du stockage sur la console. Selon le modèle, seuls les flux bloqués sont journalisés (UDR, UCG Ultra) ou les flux autorisés et bloqués (UDM Pro, UCG Max, EFG).
04
Export documentaire : le script Get-UniFiInventory.ps1 avec -IncludeFirewall exporte en CSV, en lecture seule, les zones et politiques via les points d’accès GET /v1/sites/{siteId}/firewall/zones et /firewall/policies de l’API officielle (voir le guide exploitation).
05
IDS/IPS : le test « BlackSun » apparaît dans les détections.

09 / Références

Sources

→ Faire auditer vos règles de pare-feuContact → Voir le service associéCybersécurité & réseau → Continuer avec le Wi-Fi professionnelGuide 3 de la série

0ANYSYS

IServices

IIIA

IIIRessources

IVÀ propos

Pare-feu par zones UniFi : politiques, migration et IPS pour une PME