Contrôler les Advanced Firewall Settings de Sophos Firewall

Les Advanced Firewall Settings de Sophos Firewall ne constituent pas une collection d’options de confort sans conséquence. De nombreuses valeurs agissent globalement sur l’inspection des paquets, l’état des connexions ou les délais d’expiration. Une modification peut donc toucher simultanément plusieurs règles de pare-feu, VPN, applications et chemins utilisateurs.

Le point de départ sûr est toujours en lecture seule : show advanced-firewall affiche l’état actuel. Un seul paramètre est modifié pendant une fenêtre de maintenance, uniquement lorsqu’un problème reproductible correspond précisément à ce paramètre. L’ancienne valeur, une comparaison de contrôle et le retour arrière doivent être documentés avant de saisir la commande set.

⚠️ Ne pas reprendre les Advanced Firewall Settings depuis une liste de tuning. Les valeurs par défaut documentées conviennent à la plupart des environnements. Les protections globales telles que strict-policy ou tcp-seq-checking ne doivent pas être désactivées par supposition, et les délais ne doivent pas être augmentés sans besoin applicatif mesuré.

Procédure rapide et sûre

1. Relever le symptôme exact dans Log Viewer, Packet Capture et l’application concernée, avec heure, source, destination, service et direction.
2. Enregistrer l’état actuel depuis la Device Console avec show advanced-firewall.
3. Vérifier si un article spécialisé traite déjà le paramètre et si la règle de pare-feu, NAT, le routage, la MTU ou le pair constitue une cause plus probable.
4. Modifier une seule valeur globale et préparer l’ancienne valeur sous forme de commande de retour arrière prête à l’emploi.
5. Retester le flux concerné et au moins un flux de contrôle sans rapport.
6. Si la modification n’apporte pas d’amélioration claire ou crée de nouveaux symptômes, restaurer immédiatement la valeur initiale documentée.

Une connexion verte ou un seul ping réussi ne suffit pas comme validation. Selon la modification, Rule ID, NAT Rule ID, le comportement TCP ou UDP, le flux de paquets, la fonction applicative et le sens retour doivent également être corrects. La procédure est décrite dans Tester correctement une règle Sophos Firewall.

Lire l’état et comprendre l’effet

Les commandes s’exécutent dans la Device Console, et non dans l’Advanced Shell. Après la connexion SSH, sélectionner 4. Device Console dans le menu de la console. L’accès, la vérification de la clé d’hôte et une autorisation d’administration ciblée sont expliqués dans Dépannage CLI de Sophos Firewall.

show advanced-firewall

La sortie constitue une référence, pas un Health Check. Une valeur peut s’afficher correctement tout en étant inadaptée à une application. À l’inverse, une valeur différente de la valeur par défaut ne prouve pas à elle seule une panne. Il faut savoir quand et pourquoi elle a été définie et quel comportement mesurable elle modifie.

Effet global plutôt que par règle de pare-feu

set advanced-firewall ne modifie pas une règle de pare-feu individuelle. Les paramètres se situent sous ou à côté de l’évaluation normale des politiques. Un délai UDP augmenté globalement ne s’applique donc pas uniquement à une règle VoIP. De même, tcp-seq-checking off ne limite pas l’assouplissement à un serveur.

Quatre éléments sont documentés avant chaque modification : la valeur actuelle, le flux de test précis, l’effet attendu et la commande de restauration. Sans test positif et négatif ciblé, la modification n’est pas prête pour la production.

Sécuriser l’accès et l’inspection des paquets

Bloquer globalement WebAdmin depuis le WAN

restrict-admin-console-wan-access est un interrupteur global de protection peu granulaire. Avec enable, WebAdmin est désactivé pour toutes les sources WAN ; Sophos documente enable comme valeur par défaut. La formulation apparemment inversée est importante : enable active la restriction, et non l’accès WAN.

set advanced-firewall restrict-admin-console-wan-access enable

Cette protection ne doit pas être simplement ouverte avec disable pour une source d’administration fixe. Vérifier d’abord si un VPN de gestion, Sophos Central ou une Local Service ACL Exception ciblée suffit. La conception sûre est décrite dans Device Access et Local Service ACL.

ICMP, fragments et extensions IPv6

