Déployer et router Sophos Firewall sur Azure

Sophos Firewall peut être déployé depuis Azure Marketplace comme appliance unique ou avec un modèle Load Balancer et deux firewalls. Sophos appelle le second design active-active, mais ce n’est pas un cluster HA SFOS natif. Configuration, sessions et état ne sont pas synchronisés comme entre deux appliances HA.

⚠️ Le routage Azure fait partie de la configuration firewall. Une règle SFOS correcte ne suffit pas si une User Defined Route, une Network Security Group ou le retour du Load Balancer manque. Chaque ouverture est validée sur le trajet aller-retour complet.

Choisir le modèle et la licence

L’infrastructure Azure et le logiciel Sophos sont facturés séparément. PAYG est horaire, sans engagement minimal dans le modèle documenté, et inclut Xstream ; ni abonnements individuels ni Enhanced Plus Support ne peuvent s’y ajouter. Vérifier le pays de facturation parmi les pays de reversement Microsoft et l’offre réelle ; si PAYG est indisponible, choisir BYOL. Acheté auprès d’un revendeur agréé, BYOL permet de choisir packs, abonnements individuels (Network Protection, Web Protection, Zero-Day Protection) et support, dont Enhanced Plus Support. Les durées documentées sont un, deux ou trois ans : confirmer offre et droits, sans promesse de prix ou de support. Arrêter le logiciel ne supprime pas les ressources Azure facturables.

Pour standalone, Sophos recommande au moins Standard_F2s_v2, deux vCPU, 4 GB de RAM et au moins deux NIC. La taille réelle dépend aussi du débit, des protections activées et des quotas Azure. L’IP publique utilise la Standard SKU avec attribution statique. La Basic SKU est retirée et ne convient pas aux nouveaux déploiements.

Déployer standalone depuis Marketplace

Créer et sécuriser l’appliance

1. Sélectionner Sophos Firewall dans Azure Marketplace et choisir BYOL ou PAYG.
2. Définir Resource Group, région et taille. VNet, subnets et réseaux distants ne se chevauchent pas.
3. Associer PortA au LAN et PortB au WAN. N’ouvrir les NSG qu’aux sources d’administration requises.
4. Terminer le déploiement et ouvrir WebAdmin sur https://<dns-name>:4444.
5. Terminer de façon contrôlée assistant, enregistrement, licence et firmware.
6. Définir l’adresse privée de la NIC LAN sur Static selon la procédure avec arrêt de la VM décrite ci-dessous. Ajouter à chaque subnet de workloads une UDR 0.0.0.0/0, Virtual appliance, avec cette IP LAN comme Next Hop.
7. Tester IP Forwarding, NSG, règles SFOS et retour avec un client défini.

La route UDR par défaut force le trafic Internet du subnet de workloads associé à travers le firewall ; les routes Azure plus spécifiques restent prioritaires. Sans cette UDR, Azure utilise son chemin par défaut. Une connexion route-based à Azure VPN Gateway utilise aussi l’interface XFRM avec routes statiques, SD-WAN ou BGP.

Préparer le plan d’adressage

Pour un nouveau déploiement, créer d’abord l’IP publique sous Public IP addresses > Create avec IP version: IPv4, SKU: Standard, Availability zone: 1, Tier: Regional, IP address assignment: Static et Routing preference: Microsoft network. Définir un DNS name label unique et choisir Domain name label scope: None. Sophos indique aussi DDoS protection > Protection type: Network pour cette procédure. Cette option nécessite un plan Azure DDoS adapté et peut entraîner des coûts supplémentaires; valider donc le plan avec le responsable Azure avant la création. Sélectionner ensuite l’adresse dans Public IP name. Availability zone: 1 est le choix de l’exemple documenté. La limitation à une seule zone de disponibilité est distincte : elle ne démontre ni prise en charge exclusive de la zone 1, ni validation d’autres zones ou d’une architecture multizone. L’ancienne option Basic dynamique n’est plus adaptée depuis son retrait par Azure.

Un plan transférable utilise VNet 10.20.0.0/16, LAN 10.20.10.0/24 sur PortA, WAN 10.20.20.0/24 sur PortB et 10.20.10.4 comme IP LAN statique. Ces valeurs RFC 1918 sont remplacées par des plages libres, sans chevauchement avec peering, VPN ou on-premises.

Créer l’UDR LAN avec les champs Azure exacts

