Analyser les paquets rejetés par Sophos Firewall

Lorsque Sophos Firewall rejette des paquets, ce n’est pas automatiquement une erreur. Souvent, c’est précisément la décision de sécurité souhaitée : une règle ne correspond pas, une politique bloque, un paquet n’appartient à aucune connexion connue ou un module comme le filtre Web, IPS ou Application Control intervient.

Cela devient problématique lorsqu’un service ne fonctionne pas et qu’il n’est pas clair si le pare-feu bloque, si le trafic n’arrive pas du tout ou si le trafic de retour emprunte un autre chemin. Dans ce cas, il faut suivre un ordre précis : d’abord Log Viewer, puis Packet Capture, ensuite, si nécessaire, les journaux de service ou la CLI.

Pour le matching général des règles, consultez Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture. Cet article se concentre sur les rejets et les paquets rejetés.

Quel article de dépannage convient ?

Tous les problèmes de connexion ne sont pas des problèmes de rejet. Selon l’observation, un autre point de départ peut être plus rapide :

• Un rejet, Invalid traffic, une Violation ou Firewall ID 0 est visible dans Log Viewer ou Packet Capture: Cet article.
• Une règle de pare-feu attendue n’est pas atteinte: Vérifier les causes d’une règle de Sophos Firewall qui ne s’applique pas.
• Une règle doit être validée spécifiquement après une modification: Tester une règle de Sophos Firewall avec Log Viewer et Packet Capture.
• Les paquets doivent être vérifiés dans WebAdmin avec un filtre strict: Utiliser Packet Capture dans WebAdmin de Sophos Firewall.
• WebAdmin montre trop peu et des fichiers journaux sont nécessaires: Dépannage de Sophos Firewall : Services et journaux.
• Les journaux doivent être conservés plus longtemps ou corrélés de manière centralisée: Envoyer les journaux Syslog de Sophos Firewall à un SIEM.
• WebAdmin, SSH, DNS, VPN Portal ou SNMP vers le pare-feu lui-même est affecté: Sécuriser l’accès à Sophos Firewall : Configurer correctement Device Access.
• Le tunnel IPsec est établi, mais le trafic ne circule pas correctement: Dépannage VPN IPsec de Sophos Firewall.
• Les grandes transmissions sont bloquées ou certaines applications échouent: Vérifier MTU et MSS de Sophos Firewall en cas de problèmes VPN.

Cette sélection permet de gagner du temps, car chaque problème n’est pas traité comme une erreur de règle de pare-feu. Il faut d’abord déterminer si le pare-feu voit le trafic, quelle règle ou quel module décide et si le retour emprunte bien le même chemin.

Un rejet n’est pas toujours un rejet

Pour l’analyse, il faut d’abord distinguer le type de rejet. Sinon, on cherche rapidement au mauvais endroit.

• Rejet voulu: Le pare-feu bloque selon une règle, une politique Web, IPS ou un flux de menaces. Vérifier si la politique est correcte sur le plan fonctionnel.
• Rejet inattendu: Le trafic légitime est rejeté par une règle ou un module. Vérifier Rule ID, NAT ID, module et raison dans Log Viewer ou Packet Capture.
• Pas de rejet par le pare-feu: Le trafic n’atteint pas le pare-feu ou la réponse emprunte un autre chemin. Vérifier client, VLAN, switch, passerelle, route, SD-WAN ou retour.

Cette classification évite des exceptions inutiles. Si le rejet est voulu, il n’y a pas besoin de réparation technique, mais d’une décision politique. Si le trafic n’atteint pas le pare-feu, une nouvelle règle de pare-feu ne sera d’aucune aide. Si un module de sécurité bloque, il ne faut pas créer aveuglément une règle de pare-feu large.

Première classification

Avant l’analyse, il faut délimiter l’erreur aussi précisément que possible.

Questions importantes :

• Quelles sont les IP source et destination concernées ?
• Quel port et quel protocole sont utilisés ?
• S’agit-il de client-Internet, VPN site-à-site, accès distant, DNAT, WAF ou trafic interne ?
• L’erreur est-elle permanente ou sporadique ?
• Cela concerne-t-il seulement une application, un utilisateur ou tout un réseau ?
• Une règle de pare-feu, une règle NAT, une route, une règle SD-WAN, une inspection TLS ou une politique Web a-t-elle été modifiée peu avant ?

