Création de règles de firewall sur un routeur Ubiquiti

Contexte et besoins

Dans le cadre de mon alternance, j’interviens sur la passerelle Ubiquiti UniFi qui assure le routage, le NAT et le firewall du réseau interne. La demande est claire : empêcher un poste précis du segment interne de sortir vers Internet tout en lui laissant son accès au LAN, le temps de vérifications sur la machine. Le poste concerné est Firewall-Client1, adressé en 10.0.0.139 dans la zone Internal.

Côté outillage, l’UniFi Network Application expose un moteur de policies par zones qui rend ce genre d’isolation très lisible — à condition de bien comprendre le sens des règles et l’effet de chaque action (Accept, Drop, Reject). C’est ce que je documente ici : la mise en place de la règle, les contrôles côté passerelle et côté poste, et la procédure de levée du blocage.

Rappel théorique sur le firewall UniFi

UniFi expose un firewall stateful basé sur iptables/nftables sous le capot. Depuis la version récente de l’application UniFi Network, l’interface s’organise autour de zones plutôt que de directions brutes.

Le moteur de zones

Une zone regroupe plusieurs réseaux qui partagent le même niveau de confiance. Au lieu d’écrire une règle pour chaque VLAN, on écrit la règle au niveau de la zone et elle s’applique à tous les réseaux qui en font partie.

Sur ma passerelle, six zones sont définies :

Le moteur affiche aussi une matrice source → destination très lisible : chaque case croise une zone source et une zone destination, et indique combien de policies y sont attachées et leur effet global (Allow All, Allow Return, Block All).

Action : Accept, Drop, Reject

Trois actions possibles sur une règle :

• Accept : le paquet passe.
• Drop : le paquet est jeté silencieusement. L’expéditeur ne reçoit rien et finit par tomber en timeout.
• Reject : le paquet est refusé avec un ICMP unreachable (ou TCP RST). L’expéditeur sait immédiatement que la destination est inaccessible.

Pour un poste interne dont je veux rendre le blocage immédiatement visible côté utilisateur, je préfère Reject : la machine remonte tout de suite l’erreur au lieu de boucler en retransmissions. Pour bloquer du scan venu d’Internet, c’est l’inverse : on Drop pour ne pas révéler que l’IP existe.

Ordre des règles

Les règles d’une même zone sont évaluées du haut vers le bas, première correspondance gagne. Une règle de blocage spécifique doit donc être placée avant la règle générique d’autorisation. C’est la cause numéro un de règles « qui ne fonctionnent pas » : la règle est correcte mais arrive trop tard dans la chaîne.

Topologie

Le segment concerné est en 10.0.0.0/24, derrière la passerelle UniFi qui assume routage, NAT et firewall.

Connexion à l’UniFi Network Application

J’ouvre l’interface depuis mon poste d’admin et je m’authentifie avec un compte local. Le tableau de bord donne un aperçu du trafic, des clients et de l’état des liens WAN.

Je passe ensuite dans Settings → Security → Traffic & Firewall Rules → Create Rule.

Création de la règle de blocage

Je remplis le formulaire en m’appuyant sur les zones définies dans le moteur :

Name        : 10.0.0.139 ↔ WAN
Action      : Reject
IP Version  : Both
Protocol    : All
Source Zone : Internal
Source      : 10.0.0.139
Source Port : Any
Dest. Zone  : External
Destination : Any
Dest. Port  : Any

Explications ligne par ligne :

• Name : nommage explicite avec l’IP cible et le sens du flux. Un autre admin comprend la règle d’un coup d’œil sans ouvrir le détail.
• Action: Reject : remontée immédiate côté client (cf. discussion plus haut).
• IP Version: Both : couvre IPv4 et IPv6. Si le poste est joignable en IPv6 et qu’on n’oublie de filtrer que IPv4, il continue à sortir par la deuxième pile.
• Protocol: All : on bloque TCP, UDP, ICMP. Si on autorise par erreur ICMP, le poste peut continuer à pinguer Internet et à faire de la découverte.
• Source Zone: Internal + Source: 10.0.0.139 : on limite la règle à un poste précis du segment interne. Les autres machines de la zone Internal ne sont pas concernées.
• Dest. Zone: External + Destination: Any : la zone External regroupe les WAN (Free WAN1 et Internet 2). Comme la règle est cantonnée au sens Internal → External, le trafic intra-LAN ne passe pas par cette chaîne et reste autorisé.

