Configurer correctement Sophos Firewall après l'assistant de configuration

Après l’assistant de configuration, un Sophos Firewall est accessible, enregistré et fondamentalement prêt à l’emploi. Cependant, il n’est pas encore sécurisé. L’assistant effectue le démarrage, mais pas l’architecture productive.

Cet article regroupe les points à vérifier après la configuration initiale : accès Internet, enregistrement, statut des licences, firmware, sauvegarde, zones, accès au dispositif, DNS, DHCP, règles de pare-feu, NAT, journalisation et premières mesures de renforcement. Il est conçu comme une liste de contrôle pratique pour les nouveaux matériels XGS, les pare-feux virtuels et les petites migrations.

En cas de migration de XG à XGS, de matériel à virtuel ou de restauration sur un appareil de remplacement, il convient également de consulter Créer ou restaurer une sauvegarde Sophos Firewall et Sophos XG vs. XGS : différences, EOL et migration.

Chemin rapide après la première connexion

Lorsque le pare-feu sort de l’assistant, chaque détail n’est pas immédiatement urgent. Dans les 30 premières minutes, l’objectif principal est de ne pas perdre l’accès, de sécuriser l’état et de reconnaître les principaux risques opérationnels.

Cet ordre est pertinent pour la plupart des nouvelles installations :

1. Sécuriser l’accès administrateur : Documenter le mot de passe, la clé maître de stockage sécurisé et un deuxième accès administrateur ou de secours.
2. Vérifier la licence et l’enregistrement : Sous Administration > Licensing, vérifier si le modèle, le numéro de série, la licence de base et les abonnements sont corrects.
3. Créer une sauvegarde : Télécharger une sauvegarde manuelle avant d’apporter d’autres modifications et la stocker à l’extérieur.
4. Vérifier le firmware et les modèles : Vérifier la version du firmware, les correctifs et les mises à jour des modèles, mais n’installer les mises à jour qu’avec une fenêtre de maintenance et un plan de retour en arrière.
5. Limiter l’accès au dispositif : Ne pas laisser WebAdmin et SSH largement accessibles depuis les zones client, invité, IoT ou WAN.
6. Vérifier la plausibilité des zones et interfaces : Vérifier les zones WAN, LAN, VLAN, ponts, réseau de gestion et futures zones de sécurité par rapport au plan réseau.
7. Évaluer les règles par défaut : Ne pas adopter les premières règles de pare-feu et NAT comme un design de sécurité final.
8. Activer la journalisation : Activer Log firewall traffic pour les règles importantes afin que les tests ultérieurs soient traçables dans le Log Viewer.
9. Planifier le test d’acceptation : ne libérer le trafic productif qu’après un court plan de test, pas directement après l’assistant.

Ce n’est que lorsque ces points sont clairs que le trafic productif, l’accès à distance, WAF, SD-WAN, RED ou l’inspection TLS devraient être mis en place. Sinon, le dépannage ultérieur devient inutilement difficile, car il est incertain si un problème provient de la configuration de base, d’une fonction de sécurité ou d’une application.

Parcours de setup selon la situation

Après l’assistant, le travail se divise rapidement en plusieurs domaines. Pour les nouveaux pare-feux, cet ordre est pertinent :

• Connexion à Central : si la firewall doit être connectée à Sophos Central ou si les limites de Central doivent être comprises, voir Connecter Sophos Firewall à Sophos Central.
• Statut de licence : pour Base License, Support et Subscriptions, voir Comprendre la Base License de Sophos Firewall.
• Backup et restore : avant le premier changement, Créer ou restaurer une sauvegarde Sophos Firewall devrait être préparé.
• Accès de management : WebAdmin, SSH, User Portal ou VPN Portal sont durcis avec Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.
• Design réseau : pour les zones, interfaces, VLAN ou bridges, Configurer les zones et interfaces de Sophos Firewall est le meilleur point d’entrée.
• Premières règles : pour les bases des règles firewall et NAT, voir Comprendre et configurer correctement les règles Sophos Firewall.
• DNS et DHCP : la résolution de noms interne est plus propre avec Configurer les DNS request routes sur Sophos Firewall.
• Reporting : pour les logs, rapports et conservation prolongée, voir Activer Central Firewall Reporting.
• Health Check : les findings de sécurité après SFOS 22 peuvent être priorisés avec Utiliser correctement Sophos Firewall Health Check.
• Planification d’upgrade : pour un firmware update ou un upgrade SFOS 22, voir Vérifier Sophos Firewall avant la mise à niveau SFOS 22.

