Sophos Firewall : Matériel, virtuel ou cloud ?

Sophos Firewall peut être exploité sous forme de XGS Appliance, d’appliance virtuelle, de Software Appliance ou de Cloud Deployment. Toutes ces variantes exécutent Sophos Firewall OS, mais leur modèle d’exploitation diffère. Le choix influe sur les performances, le support, la conception des ports réseau, la haute disponibilité (HA), la récupération, les licences et la surveillance. Il détermine aussi les responsabilités de chaque équipe en cas d’incident sur la plateforme.

Pour les nouveaux projets, il ne suffit pas de comparer les prix. Il faut surtout choisir la variante adaptée au site physique, à la plateforme de virtualisation, à l’architecture cloud et à l’équipe d’exploitation. Le guide de dimensionnement Sophos Firewall est également essentiel pour dimensionner la solution en fonction des performances requises.

Le choix de la plateforme détermine également les fonctions de conformité : Le mode FIPS 140-3 est proposé sur XGS Appliances, les plateformes virtuelles compatibles, AWS et Azure, mais pas sur les Software Appliances ni le matériel XG ou SG.

Choisir le modèle d’exploitation

Décision rapide

• XGS Appliance : Convient principalement lorsqu’un emplacement nécessite un pare-feu dédié et clairement pris en charge avec des ports physiques.
• Appliance virtuelle : Convient principalement si une plate-forme de virtualisation stable est disponible et si les zones du réseau peuvent être proprement séparées virtuellement.
• Software Appliance : Convient généralement si votre propre matériel doit être délibérément exploité et pris en charge en tant que plate-forme de pare-feu.
• Cloud Deployment : Convient le plus souvent pour protéger les charges de travail dans AWS ou Azure ou pour les connecter aux réseaux locaux.

La règle essentielle : un pare-feu virtuel ou cloud ne dispense pas d’une planification rigoureuse. Les ressources CPU, la RAM, le stockage, les commutateurs virtuels, le routage, la HA, les sauvegardes et la surveillance doivent être planifiés avec autant de soin que pour une appliance matérielle.

Quand faire attention

La décision ne doit pas se baser uniquement sur ce qui est techniquement possible. Certains environnements semblent flexibles sur le papier, mais créent des risques inutiles en fonctionnement.

• L’hyperviseur est déjà fortement sollicité : IPS, TLS Inspection, VPN et la journalisation nécessitent des réserves prévisibles de ressources CPU et d’E/S.
• WAN, LAN, DMZ et la gestion passent par le même goulot d’étranglement physique : Une séparation logiquement propre n’est d’aucune utilité si le chemin réel des données est surchargé ou mal segmenté.
• Aucune équipe n’assume une responsabilité partagée pour l’hyperviseur et le pare-feu : Les incidents restent sans résolution entre les équipes plateforme, réseau et pare-feu.
• HA n’était prévu que comme une case à cocher : Sans tests d’hôte, de stockage, de réseau et de restauration, la haute disponibilité n’est pas prouvée.
• Le routage cloud n’est pas entièrement documenté : Le pare-feu protège uniquement le trafic qui y est réellement acheminé.
• La restauration n’a jamais été pratiquée : Une sauvegarde n’est fiable que si une restauration a été testée de manière réaliste ou au moins correctement planifiée.

Dans de tels cas, choisir une XGS Appliance n’est souvent pas moins moderne : c’est simplement un choix d’exploitation plus robuste. À l’inverse, un pare-feu virtuel ou cloud peut être très pertinent si la plateforme, la conception du réseau, la surveillance et les responsabilités sont clairement définies.

Comparer les plateformes

XGS Appliance

Une XGS Appliance est généralement la solution la plus prévisible pour les sites traditionnels. Le matériel, les ports réseau, le support, le processus RMA, le cycle de vie et le système d’exploitation du pare-feu forment un ensemble cohérent.

La gamme matérielle Sophos répond à des besoins variés, des particuliers et petites entreprises jusqu’aux grandes entreprises. Le choix d’une XGS Appliance dépend du trafic, des fonctions de protection, des ports et des exigences HA. Si nécessaire, demander à l’équipe commerciale Sophos ou à un partenaire de vérifier ce choix au regard de ces besoins. L’adéquation à un réseau domestique ne signifie pas automatiquement que la licence Home gratuite peut être utilisée sur le matériel choisi.

Avantages :

• un matériel pare-feu dédié,
• une configuration fixe des ports réseau et des options d’extension,
• affectation claire des liens WAN, LAN, DMZ, HA et gestion,
• processus de support et de remplacement matériel facile,
• aucune dépendance aux ressources de l’hyperviseur,
• Bien adapté aux succursales, aux sièges sociaux et aux pare-feu de périphérie. Le plus grand avantage réside dans le fonctionnement : en cas de problème, vous n’avez pas besoin de clarifier au préalable si l’hyperviseur, le vSwitch, le stockage, le routage cloud ou le pare-feu lui-même en sont la cause. Pour de nombreux sites de PME, cela est plus important qu’une flexibilité maximale.

Appliance virtuelle

Un Sophos Firewall virtuel a du sens s’il existe déjà une plate-forme de virtualisation propre et que le pare-feu doit être intégré dans un centre de données, un environnement multi-tenant ou une conception de segmentation interne.

Il fournit sous forme virtualisée des fonctions de sécurité SFOS disponibles sur les appliances matérielles, notamment la sécurité fondée sur l’identité. Les décisions de sécurité tiennent ainsi compte de l’identité de l’utilisateur, et pas seulement de son adresse réseau. Les organisations et les fournisseurs de services de sécurité managés (MSSP) peuvent regrouper la protection réseau de centres de données virtuels ou de bureaux sur un pare-feu virtuel. Les fonctions disponibles dépendent des licences et de la plateforme prise en charge ; cela n’implique ni une accélération matérielle identique ni le même débit qu’une XGS Appliance.

