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

Après l’assistant de configuration, un Sophos Firewall est accessible et fondamentalement prêt à l’emploi ; l’enregistrement est terminé ou volontairement différé sur le matériel éligible. Cependant, il n’est pas encore sécurisé. L’assistant effectue le démarrage, mais ne met pas en place l’architecture de production.

Cet article regroupe les contrôles à effectuer après la configuration initiale : accès Internet, enregistrement, licences, firmware, sauvegarde, zones, Device Access, DNS, DHCP, règles de pare-feu et NAT, journalisation et premières mesures de renforcement. Il suit SFOS 22 et sert de liste de contrôle pratique pour les nouvelles XGS Appliances, les pare-feux virtuels et les petites migrations. Les noms de champs correspondent à l’interface Sophos en anglais ; certaines pages et options varient selon la plateforme, le modèle et une configuration en ligne ou hors ligne.

En cas de migration de XG à XGS Appliance, 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.

Pour situer le contexte : Les règles et politiques de pare-feu contrôlent le trafic Internet et réseau. L’inspection SSL/TLS peut intercepter et déchiffrer les connexions SSL et TLS sur TCP. IPS utilise des règles qui contribuent à prévenir les attaques réseau. Web Protection permet de définir des restrictions de navigation selon les catégories, les groupes d’URL et les types de fichiers. La disponibilité de chaque fonction et ses effets dépendent de la licence et de la configuration. L’effet de protection souhaité doit être vérifié au moyen de tests adaptés ; une configuration de base réussie ne garantit pas une protection complète.

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 signatures de sécurité : Vérifier la version du firmware, les correctifs et les mises à jour des signatures de sécurité, 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 : n’autoriser le trafic de production 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 de production, 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 configuration 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 le pare-feu doit être connecté à Sophos Fusion (anciennement Sophos Central) ou si les limites de Central doivent être comprises, voir Connecter Sophos Firewall à Sophos Fusion.
• Statut de licence : pour Base License, Support et Subscriptions, voir Comprendre la Base License de Sophos Firewall.
• Sauvegarde et restauration : avant le premier changement, la procédure décrite dans Créer ou restaurer une sauvegarde Sophos Firewall devrait être préparée.
• Accès d’administration : WebAdmin, SSH, User Portal ou VPN Portal sont durcis avec Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.
• Conception du réseau : pour les zones, interfaces, VLAN ou ponts réseau, 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 de pare-feu 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.
• Rapports : pour les journaux, rapports et conservation prolongée, voir Activer Central Firewall Reporting.
• Health Check : les constats de sécurité après SFOS 22 peuvent être priorisés avec Utiliser correctement Sophos Firewall Health Check.
• Planification de la mise à niveau : pour une mise à jour du micrologiciel ou une mise à niveau vers 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 de production, 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.
• Un compte Sophos Fusion avec licence complète ou d’essai et un pare-feu avec Base License ; pour connecter à Central un appareil déjà configuré et revendiqué, une personne pouvant générer un OTP si nécessaire.
• Mot de passe administrateur prévu et emplacement dans le gestionnaire de mots de passe.
• Secure Storage Master Key (SSMK) prévu et emplacement de stockage protégé dans le gestionnaire de mots de passe ou dans le cadre de la procédure de récupération prévue ; définir les deux avant de commencer.
• Décision de configurer le pare-feu directement ou de le restaurer à partir d’une sauvegarde.

Préparer son propre Sophos ID pour la connexion. Si aucun Sophos ID personnel n’existe encore, il peut être créé pendant la configuration. Cela ne remplace ni l’invitation et les autorisations dans le compte Sophos Fusion prévu, ni le choix du bon tenant, ni la revendication du pare-feu ou les prérequis de licence associés. La préparation du compte est expliquée dans Gérer Sophos ID et l’accès au compte.

Le pare-feu a besoin d’une connexion Internet fonctionnelle pour l’enregistrement, la vérification des licences, les mises à jour des signatures de sécurité 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é.