Cette séparation est importante car un assistant réussi ne signifie pas une architecture de sécurité complète. Avant le trafic productif, l’accès à la gestion, la sauvegarde, la licence, les zones, les règles, la journalisation et les fonctions de protection doivent être consciemment vérifiés.

Préparer avant la configuration

Avant de lancer l’assistant, l’accès, la connexion WAN, le réseau de management et le contexte de licence doivent être clairs. Cela évite d’improviser pendant la configuration et de devoir corriger plus tard des hypothèses de base floues.

Prérequis pour la configuration

Avant la configuration, il doit être clair comment le pare-feu sera intégré au réseau. De nombreux problèmes ultérieurs ne proviennent pas de l’assistant lui-même, mais parce que WAN, LAN, DNS, accès à la gestion ou données de licence sont improvisés.

Préparer avant de commencer :

• Modèle de pare-feu, numéro de série et emplacement prévu.
• Données d’accès WAN ou informations du fournisseur, par exemple DHCP, IP statique, PPPoE, VLAN ou routeur en amont.
• Réseau cible interne pour le premier accès LAN ou gestion.
• Serveurs DNS fonctionnant pendant la configuration.
• Accès Sophos Central ou une personne pouvant générer un OTP pour l’enregistrement.
• Mot de passe administrateur prévu et emplacement dans le gestionnaire de mots de passe.
• Décision de configurer le pare-feu directement ou de le restaurer à partir d’une sauvegarde.

Le pare-feu a besoin d’une connexion Internet fonctionnelle pour l’enregistrement, la vérification des licences, les mises à jour des modèles et la connexion à Central. Si un appareil en amont filtre le trafic sortant, l’accès HTTPS nécessaire doit au moins fonctionner. Pour des configurations de fournisseur plus complexes, l’accès WAN doit être planifié consciemment plutôt que deviné pendant l’assistant.

Connexions et configuration réseau

Selon le modèle, les noms de port et l’attribution par défaut diffèrent. Sur de nombreux appareils matériels, le premier accès LAN est possible via l’adresse par défaut, tandis que les modèles plus grands peuvent également avoir un port de gestion dédié.

Accès typiques initiaux :

• Port LAN avec https://172.16.16.16:4444: Configuration initiale via le réseau de configuration local
• Port MGMT avec https://10.0.1.1:4444: Accès de gestion dédié sur les modèles avec port MGMT
• Console série ou accès local: Scénarios d’urgence ou de réimage

Le client pour la configuration initiale doit être connecté directement ou via un réseau de configuration contrôlé. Les anciens serveurs DHCP, les VLAN incorrects ou un port de commutateur productif avec une configuration de port inattendue peuvent rendre la configuration initiale inutilement difficile.

Accès à l’interface Web

Pour configurer, on accède à la WebAdmin Console via un navigateur Web. Selon l’interface, l’une de ces adresses est utilisée :

• Port LAN : https://172.16.16.16:4444
• Port de gestion : https://10.0.1.1:4444

Lors du premier accès, le pare-feu utilise un certificat signé localement. L’avertissement du navigateur est normal à ce moment, mais ne doit pas être ignoré plus tard. Pour l’accès WebAdmin productif, un certificat approprié doit être planifié, surtout si plusieurs administrateurs, la gestion centrale ou un FQDN de gestion sont utilisés.

Tant que l’utilisateur par défaut admin avec le mot de passe par défaut est encore utilisé, des restrictions supplémentaires s’appliquent. SSH depuis la zone WAN n’est pas rejeté normalement; le pare-feu ferme la connexion silencieusement. WebAdmin depuis la zone WAN affiche un message Forbidden. SCP avec les identifiants par défaut n’est pas utilisable dans les zones LAN et WAN. Cet état doit être compris comme une phase d’installation, pas comme un modèle d’exploitation.

Exécuter l’assistant de configuration