Les déploiements virtuels et cloud avec SFOS peuvent également prendre en compte l’état de santé des endpoints gérés dans les décisions d’accès grâce à Sophos Endpoint Security Heartbeat. Cela nécessite des droits de licence Endpoint et pare-feu appropriés, l’enregistrement dans la même organisation correcte et une réaction explicitement configurée. La sécurité fondée sur l’identité n’est pas un mécanisme équivalent pour évaluer l’état de santé des endpoints ; l’enregistrement seul ne prouve ni leur isolation ni le blocage de tous les chemins de trafic. Les prérequis, les mécanismes de réaction et les contrôles de leurs effets sont expliqués dans le guide de Security Heartbeat et Synchronized Security.

Sophos propose également l’administration centralisée des équipements Sophos Firewall. L’aperçu des plateformes SFOS 22 emploie le nom Sophos Fusion (previously Sophos Central), tandis que celui de SFOS 23 utilise Sophos Central. Ces noms différents ne démontrent pas que l’administration centralisée a été introduite avec SFOS 23. Lors de la planification, vérifier le service utilisé dans votre portail d’administration et les prérequis d’intégration du pare-feu ; l’analyse centralisée des journaux ne constitue pas, à elle seule, une administration centralisée des équipements.

Les plateformes virtuelles pertinentes incluent VMware, Microsoft Hyper-V, KVM, Nutanix Prism et Citrix Hypervisor. Avant le déploiement, vérifier la version concrète de la plateforme par rapport aux informations de compatibilité Sophos actuelles. Sophos indique au minimum un vCPU, 4 Go de RAM, deux vNIC, un disque principal de 32 Go et un disque de rapports de 80 Go. Ce sont des valeurs minimales d’installation, pas un dimensionnement pour le trafic d’inspection en production.

La vérification ne doit pas s’arrêter à la famille de produits. Pour Nutanix, par exemple, Sophos exige AOS 6.5.x ou une version LTS ultérieure, la version AHV associée, une version compatible de Prism Central et un cluster AHV enregistré dans Prism Central. KVM nécessite un hôte x86 avec un noyau Linux récent et la prise en charge Intel VT ou AMD-V activée. Si le nombre de vCPU et la RAM augmentent pour absorber davantage de charge, prévoir aussi un disque de rapports plus grand pour le volume de logs supplémentaire.

Questions opérationnelles importantes :

• Les ressources CPU sont-elles garanties ou fortement sursouscrites ?
• La RAM et le stockage sont-ils suffisamment dimensionnés ?
• Les cartes réseau virtuelles et les groupes de ports sont-ils clairement séparés ?
• Existe-t-il des chemins réseau dédiés pour WAN, LAN, DMZ, HA et la gestion ?
• Le mode promiscuous, le trunking VLAN ou SR-IOV sont-ils requis ?
• Existe-t-il une stratégie cohérente de sauvegarde et de restauration ?
• Les responsabilités pour le diagnostic conjoint de l’hyperviseur, du stockage et du pare-feu sont-elles clairement définies ?

Un pare-feu virtuel peut très bien fonctionner. Cependant, les choses deviennent rapidement problématiques lorsqu’il s’exécute sur un hôte surchargé ou lorsque WAN, LAN et la gestion semblent logiquement propres, mais fonctionnent physiquement à travers les mêmes goulots d’étranglement.

⚠️ Les snapshots de l’hyperviseur ou les sauvegardes du fournisseur de virtualisation ne remplacent pas de manière prise en charge la sauvegarde Sophos intégrée. Pour une restauration supportée, sauvegarder la configuration sous Backup & Firmware > Backup & Restore. Des sauvegardes de plateforme peuvent exister en complément, mais ne doivent pas constituer l’unique voie de récupération.

Software Appliance

Une Software Appliance s’installe sur du matériel x86-64 dédié. Cette solution peut convenir aux laboratoires, aux environnements particuliers ou aux architectures très ciblées. En production chez un client, ce modèle doit être choisi délibérément, car le choix du matériel, les pilotes, les pièces de rechange, la surveillance et le support relèvent largement de l’exploitant.

Sur un matériel physique adapté, SFOS fournit des règles et des politiques de pare-feu, des fonctions de réponse aux menaces ainsi que du routage statique, SD-WAN et dynamique, sous réserve des licences applicables et du dimensionnement de la plateforme. Les noms de fabricants comme Dell ou HP sont des exemples, et non une liste de compatibilité vérifiée modèle par modèle.

L’installation reformate et repartitionne le disque, supprimant le système d’exploitation existant et tous les fichiers. Pour une Software Appliance SFOS 22, Sophos exige notamment Legacy BIOS, au moins 4 Go de RAM, deux interfaces réseau et au moins 32 Go de stockage ; 64 Go sont recommandés. Si les exigences minimales ne sont pas remplies, le pare-feu peut passer en mode fail-safe.

Divergence des valeurs de stockage : Les aperçus des plateformes SFOS 22 et 23 indiquent un minimum de 10 Go pour le matériel personnalisé. Les exigences spécifiques d’installation de Software Appliance pour SFOS 22 imposent en revanche au moins 32 Go et recommandent 64 Go. Ce guide retient délibérément l’exigence d’installation la plus précise et la plus prudente : au moins 32 Go, avec 64 Go recommandés. Ne pas prévoir d’installation avec 10 Go ; vérifier également les exigences de la version SFOS choisie avant l’installation.

Si une appliance démarre déjà en mode Failsafe, consigner la cause détectée par SFOS avec le runbook Vérifier Sophos Firewall en mode Failsafe avant de modifier les ressources.

Vérifier:

• Le matériel est-il adapté à un fonctionnement continu ?
• Les cartes réseau, le stockage et la configuration BIOS/UEFI sont-ils adaptés ?
• Existe-t-il du matériel de remplacement ?
• Le processus d’installation et de récupération est-il documenté ?
• Qui est responsable des erreurs matérielles ?