Sans ces informations, on cherche souvent trop largement dans Log Viewer. Il est préférable d’avoir un test reproductible avec l’heure, les adresses IP et la direction attendue.

Utiliser correctement Log Viewer

Le Log viewer est le premier point de départ. Il affiche les journaux d’événements et peut être filtré par module, temps, champ et texte libre.

Log Viewer s’ouvre en haut à droite de l’interface WebAdmin. Pour les rejets, selon le cas, ces modules sont importants :

• Firewall: Matching des règles, connexions autorisées et rejetées.
• Web: Politique Web, catégorie, groupe d’URL, analyse de malware.
• SSL/TLS inspection: Décryptage, erreurs TLS, exceptions.
• Application filter: Résultats de l’Application Control.
• IPS: Prévention des intrusions et décisions DPI.
• Active threat response: Flux de menaces, NDR Essentials ou autres résultats ATR.
• Web server protection: WAF, proxy inverse et services Web publiés.
• VPN: Événements IPsec, SSL VPN et accès distant.

Les règles de pare-feu enregistrent généralement les sessions lorsque le pare-feu reçoit un événement Destroy et ferme la connexion. Si une connexion se termine sans cet événement, elle n’apparaît pas toujours comme prévu. Pour les connexions SSL/TLS, la connexion est enregistrée après le handshake et lors de la fermeture.

La configuration des journaux est également importante. Si un type de journal n’est pas activé sous System services > Log settings, il n’apparaît pas de manière fiable localement, dans Sophos Central ou dans le Syslog. Pour une évaluation à long terme, consultez Envoyer les journaux Syslog de Sophos Firewall à un SIEM ou Activer le Central Firewall Reporting.

Classer les événements Invalid Traffic

Invalid traffic est un constat important, mais pas une analyse de cause complète. Le pare-feu signale ainsi du trafic qui ne correspond pas proprement à une connexion valide ou à une décision de policy. Les cas typiques sont des paquets hors de l’état de session attendu, des chemins asymétriques, des sessions expirées, des flags TCP inattendus ou du trafic retour qui ne passe pas par le même chemin.

Pour ce type d’événement, il ne faut pas commencer par créer une règle Allow. Il vaut mieux suivre cet ordre :

1. Reprendre la source, la destination, le port et l’heure depuis l’événement.
2. Vérifier dans Log Viewer si une Firewall Rule ID, NAT Rule ID ou un module est visible.
3. Tester avec Packet Capture si les deux directions passent par le même pare-feu.
4. Vérifier le routage, SD-WAN, les chemins VPN, le rôle HA et la route de retour.
5. Décider seulement ensuite si une règle, une logique NAT, une route ou un Security Profile doit être adapté.

Invalid traffic est particulièrement utile comme indication de problèmes d’état ou de retour. Si seule la règle Allow est élargie, la cause réelle reste souvent présente.

Utiliser correctement Packet Capture

Le chemin de menu est :

Diagnostics > Packet capture

Packet Capture montre si les paquets arrivent à une interface, sont transférés, traités par le pare-feu lui-même ou rejetés. C’est particulièrement important lorsque rien de concluant n’apparaît dans Log Viewer.

Procédure de base :

1. Délimiter le cas de test : noter IP source, IP destination, port et protocole.
2. Ouvrir Diagnostics > Packet capture.
3. Définir le filtre de capture aussi étroitement que possible.
4. Activer Packet Capture.
5. Reproduire le problème.
6. Arrêter la capture.
7. Vérifier les entrées par source, destination, Rule ID, NAT ID, statut et raison.

Packet Capture affiche notamment Rule ID, NAT ID, Status, Reason, Connection ID, Web filter ID, Application ID, IPS policy ID et Username. Ces champs aident lorsque non seulement une règle de pare-feu, mais aussi un filtre Web, IPS, Application Control ou NAT sont impliqués.

Pour l’utilisation de l’outil, consultez Utiliser Packet Capture dans WebAdmin de Sophos Firewall pour un guide plus détaillé.

Comprendre le statut de Packet Capture

Les valeurs de statut sont cruciales pour l’analyse. Sophos Firewall propose six valeurs de statut dans le filtre d’affichage : Allowed, Violation, Consumed, Generated, Incoming et Forwarded.