L’assistant de configuration configure le pare-feu à un niveau de base. À cette étape, l’objectif n’est pas encore le design de sécurité final, mais de mettre le pare-feu en ligne, enregistré et administrable de manière contrôlée.

Configuration initiale avec l’assistant de configuration

L’assistant de configuration recueille les données de base et met le pare-feu dans un état prêt à démarrer. Ces points doivent être définis consciemment :

1. Accepter les conditions d’utilisation de Sophos End User.
2. Démarrer la configuration.
3. Définir le mot de passe administrateur et le stocker en toute sécurité.
4. Définir le nom du pare-feu et le fuseau horaire.
5. Fournir le numéro de série ou les données de licence existantes.
6. Ne laisser installer automatiquement une mise à jour du firmware pendant la configuration que si l’accès Internet et la fenêtre de maintenance le permettent.
7. Créer une clé maître de stockage sécurisé et la documenter dans le gestionnaire de mots de passe.
8. Effectuer l’enregistrement et la vérification des licences ou les reporter consciemment.

La clé maître de stockage sécurisé est importante pour les données protégées et les scénarios de restauration. Elle ne doit pas être stockée dans un fichier texte local sur l’ordinateur portable de l’administrateur, mais dans une procédure de mot de passe ou de récupération contrôlée. Si elle est perdue, elle peut être techniquement réinitialisée, mais les sauvegardes ou données protégées existantes ne peuvent pas être automatiquement déchiffrées.

Vérification de la connexion Internet et du DNS

L’assistant vérifie si le pare-feu atteint Internet. Si la vérification échoue, il ne faut pas simplement entrer “n’importe quel DNS”. Une délimitation propre est préférable :

• L’interface WAN a-t-elle une adresse IP valide ?
• La passerelle par défaut est-elle correcte ?
• PPPoE, VLAN ou routage statique sont-ils nécessaires ?
• Le pare-feu peut-il résoudre le DNS ?
• Le trafic HTTPS sortant est-il bloqué par un appareil en amont ?
• La date, l’heure et le fuseau horaire sont-ils corrects ?

Pour les environnements productifs, le DNS ne doit pas être mis au hasard sur des résolveurs publics si une résolution de noms interne est nécessaire. Après la configuration initiale, les domaines internes doivent être correctement redirigés vers les serveurs DNS internes via les routes de requêtes DNS sur Sophos Firewall.

Enregistrement de Sophos Firewall

L’enregistrement connecte le pare-feu au contexte de licence et de Central de Sophos. Il peut être effectué directement dans l’assistant ou plus tard en fonctionnement. Pour les pare-feux productifs, cette étape ne doit pas rester inutilement ouverte, car le statut des licences, le support, les abonnements et les fonctions Central en dépendent.

Sophos prend en charge plusieurs méthodes d’enregistrement. Dans les environnements partenaires ou clients, l’OTP est particulièrement pratique, car chaque administrateur n’a pas besoin de connaître les identifiants de super-administrateur de Sophos Central.

Procédure typique :

1. Avoir le numéro de série du pare-feu à portée de main.
2. Réclamer le pare-feu dans Sophos Central ou faire générer un OTP par un administrateur Sophos Central.
3. Entrer l’OTP dans le pare-feu.
4. Terminer l’enregistrement.
5. Ensuite, sous Administration > Licensing, vérifier si le pare-feu est correctement enregistré.

Important : La gestion de pare-feu Sophos Central nécessite un abonnement payant ou un contexte de support/bundle approprié. La simple licence de base du pare-feu ne suffit pas pour toutes les fonctions de gestion Central. De plus, la firewall doit pouvoir accéder à Internet en IPv4 pour Central Management.

Activation des licences

Après l’enregistrement, le pare-feu vérifie ses licences auprès du serveur de licences Sophos. Si le pare-feu a accès à Internet, les informations de licence sont synchronisées régulièrement. De plus, on peut lancer manuellement la synchronisation dans la WebAdmin Console.

Sous Administration > Licensing, il faut vérifier :

• Le bon modèle avec le numéro de série correct est-il enregistré ?
• La licence de base est-elle active ?
• Le support, Xstream Protection, Standard Protection ou les abonnements individuels sont-ils correctement visibles ?
• Les dates d’expiration sont-elles plausibles ?
• Une nouvelle clé de licence a-t-elle été réellement appliquée ou seulement enregistrée dans le portail ?
• Le pare-feu montre-t-il après Synchronize le même état que Sophos Central ?