Sophos demande d’arrêter la VM avant le passage de l’IP LAN en statique: Virtual machines > > Stop, puis NIC LAN, Settings > IP configurations > ipconfig, Allocation: Static, conserver l’IP LAN actuelle ou saisir l’adresse réservée, puis enregistrer. Après redémarrage, créer la table sous Route tables > Create. Dans Subnets > Associate, associer chaque subnet de clients ou de workloads dont le trafic doit traverser l’appliance. Si les clients se trouvent directement dans le subnet LAN de PortA, associer ce subnet LAN, comme dans l’exemple de base Sophos. Ne pas associer le subnet WAN du firewall. Dans Routes > Add, saisir Route name: default-via-sfos, Destination type: IP Addresses, Destination IP addresses/CIDR ranges: 0.0.0.0/0, Next hop type: Virtual appliance et Next hop address: 10.20.10.4. Vérifier Enable IP forwarding sur les deux NIC. Ne conserver Propagate gateway routes: Yes que si cela correspond au design VPN/ExpressRoute. Créer enfin une règle LAN vers WAN restrictive et journalisée sous Rules and policies > Firewall rules.

Exploiter active-active avec Load Balancer

Le modèle Sophos crée deux firewalls et un Standard Load Balancer externe et interne avec HA Ports. Il impose un VNet /16 et des subnets LAN et WAN /24; Sophos demande de consulter son interlocuteur avant toute autre taille de subnet.

Les health probes atteignent WebAdmin sur 4444 et le proxy sur 3128. Les probes internes dépendent aussi de routes spéciales vers l’adresse de plateforme 168.63.129.16, injectées dans la table de routage du noyau par l’Automation Runbook. Ces routes ne persistent pas après une mise à niveau firmware; le runbook fourni est alors relancé et contrôlé.

Pendant le déploiement, Trusted network doit temporairement valoir * pour permettre l’accès du Azure Automation Runbook depuis des IP Azure publiques. Dès son succès, restreindre la NSG aux CIDR admin documentés. La première firewall utilise WebAdmin 4444 et SSH 2222, la seconde 4445 et 2223. Les deux appliances sont enregistrées séparément et reçoivent les mêmes règles firewall, NAT et routing.

Configurer les probes et l’egress

Sur les deux firewalls, créer les gateways sous Routing > Gateways et les routes de probe sous Routing > SD-WAN routes; la route externe reste au-dessus de l’interne. L’UDR 0.0.0.0/0 des workloads utilise Next hop type: Virtual appliance et l’IP frontend du Load Balancer interne. Les probes TCP 4444 et 3128 apparaissent dans l’appliance avec la source 168.63.129.16. Si les ports changent, les probes interne et externe doivent rester distinctes. Dans la NSG, autoriser leur chemin avec le Source Service Tag AzureLoadBalancer; les listeners SFOS et les routes spéciales Sophos doivent également correspondre. Ni le Service Tag ni l’adresse de plateforme ne constituent une source Internet généralement fiable. Vérifier les deux backends sous Load balancer > Monitoring > Insights ou Health Probe Status; une probe saine ne valide pas l’application ni son retour.

Contrôler le déploiement du template

Ouvrir la ressource de déploiement active-active, relever et vérifier sa révision, puis Deploy to Azure. Avant Next > Create, contrôler :

• Subscription, Resource group, Region, Location ; disponibilité des Automation accounts dans cette souscription/région.
• Base URL de la révision vérifiée, VM name, Admin password conservé en lieu sûr, Image SKU (BYOL/PAYG-new), VM size avec au moins deux NIC.
• Net new or existing, Net RG, Net name, Net prefix (/16), WAN name/prefix, LAN name/prefix (/24), Loadbalancer Int IP libre dans le LAN.
• Choix nouveau/existant, groupes et noms de Public IP, Storage, Network security group, Availability set, Automation account ; Public IP DNS, Storage type, NIC WAN, NIC LAN, Number of instances: 2. Vérifier ressources existantes et label DNS unique.
• Sauvegarder les règles NSG initiales et la durée autorisée de Trusted network: *. Restreindre à nouveau l’administration même si l’automatisation échoue ; sans exception temporaire approuvée, arrêter plutôt que laisser l’administration publique sans restriction.

Inventorier ensuite NIC/sous-réseaux, gateways, frontends LB, probes et ports d’administration réels ; ne pas transposer l’exemple standalone.

Gateways et routes de probes sur les deux appliances

Créer et sauvegarder sous Routing > Gateways > Add :

L’exemple conservé utilise 10.54.11.1/10.54.22.1 et WAN pour les deux gateways, puis lie les routes interne/externe à #PortA/#PortB. Ce mapping inhabituel est propre au déploiement. Vérifier NIC, interfaces SFOS et accessibilité des sous-réseaux ; en cas de contradiction, arrêter et résoudre avec le responsable, sans copier les IP ni inventer un mapping universel.

Sous Routing > SD-WAN routes > Add, créer l’interne puis l’externe, chacune à Top :

Vérifier objets et définition du service sur le flux réel : HTTP ne signifie pas remplacer les probes TCP 4444/3128 par 80. Ne pas généraliser le service interne non précisé en route large ; source et destination restent restreintes. Sauvegarder, garder l’externe au-dessus de l’interne et répéter le mapping vérifié sur la seconde appliance. Contrôler Load balancers > Monitoring > Metrics > Health probe status, agrégation Avg, filtre Backend IP address, pour chaque backend/LB, puis tester sortie et retour réels.