Pour les sites traditionnels, une XGS Appliance est souvent plus simple. Dans des cas techniques particuliers, une Software Appliance peut néanmoins convenir si l’équipe d’exploitation maîtrise bien la plateforme.

Cloud Deployment

Les déploiements cloud sont particulièrement utiles pour protéger des charges de travail dans AWS ou Azure ou pour relier des réseaux cloud à des sites locaux. Les points à examiner diffèrent de ceux d’un site traditionnel.

Prévoir :

• la conception VPC/VNet,
• les tables de routage,
• les zones de disponibilité,
• les Elastic IPs ou les adresses IP publiques,
• le VPN site à site ou le SD-WAN,
• la journalisation et l’analyse centralisée,
• les coûts cloud liés aux instances, au stockage, au trafic et à l’architecture HA,
• la répartition des responsabilités opérationnelles entre l’équipe cloud et l’équipe pare-feu.

Un pare-feu cloud ne remplace pas une conception de réseau cloud propre. Seuls les chemins réellement acheminés via le pare-feu sont protégés. Les choix de déploiement et de routage sont détaillés dans les guides pour Sophos Firewall sur AWS et Sophos Firewall sur Azure.

Installer une appliance virtuelle ou logicielle

Télécharger l’image directement depuis la page Sophos Firewall Installers. Sous Virtual Installers, choisir le paquet OVF correspondant pour Citrix ou VMware, le paquet VHD pour Hyper-V ou le paquet QCOW2 pour KVM, Proxmox ou Nutanix. Pour du matériel personnalisé, utiliser plutôt l’ISO sous Software Installers.

Avant l’importation, vérifier que la page de téléchargement liée ci-dessus a été chargée via HTTPS, que le paquet a été obtenu sans miroir tiers et que l’archive a été entièrement extraite sans erreur. Pour un paquet OVF, conserver ensemble le manifeste, l’OVF et les deux fichiers VMDK. Si l’importation signale une divergence de manifeste ou de somme de contrôle, arrêter et télécharger à nouveau le paquet directement depuis Sophos. Pour un transfert interne, il est également possible de relever une valeur SHA-256 immédiatement après le téléchargement, puis de la comparer sur le système cible. Ce contrôle détecte les erreurs de transfert, mais ne remplace pas une signature du fabricant.

Les ressources minimales avant l’importation sont 1 vCPU, 4 GB de RAM, deux vNIC, un disque principal de 32 GB et un disque de rapports de 80 GB. Des ressources insuffisantes déclenchent le mode fail-safe. Vérifier les droits CPU et ressources de la licence achetée avant de modifier les allocations ; ces minima ne constituent pas un dimensionnement de production. Augmenter la capacité du disque de rapports lorsque des ressources CPU/RAM supplémentaires permettent de générer davantage de journaux. Les snapshots de l’hyperviseur et les outils de sauvegarde du fournisseur ne constituent pas des sauvegardes de pare-feu prises en charge ; utiliser la fonction de sauvegarde SFOS.

Les procédures d’installation suivantes doivent être vérifiées pour la combinaison concrète de plateforme et de SFOS ; une installation réussie ne confirme pas encore le bon fonctionnement du chemin de production ou de rétablissement. Vérifier d’abord la prise en charge actuelle de la plateforme, du système d’exploitation, des outils d’administration et de l’image. Valider l’installation sur une nouvelle VM isolée avant d’y acheminer du trafic de production. Conserver le pare-feu existant et les routes de production inchangés jusqu’à la validation finale.

Les aperçus des plateformes SFOS 22 et 23 mentionnent également, pour la famille Citrix, XCP-ng-Center comme outil d’administration alternatif à XenCenter et, pour VMware, VMware Workstation comme alternative à la méthode ESXi/vSphere décrite ici. Ces options répertoriées ne confirment pas leur prise en charge actuelle et ne constituent pas une validation générale de toutes les versions de XCP-ng. Avant de choisir l’une de ces alternatives, la prise en charge des versions exactes de l’hôte, de la plateforme et de l’outil d’administration doit être confirmée. Si elle reste incertaine, arrêter le déploiement et utiliser une méthode dont la prise en charge est avérée. Les étapes XenCenter et ESXi/vSphere qui suivent ne constituent pas une procédure d’installation pour ces alternatives ; en particulier, ne pas transposer la procédure ESXi à Workstation.

Citrix Hypervisor et XenCenter

Prérequis : Citrix Hypervisor est déjà installé sur un hôte accessible et XenCenter est installé sur le poste d’administration. Vérifier les versions prises en charge de l’hôte, du système d’exploitation et de l’outil, puis enregistrer le paquet OVF Citrix extrait à un emplacement où XenCenter peut lire tous ses fichiers.

1. Dans XenCenter, cliquer avec le bouton droit sur la ressource prévue et sélectionner Import > Browse. Sélectionner l’OVF, cliquer sur Open, puis sur Next.
2. Sous Import VM(s) to, sélectionner la destination ou spécifier un Home Server, puis cliquer sur Next. Sélectionner le référentiel de stockage pour les deux disques.
3. Affecter les interfaces réseau de manière explicite : PortA au réseau d’administration/LAN isolé, et l’adaptateur côté WAN au réseau WAN/de test distinct prévu. Ne pas exposer WebAdmin avec sa configuration d’usine à Internet.
4. Verify manifest content est facultatif dans l’assistant d’importation ; conserver le manifeste et examiner toute divergence au lieu de la contourner. Continuer avec Next. Sous OS Fixup Settings, conserver Don’t use Operating System Fixup sélectionné.
5. Examiner le récapitulatif et cliquer sur Finish. Confirmer la réussite de l’importation, la présence des deux disques et les deux affectations réseau prévues avant de cliquer avec le bouton droit sur cette nouvelle VM et de sélectionner Start. Ouvrir sa console, puis suivre la procédure commune de premier accès ci-dessous.