Sans licence appropriée, de nombreuses fonctions de protection ne fonctionnent pas ou seulement de manière limitée. Cela concerne, selon la fonction, par exemple IPS, Web Protection, Zero-Day Protection, DNS Protection, Central Orchestration, Active Threat Response ou les services de support. Les bases du support et des modules sont expliquées dans Comprendre la licence de base de Sophos Firewall OS et Quels sont les bundles Sophos Firewall disponibles ?.

Connexion à la plateforme Sophos Central

Pour le fonctionnement local d’un seul Sophos Firewall, Sophos Central n’est pas strictement nécessaire. Le pare-feu peut être entièrement géré via WebAdmin. Cependant, Sophos Central offre des avantages si ces fonctions sont consciemment utilisées :

• vue d’ensemble centrale d’un ou plusieurs pare-feux,
• gestion de pare-feu Central sans publication directe de WebAdmin depuis Internet,
• sauvegardes Central,
• rapports de pare-feu Central,
• selon la licence, conservation plus longue des journaux et fonctions de rapport supplémentaires,
• Security Heartbeat et Synchronized Application Control dans les environnements Sophos Endpoint,
• intégration dans d’autres processus Sophos Central.

Il est important d’avoir les bonnes attentes : Sophos Central ne remplace pas une documentation opérationnelle locale et un processus administratif propre. Ceux qui activent la gestion Central doivent définir consciemment les rôles, MFA, accès, stockage des sauvegardes et conservation des rapports.

Plus d’informations sont disponibles dans l’article Connecter Sophos Firewall à Sophos Central : avantages et limites.

Finalisation de la configuration

Après la finalisation de la configuration, le pare-feu redémarre ou redirige vers l’écran de connexion. Si une mise à jour du firmware est effectuée pendant l’assistant et que la connexion est interrompue, il ne faut pas conclure immédiatement à un défaut : la firewall peut redémarrer et revenir avec le firmware livré. Ensuite, il ne faut pas commencer directement avec le trafic productif, mais d’abord contrôler l’état de base.

Vérifier directement après la première connexion :

• Date, heure et fuseau horaire.
• Version du firmware et mises à jour des modèles.
• Statut des licences sous Administration > Licensing.
• Statut WAN et accès Internet.
• Mot de passe administrateur et clé maître de stockage sécurisé dans le gestionnaire de mots de passe.
• Configuration de sauvegarde.
• Accessibilité de la WebAdmin Console uniquement depuis les réseaux souhaités.
• Règles par défaut, NAT et DNS.
• Premiers journaux dans le Log viewer.

Rendre le pare-feu prêt pour la production après l’assistant de configuration

Après l’assistant, le vrai travail commence : le pare-feu doit être renforcé, intégré à l’architecture réseau, documenté et préparé pour le dépannage. Ces étapes influencent davantage l’exploitation future que l’assistant lui-même.

Pourquoi l’assistant de configuration ne suffit pas

L’assistant crée une première configuration de base, mais pas une architecture de sécurité complète. Les interfaces, zones, accès au dispositif, DNS, DHCP, règles de pare-feu, NAT, journaux, sauvegardes et profils de protection doivent être consciemment vérifiés.

Un Sophos Firewall n’est pas un routeur grand public où l’on a terminé après l’assistant. Bien planifié, il peut sécuriser un réseau très efficacement, mais seulement si l’architecture est correcte : les zones doivent correspondre à la logique de sécurité, les accès de gestion doivent être restreints, les règles doivent être créées consciemment et documentées, et les fonctions de protection comme le filtrage Web, IPS, Application Control ou l’inspection TLS doivent être activées et testées de manière ciblée. Un pare-feu mal configuré peut donner un faux sentiment de sécurité.

Il vaut la peine de jeter un coup d’œil au Control Center en premier. On y voit l’état du système, le trafic, les informations sur les utilisateurs et les appareils, les règles de pare-feu actives, les rapports et les notifications comme les nouvelles versions de firmware ou les résultats du Health Check. Les avertissements et notifications dans cette zone ne doivent pas être simplement ignorés, mais utilisés comme une liste de contrôle pratique pour le suivi.