• Incoming: Le paquet arrive sur une interface WAN ou LAN. La source atteint le pare-feu.
• Allowed: Le paquet a été autorisé par la règle de pare-feu ou la politique concernée. Ce statut recoupe souvent Forwarded en pratique ; si un paquet apparaît comme Allowed mais pas Forwarded, vérifiez le routage, le chemin de retour ou un module de sécurité en aval.
• Forwarded: Le paquet est transféré. Le pare-feu laisse passer le paquet en principe.
• Consumed: Le paquet est destiné au pare-feu lui-même. Device Access, VPN Portal, DNS, DHCP ou autre service local.
• Generated: Le paquet est généré par le pare-feu. Réponse ou trafic système du pare-feu.
• Violation: Le paquet est rejeté en raison d’une violation de politique. Une règle, un module ou une fonction de sécurité bloque.

Un Incoming seul sans Forwarded correspondant peut signifier que le pare-feu rejette le paquet, le traite lui-même ou que le filtre ne montre pas tout le flux. Il faut donc toujours considérer les deux directions.

Après le premier statut, il ne faut pas créer immédiatement une exception. Il est préférable de déduire le prochain test du statut :

• Seul Incoming visible: Vérifier le filtre, capturer la direction opposée, rechercher Rule ID et exclure Firewall ID 0.
• Incoming et Forwarded, mais pas de réponse: Vérifier la route de retour, le système cible, le pare-feu local du serveur, NAT et routage asymétrique.
• Consumed visible: Vérifier Device Access, Local service ACL et le service local du pare-feu concerné.
• Generated visible: Vérifier si le pare-feu répond lui-même ou génère du trafic système.
• Violation visible: Comparer Reason, Rule ID, NAT ID et module concerné dans Log Viewer.

Cela maintient l’analyse reproductible : le statut détermine quel outil est le plus approprié ensuite. Pour Violation, Log Viewer est important, pour une réponse manquante, plutôt le retour et Packet Capture, pour Consumed, Device Access au lieu de la règle de pare-feu.

Triage rapide des symptômes

En pratique, un court tableau de symptômes fait gagner du temps avant d’aller plus loin dans les logs ou le shell :

• Log Viewer affiche Invalid traffic: État de session, chemin de retour, routage asymétrique. Vérifier les deux directions avec Packet Capture.
• Packet Capture affiche seulement Incoming: Rejet, service local, règle par défaut ou filtre incomplet. Élargir le filtre, exécuter Policy Test, vérifier Firewall ID 0.
• Packet Capture affiche Forwarded, mais aucune réponse: Système cible, route de retour, NAT, firewall externe. Vérifier les paquets de réponse et le chemin retour.
• Packet Capture affiche Consumed: Trafic vers le pare-feu lui-même. Vérifier Device Access et Local service ACL.
• Packet Capture affiche Violation: Règle, module de sécurité ou violation de policy. Comparer Reason, Rule ID, NAT ID et le log du module.
• Log Viewer et Packet Capture ne montrent rien: Le trafic n’atteint pas le pare-feu. Vérifier client, VLAN, switch, gateway ou mauvaise cible de test.

Firewall ID 0 et règle de rejet explicite

Si aucune règle de pare-feu explicite ne correspond, Sophos Firewall rejette le trafic via la règle finale intégrée avec Firewall ID 0 ou Policy ID 0. Cette règle se trouve toujours à la fin des règles de pare-feu. Point important pour le dépannage et le SIEM : la règle drop-all intégrée ne journalise pas elle-même le trafic. Pour pouvoir suivre tous les rejets de manière traçable, il faut donc une règle de rejet explicite avec journalisation activée.

Si les rejets par la règle par défaut ne sont pas visibles, la décision de policy n’est pas automatiquement fausse. Dans Packet Capture, on peut alors voir seulement Incoming, mais pas d’entrée Violation Firewall correspondante. Le problème est alors la traçabilité dans le dépannage, pas forcément la décision de rejet elle-même.

Si un cas de test ne correspond à aucune règle et qu’aucun rejet n’est visible, il faut donc vérifier en plus :

1. Utiliser Policy Test et vérifier si le test tombe sur Firewall ID 0 ou la règle par défaut.
2. Vérifier l’ordre des règles et s’assurer qu’aucune autre règle plus haut ne correspond de manière inattendue.
3. Créer une règle de rejet explicite à la fin de la base de règles si les rejets doivent être journalisés ou transmis à Central Reporting ou Syslog.
4. Effectuer à nouveau le test et vérifier si le rejet est maintenant visible avec l’ID de règle explicite.
5. Inclure la règle de rejet explicite dans la documentation des changements et la révision des règles, afin qu’elle ne soit pas plus tard mal interprétée comme une règle normale Allow/Deny.

