Déployer et exploiter Sophos Firewall sur AWS

Sophos Firewall 22 fonctionne dans AWS comme appliance EC2 virtuelle inline dans une VPC. Il faut d’abord définir le trafic à inspecter. Une firewall standalone peut contrôler le trafic entrant et sortant. Le template Sophos Auto Scaling est en revanche un design PAYG spécialisé dans le trafic DNAT ou WAF entrant.

Le parcours sûr consiste à choisir l’architecture et la licence, consigner le plan IP et de routage, lancer le template Marketplace approprié, limiter l’administration à une IP source fixe, valider un flux de bout en bout, puis seulement ouvrir d’autres services.

⚠️ Les AWS Security Groups restent une seconde couche de pare-feu. Une règle SFOS permissive ne sert à rien si une Security Group, une NACL ou une Route Table bloque le chemin. Inversement, il ne faut pas associer un port AWS ouvert à une règle Sophos trop large. Les Security Groups sont stateful et les Network ACL stateless : une NACL personnalisée doit donc autoriser l’aller et le retour.

Choisir standalone ou Auto Scaling

AWS ne prend pas en charge le HA natif de Sophos Firewall. Auto Scaling et Network Load Balancing forment un autre design cloud, sans synchronisation HA SFOS. Un design standalone doit donc inclure une procédure de reconstruction et une fenêtre d’interruption acceptée.

La liste actuelle des types EC2 compatibles figure dans la vue d’ensemble Sophos AWS. Avec BYOL, il ne suffit pas de choisir la plus grande instance : ses ressources doivent correspondre à la licence virtuelle achetée. Avec PAYG, Sophos indique que la facturation logicielle ne s’arrête qu’après suppression de toutes les instances firewall concernées du compte AWS.

Préparer le déploiement standalone

Consigner avant le lancement :

• compte AWS, région, Availability Zone et offre BYOL ou PAYG ;
• VPC nouvelle ou existante et CIDR public et privé sans chevauchement ;
• source d’administration fixe, par exemple 198.51.100.27/32, plutôt qu’un accès mondial ;
• Elastic IP, noms DNS et services entrants requis ;
• réseaux cibles privés, route par défaut et chemin retour de chaque flux de test ;
• type EC2 pris en charge, limite de licence, responsable des coûts et tags ;
• procédures de backup, firmware et reconstruction.

198.51.100.27/32 est une adresse de documentation à remplacer par l’adresse publique réelle de l’administrateur. Si elle change souvent, un VPN ou un jump host contrôlé est plus sûr qu’une large exposition de TCP 4444.

Dans une VPC existante, ne pas choisir les subnets uniquement par leur nom. Leurs Route Tables doivent correspondre au sens prévu. AWS explique l’insertion d’une appliance dans ses exemples de routage middlebox. Le Source/Destination Check doit également être désactivé sur les ENI de la firewall qui transfèrent du trafic tiers. Laisser CloudFormation régler ces détails, puis les vérifier sans les modifier à l’aveugle.

Déployer standalone avec CloudFormation

1. Ouvrir l’offre Sophos Firewall BYOL ou PAYG dans AWS Marketplace, cliquer sur View purchase options et accepter les conditions.
2. Sous Continue to Configuration, choisir l’option de fulfillment, la version logicielle SFOS actuelle et la région.
3. Sous Continue to Launch, choisir Launch CloudFormation et ouvrir le template dans la console AWS CloudFormation.
4. Saisir un Stack name unique. Pour une nouvelle VPC, vérifier que les plages ne chevauchent aucune VPC, aucun VPN ni réseau local existant.
5. Pour une VPC existante, associer VPC ID, un Public Subnet, un Private Subnet et une Elastic IP nouvelle ou inutilisée. Laisser Network Address Prefix for new VPC inchangé comme l’indique Sophos.
6. Comparer AMI et taille EC2 à la liste Sophos actuelle et, pour BYOL, à la licence. Ne pas stocker les secrets dans des tickets, captures ou fichiers de paramètres lisibles publiquement.
7. Examiner les ressources IAM demandées. Ensuite seulement, confirmer I acknowledge that AWS CloudFormation might create IAM resources et cliquer sur Submit.
8. Attendre CREATE_COMPLETE. Lire l’Elastic IP sous Outputs, puis contrôler les deux status checks et les ENI attendues dans la console EC2.
9. Ouvrir WebAdmin depuis la source autorisée sur https://<EIP>:4444. Ne contourner l’avertissement du certificat local initial qu’après contrôle de l’IP cible, puis accepter les conditions et terminer l’enregistrement et le basic setup.

Sophos décrit la séquence complète pour la version dans Deploy Sophos Firewall on AWS. Les paramètres Marketplace peuvent évoluer : comparer les champs avec cette page et le template réellement ouvert avant chaque mise en production.

Ouvrir conjointement les règles AWS et SFOS

Le template Sophos active initialement uniquement WebAdmin et SSH. IPsec, SSL VPN, RED, WAF, User Portal et les applications publiées nécessitent des règles AWS correspondantes. RED utilise par exemple TCP 3410.

Pour chaque ouverture, documenter une fois protocole, port destination et source, mais les mettre en œuvre séparément :