Vérification du firmware, des licences et des sauvegardes

Sous Backup & firmware, on vérifie si le firmware actif est à jour. Les mises à jour du firmware sont importantes pour la sécurité, car elles apportent des corrections de bugs, des améliorations de stabilité et des correctifs de sécurité. Les mises à jour ne doivent pas être reportées indéfiniment, mais ne doivent pas non plus être installées sans préparation.

Sophos Firewall fonctionne avec deux emplacements de firmware. Cela permet de redémarrer avec un firmware précédent en cas de problème. Cependant, avant chaque changement majeur, une sauvegarde manuelle doit être créée. Pour les pare-feux productifs, on planifie une fenêtre de maintenance, on vérifie les notes de version, le statut HA, l’espace libre, les dépendances VPN et l’accessibilité externe.

Sous Backup & firmware, une sauvegarde régulière doit également être configurée. Pour les sauvegardes chiffrées, un mot de passe de sauvegarde est nécessaire. Pour la restauration de données sensibles, la clé maître de stockage sécurisé est également pertinente. Cette clé doit absolument être stockée dans un gestionnaire de mots de passe. Si elle est perdue, elle peut être réinitialisée via la console, mais les sauvegardes protégées existantes ne peuvent plus être restaurées normalement.

Ensuite, on vérifie sous Administration > Licensing si l’enregistrement, la licence de base et les abonnements souscrits sont correctement affichés. Pour le sujet des mises à jour, les articles Mise à jour du firmware Sophos Firewall : préparation et meilleures pratiques et Mise à jour du firmware sur Sophos Firewall sont utiles. Les sauvegardes sont expliquées plus en détail dans l’article Créer ou restaurer une sauvegarde Sophos Firewall.

Planification propre des zones et interfaces

L’assistant peut regrouper plusieurs ports LAN en un pont sur les appareils matériels. C’est pratique pour un démarrage rapide, mais ce n’est pas toujours la meilleure architecture cible. Sous Network > Interfaces, il faut vérifier quels ports, VLAN, ponts ou LAG sont réellement nécessaires.

Chaque interface est assignée à une zone spécifique. Cette assignation détermine plus tard comment les règles de pare-feu, l’accès au dispositif et les profils de protection s’appliquent. Les zones productives typiques sont par exemple LAN, Server, DMZ, Guest, VoIP, Management ou VPN. Chaque VLAN n’a pas nécessairement besoin de sa propre zone, mais chaque zone doit avoir une signification de sécurité claire.

Plus d’informations sont disponibles dans l’article Planifier et configurer les zones et interfaces de Sophos Firewall.

Sécuriser l’accès au dispositif

Une erreur courante après la configuration initiale est un accès de gestion trop large. Les accès aux services locaux du pare-feu, tels que WebAdmin, SSH, User Portal, VPN Portal, DNS ou Ping, ne sont pas contrôlés par des règles de pare-feu normales. Administration > Device access est responsable de cela.

Pour les systèmes productifs, HTTPS et SSH ne doivent pas être largement autorisés depuis des zones non sécurisées. Si un accès externe est nécessaire, il faut utiliser une Local service ACL exception rule et limiter l’accès à des adresses IP fixes ou des réseaux de gestion définis. Alternativement, la gestion de pare-feu Sophos Central est souvent la solution la plus propre.

⚠️ WebAdmin, SSH, User Portal et VPN Portal ne doivent jamais être accessibles simplement parce que la base de règles firewall semble propre. Ces services dépendent de Device Access et des Local Service ACLs. Après chaque changement, il faut tester activement depuis quelles zones et quels réseaux source l’accès est réellement possible.

Plus d’informations sont disponibles dans l’article Sécuriser l’accès à Sophos Firewall : configurer correctement l’accès au dispositif.

Définir les comptes administrateur, MFA et secours

Après la première connexion, il ne faut pas travailler en permanence avec un accès administrateur partagé. Pour le quotidien, des administrateurs propres, des rôles clairs et un accès d’urgence documenté sont préférables. Cela permet de savoir plus tard qui a effectué une modification, et un mot de passe compromis ne donne pas automatiquement un accès complet au pare-feu.

Pour les nouveaux pare-feux, cet ordre est pertinent :