Dans la configuration d’usine du matériel décrit, Port B est le port WAN et obtient son adresse par DHCP. Il s’agit d’un réglage initial, pas d’une exigence pour toutes les plateformes ou tous les fournisseurs : En cas d’adressage statique, de PPPoE ou de VLAN opérateur, adapter la configuration WAN au plan de connexion.

Pour le premier accès LAN avec la configuration d’usine documentée, attribuer d’abord au PC d’administration une adresse IPv4 libre dans 172.16.16.0/24, par exemple 172.16.16.2 avec le masque de sous-réseau 255.255.255.0. Connecter le PC directement ou via le réseau de configuration contrôlé au port LAN prévu ; il s’agit de Port A dans l’exemple matériel décrit. Ouvrir ensuite seulement https://172.16.16.16:4444. Les noms des ports et leur affectation d’usine doivent correspondre au modèle ou à la plateforme ; ces instructions LAN ne remplacent pas l’accès MGMT distinct.

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 en production avec une configuration de port inattendue peuvent rendre la configuration initiale inutilement difficile.

Configurer le port d’administration dédié

Il est également possible de modifier l’adresse IP du port d’administration dès l’assistant de configuration. Terminer ensuite la configuration et rouvrir WebAdmin via l’adresse qui y a effectivement été attribuée, avec HTTPS et le port configuré pour la console ; si le port par défaut est inchangé, il s’agit par exemple de https://10.0.1.1:4444, à condition que cette adresse ait été conservée. Après un changement d’adresse, le PC d’administration doit également se trouver dans le sous-réseau approprié ou disposer d’une route autorisée vers le nouveau réseau d’administration. Cela ne change rien à la modification ultérieure sous Network > Interfaces ni à la distinction concernant HA décrite ci-dessous.

Sur les modèles dotés d’un port de gestion dédié, ce réseau doit réellement rester réservé aux administrateurs. Les utilisateurs non administrateurs, les clients ordinaires ou les appareils invités ne doivent pas se trouver dans le même sous-réseau du port de gestion. Sinon, un accès initial pratique devient très vite une surface de gestion inutilement exposée.

Les appliances 1U et supérieures disposent d’au moins un port d’administration dédié. Il apparaît comme PortMGMT sous Network > Interfaces, appartient par défaut à la zone LAN et utilise initialement 10.0.1.1. Pour la configuration, attribuer au poste d’administration directement connecté une adresse libre du même sous-réseau, par exemple 10.0.1.2/24. Après la configuration, attribuer à PortMGMT une adresse du VLAN d’administration prévu. Si l’accès doit passer par un VPN, autoriser uniquement HTTPS et, si nécessaire, SSH pour la zone VPN sous Administration > Device access.

Remarque HA : Dans un cluster HA, SFOS synchronise la configuration normale du port d’administration du Primary vers l’Auxiliary. L’adresse IP de l’interface PortMGMT est donc identique sur les deux appareils et ne peut pas être définie différemment par nœud. L’accès WebAdmin séparé à l’Auxiliary utilise l’adresse Peer administration IP supplémentaire dans le même réseau d’administration.

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 en production, 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.

Uniquement si la configuration d’usine est inchangée, le nom d’utilisateur est admin et le mot de passe est admin. Effectuer cette première connexion exclusivement depuis un réseau d’administration ou de configuration isolé et contrôlé, puis remplacer immédiatement le mot de passe par un mot de passe fort et personnel. Si l’appareil a déjà été configuré ou si le mot de passe a été modifié, utiliser les identifiants effectivement valides. Les identifiants d’usine ne doivent pas être utilisés en production.

Pour les accès ultérieurs depuis le navigateur, utiliser HTTPS avec l’adresse IP interne effectivement actuelle ou le nom d’hôte résolvable du pare-feu, ainsi que le port configuré pour la console, par exemple https://firewall.example:4444. Remplacer le nom d’hôte d’exemple et, si nécessaire, le port : 4444 est la valeur par défaut, pas nécessairement la valeur actuellement configurée. Les adresses IP indiquées ci-dessus sont des exemples de configuration d’usine et ne restent pas automatiquement valides après une modification. Les paramètres de la console se modifient sous Administration > Admin settings. Indépendamment de ces paramètres, Administration > Device access détermine depuis quelles zones ou sources les services locaux sont accessibles ; ni les droits du compte ni la déconnexion ne remplacent ces restrictions d’accès. Ne pas autoriser de manière générale l’accès à WebAdmin depuis le WAN.