Lors de la création de cette règle finale, les zones doivent être choisies consciemment. Sophos recommande d’utiliser des zones source et destination individuelles et non pas simplement Any comme zone, afin de ne pas influencer inutilement les services internes. Dans un environnement soumis à audit, la règle finale explicite est utile. Elle ne remplace toutefois pas une structure de règles propre. Si beaucoup de trafic légitime atterrit sur la règle de fin, il manque probablement une règle autorisante plus précise plus haut ou un réseau est mal classé.

Lire les champs importants dans Packet Capture

Pour les rejets, le statut n’est pas le seul élément important. Les champs supplémentaires montrent quelle partie du pare-feu a traité le trafic.

• Rule ID: Règle de pare-feu correspondante. Correspond-elle à la règle attendue ?
• NAT ID: Règle NAT correspondante. NAT est-il attendu, manque-t-il NAT ou une mauvaise règle NAT s’applique-t-elle ?
• Reason: Raison du rejet ou de la violation. Ne pas lire isolément, mais comparer avec le statut et le module.
• Web filter ID: Décision de politique Web. Vérifier catégorie, groupe d’URL et contexte utilisateur.
• Application ID: Application reconnue. Application Control peut décider différemment de ce que le port laisse supposer.
• IPS policy ID: Politique IPS appliquée. Vérifier signature, contexte de règle et risque de faux positif.
• Username: Utilisateur reconnu. Évaluer le matching utilisateur uniquement si l’utilisateur est vraiment visible.

Si Rule ID ou NAT ID sont inattendus, il ne faut pas créer immédiatement une exception. Il faut d’abord clarifier si le cas de test était bien défini, si une règle plus générale plus haut correspond ou si NAT modifie la vue sur la source et la destination.

Utiliser Reason comme guide

La valeur Reason n’est pas un rapport de root cause complet, mais elle indique bien le module à examiner ensuite. Firewall renvoie plutôt à la base de règles, à la règle par défaut ou à la logique de zones. LOCAL_ACL correspond à Device Access et Local service ACL. INVALID_TRAFFIC indique plutôt l’état de session, le chemin de retour ou un routage asymétrique. APPLICATION_FILTER, IPS, USER_IDENTITY, IP_SPOOF, SSL_VPN_ACL_VIOLATION ou VIRTUAL_HOST montrent qu’il ne faut pas vérifier uniquement la règle de pare-feu.

Un enchaînement court est donc utile : lire d’abord le statut, classer ensuite le Reason, puis ouvrir le module approprié dans Log Viewer. Ainsi, une entrée Violation isolée devient un chemin de vérification traçable au lieu d’une invitation à créer une exception large.

Consumed et services locaux du pare-feu

Consumed n’est pas un rejet normal. Le statut signifie que le paquet est destiné au pare-feu lui-même. Les cibles typiques sont WebAdmin, User Portal, VPN Portal, SSH, DNS, DHCP, IPsec, SSL VPN ou SNMP.

Dans ces cas, ce n’est souvent pas la règle de pare-feu normale qui est décisive, mais Device Access et Local service ACL. Si, par exemple, WebAdmin, SSH, VPN Portal ou SNMP ne sont pas accessibles, il ne faut pas chercher uniquement sous Rules and policies > Firewall rules. Le bon point de départ est généralement Administration > Device access.

Pour le renforcement et le dépannage des services locaux du pare-feu, consultez Sécuriser l’accès à Sophos Firewall : Configurer correctement Device Access.

Causes fréquentes de rejet

Aucune règle de pare-feu correspondante

La cause la plus fréquente est une règle qui ne correspond pas. Les raisons peuvent être :

• zone source incorrecte
• réseau source incorrect
• zone de destination incorrecte
• IP de destination mal interprétée en cas de DNAT
• service manquant ou protocole incorrect
• utilisateur non authentifié
• le calendrier ne correspond pas
• une règle plus spécifique est en dessous d’une règle plus générale

