Règles de pare-feu pour les réseaux WiFi invités

# Script de Podcast : Maîtriser les règles de pare-feu pour le WiFi invité **Animateur :** Un architecte de solutions senior de chez Purple. **(Musique d'introduction - Claire, professionnelle, s'estompe après 5 secondes)** **Animateur :** Bonjour et bienvenue dans ce briefing technique de Purple. Je suis architecte de solutions senior ici chez Purple, et aujourd'hui nous abordons un sujet absolument fondamental pour le déploiement d'un WiFi invité sécurisé et performant : les règles de pare-feu. Ce briefing s'adresse aux responsables informatiques, aux architectes réseau et aux directeurs des opérations qui doivent concilier un accès invité fluide avec une sécurité réseau d'entreprise en béton armé. Se tromper sur ce point est l'un des plus grands risques pour tout établissement, entraînant des failles de sécurité et des goulots d'étranglement de performance. Dans ce briefing, nous vous fournirons des conseils directs et exploitables pour vous aider à configurer correctement vos pare-feux, spécifiquement pour un déploiement Purple. **(Musique de transition - courte, subtile)** **Animateur :** Entrons directement dans les détails techniques. Le principe unique le plus important que vous devez respecter est l'**isolation**. Votre réseau invité doit être traité comme un environnement totalement non fiable. Cela signifie qu'il faut créer un réseau local virtuel dédié, ou VLAN, pour votre trafic invité, complètement segmenté de votre réseau local d'entreprise (LAN) où résident vos systèmes d'exploitation critiques. Il ne doit y avoir absolument aucun mouvement latéral possible du VLAN invité vers le VLAN d'entreprise. Votre pare-feu est le gardien qui applique cette séparation. Alors, quel trafic devez-vous explicitement autoriser à sortir de ce réseau invité isolé ? Nous fonctionnons selon le principe du « refus par défaut ». Rien ne passe à moins que vous ne créiez une règle d'autorisation spécifique. Voici les éléments essentiels. Tout d'abord, le **Port 53 pour le DNS**. Vos invités doivent pouvoir résoudre des noms de domaine comme « purple.ai » en adresses IP. Vous devez configurer votre réseau invité pour qu'il utilise des résolveurs DNS publics et fiables, comme le 8.8.8.8 de Google ou le 1.1.1.1 de Cloudflare. Cela empêche les utilisateurs d'utiliser potentiellement des serveurs DNS personnalisés pour contourner vos politiques ou d'effectuer du tunneling DNS. Ensuite, et c'est le plus évident, les **Ports 80 et 443 pour le HTTP et le HTTPS**. C'est l'épine dorsale de toute la navigation web. Lorsqu'un invité se connecte pour la première fois, sa requête web initiale est interceptée par le contrôleur réseau et redirigée vers votre Captive Portal Purple. Sans accès à ces ports, l'ensemble du parcours de l'invité échoue avant même d'avoir commencé. Pour un déploiement Purple réussi, vous devez également vous assurer que le réseau invité peut communiquer avec les services cloud de Purple et potentiellement avec votre contrôleur WiFi sur site. Cela implique généralement d'autoriser le trafic sortant sur les **Ports 8080 et 8443** pour la gestion du contrôleur et les statistiques. Enfin, il existe quelques services réseau fondamentaux. Les **Ports 67 et 68 pour le DHCP**, qui permettent d'attribuer automatiquement une adresse IP aux appareils des invités. Et le **Port 123 pour le NTP**, ou Network Time Protocol, qui est crucial pour maintenir l'exactitude des horodatages des appareils et des journaux d'événements — ce qui est inestimable lors de toute enquête de sécurité. Qu'en est-il des règles entrantes ? Pour le réseau invité, c'est simple : vous n'en autorisez aucune. Il n'y a aucune raison légitime pour qu'un appareil sur l'internet public initie une connexion *vers* votre réseau invité. La seule exception est si vous hébergez votre contrôleur WiFi ou votre Captive Portal sur site. Dans ce scénario spécifique, vous créeriez une règle de redirection de port (Port Forwarding) hautement restreinte, également appelée règle NAT de destination, pour guider le trafic externe vers l'adresse IP interne spécifique du portail. Pour les configurations plus avancées utilisant une authentification de classe entreprise, vous pourriez également avoir besoin de règles entrantes pour **RADIUS sur les ports UDP 1812 et 1813**. N'oubliez pas que la règle par défaut tout en bas de votre politique de pare-feu doit être : **Tout refuser**. Si le trafic ne correspond pas à l'une de ces règles d'autorisation spécifiques, il est rejeté. **(Musique de transition - courte, subtile)** **Hôte :** Parlons maintenant de la mise en œuvre et des pièges courants. Ces recommandations sont indépendantes des fournisseurs. Tout d'abord, utilisez toujours un pare-feu à inspection d'état (stateful). Un pare-feu stateful suit l'état des connexions et autorise automatiquement le trafic de retour pour les sessions établies, ce qui simplifie votre ensemble de règles. Deuxièmement, activez l'« isolation des clients » sur vos points d'accès sans fil. Il s'agit d'une fonctionnalité essentielle qui empêche les appareils connectés au même réseau WiFi de communiquer entre eux. Et troisièmement, planifiez des audits réguliers de vos règles de pare-feu. Les règles inutilisées ou trop permissives constituent une dette de sécurité que vous devez rembourser. Nous constatons constamment des erreurs courantes. Le péché originel est la règle « autoriser tout vers tout », souvent mise en place temporairement pour des tests puis oubliée. C'est une porte grande ouverte pour les attaquants. Une autre erreur consiste à oublier l'IPv6 ; assurez-vous que vos règles de pare-feu s'appliquent à la fois au trafic IPv4 et IPv6. Enfin, ne vous contentez pas de configurer vos règles et de passer à autre chose. Les journaux de votre pare-feu sont votre système d'alerte précoce. Surveillez-les pour détecter des schémas inhabituels ou des connexions refusées répétées. Laissez-moi vous donner un exemple concret et rapide. Nous avons travaillé avec une grande chaîne hôtelière qui recevait de fréquentes plaintes de clients concernant la lenteur du WiFi. Leurs règles de pare-feu étaient trop permissives, ce qui permettait à des tempêtes de diffusion provenant d'appareils invités mal configurés d'inonder le réseau. En mettant en œuvre une isolation stricte des VLAN et les règles sortantes essentielles que nous venons de présenter, ils ont non seulement sécurisé leur réseau d'entreprise, mais ont également augmenté le débit du WiFi des invités de plus de 30 % et réduit considérablement les appels d'assistance liés au réseau. **(Musique de transition - courte, subtile)** **Hôte :** Passons à une séance de questions-réponses rapide. On me pose ces questions tout le temps. *Première question : Dois-je bloquer les VPN sur le réseau invité ?* C'est une décision de politique générale. Les bloquer vous donne plus de visibilité sur le trafic, mais cela peut frustrer les voyageurs d'affaires qui ont besoin d'un VPN pour travailler. Une approche équilibrée consiste à l'autoriser, tout en veillant à ce que vos autres règles soient strictes. *Deuxièmement : Qu'en est-il des appareils IoT comme les téléviseurs intelligents ou les haut-parleurs sur le réseau invités ?* Traitez-les comme hautement non fiables. Idéalement, placez-les sur un troisième VLAN encore plus restreint, avec des règles de pare-feu qui n'autorisent la communication qu'avec leurs serveurs de gestion cloud spécifiques et rien d'autre. *Et troisièmement : Quel est le rapport avec la conformité PCI DSS pour nos points de vente ?* La norme PCI DSS impose la séparation complète et vérifiable de l'environnement des données des titulaires de carte. Un réseau invités correctement configuré et isolé, protégé par un pare-feu du VLAN utilisé par vos terminaux de paiement, est un contrôle fondamental et non négociable pour la conformité. **(Musique de transition - courte, subtile)** **Animateur :** Donc, pour résumer. La sécurité de l'ensemble de votre réseau d'entreprise dépend de la manière dont vous configurez la limite autour de votre WiFi invités. Les principes fondamentaux sont les suivants : **Isolez** votre trafic invités sur son propre VLAN. **Appliquez** une politique de « refus par défaut », en n'autorisant que les ports essentiels pour la navigation web, le DNS et les services Purple. **Empêchez** tout trafic entrant et tout mouvement latéral. Et enfin, **Auditez** vos règles et surveillez vos journaux en continu. En suivant ces conseils, vous pouvez offrir un service précieux à vos visiteurs tout en protégeant vos actifs commerciaux critiques, en garantissant la conformité et en offrant une expérience utilisateur supérieure. Pour obtenir un guide de référence détaillé des ports et des schémas réseau, veuillez consulter le guide de référence technique sur notre site web qui accompagne ce briefing. **(Musique de fin - Claire, professionnelle, monte en fondu)** **Animateur :** Merci d'avoir suivi ce briefing technique Purple. À la prochaine fois. **(La musique s'estompe)**