1. Tester au moins un deuxième accès administratif avant d’activer largement le MFA.
2. Traiter l’utilisateur par défaut local admin comme un compte de secours et ne pas l’utiliser comme utilisateur quotidien.
3. Activer le MFA pour WebAdmin, VPN Portal et Remote Access de manière planifiée.
4. Documenter les rôles et responsabilités, surtout si la gestion de pare-feu Sophos Central est utilisée.
5. Définir la réinitialisation des jetons, le stockage des mots de passe et l’accès en dehors des heures de bureau.

Le MFA réduit le risque de vol de données d’accès, mais ne remplace pas une restriction d’accès. C’est pourquoi MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access et l’accès au dispositif vont de pair. Si plusieurs personnes travaillent via Sophos Central, les rôles administratifs de Sophos Central doivent également être vérifiés.

Vérifier DNS, DHCP et résolution de noms interne

Sous Network > DNS, on définit comment le pare-feu reçoit les serveurs DNS : par DHCP, via les informations PPPoE du fournisseur ou statiquement. Pour les domaines internes, il faut utiliser DNS request routes pour que les requêtes pour les zones internes soient dirigées vers le bon serveur DNS interne.

Pour les nouvelles installations, le DNS doit être testé avec de vrais noms internes et externes. Un test uniquement avec google.com ne suffit pas si Active Directory, serveurs de fichiers, imprimantes, systèmes de gestion ou applications internes sont utilisés plus tard. Il est surtout important de savoir si les clients reçoivent les bons serveurs DNS et si le pare-feu ne redirige pas accidentellement les domaines internes vers des résolveurs publics.

Test pratique du DNS :

• Le pare-feu résout les noms externes: L’enregistrement, la vérification des licences, les mises à jour et la connexion à Central fonctionnent
• Le client résout les noms externes: DHCP, serveur DNS et règle de pare-feu correspondent
• Le client résout les noms internes: Le DNS interne ou la route de requêtes DNS fonctionne
• Le client VPN ou VLAN résout les noms internes: Le serveur DNS, le domaine de recherche et la règle de zone correspondent également en dehors du premier LAN

Le DHCP est configuré sous Network > DHCP par interface. Il est important d’adapter proprement les plages DHCP à la structure des interfaces et VLAN. Le serveur DHCP ne doit pas attribuer d’adresses déjà utilisées statiquement pour les serveurs, commutateurs, points d’accès, imprimantes ou appareils de gestion. De plus, la passerelle, le serveur DNS, le nom de domaine et la durée du bail doivent être définis consciemment pour que les clients ne reçoivent pas seulement une adresse IP quelconque après la première connexion, mais travaillent réellement dans le réseau prévu.

Si le DHCP doit être relayé via des connexions VPN, le pare-feu peut également fonctionner comme un relais DHCP. Pour les options spéciales DHCP, voir Configurer les options DHCP de Sophos Firewall.

Vérifier les premières règles de pare-feu et NAT

La règle par défaut de sortie créée par l’assistant ne doit pas être adoptée aveuglément. Sous Rules and policies > Firewall rules, il faut vérifier quelles zones sources sont autorisées, quels objectifs doivent être atteints et quelles fonctionnalités de sécurité sont actives. Les règles sont traitées de haut en bas ; la première règle correspondante gagne.

Pour commencer, il doit exister au moins une règle client-vers-Internet nommée consciemment. Cette règle ne doit pas simplement autoriser Any vers Any, mais montrer clairement la zone source, le réseau source, les objectifs, les services, la journalisation et les fonctionnalités de sécurité. Si la règle est étendue plus tard, il doit rester traçable si elle est destinée aux clients normaux, serveurs, invités, IoT ou appareils de gestion.

Une première vérification des règles peut ressembler à ceci :

1. Connecter un client de test dans la zone prévue.
2. Vérifier l’adresse IP, la passerelle et le DNS sur le client.
3. Générer un appel HTTPS externe.
4. Rechercher dans le Log viewer l’IP source, la cible, le service et l’ID de règle.
5. Vérifier si la règle de pare-feu et la règle NAT attendues ont été atteintes.
6. Effectuer un test intentionnellement non autorisé, par exemple depuis une zone d’invité ou de gestion.
7. Documenter quelle règle reste productive et quelle règle de l’assistant ou de test est supprimée.