icmp-error-message contrôle les messages d’erreur ICMP tels que Network, Host ou Port Unreachable. La valeur par défaut documentée est allow. Un deny général peut masquer des signaux d’erreur et de Path MTU importants et compliquer le diagnostic.

fragmented-traffic autorise ou refuse le trafic IP fragmenté ; la valeur par défaut est allow. La fragmentation n’est pas automatiquement une attaque. Avant un deny global, il faut clarifier la MTU, PMTUD, la surcharge VPN, le protocole et le flux réel des paquets.

ipv6-unknown-extension-header traite les paquets IPv6 comportant des Extension Headers inconnus. Sophos documente deny comme valeur par défaut. Un assouplissement exige un cas d’usage légitime démontré et un Packet Capture IPv6, pas seulement un problème général d’accessibilité.

ipv6-ready-logo-compliance est sur off par défaut. Avec on, le pare-feu adapte son comportement au programme de test formel IPv6 Ready Logo. Ce n’est ni l’interrupteur d’activation d’IPv6 ni un contournement IPv6 général. Les bases et la validation d’un chemin IPv6 de production sont expliquées dans Prise en charge d’IPv6 sur Sophos Firewall.

strict-policy est sur on par défaut et rejette certains paquets inhabituels ainsi que des attaques basées sur IP. Pour l’erreur précise Invalid TCP reserved bit, la procédure ciblée est disponible dans Contrôler Accurate ECN et Strict Policy. Sans cette preuve ou une preuve équivalente, la fonction reste active.

ftpbounce-prevention protège contre les attaques FTP bounce dans lesquelles une commande PORT contient l’adresse étrangère d’un tiers. Le paramètre distingue le contrôle sur la connexion de commande ou de données ; Sophos documente control comme valeur par défaut. Un passage à data n’est évalué qu’avec un cas clair de compatibilité FTP, une règle ciblée et un test de transfert de fichiers documenté.

Contrôler le comportement TCP de manière ciblée

Sophos active par défaut Selective Acknowledgement avec tcp-selective-acknowledgement on. SACK permet au destinataire d’indiquer les segments manquants précis, évitant de retransmettre toute la fenêtre TCP. tcp-window-scaling on est également la valeur par défaut et autorise des fenêtres supérieures à 64 KB. Ces deux fonctions sont particulièrement utiles sur les chemins à forte bande passante ou latence ; leur désactivation n’est pas une solution générale de stabilité.

tcp-frto et tcp-timestamp sont sur off par défaut. F-RTO améliore la récupération côté émetteur après des Retransmission Timeouts, notamment lorsque les pertes proviennent d’interférences radio aléatoires plutôt que de congestion. TCP Timestamps permet de mesurer plus précisément le temps aller-retour. Chaque option n’est activée qu’avec un test TCP reproductible et une comparaison de contrôle, et non ensemble comme réglage générique de performance.

Contrôle des séquences et connexions midstream

Avec tcp-seq-checking on, le pare-feu vérifie par défaut si les Sequence et Acknowledgement Numbers correspondent à l’état TCP connu. Certaines applications non conformes aux RFC peuvent envoyer des numéros de séquence invalides. Toutefois, off assouplit ce contrôle globalement. Packet Capture, le motif de rejet et le pair doivent d’abord confirmer le soupçon.

midstream-connection-pickup est sur off par défaut. Avec on, le pare-feu peut reprendre des connexions TCP déjà actives mais pas encore suivies. Sophos cite par exemple l’introduction d’un bridge dans un réseau en production ou certains designs asymétriques. L’option ne remplace ni un routage symétrique ni des règles de pare-feu correctes et ne doit pas rester active après une migration sans justification.

Délai d’inactivité des connexions TCP établies

tcp-est-idle-timeout détermine combien de temps une connexion TCP établie mais inactive reste dans l’état. La plage autorisée va de 2700 à 432000 secondes.

Une durée plus longue peut aider une application ayant de véritables longues périodes d’inactivité, mais elle augmente aussi le nombre d’états anciens et ne résout pas les délais sur le serveur, le répartiteur de charge, la passerelle NAT ou le client. Comparer les deux extrémités, les keepalives et l’heure de l’interruption avant toute modification. Restaurer explicitement l’ancienne valeur numérique si le test n’apporte aucun bénéfice clair.