Pour la structure des règles, consultez Comprendre et configurer correctement les règles de Sophos Firewall. Si DNAT est impliqué, vérifiez également Publier un serveur via DNAT sur Sophos Firewall.

NAT ou retour incorrect

Parfois, le pare-feu autorise l’aller, mais la réponse revient par un autre chemin ou est mal traduite.

Points typiques :

• SNAT ou MASQ manquant.
• DNAT pointe vers le mauvais hôte interne.
• Une règle NAT liée a été désactivée.
• Route de retour manquante.
• SD-WAN ou routage statique envoie le trafic de réponse par un autre chemin.
• Pour le trafic VPN, une route IPsec ou de retour appropriée manque.

Le routage asymétrique génère souvent des erreurs difficiles à comprendre, car le pare-feu ne peut pas attribuer correctement l’état de la connexion. Les paquets peuvent alors apparaître comme n’appartenant pas à la connexion.

Le paquet n’appartient à aucune connexion connue

Les messages comme Could not associate packet to any connection ou des indications similaires de Conntrack signifient souvent que le pare-feu ne trouve pas d’objet de contexte de connexion correspondant.

Causes possibles :

• Le trafic de retour emprunte un autre chemin.
• La connexion a été établie sur un autre nœud HA.
• La session a déjà expiré.
• Les indicateurs TCP ne correspondent pas à la connexion attendue.
• Un appareil envoie des réponses sans demande préalable.
• L’inspection stateful ne voit qu’une partie du flux de données.

Ici, Packet Capture est plus important qu’une seule entrée de journal. Il faut voir si les deux directions passent par le même pare-feu et la même zone.

Webfilter, TLS Inspection, Application Control ou IPS bloqué

Tous les rejets ne proviennent pas de la règle de pare-feu elle-même. Souvent, le trafic est autorisé, mais ensuite bloqué par un module de sécurité.

Exemples typiques :

• La politique Web bloque une catégorie ou un groupe d’URL.
• L’inspection TLS échoue en raison d’un certificat, SNI, chiffrement ou exception.
• Application Control reconnaît une application indésirable.
• IPS bloque un motif.
• Active Threat Response rencontre un IoC.
• Zero-Day Protection retient ou bloque un téléchargement.

Pour les résultats IPS, il faut vérifier la signature, la politique et le contexte de la règle avant de créer une exception large. Le processus approprié est décrit dans Configurer et tester en toute sécurité IPS de Sophos Firewall.

Pour les cas Web et TLS, il faut également vérifier QUIC. Si les navigateurs contournent via UDP 443, les attentes de filtre Web et TLS ne correspondent pas toujours. Plus d’informations : Bloquer correctement le protocole QUIC et HTTP/3 sur Sophos Firewall.

MTU, MSS ou fragmentation

Pour VPN, PPPoE, SD-WAN, mobile ou tunnels imbriqués, un paquet peut être trop grand pour le chemin. On ne voit alors pas toujours un rejet clair du pare-feu, mais plutôt des interruptions de connexion, des applications lentes ou certains services qui restent bloqués.

Pour ces cas, consultez Vérifier MTU et MSS de Sophos Firewall en cas de problèmes VPN.

Processus structuré

Pour la pratique, cet ordre fonctionne bien :

1. Noter le cas de test : Source, destination, port, protocole, heure.
2. Vérifier Log Viewer : Filtrer par module de pare-feu et modules de sécurité appropriés.
3. Rechercher Rule ID et NAT ID : Vérifier quelle règle a réellement été atteinte.
4. Démarrer Packet Capture : Définir un filtre étroit et reproduire le test.
5. Vérifier le statut : Évaluer Incoming, Forwarded, Consumed, Generated ou Violation.
6. Vérifier la direction de retour : La réponse revient-elle et par le même chemin ?
7. Vérifier les modules de sécurité : Web, TLS, Application Control, IPS, ATR, WAF.
8. Vérifier les journaux de service : En cas de problèmes de service, vérifier le fichier journal approprié sous /log.
9. Vérifier les journaux centraux : Inclure Central Reporting ou SIEM si les journaux locaux ne suffisent pas.

Les fichiers journaux et de service appropriés sont résumés dans Dépannage de Sophos Firewall : Services et journaux.

Si rien n’apparaît dans Log Viewer

Aucune entrée de journal ne signifie pas automatiquement que le pare-feu n’est pas impliqué.

Causes possibles :