Pour le NAT : le NAT n’autorise pas le trafic de lui-même. Il faut toujours une règle de pare-feu appropriée. Pour les clients normaux vers Internet, une règle de NAT source avec MASQ est généralement pertinente. Pour les serveurs publiés, il faut une règle DNAT plus une règle de pare-feu appropriée, une journalisation et un test externe depuis l’extérieur de son propre LAN. Pour les nouvelles configurations, les règles NAT autonomes sont généralement plus claires que les règles NAT liées. Les bases sont expliquées dans Comprendre et configurer correctement les règles de Sophos Firewall et Comprendre le NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT. Si un serveur interne doit être publié, l’article Publier un serveur par DNAT sur Sophos Firewall est approprié.

Activer consciemment les fonctions de protection

Une règle de pare-feu n’est pas automatiquement une règle de protection complète. Selon la licence et l’objectif, IPS, Web Protection, Application Control, analyse des logiciels malveillants, inspection TLS, protection contre les menaces zero-day ou Threat Feeds doivent être activés, testés et documentés consciemment.

Ordre pratique :

1. Créer des zones et des règles propres.
2. Activer la journalisation pour les règles importantes.
3. Activer IPS et Web Protection là où cela est pertinent.
4. Ajouter Application Control pour les applications risquées ou indésirables.
5. Introduire l’inspection TLS de manière planifiée, avec un groupe de test, une distribution CA et des exceptions.
6. Activer Threat Feeds, NDR ou Active Threat Response uniquement lorsque la surveillance et le processus de faux positifs sont clarifiés.

Pour le contexte plus large du renforcement, voir Meilleures pratiques Sophos Firewall : réseau, règles et sécurité. Pour la protection contre les menaces zero-day, voir Comprendre et exploiter la protection contre les menaces zero-day de Sophos Firewall, pour l’inspection TLS Introduire l’inspection TLS de Sophos Firewall.

Préparer la journalisation et le dépannage

Dans les règles de pare-feu importantes, Log firewall traffic doit être activé, sinon il manque souvent exactement les informations nécessaires pour le dépannage. Beaucoup ne le réalisent pas : si une règle de pare-feu ne journalise pas, le trafic correspondant n’apparaît pas de manière significative dans le Log Viewer. On peut alors voir peut-être d’autres événements système, mais pas la décision de règle concrète que l’on cherche réellement.

Sous System services > Log settings, on peut définir quels types de journaux sont envoyés localement, à un serveur Syslog ou à Sophos Central. Le pare-feu possède des fichiers journaux locaux et une base de données de rapports interne, mais ceux-ci ne sont pas destinés à être un archivage à long terme pour des semaines, des mois ou des années. Si les journaux doivent être conservés de manière permanente ou recherchés de manière centralisée, un serveur Syslog externe ou Sophos Central Firewall Reporting est nécessaire.

Pour Sophos Central, en gros : avec un abonnement de pare-feu actif, les rapports de pare-feu Central sont disponibles pour une période limitée. Avec Xstream Protection ou Central Orchestration, des évaluations plus longues sont possibles. Avec Sophos Central Firewall Reporting Advanced, on obtient un stockage supplémentaire et une conservation nettement plus longue. Les détails sont décrits dans Activer le Central Firewall Reporting.

Pour les premières analyses, Log viewer, Policy tester et Packet capture suffisent généralement. Pour des analyses plus approfondies, on peut également sécuriser les journaux CLI, activer les journaux de débogage ou utiliser tcpdump. Les journaux de débogage ne doivent être activés que de manière ciblée et temporaire, car ils génèrent beaucoup plus de données. Comment tester les règles est montré dans Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture. Pour Packet Capture, les noms de service et les fichiers journaux, voir les articles Utiliser l’outil Packet Capture dans WebAdmin et Dépannage Sophos Firewall : services et journaux. Si les journaux doivent être collectés pour le support ou une analyse externe, Sécuriser les journaux Sophos Firewall pour une analyse externe est utile.

Test d’acceptation avant le trafic productif

Avant le passage en production, il ne faut pas seulement vérifier si “Internet fonctionne”. Un petit test d’acceptation documenté évite de nombreux cas de support ultérieurs.