Récupérer les routes injectées après firmware

Prévoir une maintenance : le runbook documenté redémarre la VM et peut couper les sessions. Exporter les backups SFOS, sauvegarder runbook/NSG et vérifier l’autre backend avant d’intervenir sur une VM. Si les deux sont défaillants, prévoir une interruption plutôt que promettre une récupération sans coupure.

1. Network security groups > [NSG firewall] > Inbound security rules > allow_ssh : identifier l’accès du runner au port SSH réel. La source utilise Source: IP address, Source IP addresses/CIDR ranges: 0.0.0.0/0, exception temporaire à haut risque, jamais une recommandation permanente. Préférer un chemin vérifié plus restreint ; sinon exiger accord explicite, délai court et seul mapping SSH nécessaire. Ne pas deviner un CIDR Azure ou ouvrir d’autres ports.
2. Groupe de ressources > Automation account > Runbooks > [runbook déployé] > Edit > Edit in portal. La révision conservée demande de commenter les lignes 20–24 : identifier le bloc prévu dans le script réel et sauvegarder l’original ; ne pas transposer les numéros. Si le rôle est incertain, arrêter. Save > Publish, vérifier le diff, Start.
3. Saisir les paramètres de cette VM :

4. Vérifier sortie, erreurs et statut du job. Completed ne confirme que sa fin : attendre redémarrage/accès, vérifier route 168.63.129.16, deux probes et application/sortie réelle. Ensuite seulement récupérer la seconde VM avec ses propres valeurs.
5. Restaurer immédiatement les restrictions NSG relevées, même en cas d’échec, et vérifier l’accès effectif. Garder le backend sain, conserver les erreurs, restaurer le script si l’édition était erronée et escalader avant relance ou intervention sur l’autre. Completed ne prouve ni santé à 100 % ni Internet.

DNAT et chemin retour

Le Load Balancer externe choisit un firewall. Les HA Ports transportent les flux NVA sur tous les protocoles et ports, mais ne remplacent pas une publication propre au service. Pour le service TCP publié, créer sur le Load Balancer externe une health probe adaptée et une règle de Load Balancing qui utilise cette probe. La règle NAT SFOS traduit ensuite vers le serveur. Dans Rules and policies > NAT rules, Translated source (SNAT): MASQ force le serveur à répondre à l’IP LAN de ce même firewall. Sans MASQ, le retour peut passer par l’autre firewall et casser la session.

La publication directe de RDP n’est pas recommandée. VPN ou ZTNA sont préférables. Si le service doit être publié, source, service et destination sont limités dans Azure et SFOS, logging et IPS sont activés et un test négatif est effectué.

Valider, dépanner et revenir en arrière

Contrôles de validation

1. Dans Effective routes d’une VM de test, vérifier que 0.0.0.0/0 pointe vers l’IP LAN SFOS ou, en active-active, vers l’IP du Load Balancer interne.
2. Tester DNS, HTTPS et l’application, puis confirmer Rule ID, source et destination dans Log viewer > Firewall. Pour un service publié, effectuer un test positif autorisé et un test négatif non autorisé. Vérifier séparément la cible DNAT et le chemin retour du serveur.
3. En active-active, contrôler Health Probe Status et Backend Pool. Uniquement en fenêtre de maintenance, retirer un firewall, tester les nouvelles connexions via l’autre, puis rétablir un backend sain avant le second passage. Les sessions existantes ne sont pas synchronisées et peuvent être interrompues.

Erreurs typiques

Sans egress, vérifier dans l’ordre Effective Routes, association au subnet de workloads, IP LAN statique, IP forwarding, NSG et Rule ID SFOS. Pour une probe unhealthy, contrôler protocole/port TCP, listener, NSG et routes SD-WAN vers 168.63.129.16. Après un firmware upgrade, les routes injectées ne persistent pas: relancer le runbook Sophos pour les deux VM, vérifier les probes et rétablir immédiatement les CIDR admin dans la NSG SSH. Pour un DNAT intermittent, comparer les règles des deux appliances, MASQ, Backend Pool et route retour du serveur.

Avant un retour arrière egress, noter le Next Hop précédemment approuvé. Réassocier l’ancienne Route Table ou isoler le subnet de workloads pendant le changement. Une simple dissociation peut activer la route système Azure 0.0.0.0/0 -> Internet et contourner le firewall; elle n’est permise que si ce chemin a été vérifié et accepté. Ne supprimer l’UDR et les règles temporaires qu’après validation du retour rétabli. Pour DNAT, désactiver d’abord la règle du Load Balancer externe. Les snapshots Azure ne remplacent pas un backup SFOS exporté.

Poursuivre avec le runbook interne Azure VPN Gateway ou la configuration Entra Domain Services du runbook AD.