VMware ESXi et vSphere Client

Prérequis : le serveur exécute déjà une version ESXi actuellement prise en charge, et l’administrateur dispose d’une session d’administration vSphere Client fonctionnelle avec accès réseau au serveur. Extraire le paquet VMware sur le poste d’administration. Les anciens libellés de version du matériel virtuel ne prouvent pas qu’ESXi 4 ou 5 est actuellement pris en charge.

Choisir le modèle OVF en connaissance de cause :

• sf_virtual et sf_virtual_vm7 : ancienne version de matériel 7, PCNet32 (Vlance), liaison virtuelle décrite comme fixe à 10 Mbps, half duplex.
• sf_virtual_vm8 : version de matériel 8, E1000E, 1000 Mbps, full duplex, auto-négociation On.
• sf_virtual_vm8_paravirtual : version de matériel 8, VMXNET 3, 10000 Mbps, full duplex, auto-négociation Off. Utiliser E1000E comme solution de repli documentée si le pilote VMXNET 3 ne fonctionne pas dans votre déploiement.
• sf_virtual_virtualbox n’est pas un modèle VMware. Les caractéristiques de liaison ci-dessus décrivent les adaptateurs virtuels ; elles ne garantissent pas le débit du pare-feu.

1. Dans vSphere Client, cliquer avec le bouton droit sur l’emplacement de déploiement et sélectionner Deploy OVF Template > Local file > Choose files. Sélectionner l’OVF choisi avec sf_virtual-disk1.vmdk, sf_virtual-disk2.vmdk et sf_virtual.mf, puis cliquer sur Open > Next.
2. Saisir le nom et l’emplacement, sélectionner la ressource de calcul et examiner les détails en poursuivant avec Next.
3. Sélectionner le datastore et le format des disques virtuels. Thick Provision Lazy Zeroed alloue l’espace à la création et initialise les blocs à zéro lors de leur première écriture. Thick Provision Eager Zeroed alloue et initialise l’espace à zéro dès la création, ce qui peut prendre davantage de temps. Thin Provision alloue l’espace selon les besoins pour économiser du stockage ; surveiller la capacité réelle du datastore. Ni ces descriptions des formats de disque ni cette procédure ne démontrent la prise en charge de Fault Tolerance par Sophos ou une restriction universelle de conversion des disques.
4. Affecter explicitement les deux réseaux sources, avec PortA sur le réseau d’administration isolé. Examiner toute la configuration et cliquer sur Finish. Attendre la réussite du déploiement, puis contrôler la taille des deux disques et l’affectation des interfaces réseau connectées.
5. Sélectionner Actions > Power > Power on, ouvrir la console et suivre la procédure commune de premier accès.

Hyper-V Manager

Prérequis : un hôte Hyper-V pris en charge et Hyper-V Manager sur un poste d’administration disposant d’un accès réseau à cet hôte. Extraire le paquet Hyper-V et placer les deux fichiers VHD sur un stockage accessible à l’hôte ; un chemin visible uniquement sur le PC de l’administrateur ne suffit pas pour un hôte distant.

1. Ouvrir Action > Connect to Server, puis Action > New > Virtual Machine. Dans l’assistant, choisir le nom et l’emplacement, Generation 1, puis une Startup memory d’au moins 4096 MB.
2. Choisir le commutateur virtuel d’administration isolé pour le premier adaptateur. Sélectionner Use an existing virtual hard disk > Browse > PRIMARY-DISK.vhd > Open. Examiner la configuration et cliquer sur Finish, sans démarrer la VM pour l’instant.
3. Cliquer avec le bouton droit sur la nouvelle VM, ouvrir Settings et, sous Hardware, sélectionner Network Adapter > Add. Affecter ce second adaptateur au réseau distinct prévu et cliquer sur Apply.
4. Sélectionner SCSI Controller > Hard Drive > Add > Virtual hard disk > Browse, choisir AUXILIARY-DISK.vhd, puis Open > OK. Vérifier le disque principal de démarrage, le disque SCSI auxiliaire, les deux commutateurs et les tailles des disques.
5. Cliquer avec le bouton droit sur la VM et sélectionner Connect, puis la démarrer depuis la console. Suivre la procédure commune de premier accès.

KVM et Virtual Machine Manager

Prérequis : un hôte Linux x86 avec un noyau récent et Intel VT ou AMD-V activé, ainsi que Virtual Machine Manager installé et accessible, ou des outils d’administration KVM adaptés et pris en charge. Exécuter ces contrôles en lecture seule sur l’hôte Linux, et non dans la console SFOS :

grep --color vmx /proc/cpuinfo
grep --color svm /proc/cpuinfo

Le résultat doit contenir les indicateurs vmx pour Intel ou svm pour AMD, pas nécessairement les deux. Si le contrôle correspondant ne renvoie aucune correspondance, arrêter et vérifier les capacités du processeur, les paramètres de virtualisation du firmware et, pour un hôte virtualisé en mode imbriqué, l’exposition de ces fonctions. La présence des indicateurs ne prouve à elle seule ni l’activation dans le firmware ni le bon fonctionnement d’un déploiement KVM. #!sh, présent dans d’anciennes instructions, est un marqueur de mise en forme, pas un préfixe de commande.