Navigateurs et langue de la WebAdmin Console

Les navigateurs courants Chrome, Edge, Firefox et Safari sont pris en charge ; utiliser une version récente du navigateur. La langue de la console s’applique aux menus, boutons, messages d’erreur, infobulles et autres textes affichés à l’écran. Depuis SFOS 20.0 MR1, le pare-feu détecte automatiquement la langue préférée du navigateur. Si aucune langue prise en charge ne correspond, l’anglais est utilisé. La préférence linguistique est enregistrée dans le cache du navigateur.

Pour changer de langue, ouvrir la liste déroulante des langues sur la page de connexion, sélectionner la langue souhaitée, puis se connecter. La WebAdmin Console utilise alors cette langue. Les chemins de menus et les libellés de l’interface restent en anglais dans cet article pour faciliter un repérage sans ambiguïté ; une console dans une autre langue affiche les libellés localisés correspondants.

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 en état de démarrer. La liste suivante présente les décisions à prendre, et non un ordre d’écrans identique sur toutes les plateformes :

1. Accepter les conditions d’utilisation de Sophos End User.
2. Démarrer la configuration.
3. Remplacer le mot de passe administrateur par défaut par un mot de passe fort et complexe, et le stocker en toute sécurité.
4. Définir le nom du pare-feu et le fuseau horaire.
5. Vérifier le Deployment Mode et les paramètres WAN, LAN et DNS par rapport au plan réseau.
6. Fournir le numéro de série ou les données de licence existantes.
7. Examiner attentivement l’option d’installation automatique du firmware. Dans le parcours de revendication décrit ci-dessous, Install the latest firmware automatically during setup (recommended) est désélectionné ; la mise à niveau du firmware est ensuite planifiée séparément avec une fenêtre de maintenance et un accès local.
8. Créer la Secure Storage Master Key et la conserver dans le gestionnaire de mots de passe.
9. Effectuer l’enregistrement et la synchronisation des licences ou, si la plateforme le permet, les reporter délibérément.

Si les paramètres réseau doivent être modifiés pendant la configuration en mode gateway et que l’assistant propose cette étape, ouvrir Manual configuration, saisir les paramètres adaptés au réseau et les appliquer avec Apply. Confirmer la boîte de dialogue avec OK, puis poursuivre avec Continue. Ne pas recopier les valeurs d’exemple sans les vérifier ; cette séquence facultative n’est pas un ordre d’écrans universel pour toutes les plateformes.

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.

SFOS 22 applique dans l’assistant des valeurs par défaut recommandées, notamment pour les correctifs à chaud et Device Access. Elles constituent un point de départ, pas une validation générale : vérifiez les réglages effectifs après la première connexion. Sous Administration > Admin and user settings, contrôlez en particulier la déconnexion des sessions administrateur inactives et la protection contre les tentatives de connexion par force brute. N’affaiblissez pas globalement les valeurs recommandées ; avant toute modification, consignez les valeurs initiales et testez la connexion depuis le réseau d’administration prévu.

Vérifiez le délai d’inactivité dans Sign out administrator session. Sous Prevent brute force sign-in attacks, contrôlez le nombre de tentatives de connexion échouées depuis la même adresse IP pendant l’intervalle configuré et la durée du blocage de l’accès. Consignez les valeurs effectives avant toute modification ; ne déclenchez pas volontairement un blocage pour tester ces contrôles.

Pour l’accès SSH des administrateurs, l’authentification par clé publique est une alternative au mot de passe ; elle ne remplace pas l’authentification WebAdmin. Le guide d’accès SSH et de configuration des clés publiques explique Administration > Device access > Public key authentication for admin, la gestion des clés et le test dans une seconde session en gardant la session d’administration existante ouverte. Conservez un accès d’administration de secours fonctionnel jusqu’à la vérification de la nouvelle connexion SSH.