1. La Security Group n’autorise que la source requise vers le port requis de la bonne ENI.
2. Une NACL personnalisée autorise la requête et le retour. AWS explique la différence dans Security Groups et Network ACLs.
3. La Route Table fait passer le trafic par la firewall et fournit un retour valide.
4. La règle firewall SFOS et, si nécessaire, la règle NAT utilisent des zones, hôtes et services précis, journalisent le trafic et appliquent les Security Profiles adaptés.

Ne jamais ouvrir SSH ou WebAdmin à 0.0.0.0/0 par précaution. Un accès AWS étroit ne remplace pas une règle SFOS précise et explicite.

Construire Auto Scaling pour le trafic entrant

Auto Scaling nécessite un compte AWS, l’offre Sophos Cloud Firewall (PAYG) et des identifiants API Sophos Central. Dans Central, aller dans My products > General settings > API credentials management et créer une credential avec le rôle Service principal firewall. Traiter Client ID et Client secret comme un mot de passe.

Choisir Sophos Auto Scaling Firewall for AWS comme option de fulfillment. Le template exige deux Availability Zones différentes. Dans une VPC existante, indiquer deux Public Subnets et un Private Subnet ; Sophos exige Auto-assign public IPv4 address sur les deux subnets publics.

Examiner particulièrement :

• Trusted Network CIDR : IP publique d’administration en /32, jamais 0.0.0.0/0 ;
• Public Network CIDR : l’exemple Sophos commence par 0.0.0.0/0, ouvrant les ports hors management à Internet. Avanet recommande de saisir les sources connues ou de réduire immédiatement cette valeur ;
• Minimum capacity : plus petit nombre de workers à maintenir ;
• Starting capacity : workers lancés au départ. Dans son exemple, Sophos recommande la valeur Maximum capacity pour enregistrer tous les workers ensemble ;
• Maximum capacity : plafond strict de workers et de coûts ;
• Warm Pool Refresh Period : intervalle de démarrage des instances arrêtées pour synchroniser la policy Central ; le défaut documenté est de cinq jours ;
• Use CloudWatch : envoie les logs firewall à CloudWatch Logs.

Après CREATE_COMPLETE, ouvrir My products > Firewall management > Firewalls et confirmer que le groupe automatique contient tous les workers PAYG attendus et approuvés. Modifier seulement ensuite capacity ou scaling policy. Les paramètres actuels figurent dans Sophos Firewall with AWS Auto Scaling.

DNAT derrière le Network Load Balancer

Pour un service publié, un listener TCP du NLB transmet à une Target Group de workers. Dans la policy de groupe Sophos Central, créer les plages des WAN Subnets des deux zones, l’hôte interne et le service du port publié. Ne pas inclure la première adresse IP de chaque subnet AWS dans la plage.

Dans ce design single-arm, la règle firewall correspond de WAN à WAN sur les plages et le service exact. DNAT traduit vers le serveur interne et utilise MASQ comme translated source afin que le retour traverse le même worker. Associer ensuite Target Group, Auto Scaling Group et listener NLB. Sophos montre la séquence dans le DNAT use case.

L’exemple officiel utilise RDP, mais une publication RDP directe n’est pas recommandée. Préférer VPN ou ZTNA. Si DNAT est indispensable, limiter les sources dans NLB, AWS et SFOS, activer IPS et logging et effectuer un test négatif.

Valider un flux couche par couche

Noter un flux initial, par exemple 198.51.100.27:55000 -> NLB-DNS:443 -> App-Server:443. Le port source est seulement un exemple de port client éphémère. Contrôler dans cet ordre :

1. DNS et listener NLB pointent vers la cible attendue et la Target Group indique les workers attendus healthy.
2. Security Groups et NACL autorisent exactement l’aller et le retour.
3. Route Tables et ENI font passer le trafic par l’appliance ; Source/Destination Check est désactivé sur les interfaces de transit.
4. SFOS Log Viewer affiche la Rule ID attendue. Pour DNAT, destinations originale et traduite ainsi que le retour sont corrects.
5. Le test autorisé atteint l’application et un test depuis une source interdite reste bloqué.

Sans log SFOS, examiner ce qui précède la firewall : DNS, listener, Target Health, Security Group, NACL et route. Pour un drop avec une Rule ID inattendue, corriger zones, objets réseau, service et ordre. Si l’aller fonctionne sans réponse, contrôler Route Table, NACL, default gateway du serveur et, avec Auto Scaling, MASQ.

Exploiter et restaurer

Standalone et Auto Scaling nécessitent des runbooks différents. Pour standalone, documenter un backup SFOS et une restauration testée, le processus firmware, les paramètres CloudFormation et un exercice de reconstruction. Un snapshot EC2 ne remplace pas un backup SFOS exporté.

Les workers Auto Scaling sont éphémères. Avec CloudWatch, leurs logs apparaissent sous /sophos/xg/ ; configurer explicitement rétention, chiffrement, accès et coûts. Les instances EC2 terminées restent selon Sophos dans le groupe Central et doivent y être supprimées manuellement. Le Warm Pool ne remplace pas la vérification que chaque worker actif a reçu la policy actuelle.

Le dossier d’exploitation couvre tags de responsabilité et de coûts, alarmes budgétaires, licence, rotation des secrets, rétention CloudWatch, nettoyage Central, approbation firmware, tests de changement et reprise. Répéter le test positif et négatif après toute modification de template, routage ou policy.