1. Extraire l’archive KVM. Ouvrir File > New Virtual Machine > Import existing disk image > Browse, choisir PRIMARY-DISK.qcow2 avec Choose volume, puis cliquer sur Forward.
2. Définir Memory (RAM) sur au moins 4096 MB et CPU sur au moins 1, dans les limites des droits de licence et du dimensionnement. Sélectionner Customize configuration before install > Finish. Saisir un nom et cliquer sur Apply.
3. Pour la première interface réseau, sélectionner le réseau d’administration isolé comme Network source. L’exemple conservé utilise Device model > Hypervisor default ; vérifier que l’adaptateur obtenu est pris en charge, puis cliquer sur Apply. Ne pas choisir un bridge WAN/LAN partagé sans segmentation.
4. Sélectionner le disque principal, initialement affiché comme IDE Disk 1, puis Advanced options > Disk bus > VirtIO > Apply.
5. Sélectionner Add Hardware > Network, choisir le réseau distinct prévu, puis Device model > virtio > Finish.
6. Sélectionner Add Hardware > Storage > Select or create custom storage > Manage. Choisir AUXILIARY-DISK.qcow2 avec Choose volume, définir Disk bus > VirtIO, puis cliquer sur Finish.
7. Vérifier les deux disques, leurs bus et leurs tailles, ainsi que les affectations réseau, avant de cliquer sur Begin Installation. Sélectionner le pare-feu et ouvrir sa console avec Open, puis suivre la procédure commune de premier accès.

Proxmox VE : procédure pour un stockage de type répertoire

Cette procédure fondée sur des chemins de fichiers s’applique à un stockage de type répertoire adapté, et non à n’importe quel backend LVM, ZFS ou Ceph. Examiner d’abord /etc/pve/storage.cfg pour identifier l’ID du stockage, son backend et son chemin réels. Si votre backend ne peut pas utiliser ces chemins de fichiers QCOW2, arrêter et obtenir la procédure d’importation appropriée et prise en charge ; ne pas y recopier les exemples de stockage par répertoire.

1. Sélectionner le serveur et Create VM. Saisir Name, sélectionner Do not use any media, choisir les paramètres System, Hard Disk et CPU adaptés à l’environnement, puis définir Memory (MB) sur au moins 4096. Les valeurs par défaut de Machine, SCSI Controller et Cache sont propres à l’exemple, et non des exigences universelles.
2. Sélectionner le Bridge d’administration isolé. Laisser Start after created décoché, examiner la configuration et cliquer sur Finish. Noter le VMID et confirmer qu’il s’agit bien de la nouvelle VM de test inutilisée.
3. Ouvrir >_ Shell sur l’hôte avec les privilèges appropriés. Maintenir uniquement cette nouvelle VM à l’arrêt, conserver une copie de /etc/pve/qemu-server/<vmid>.conf et noter son affectation de disques existante. Ne jamais supprimer ni remplacer un disque de production. /var/lib/vz/images/108/ n’est qu’un exemple de répertoire pour le VMID 108 ; utiliser le chemin correspondant au stockage et au VMID que vous avez confirmés.
4. Transférer l’archive KVM réellement téléchargée dans ce répertoire et l’extraire, par exemple avec unzip ACTUAL_DOWNLOADED_ARCHIVE.zip après avoir remplacé le nom fictif par le nom réel du fichier. Les fichiers attendus sont PRIMARY-DISK.qcow2 et AUXILIARY-DISK.qcow2 ; un nom de fichier d’une ancienne version ne constitue pas une instruction de téléchargement actuelle.
5. Ouvrir /etc/pve/qemu-server/<vmid>.conf dans un éditeur de texte. Uniquement sur cette VM jetable à l’arrêt, remplacer l’affectation initiale de scsi0 et ajouter celle du disque auxiliaire. La syntaxe d’exemple conservée est :

scsi0: vmdisk:<vmid>/PRIMARY-DISK.qcow2,size=32G
scsi1: vmdisk:<vmid>/AUXILIARY-DISK.qcow2,size=80G

Remplacer vmdisk par l’ID confirmé du stockage de type répertoire et <vmid> par le VMID réel ; ces valeurs sont des paramètres fictifs, non des valeurs directement utilisables. Les indications size ne redimensionnent pas une image trop petite. Vérifier que les images réelles respectent les tailles minimales et qu’aucune affectation scsi1 existante n’est écrasée.

6. Dans Hardware, vérifier les deux emplacements de disque, les tailles et le disque principal de démarrage. Utiliser Add > Network device pour ajouter la seconde interface réseau sur le Bridge distinct choisi à cet effet. Sous Options, laisser QEMU Guest Agent désactivé. Vérifier à nouveau les affectations avant de cliquer sur Start et d’ouvrir la console.
7. Si la modification est incorrecte, maintenir la nouvelle VM éteinte et restaurer sa configuration sauvegardée après avoir revérifié l’identité du VMID et du stockage. Ne pas supprimer le fichier du disque d’origine lors de ce retour arrière. Cette annulation locale est une procédure de préproduction, pas une récupération en production testée. Ne suivre la procédure commune de premier accès qu’une fois les contrôles matériels corrigés et concluants.

Nutanix Prism Central

Prérequis : AOS 6.5.x ou une version LTS ultérieure, la version AHV fournie avec celle-ci, une version compatible de Prism Central (PC) et le cluster AHV enregistré dans PC. Les instructions de plateforme précisent d’utiliser la dernière version GA (LTS) de la Partner VA : GA signifie General Availability et LTS signifie Long-Term Support. Vérifier la version de l’appliance partenaire et la combinaison de plateformes réellement prises en charge ; une page d’aide SFOS 23 ne permet pas, à elle seule, d’identifier la dernière version GA. Confirmer les ressources CPU autorisées par la licence, au moins 4 GB de RAM, deux interfaces réseau et des disques de 32 GB/80 GB.