Choisir le Gateway Mode ou le Bridge Mode

Le choix du mode dans le Setup Wizard n’est pas un réglage purement visuel. Avec This Firewall (Routed Mode), Sophos Firewall agit comme passerelle de couche 3, route le trafic et peut remplacer la passerelle existante. Il s’agit généralement du design le plus clair pour une nouvelle installation, mais il exige de planifier les adresses WAN et LAN, les routes, le NAT et les règles de pare-feu.

Avec Internet gateway (Bridge Mode), le pare-feu fonctionne en ligne comme bridge de couche 2 devant ou derrière le routeur existant. Le plan d’adressage IP actuel peut être conservé pendant que le trafic passe par l’IPS, l’analyse des malwares et d’autres fonctions de protection. Le bridge transmet également STP, RSTP et le multicast routing. Transparent ne signifie donc pas sans risque : le chemin des switches, la protection contre les boucles, les bridge members, les zones et les règles font toujours partie du plan réseau.

⚠️ Lorsque Finish est sélectionné, l’assistant applique la configuration et redémarre le pare-feu. Exécuter l’assistant après la configuration d’un cluster HA désactive HA. Il ne faut donc pas répéter le choix du mode dans le wizard d’un cluster HA existant. Sophos prend en charge HA sur les interfaces bridge pour un nouveau déploiement en Bridge Mode via l’assistant, mais le câblage, le changement de rôle et le chemin de données doivent tout de même être testés de manière contrôlée.

Pour les modèles avec radio Wi-Fi intégrée, configurer le réseau sans fil protégé et le réseau sans fil invité selon le plan réseau dans l’étape correspondante de la configuration en mode gateway, puis sélectionner Continue. Ces choix ne remplacent pas la vérification de la séparation souhaitée entre le réseau invité et le LAN.

Sur les modèles XGS 88w, 108w, 118w et 128w, le wizard ne propose pas Bridge wireless network with LAN. Cette limitation doit aussi être prise en compte lors de la configuration en mode gateway ; la configuration après installation décrite ci-dessous ne se limite donc pas à Bridge Mode. Si LocalWifi0 doit être directement relié au LAN par bridge, cette configuration est effectuée après l’installation sous Wireless > Access points > LocalWifi0 > Bridge to Ethernet, puis testée avec un client Wi-Fi.

En Gateway Mode, le wizard peut aussi activer Enable TAP/Discover Mode pour un ou plusieurs ports de surveillance passive. Cela ne rend pas les interfaces routées passives : seul le port TAP observe une copie miroir. Configurer le Discover Mode avec TAP et SPAN explique la procédure complète pour SPAN, les rapports et HA.

Après le redémarrage, les deux modes exigent d’abord de vérifier l’accès d’administration, l’état des interfaces, le DNS et un flux de test connu. En Gateway Mode, il faut aussi vérifier la default gateway, le NAT et la Firewall Rule ID. En Bridge Mode, il faut contrôler les deux bridge members, STP/RSTP, le routeur qui reste responsable ainsi qu’un chemin aller-retour réel.

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 de production, 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 en production, cette étape ne doit pas rester inutilement ouverte, car le statut des licences, le support, les abonnements et les fonctions Central en dépendent.

La revendication, ou claim, associe le numéro de série au bon compte Sophos Fusion. Elle ne correspond pas à l’enregistrement ultérieur d’un pare-feu existant pour Central Management avec un OTP. Le parcours de configuration en ligne ci-dessous nécessite un compte Sophos Fusion avec licence complète ou d’essai et un pare-feu avec Base License.

La procédure de revendication suivante suppose un numéro de série existant. Si aucun numéro de série n’est encore disponible et que l’assistant en ligne propose la deuxième option correspondante, celle-ci fournit un numéro de série temporaire pour un essai de 30 jours. Se connecter ensuite au compte Sophos Fusion prévu ou créer un compte, choisir l’option de licence pour l’essai et confirmer avec Claim firewall. Le numéro de série est attribué au pare-feu ; poursuivre avec Continue. Ce numéro de série temporaire ne correspond ni à l’évaluation de modules de protection individuels d’un pare-feu déjà identifié décrite plus bas, ni au report de l’enregistrement du matériel.