Tests pertinents :

• Connexion administrateur depuis le réseau de gestion: WebAdmin est accessible, mais pas ouvert depuis des zones indésirables
• Connexion administrateur depuis une zone client, invitée ou WAN : l’accès est bloqué si aucun réseau de management explicite n’y est prévu
• Deuxième administrateur ou accès de secours: L’accès reste possible si MFA, SSO ou un compte utilisateur échoue
• Client depuis le LAN vers Internet: La règle de pare-feu, NAT, DNS et la politique de sécurité fonctionnent comme prévu
• Nom DNS interne: Les routes de requêtes DNS ou les résolveurs internes fonctionnent
• Trafic de test bloqué: Log Viewer montre la règle correspondante ou le drop attendu
• Téléchargement et stockage de sauvegarde: La sauvegarde n’est pas seulement créée, mais aussi trouvable
• Cible Central ou Syslog: Les journaux et rapports arrivent en dehors du pare-feu, si prévu

Le test doit être brièvement documenté : date, version du firmware, emplacement, IP source testée, cible, résultat attendu et points ouverts. Cela peut sembler peu spectaculaire, mais cela fait gagner du temps si, des jours plus tard, un VPN, une règle NAT ou un problème DNS doit être examiné.

Liste de contrôle après la configuration initiale

Vérifier immédiatement

• Mot de passe administrateur et clé maître de stockage sécurisé stockés en toute sécurité.
• Pare-feu enregistré et statut des licences vérifié.
• Version du firmware et mises à jour des modèles contrôlées.
• Sauvegarde manuelle créée et stockée à l’extérieur.
• WebAdmin et SSH accessibles uniquement depuis les réseaux souhaités.
• Test négatif actif de WebAdmin et SSH depuis des zones non souhaitées.
• Deuxième accès administrateur et concept de secours testés.
• WAN, DNS et fuseau horaire vérifiés.
• Règle de pare-feu par défaut évaluée consciemment.

Vérifier dans les premiers jours

• Zones, VLAN, ponts et LAG planifiés proprement.
• Routes de requêtes DNS et plages DHCP contrôlées.
• Règles de pare-feu et NAT documentées.
• Journalisation activée sur les règles importantes.
• Sauvegarde Central ou processus de sauvegarde local mis en place.
• Central Reporting, Syslog ou autre cible de journalisation décidée.
• Premières règles validées avec Log Viewer, Policy Test et Packet Capture.

Vérifier avant le passage en production ou le Go-live

• Accès de gestion renforcé.
• MFA et rôles administratifs vérifiés.
• IPS, Web Protection, Application Control et autres fonctions de protection activées consciemment.
• Inspection TLS planifiée uniquement avec processus de test et d’exception.
• Accès à distance, IPsec, WAF, RED ou SD-WAN testés séparément, si utilisés.
• Chemin de retour et support documentés.

Erreurs typiques

• La configuration du wizard est utilisée directement en production : Règles trop larges, mauvaises zones ou services de management ouverts restent en place. Après le wizard, traiter une checklist d’exploitation dédiée.
• Secure Storage Master Key non documentée : Restore ou migration deviennent inutilement difficiles. Enregistrer immédiatement la SSMK dans le gestionnaire de mots de passe.
• WebAdmin accessible depuis WAN ou réseaux clients : Bots, brute force et surface d’attaque inutile deviennent plus probables. Device Access et Local Service ACL Exception Rules doivent être stricts.
• MFA activé sans fallback : Les admins peuvent se bloquer avec des problèmes de token, d’heure ou de groupe. Tester avant un deuxième admin, l’accès break-glass et le processus token.
• Logging oublié dans les règles : Le dépannage ultérieur se fait à l’aveugle. Log firewall traffic doit être actif sur les règles importantes.
• DNS résolu uniquement avec resolver public : Les noms internes ne fonctionnent pas de manière fiable. Planifier DNS internes et DNS request routes.
• NAT attendu sans règle firewall correspondante : Serveurs ou services restent injoignables malgré NAT. Toujours vérifier NAT et règle firewall ensemble.
• Firmware update installé sans backup : Le chemin de retour manque en cas de problème. Vérifier backup, release notes et fenêtre de maintenance avant les updates.

FAQ