1. Extraire PRIMARY-DISK.qcow2 et AUXILIARY-DISK.qcow2 du paquet Virtual Installers: Firewall OS for KVM sur le poste d’administration.
2. Dans PC, ouvrir Virtual Infrastructure > Images > Add Image > Add File. Ajouter chaque fichier avec Image Type > Disk. Cliquer sur Next, sélectionner Placement Method et Select Clusters pour la cible, puis Save. Actualiser après le chargement et vérifier que les deux images sont disponibles.
3. Ouvrir Infrastructure > VMs > Create VM. Sous General Configuration, définir le nom et le fuseau horaire ; sous Compute Details, définir les ressources CPU autorisées et une RAM suffisante. Sous Disks, supprimer le CD-ROM par défaut uniquement sur cette nouvelle VM.
4. Sélectionner Add New Disk > Operation > Clone from Image Service > Bus Type > SCSI > Image > PRIMARY-DISK.qcow2 > Add. Répéter pour AUXILIARY-DISK.qcow2, qui servira de disque de journaux ; l’exemple auxiliaire conservé utilise également SCSI. Ne pas transposer ici les instructions de bus VirtIO de KVM.
5. Sous Network Adapters (NIC) > Add New NIC > VLAN Name, sélectionner le VLAN d’administration isolé et cliquer sur Add. Répéter pour le second réseau distinct prévu. L’option de connectivité DHCP décrite dans la source est facultative ; prévoir ensuite un adressage stable des interfaces. Sélectionner un VLAN ne définit pas en soi une adresse IP.
6. Sous VM Host Affinity > Set Affinity, sélectionner un hôte approuvé et cliquer sur Save, puis enregistrer la VM. Vérifier le message de réussite et contrôler les deux disques, leurs bus et leurs tailles, ainsi que les affectations réseau, avant le démarrage.
7. Démarrer la nouvelle VM et sélectionner Launch console. Suivre la procédure commune de premier accès.

Premier accès, validation et retour arrière sécurisé

Avant le premier démarrage, vérifier PortA et PortB par rapport aux réseaux d’administration, LAN et WAN. Des affectations inversées peuvent exposer WebAdmin directement à Internet. Uniquement dans l’environnement initial isolé, le compte et le mot de passe administrateur d’usine documentés sont admin / admin ; la console demande le mot de passe administrateur admin. Ouvrir https://172.16.16.16:4444 depuis le client d’administration isolé, par exemple 172.16.16.2/24. Examiner et accepter les conditions d’utilisation Sophos End User Terms of Use, puis cliquer sur Start setup pour l’enregistrement et la configuration initiale. Remplacer les identifiants d’usine pendant la configuration, avant toute exposition, puis suivre le guide de prise en main.

Ne pas modifier le mot de passe par défaut dans la CLI avant l’assistant : celui-ci ne démarrera plus ensuite. Si cela s’est déjà produit, terminer manuellement la configuration initiale ; ne pas réinitialiser un pare-feu configuré simplement pour retrouver l’assistant. La réinitialisation d’usine détruit la configuration et n’est une option délibérée que pour une nouvelle VM jetable, protégée et sans configuration à conserver.

Avant le basculement en production, vérifier la licence et le numéro de série, le démarrage normal dans la console, les deux disques et les rapports, les interfaces et les zones, ainsi que la sauvegarde SFOS prise en charge. Effectuer également un test négatif d’accès à WebAdmin depuis un réseau non autorisé.

Si WebAdmin est inaccessible, ne pas réinstaller immédiatement. Vérifier que le client se trouve directement sur le réseau de PortA, que la vNIC est connectée et que le groupe de ports ou le bridge correspond réellement au réseau d’administration isolé. Confirmer le démarrage complet dans la console et exclure un conflit d’adresses impliquant 172.16.16.16. PortA ne doit pas être connecté au WAN public. L’absence de rapports ou le mode fail-safe impose de vérifier l’affectation du disque de rapports, son bus et sa taille, les ressources CPU/RAM et les deux vNIC ; consigner la cause détectée avec le runbook du mode fail-safe avant de modifier les ressources.

Si un retour arrière est décidé avant la mise en production et qu’aucun trafic de production ne passe encore par la nouvelle VM, l’éteindre, annuler les routes de test et les passerelles temporaires, puis continuer à utiliser le pare-feu existant inchangé. Ces étapes concernent uniquement le retour arrière, et non une mise en production validée avec succès. Après la mise en production, la récupération nécessite une sauvegarde SFOS récente et une reconstruction documentée, et non un snapshot de l’hyperviseur ; utiliser la procédure de sauvegarde et de restauration.

Software Appliance sur du matériel personnalisé

La cible doit disposer d’une architecture x86-64, de Legacy BIOS, d’au moins 4 GB de RAM, de deux interfaces réseau et d’un HDD/SSD de 32 GB (64 GB recommandés). La clé USB doit avoir une capacité d’au moins 1 GB. Windows/macOS est le système du poste servant à écrire le support, et non un système d’exploitation conservé à côté de SFOS. Utiliser le téléchargement Software Installers: Firewall OS Software ISO for Intel Hardware, extraire l’archive et vérifier l’ISO SW ainsi que l’intégrité du transfert comme indiqué plus haut. Ne pas utiliser une image HW/XGS ou un paquet de disques virtuels.

⚠️ L’écriture du support efface entièrement le périphérique USB sélectionné. L’installation formate et repartitionne ensuite le disque du serveur cible, supprimant son ancien système d’exploitation et toutes ses données. Avant chacune de ces opérations, identifier précisément le périphérique par sa capacité et son identité, sauvegarder les données sur un support externe et vérifier une voie de restauration indépendante. Arrêter si la cible est ambiguë. Il n’existe aucun retour arrière automatique après l’installation ; la récupération nécessite les supports et données du système d’origine sauvegardés séparément, ou une sauvegarde SFOS compatible avec son mot de passe et la SSMK associée.

Windows : Win32 Disk Imager

1. Insérer la clé USB et identifier sa lettre de lecteur, sa capacité et son identité dans la gestion des disques Windows ; déconnecter les autres supports amovibles dans la mesure du possible. Se procurer Win32 Disk Imager et le démarrer sur le poste de travail.
2. Le sélecteur de fichiers filtre normalement les fichiers IMG. Remplacer le filtre par *.* et sélectionner le fichier Sophos SW .ISO extrait.
3. Sélectionner la destination USB confirmée, et non un disque système ou de données. Vérifier à nouveau le fichier et le lecteur sélectionnés par rapport à l’identité consignée, puis cliquer sur Write et confirmer l’avertissement d’effacement. Attendre la réussite de l’opération et éjecter le support en toute sécurité. Copier l’ISO comme un fichier ordinaire ne crée pas de support amorçable.