Dimensionner les états UDP selon l’application

UDP ne possède pas de handshake TCP. Sophos distingue donc deux délais globaux. udp-timeout s’applique aux connexions UDP qui ne sont pas encore reconnues comme un stream. udp-timeout-stream s’applique lorsque les deux extrémités ont envoyé du trafic sur le même port entre des segments réseau. Les deux valeurs acceptent de 30 à 3600 secondes.

set advanced-firewall udp-timeout <30-3600>
set advanced-firewall udp-timeout-stream <30-3600>

Une valeur élevée n’est pas automatiquement meilleure. Elle conserve les états plus longtemps, mais peut aussi créer des sessions obsolètes et davantage d’états. Pour VoIP, SIP ou RTP, contrôler ensemble la signalisation, les ports média, les deux directions et l’heure précise de la coupure audio. La procédure spécialisée se trouve dans Optimiser et contrôler VoIP sur Sophos Firewall.

Ne pas confondre bypass et NAT du trafic système

Contourner le pare-feu stateful uniquement dans un cas spécial démontré

bypass-stateful-firewall-config exclut des hôtes ou réseaux du chemin stateful normal du pare-feu. Sophos exige des entrées dans les deux directions pour un chemin de connexion sortante complet. Le nombre d’entrées possibles n’est pas limité, mais c’est précisément pourquoi une ancienne liste de bypass peut rapidement devenir confuse et critique pour la sécurité.

Une règle de bypass n’est ni une règle Allow rapide ni un interrupteur normal de performance. Elle peut contourner l’évaluation des politiques, la journalisation et les fonctions de sécurité. La syntaxe, le test bidirectionnel et le retour arrière sont expliqués dans Utiliser une règle Bypass Sophos Firewall en toute sécurité.

NAT pour le trafic généré par le pare-feu

sys-traffic-nat modifie l’adresse source du trafic généré par le pare-feu lui-même vers une destination précise. destination et snatip sont obligatoires ; interface et netmask permettent de restreindre davantage l’entrée si nécessaire.

Ce mécanisme ne remplace pas une règle SNAT ou MASQ normale pour le trafic client transféré. Il ne crée pas non plus de route. Les cas spéciaux habituels et la suppression sûre sont décrits séparément dans Alias d’interface pour le trafic système, Routage SD-WAN des Reply Packets et du trafic système et IPsec Route et trafic système.

Valider et annuler une modification

Enregistrer show advanced-firewall avant et après la modification. Répéter ensuite exactement le même test contrôlé avec la même source, destination, service, direction et, si possible, une charge comparable. Le résultat ne confirme la modification que si le symptôme attendu disparaît et qu’un flux de contrôle sans rapport reste inchangé.

Le retour arrière utilise le même paramètre avec la valeur précédemment documentée. Pour une valeur numérique, restaurer la valeur initiale réellement enregistrée plutôt qu’une valeur par défaut supposée. Pour on, off, allow, deny, enable ou disable, restaurer également l’état lu dans la référence.

Si la modification n’aide pas

• Aucune différence dans le flux concerné : Restaurer la valeur initiale et contrôler la règle, NAT, la route, le pair ou l’application.
• Seules les nouvelles sessions réagissent différemment : Terminer les anciennes connexions de manière contrôlée ou utiliser un nouveau flux de test ; les états existants peuvent fausser l’évaluation.
• D’autres applications deviennent instables : Revenir immédiatement en arrière. Cela démontre l’effet global, pas la nécessité d’autres modifications Advanced Firewall.
• Cluster HA : Documenter l’état et le test sur le nœud qui traite le trafic, puis répéter le contrôle avec une nouvelle connexion après un failover planifié. Ne pas supposer un transfert sans interruption de l’état de connexion modifié.

Liste de contrôle opérationnelle

• Sortie initiale de show advanced-firewall, heure, build et personne responsable documentés.
• Un seul paramètre sélectionné avec un problème concret et un effet attendu.
• Effet global sur la sécurité et les performances évalué.
• Retour arrière préparé avec la valeur précédente réelle.
• Flux concerné, sens retour et flux de contrôle sans rapport testés.
• Entrées Bypass et sys-traffic-nat inventoriées séparément.
• show advanced-firewall enregistré à nouveau après le test et modification inutile annulée.

FAQ