Une fois enregistrée, la règle apparaît dans la liste avec un identifiant ID 10000 et l’icône d’état activé.

Vérifications

Tous les tests sont faits depuis le poste Firewall-Client1 (10.0.0.139). Le hostname apparaît dans le prompt, ça permet de bien voir d’où on tape les commandes.

Test 1 — Ping vers Internet (doit échouer)

ping 8.8.8.8

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Port Unreachable
From 10.0.0.1 icmp_seq=2 Destination Port Unreachable
From 10.0.0.1 icmp_seq=3 Destination Port Unreachable

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2042ms

La passerelle (10.0.0.1) renvoie immédiatement Destination Port Unreachable : c’est exactement le comportement d’un Reject. Si la règle avait été en Drop, on n’aurait rien reçu et la commande aurait fini en timeout.

Test 2 — Requête HTTPS (doit échouer)

curl www.google.com

curl: (6) Could not resolve host: www.google.com

Le DNS ne répond plus : la résolution sort en UDP/53 vers Internet, qui est bloqué par la même règle. C’est le signe que Protocol: All couvre bien UDP en plus de TCP.

Test 3 — Ping vers la passerelle locale (doit fonctionner)

ping 10.0.0.1

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.517 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.517/0.517/0.517/0.000/0.000 ms

La communication intra-LAN est intacte. La règle ne ferme que le sens Internal → External, donc le ping vers la passerelle (zone Gateway) et le trafic vers d’autres postes du segment passent toujours.

Tests

Trois scénarios pour valider que la règle fait exactement ce qu’on attend, ni plus ni moins.

1. Le poste ne sort pas vers Internet : ping 8.8.8.8 retourne Destination Port Unreachable immédiatement et curl www.google.com échoue dès la résolution DNS.
2. Le LAN reste joignable : ping 10.0.0.1 répond en moins d’une milliseconde. La règle ne touche pas au trafic interne.
3. La levée du blocage rétablit l’accès : je désactive temporairement la règle (toggle Status sur Disabled). Depuis le poste, ping 8.8.8.8 repasse. Je ré-active la règle, le blocage revient. C’est le test de réversibilité.

Problèmes rencontrés et solutions

Compétences du bloc 1 mobilisées

Bilan

L’objectif est atteint : Firewall-Client1 ne sort plus sur Internet, son accès au LAN est intact, et la règle se lève en un clic. Au passage, cette intervention m’a permis de bien intégrer trois choses :

• Les zones simplifient énormément la lecture d’un firewall UniFi. Au lieu de raisonner VLAN par VLAN, on regarde d’abord la matrice des zones, puis on descend au détail.
• Reject vs Drop est un vrai choix : Reject côté LAN parce qu’on veut une remontée rapide, Drop côté WAN pour ne pas répondre aux scans. La RFC 7288 le formalise bien.
• L’ordre des règles fait tout : une règle en bas de chaîne ne sert à rien si une règle d’autorisation matche avant elle.

Pour aller plus loin, l’idée serait d’utiliser un Address Group plutôt qu’une IP en dur : si un deuxième poste doit être bloqué, on l’ajoute au groupe sans toucher à la règle. C’est la pratique recommandée par la doc UniFi pour garder un firewall lisible sur la durée.

Sources

• Ubiquiti Help — UniFi Gateway Firewall , Ubiquiti.
• Ubiquiti Help — Traffic Policy Management in UniFi , Ubiquiti.
• RFC 7288 — Reflections on Host Firewalls , IETF, 2014.
• ANSSI — Recommandations relatives à l’administration sécurisée des systèmes d’information , ANSSI.
• Netfilter Documentation — iptables-extensions(8) , Netfilter project.