macOS : autre méthode native d’écriture du support

1. Utiliser Utilitaire de disque pour identifier la clé USB externe par sa capacité et son identité. Les anciennes instructions indiquent Partitions > Volume scheme: 1 partition > Format: Free Space > Apply ; ces commandes sont propres à certaines versions et peuvent ne pas exister dans votre version de macOS. Ne pas inventer d’équivalent ni formater un autre disque pour reproduire cette ancienne interface. La procédure d’écriture du support du guide de réinstallation constitue une autre méthode, en utilisant ici l’ISO SW plutôt que l’image matérielle de ce guide.
2. Dans Terminal, se placer dans le répertoire de l’ISO. Remplacer SOPHOS_ISO par le nom réel du fichier téléchargé avant d’exécuter :

hdiutil convert -format UDRW -o sf.img.dmg SOPHOS_ISO

3. Le fichier converti attendu est sf.img.dmg. Exécuter diskutil list, identifier à nouveau le disque USB externe entier et démonter ses volumes avant l’écriture brute (Unmount dans Utilitaire de disque, sans éjecter le périphérique). Arrêter si le périphérique prévu ne peut pas être identifié ou démonté.
4. La commande suivante est un modèle, et non une commande prête à être collée. Remplacer PATH_TO_USB par le chemin confirmé du périphérique entier, jamais par celui d’une partition ou par un numéro de disque supposé. Elle efface tout le périphérique :

dd if=./sf.img.dmg of=PATH_TO_USB bs=1m

Utiliser sudo uniquement si les permissions du périphérique l’exigent, après avoir revérifié la cible. Un chemin brut ajoute r au nom confirmé du périphérique (/dev/diskN devient /dev/rdiskN) ; N est un paramètre fictif, pas un numéro de disque à recopier. L’accès brut peut être plus rapide, mais ne rend pas l’opération plus sûre. Attendre le retour de l’invite de commande et la réussite de l’opération ; vider les écritures en attente avec sync, puis éjecter la clé USB en toute sécurité avant de la retirer. En cas d’erreur, arrêter plutôt que d’installer depuis un support dont l’écriture n’est pas vérifiée.

Installer et contrôler le serveur physique

1. Planifier une interruption de service, préserver le chemin passant par le pare-feu existant et les sauvegardes externes, puis vérifier Legacy BIOS, le démarrage USB et le disque d’installation exact. Déconnecter les disques de données non concernés dans la mesure du possible. Brancher un écran et un clavier locaux, ainsi qu’une console série appropriée si nécessaire.
2. Démarrer sur la clé USB préparée. Avant de saisir y et d’appuyer sur Entrée à la confirmation de l’installateur, revérifier l’identité du serveur et du disque, et confirmer que l’ancien système d’exploitation et toutes les données peuvent être perdus. Si la cible de l’installateur n’est pas claire, arrêter. Suivre les instructions jusqu’à la fin, retirer la clé USB et redémarrer ; le premier démarrage peut prendre quelques minutes. Ne pas appliquer à ce serveur générique les instructions concernant les LED XGS.
3. Vérifier les interfaces réseau détectées et identifier l’interface d’administration avant de connecter le client d’administration isolé à l’adresse 172.16.16.2/24. Confirmer le démarrage normal et utiliser https://172.16.16.16:4444, les conditions d’utilisation et Start setup comme décrit plus haut. Sécuriser les identifiants, terminer l’enregistrement et l’activation des licences, puis enregistrer une sauvegarde SFOS externe avant le basculement.
4. Si la clé USB ne démarre pas, vérifier qu’elle a été créée par écriture d’image et non par copie de fichier, contrôler l’identité de l’image SW ainsi que la sélection Legacy BIOS/démarrage USB. En cas d’interfaces réseau manquantes ou de mode fail-safe, consigner la cause indiquée dans la console et vérifier les minima ainsi que la compatibilité des pilotes avant de réinstaller. Si WebAdmin est inaccessible, vérifier l’identité de l’interface d’administration, le lien, l’adresse du client, le démarrage complet et les conflits d’adresses ; ne jamais connecter l’administration d’usine au WAN public pour contourner le problème. Utiliser le guide interne du mode fail-safe, le guide de prise en main et le guide de sauvegarde et de restauration pour décider de la suite.

Planifier l’exploitation et la récupération

Performances et dimensionnement

En ce qui concerne le matériel, les performances dépendent du modèle que vous choisissez. Pour les déploiements virtuels, logiciels et cloud, les performances dépendent davantage de la plate-forme.

Les éléments suivants sont particulièrement importants :

• les performances du processeur et la réservation des ressources CPU,
• la RAM,
• la latence du stockage,
• les cartes réseau virtuelles,
• le chemin réseau de l’hyperviseur ou du cloud,
• le nombre de sessions,
• TLS Inspection,
• IPS,
• le débit VPN,
• la journalisation et les rapports.

Les valeurs des fiches techniques doivent donc toujours être lues dans leur contexte. Le débit du pare-feu sans inspection de sécurité n’est pas équivalent aux performances de protection contre les menaces, de TLS Inspection ou d’IPsec VPN en charge réelle. Le guide d’interprétation des données de performances Sophos Firewall explique ces différences.

HA et récupération

La haute disponibilité diffère considérablement selon la plateforme.

Avec des appliances matérielles, la HA est généralement plus simple à appréhender : deux appliances, un lien HA, des interfaces définies et un équipement de remplacement clairement identifié. Les déploiements virtuels et cloud soulèvent des questions supplémentaires :