Revendiquer un nouveau pare-feu pendant la configuration en ligne

1. Dans l’assistant, décocher Install the latest firmware automatically during setup (recommended) et cliquer sur Continue. La mise à niveau reste ainsi une étape planifiée, avec fenêtre de maintenance et accès local, plutôt qu’une opération lancée pendant l’enregistrement.
2. Définir le nom du pare-feu et le fuseau horaire. Sélectionner I have an existing serial number, saisir le numéro de série du pare-feu prévu et cliquer sur Continue.
3. Sur Claim your firewall with Sophos Central, choisir Claim in Sophos Central. Se connecter au bon compte Sophos Fusion ; les libellés anglais peuvent encore mentionner Sophos Central.
4. Dans Claim firewall, saisir le numéro de série et cliquer sur Validate. Vérifier l’affectation de l’appareil avant de le revendiquer.
5. Choisir consciemment entre Just claim the firewall with Base license et Claim with 30 days Xstream Protection, Web Server Protection and Email Protection evaluation license. La première option associe uniquement la licence de base ; la seconde démarre aussi l’évaluation de 30 jours indiquée. Un essai n’est ni un bundle de protection payant ni un remplacement d’un renouvellement planifié.
6. Cliquer sur Claim firewall. De retour sur le pare-feu, terminer sur Basic setup is complete avec Skip to finish, ou utiliser Continue pour configurer les paramètres avancés de manière contrôlée.
7. Une fois la configuration terminée, se connecter localement et vérifier le numéro de série et le statut des licences sous Administration > Licensing. Dans Sophos Fusion, ouvrir My Products > Firewall Management > Firewall licenses, rechercher le même pare-feu et déplier la flèche à côté de son nom. Le compte, le numéro de série et les détails de licence doivent correspondre à l’appareil configuré.

Pour un appareil déjà configuré et revendiqué, un administrateur d’un environnement partenaire ou client peut plutôt générer un OTP pour la connexion à Central Management. Cela évite de partager les identifiants de super-administrateur, mais ne remplace ni le claim ni l’activation des licences. Connecter Sophos Firewall à Sophos Fusion explique le parcours OTP et management.

Important : Sophos Fusion Firewall Management nécessite un abonnement payant au-delà de la Base Firewall License ou une licence de support active donnant droit à cette fonction, par exemple Enhanced Support. La Base Firewall License seule ne suffit pas pour cela. De plus, le pare-feu doit pouvoir accéder à Internet via IPv4 pour Central Management.

Différer l’enregistrement : Seuls les firewalls matériels peuvent rester non revendiqués pendant 30 jours au maximum lors de la configuration initiale, par exemple pour une démonstration ou une configuration sans accès Internet. Cette option n’est pas disponible pour les firewalls software, virtuels, Azure ou AWS BYOL.

• Avec accès Internet : Dans Register your firewall, sélectionner I do not want to register now. Cliquer sur Continue, puis sur Continue dans l’avertissement, et terminer l’assistant.
• Sans accès Internet : Dans Internet Connection, sélectionner Continue Offline. Cliquer sur Continue, puis sur Continue dans l’avertissement, et terminer l’assistant.

Jusqu’à l’enregistrement, toutes les fonctions locales restent disponibles sauf Sophos Fusion et Synchronized Security Heartbeat. Après la configuration, Administration > Licensing doit afficher Registration has been currently deferred on this device. Revendiquer le firewall dans Sophos Fusion et terminer l’enregistrement dans les 30 jours. Le report n’accorde pas de droits aux abonnements payants ; vérifier séparément l’état réel des licences.

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.

Les nouveaux abonnements commencent à l’exécution de la commande, et non à l’application de la clé de licence. Il faut néanmoins appliquer la clé pour associer la licence à ce pare-feu. Une application plus tardive ne décale ni la date de début ni la date d’expiration.

Activer un abonnement payant sur le pare-feu