• La journalisation n’est pas activée dans la règle de pare-feu.
• Le type de journal pertinent n’est pas actif sous System services > Log settings.
• La connexion n’a pas été terminée proprement et donc pas enregistrée.
• Le trafic n’atteint pas le pare-feu.
• Le trafic est traité par un service local.
• Le filtre dans Log Viewer est trop strict.
• L’espace de stockage des journaux est limité ou les anciennes entrées ont déjà été écrasées.

Dans ces cas, utilisez d’abord Packet Capture. Si Packet Capture ne montre également aucune entrée, concentrez-vous plutôt sur le client, le switch, le VLAN, le routage avant le pare-feu ou une mauvaise cible de test.

Quand tcpdump ou les archives de journaux sont nécessaires

Le Packet Capture de WebAdmin est bon pour des analyses rapides. Pour des captures plus longues, des fichiers PCAP, des filtres très précis ou des cas de support, tcpdump via SSH est souvent mieux adapté. Cela est particulièrement vrai si un problème ne se produit que sporadiquement ou si la capture doit être analysée plus tard dans Wireshark ou par le support Sophos.

Pour ces cas, clarifiez avant la capture :

• Quelles IP source, IP destination et ports doivent être dans le filtre ?
• Combien de temps la capture peut-elle durer ?
• Où le fichier PCAP sera-t-il stocké ?
• Qui peut voir le fichier ?
• Quand le fichier sera-t-il supprimé après l’analyse ?

Le processus pratique est décrit dans Capturer des paquets avec tcpdump sur Sophos Firewall via CLI. Si des journaux de service sont également nécessaires en plus des paquets, consultez Sauvegarder les journaux de Sophos Firewall pour le support et l’analyse.

Ne créer des exceptions que de manière ciblée

Pour les rejets, la tentation est grande de créer rapidement une exception. Cela peut aider à court terme, mais souvent au détriment de la sécurité ou en masquant la cause.

Les exceptions ne doivent être créées que si l’on sait clairement :

• quel module bloque
• quel hôte, domaine ou application est concerné
• pourquoi le trafic est légitime
• à quel point l’exception peut être restreinte
• quand l’exception sera vérifiée ou supprimée

Les exceptions larges pour des réseaux entiers, des règles Any ou des exceptions TLS globales doivent être évitées. Il est préférable d’avoir une petite exception documentée avec une date de révision.

Documenter le constat

Un bon constat de rejet doit être documenté de manière à ce qu’une autre personne puisse reproduire le test. C’est important pour les revues internes, la documentation des changements et les cas de support.

Au minimum, consigner :

• Date, heure et fuseau horaire du test.
• IP source, IP destination, port, protocole et utilisateur.
• Règle de pare-feu attendue et Rule ID réellement visible.
• Règle NAT attendue et NAT ID réellement visible.
• Statut de Packet Capture : Allowed, Incoming, Forwarded, Consumed, Generated ou Violation.
• Message de raison ou de module pertinent.
• Changement effectué ou aucun changement conscient.
• Si une exception a été créée : propriétaire, objectif, validité et date de révision.

Cette documentation empêche qu’une étape de dépannage temporaire ne devienne une faille de sécurité permanente et non clarifiée.

Liste de contrôle

• IP source, IP destination, port et protocole connus.
• Heure du test documentée.
• Log Viewer vérifié avec le bon module et filtre temporel.
• Rule ID et NAT ID évalués.
• En cas d’absence d’entrée de rejet, vérifié si Firewall ID 0 ou la règle par défaut est concernée.
• Règle de pare-feu et ordre des règles vérifiés.
• Règle NAT et route de retour vérifiées.
• Packet Capture effectué avec un filtre étroit.
• Statut et raison évalués dans Packet Capture.
• Directions aller et retour vérifiées.
• Webfilter, TLS Inspection, Application Control, IPS et Active Threat Response vérifiés.
• Pour VPN, MTU, MSS et route vérifiés.
• Pour DNAT ou WAF, hôte cible, adresse hébergée et backend vérifiés.
• Journaux centraux ou Syslog vérifiés si les journaux locaux ne suffisent pas.
• En cas de besoin de support, tcpdump ou archive de journaux préparés de manière ciblée.
• Exceptions créées uniquement de manière restreinte et documentée.
• Constat documenté avec Rule ID, NAT ID, statut, raison et changement.

Questions fréquentes