• Les nœuds HA s’exécutent-ils sur différents hôtes ?
• Le stockage, le réseau et l’hyperviseur sont-ils vraiment redondants ?
• Les adresses MAC virtuelles et les règles vSwitch sont-elles compatibles ?
• Existe-t-il des dépendances au routage cloud ou à l’équilibrage de charge ?
• Les sauvegardes et restaurations fonctionnent-elles sur une nouvelle instance ?
• La panne d’un hôte ou d’une zone de disponibilité a-t-elle été testée ?

Les principes des différentes variantes HA sont présentés dans le guide Configurer la haute disponibilité (HA) de Sophos Firewall. Pour préparer la récupération, le guide Créer ou restaurer une sauvegarde Sophos Firewall est une lecture indispensable.

Licences et assistance

Vérifier les licences avant tout déploiement ou changement de ressources. Les anciennes instructions d’installation des plateformes limitent à la fois les vCPU et la vRAM aux droits de la licence achetée ; l’article lié ci-dessous décrit, pour les offres commerciales virtuelles, logicielles et cloud BYOL, un passage à une licence par cœurs CPU sans l’ancien plafond de RAM, prenant effet le 1er mars 2025. Cette description ne prouve pas que toutes les références commerciales (SKU), les anciens droits ou les licences Home présentent des conditions identiques. Avant d’allouer des ressources, confirmer la référence achetée et les droits en cœurs CPU, le numéro de série, l’abonnement et le support, ainsi que l’état réel de la licence de l’instance dans le portail de licences. Si les droits ne sont pas clairs, arrêter et les faire préciser par le fournisseur de la licence. Ne pas appliquer ce changement commercial aux licences Home ni déduire de cet article que les ressources sont illimitées. Le minimum d’installation de 4 GB et le dimensionnement de la RAM, du stockage et des interfaces réseau pour la production restent des exigences techniques, quel que soit le plafond de licence applicable.

Le guide Licence de base Sophos Firewall présente les principes de la licence de base. Le changement commercial décrit ci-dessus est détaillé dans l’article Sophos Firewall VM et SW : seuls les cœurs CPU comptent, suppression de la limite de RAM.

Points importants pour l’exploitation :

• Documenter la licence et l’état du support.
• Consigner clairement le numéro de série et le statut d’enregistrement.
• Vérifier les licences HA avant de créer le cluster.
• Vérifier l’éligibilité aux mises à jour du firmware et au support avant les mises à niveau.
• Connaître le processus RMA ou de récupération propre à la plateforme choisie.

Avant une mise à niveau majeure, consulter également le guide Vérifications avant la mise à niveau de Sophos Firewall vers SFOS 22, car la prise en charge de la plateforme, l’espace de stockage, les sauvegardes, la HA et les anciennes configurations VPN peuvent influer sur cette opération.

Pour un cluster HA active-passive sur des appliances virtuelles ou logicielles, seul le nœud Primary doit disposer de toutes les licences requises, y compris la Base Firewall License. En active-active, chaque nœud doit avoir sa propre Base Firewall License et les mêmes licences de protection supplémentaires ; leurs dates d’expiration peuvent différer. Cette question doit être résolue avant de créer le cluster, pas lors de l’analyse du premier basculement.

Matrice de décision

• Site traditionnel avec WAN, LAN et DMZ : Plutôt une appliance matérielle. Une appliance virtuelle ne convient qu’avec une bonne stratégie de virtualisation.
• Centre de données avec une équipe déjà dédiée aux hyperviseurs : Une appliance matérielle reste possible ; une appliance virtuelle est souvent pertinente.
• Charges de travail cloud dans AWS ou Azure : Plutôt une appliance virtuelle ou un déploiement cloud, et non une appliance matérielle classique.
• Simplicité du support et du processus RMA importante : Plutôt une appliance matérielle. Avec une appliance virtuelle ou un déploiement cloud, beaucoup dépend de l’équipe plateforme.
• Nombreux ports physiques requis : Plutôt une appliance matérielle. Une appliance virtuelle exige une conception rigoureuse des interfaces réseau et des vSwitch.
• Mise à l’échelle dynamique et Infrastructure as Code : Plutôt une appliance virtuelle ou un déploiement cloud.
• Petite équipe informatique sans expertise des hyperviseurs : Plutôt une appliance matérielle ; planifier soigneusement tout pare-feu virtuel.
• Architecture multi-locataire ou segmentation dans le centre de données : Une appliance matérielle reste possible ; une appliance virtuelle est souvent pertinente.

Erreurs courantes

• L’exécution d’un pare-feu virtuel sur un hôte dont les ressources sont surallouées.
• L’absence de séparation claire entre WAN, LAN et administration sur l’hyperviseur.
• Le choix du matériel en fonction du prix plutôt que du dimensionnement de capacité nécessaire.
• Le déploiement d’un pare-feu cloud avant d’avoir achevé la conception du routage.
• La planification de la HA sans tests de panne d’hôte, de stockage ou de ressources cloud.
• La création de sauvegardes sans mise en pratique de la restauration.
• La vérification de la licence et du support uniquement au moment d’une mise à niveau.
• L’ajout de TLS Inspection ou d’IPS sans réserve de performances.
• L’implication des responsables de la plateforme, du réseau et du pare-feu seulement après un incident.

Liste de contrôle

• Lieu de déploiement clairement défini : site physique, centre de données ou cloud.
• Trafic, bande passante et fonctions de sécurité recensés pour le dimensionnement.
• Variantes matérielles, virtuelles, logicielles ou cloud délibérément choisies.
• Responsabilité du pare-feu, de l’hyperviseur, du cloud et du réseau documentée.
• Architecture HA et stratégie de récupération vérifiées.
• Processus de sauvegarde et de restauration testé ou planifié.
• Licence, support et enregistrement clarifiés.
• Surveillance du pare-feu et de la plate-forme sous-jacente disponible.
• Possibilité de mise à niveau et prise en charge de la plateforme vérifiées.
• Personne responsable de la plateforme, du réseau, du pare-feu, de la sauvegarde et de la restauration nommée.

FAQ