Sous Administration > Licensing, cliquer sur Activate subscription, saisir la clé de licence et choisir Verify key. Comparer les détails affichés avec la commande et le pare-feu ; confirmer avec Confirm uniquement si l’affectation est correcte. Le nouvel abonnement doit ensuite afficher Subscribed sous Module subscription details.

Ouvrir ensuite My Products > Firewall Management > Firewall licenses dans Sophos Fusion, rechercher le même numéro de série et déplier les détails avec la flèche à côté du nom. Vérifier que l’abonnement activé localement y apparaît aussi avec les modules et dates d’expiration attendus. Activer une clé de licence Sophos Firewall détaille le License Schedule, les renouvellements et les erreurs d’activation.

Démarrer une évaluation depuis le pare-feu

Sous Administration > Licensing, cliquer sur Sign in to Sophos Central dans Activate evaluations in Sophos Central. Dans Activate Evaluations, sélectionner uniquement les fonctions à tester et confirmer avec Evaluate selected. De retour sur le pare-feu, les modules sélectionnés doivent afficher Evaluating sous Module subscription details. Documenter l’expiration et la décision de poursuivre la licence avant que des règles de production ne dépendent de ces modules.

Appliquer un abonnement dans Sophos Fusion et synchroniser localement

Il est également possible d’appliquer la clé de manière centralisée :

1. Dans Sophos Fusion, ouvrir My Products > Firewall Management > Firewall licenses, rechercher le pare-feu par numéro de série et déplier ses détails avec la flèche.
2. Cliquer sur Apply subscriptions, saisir le Subscription Key et choisir Preview subscription.
3. Vérifier les détails de l’abonnement et l’affectation de l’appareil avant de confirmer avec Apply subscription. Les nouveaux abonnements doivent apparaître dans les détails du pare-feu sur le portail.
4. Sur le pare-feu, ouvrir Administration > Licensing et cliquer sur Synchronize. Les mêmes abonnements doivent apparaître sous Module subscription details, avec des statuts et dates d’expiration correspondants.

Les deux sens sont ainsi contrôlés : activation locale dans la vue Central et application centralisée dans la vue locale des licences. En cas de différence, vérifier d’abord le numéro de série, le compte, le WAN, le DNS et l’heure système, plutôt que d’essayer la clé sur d’autres appareils. Une licence adaptée ne configure pas une politique de protection ; son effet se teste séparément.

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 Fusion ?

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 Fusion

Pour le fonctionnement local d’un seul Sophos Firewall, Sophos Fusion n’est pas strictement nécessaire. Le pare-feu peut être entièrement géré via WebAdmin. Cependant, Sophos Fusion 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 Fusion.

Il est important d’avoir les bonnes attentes : Sophos Fusion 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 Fusion : avantages et limites.

Finalisation de la configuration

Si l’assistant de passerelle propose une sélection d’options de protection réseau, choisir délibérément les options adaptées au réseau prévu et à la licence, puis poursuivre avec Continue. Cette sélection ne remplace pas non plus la vérification ultérieure des profils de protection et de leurs effets.

À l’étape correspondante de l’assistant, définir un destinataire de courrier électronique pour les notifications et les sauvegardes, puis poursuivre avec Continue. Avant Finish, comparer le récapitulatif de configuration aux paramètres prévus. Terminer seulement ensuite : Le pare-feu applique les modifications et redémarre. L’avertissement concernant HA et les vérifications suivantes restent applicables.

Une fois la configuration terminée, le pare-feu redémarre ou redirige vers l’écran de connexion. Dans le parcours de revendication décrit ci-dessus, Install the latest firmware automatically during setup (recommended) a été désélectionné : terminer ce parcours ne signifie donc pas que le firmware le plus récent a été installé. Vérifier la version du firmware effectivement active après la connexion et planifier séparément toute mise à jour nécessaire avec une sauvegarde, une fenêtre de maintenance et une procédure de retour arrière. Si une mise à jour automatique a été sélectionnée dans un autre parcours de configuration et que la connexion est interrompue pendant celle-ci, cela ne prouve à lui seul ni une défaillance matérielle ni la réussite de la mise à niveau. Dès que l’accès local est de nouveau possible, contrôler la version du firmware et l’état de fonctionnement de base avant d’autoriser le trafic de production.

Pour ce parcours de mise à niveau automatique pendant la configuration, le scénario de récupération documenté en cas de perte de connexion est un redémarrage avec le firmware fourni à la livraison du pare-feu. Cela peut expliquer la réapparition de la version d’origine. Ce résultat n’est pas garanti pour toute interruption ou plateforme et ne constitue pas une promesse universelle de retour arrière pour les mises à jour ordinaires du firmware. Vérifier la version active et l’état de fonctionnement de base par l’accès local et ne pas autoriser le trafic de production avant la fin de ces contrôles.

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

• Date, heure et fuseau horaire.
• Version du firmware et mises à jour des signatures de sécurité.
• 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.

Repères communs dans WebAdmin

Après chaque connexion, Control center s’ouvre et présente une vue d’ensemble de l’état du système et des fonctions de sécurité. Le champ de recherche en haut du menu de gauche permet de rechercher dans les entrées de menu, les onglets et les titres de section. Les résultats affichent également les chemins correspondants ; il est ainsi possible de trouver la page de paramètres appropriée sans ouvrir chaque menu séparément.

En-tête de SFOS 22 : navigation et déconnexion

Ces indications concernent l’en-tête documenté pour SFOS 22. How-to guides ouvre la bibliothèque de vidéos de configuration, Log viewer ouvre le Log Viewer dans une fenêtre distincte et Help ouvre l’aide contextuelle de la page actuelle.

En haut à droite, cliquer sur le nom de l’utilisateur connecté, par exemple admin. Le menu propose Support pour accéder à la page de support et ouvrir une demande d’assistance, About product pour accéder à la page des licences et Console pour ouvrir la console CLI. Sur les appareils HA, il affiche également le type de HA, l’état actuel, les noms des nœuds et les numéros de série des appareils Primary et Auxiliary.

Une fois le travail terminé, sélectionner Logout via le nom d’utilisateur en haut à droite afin de ne pas laisser de session ouverte. Reboot device redémarre le pare-feu et Shutdown device l’éteint : ces deux actions interrompent le fonctionnement et doivent être réservées à une maintenance planifiée ; elles ne remplacent pas la déconnexion. Les libellés différents de l’en-tête expressément documenté pour SFOS 23 sont présentés dans la section suivante ; ils ne prouvent pas que les anciens chemins de menus ont été supprimés partout.

En-tête de SFOS 23 : se repérer après la connexion

Ces indications concernent expressément l’en-tête WebAdmin documenté pour SFOS 23 ; la procédure de configuration SFOS 22 ci-dessus reste la base.

• Le logo Sophos ramène au Control center. L’en-tête affiche le modèle et le numéro de série. L’Account icon permet de vérifier le rôle de l’utilisateur, le nom de l’appareil, son numéro de série ainsi que la version et le build du firmware avant d’intervenir.
• Dans le menu du compte, Command line ouvre la console CLI et Licenses ouvre la vue des licences. Pour se déconnecter, choisir Account icon > Sign out. Restart redémarre l’appareil ; Shutdown l’arrête. Ces deux actions interrompent le fonctionnement et ne remplacent pas la déconnexion : ne pas les sélectionner pour découvrir l’interface, mais uniquement dans le cadre d’une maintenance planifiée.
• Le menu du point d’interrogation propose Help, Videos et Support. L’icône de retour d’expérience ouvre une fenêtre pour envoyer des commentaires.
• Lorsque HA est configuré, l’HA icon distinct ouvre l’état du cluster ainsi que les noms et numéros de série des appareils Primary et Auxiliary. Il ne s’agit pas de l’icône HA de Sophos Fusion. Pour la configuration et l’exploitation, consulter Clusters HA et variantes.
• Logs and policy test regroupe l’accès aux logs et l’onglet Policy test. L’utilisation des logs reste décrite dans le guide du Log Viewer ; tester correctement les règles de pare-feu explique l’accès au test selon la version.

Ne pas généraliser les libellés : La section précédente sur la déconnexion dans la documentation SFOS 23 indique encore Logout, alors que la section consacrée à l’en-tête emploie Sign out. La page Manage, inchangée, indique également admin > Console plutôt que Account icon > Command line. Ces passages ne sont pas cohérents entre eux ; les nouveaux libellés ci-dessus s’appliquent uniquement à l’en-tête SFOS 23 expressément documenté. Ils ne prouvent pas que les anciens chemins SFOS 22 ont été supprimés partout.

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 micrologiciel. Cela permet de redémarrer avec un micrologiciel précédent en cas de problème. Cependant, avant chaque changement majeur, une sauvegarde manuelle doit être créée. Pour les pare-feux en production, 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 de production 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 en production, 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, Sophos Fusion Firewall Management 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 de pare-feu 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 Sophos Fusion Firewall Management est utilisé.
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 Fusion, les rôles administratifs de Sophos Fusion 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 : La résolution DNS fonctionne pour les noms testés. Vérifier ensuite séparément l’enregistrement, la synchronisation des licences, les mises à jour et la connexion à Central.
• Le client résout les noms externes : La résolution DNS fonctionne pour les noms testés. Vérifier également l’attribution DHCP, le serveur DNS utilisé et la règle de pare-feu.
• Le client résout les noms internes : La résolution des noms internes fonctionne pour les noms testés. Vérifier si le serveur DNS interne prévu ou la DNS request route est utilisé.
• Le client VPN ou VLAN résout les noms internes : La résolution des noms fonctionne également depuis le réseau testé. Vérifier néanmoins le serveur DNS, le domaine de recherche et la règle de zone par rapport à la configuration prévue.

Le DHCP est configuré sous Network > DHCP par interface. Configurer Sophos Firewall comme serveur DHCP explique comment planifier et tester correctement la plage, la passerelle, le DNS, la durée du bail et les attributions statiques.

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 en production 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 Fusion. 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 Central Firewall Reporting est nécessaire.

Pour Sophos Fusion, 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 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 de production

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.

Si possible, testez d’abord les règles hors ligne sur un réseau de test. Une autre approche progressive consiste à utiliser temporairement une autre adresse de passerelle sur le réseau réel et à ne diriger que quelques clients de test vers le pare-feu. Ne changez l’adresse de passerelle ou le câblage, pendant la fenêtre de maintenance prévue, qu’après avoir validé les flux aller et retour. En cas d’échec, repointez les clients de test vers l’ancienne passerelle ; la production reste inchangée.

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 d’administration 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 rejet 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 signatures de sécurité 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 la mise en service

• 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 de l’assistant est utilisée directement en production : Des règles trop larges, de mauvaises zones ou des services d’administration ouverts restent en place. Après l’assistant, passer en revue une liste de contrôle d’exploitation dédiée.
• Secure Storage Master Key non documentée : La restauration ou la migration deviennent inutilement difficiles. Enregistrer immédiatement la SSMK dans le gestionnaire de mots de passe.
• WebAdmin accessible depuis WAN ou réseaux clients : Les robots, les attaques par force brute et une surface d’attaque inutile deviennent plus probables. Device Access et Local Service ACL Exception Rules doivent être stricts.
• MFA activé sans solution de secours : Les administrateurs peuvent se retrouver bloqués en cas de problèmes de jeton, d’heure ou de groupe. Tester au préalable l’accès d’un deuxième administrateur, l’accès d’urgence et la procédure de gestion des jetons.
• Journalisation oubliée dans les règles : Le dépannage ultérieur se fait à l’aveugle. Log firewall traffic doit être actif sur les règles importantes.
• Résolution DNS assurée uniquement par un résolveur public : Les noms internes ne fonctionnent pas de manière fiable. Planifier les serveurs DNS internes et les DNS request routes.
• NAT attendu sans règle de pare-feu correspondante : Les serveurs ou services restent injoignables malgré NAT. Toujours vérifier NAT et la règle de pare-feu ensemble.
• Mise à jour du micrologiciel installée sans sauvegarde : La possibilité de revenir en arrière manque en cas de problème. Vérifier la sauvegarde, les notes de version et la fenêtre de maintenance avant les mises à jour.

FAQ