Contrôler Spoof Protection et DoS Settings

Spoof Protection et DoS Settings font partie des fonctions de durcissement classiques d’un Sophos Firewall. Les fonctionnalités réduisent les paquets simples, bruyants ou manifestement incorrects avant qu’ils ne deviennent du bruit inutile dans les journaux, les règles ou les services publiés. Dans le même temps, ces paramètres ne constituent pas une protection magique contre toutes sortes d’attaques.

L’article classe les fonctions comme un renforcement de base minutieux : comprenez d’abord la conception du réseau et les chemins de retour, puis activez, testez et vérifiez les journaux. La distinction est particulièrement importante : ces fonctions complètent le nettoyage des règles de pare-feu, IPS, Threat Feeds, WAF et la journalisation. Ils ne remplacent pas ces éléments de base.

Brèvement expliqué

Spoof Protection vérifie si les paquets avec une adresse source plausible arrivent sur l’interface attendue. Par exemple, si un paquet avec une adresse source interne apparaît depuis Internet, cela est suspect dans la plupart des conceptions. DoS Settings, en revanche, répond à certains modèles d’attaques d’inondation ou de connexion, par exemple des quantités notables de trafic SYN, UDP ou ICMP.

Dans SFOS 22, le chemin WebAdmin est le suivant :

Intrusion prevention > DoS & spoof protection

Les paramètres de cette page agissent sur le traitement des paquets. Avant de cliquer sur Apply ou Save, relever les valeurs existantes et définir une procédure de retour arrière.

Ce que font les fonctions

• Spoof Protection: Supprimer les paquets avec une adresse IP source peu plausible, réduire les tentatives d’usurpation simples, rendre visibles les paquets mal acheminés. ne remplace pas la zone propre, l’interface et la planification du routage.
• DoS Settings: limite les types d’inondation simples, rend les attaques bruyantes ou les erreurs de configuration visibles plus tôt. ne remplace pas la protection DDoS du fournisseur, pas de WAF et pas de conception en amont proprement dimensionnée.

En pratique, ces fonctions sont particulièrement intéressantes en tant que renforcement de base. L’avantage est de réduire les absurdités évidentes. Dans les véritables attaques DDoS volumétriques, la connexion Internet est souvent déjà saturée avant que le pare-feu puisse répondre de manière significative. Ensuite, vous avez besoin d’une protection du fournisseur, d’un nettoyage en amont ou d’une autre architecture.

Ne pas confondre les types de protection

Le même écran regroupe plusieurs mécanismes qui répondent à des questions opérationnelles différentes.

• Enable spoof prevention: active Spoof Prevention pour les zones sélectionnées. Des zones ou chemins de retour mal compris peuvent affecter le trafic légitime.
• Trusted MAC et paires IP-MAC: les adresses MAC ou combinaisons IP-MAC connues sont considérées comme fiables. Les appareils mobiles, changements DHCP ou la virtualisation peuvent générer des tâches de maintenance.
• DoS settings: définissent les seuils et flags pour les floodings SYN, UDP, TCP ou ICMP/ICMPv6. Des valeurs trop strictes perturbent les pics de charge légitimes, les scans, la surveillance ou la VoIP.
• DoS bypass rule: exclut certains trafics des DoS Settings dans WebAdmin. Les exceptions larges affaiblissent cette protection. Pour l’interaction avec les policies CLI, voir les précisions de version dans la section CLI.

Cette distinction est importante, car une erreur après l’activation n’est pas automatiquement un problème de règle de pare-feu. Le seuil DoS est parfois trop agressif, une liaison IP-MAC n’est parfois plus correcte et Spoof Protection révèle parfois un véritable problème de routage ou de VLAN.

Quand Spoof Protection a du sens

Spoof Protection s’adapte particulièrement bien aux réseaux clairement segmentés dans lesquels les réseaux sources, les interfaces et les itinéraires sont clairement planifiés. Plus la structure du réseau est claire, plus il est facile d’évaluer si une adresse source sur une interface est plausible.

Applications utiles :

• Internet WAN sur lequel aucune source interne RFC1918 ne doit apparaître.
• DMZ ou zones de serveur avec des réseaux source et destination clairs.
• Zones client, invité ou IoT dans lesquelles aucun réseau interne externe ne doit apparaître comme sources.
• Emplacements où le routage, les VLANs et les zones sont clairement documentés.
• Les environnements dans lesquels les paquets sont abandonnés doivent ensuite être traçables avec Packet Capture et les journaux.

Les choses deviennent plus difficiles avec un routage asymétrique, des réseaux de transit complexes, des chemins de migration temporaires, des VLAN mal documentés ou plusieurs pare-feu dans le même chemin de données. Un flux de données légitime peut ressembler à une usurpation d’identité, même si la conception du routage ou le chemin de retour est en réalité impur.

Vérifier avant activation

Spoof Protection et DoS Settings ne doivent pas être activés aveuglément dans un environnement de production. Il convient de préciser au préalable quels réseaux et services sont concernés.

Points de contrôle importants :

1. Zones de documents, interfaces, VLANs, ponts et LAGs.
2. Vérifiez les routes statiques, les routes SD-WAN, les routes VPN et les chemins asymétriques.
3. Identifiez les services publiés via DNAT ou WAF.
4. Notez les services critiques tels que VoIP, la surveillance, la sauvegarde, les analyses, le VPN et les connexions au site.
5. Préparez la journalisation et l’évaluation centrale si les événements doivent être traçables ultérieurement.
6. Définissez la fenêtre de maintenance ou la zone pilote pour la première activation.
7. Contrôlez les DoS bypass rules, les entrées Trusted MAC et les liaisons IP-MAC existantes.
8. Relevez le type de contrôle spoof et les zones sélectionnées, Restrict unknown IP on trusted MAC, tous les flags Apply, les valeurs Packet Rate et Burst Rate, ainsi que les exceptions et liaisons existantes. Ces valeurs serviront au retour arrière.

Si les règles normales du pare-feu sont difficiles à comprendre, la règle et l’état du routage doivent d’abord être nettoyés. Pour les connexions de test individuelles, Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est un meilleur début.

Activer Spoof Protection avec précaution

Une approche étape par étape est logique pour Spoof Protection. Vous devez d’abord sécuriser les zones les plus claires, et non toutes les zones spéciales immédiatement.

Processus pratique :

1. Enregistrez la configuration actuelle ou au moins documentez les paramètres concernés.
2. Sous Intrusion prevention > DoS & spoof protection, sélectionnez Enable spoof prevention, le type de contrôle requis et, dans un premier temps, uniquement des zones bien documentées.
3. Cliquez sur Apply.
4. Exécutez les connexions de test planifiées : accès Internet, VPN, services publiés, serveurs centraux, surveillance.
5. Vérifiez Log Viewer et Packet Capture pour les chutes inattendues.
6. Ne traitez pas immédiatement les pertes légitimes et visibles avec de larges exceptions, mais vérifiez d’abord le routage, l’adresse IP source et l’interface.

Une erreur courante consiste à traiter Spoof Protection comme un pur hook de sécurité. En réalité, la fonction teste une hypothèse sur la conception du réseau. Si cette hypothèse n’est pas correcte, Spoof Protection ne doit pas nécessairement être faux. Souvent une interface, une route, un VLAN ou une route retour ne sont pas construits comme prévu.

Bien comprendre IP, MAC et paires IP-MAC

Sophos distingue plusieurs types de contrôle. IP spoofing rejette le trafic lorsque l’IP source ne correspond pas à la table de routage ou à un sous-réseau directement connecté. MAC filter fonctionne avec des adresses MAC de confiance ; au moins une Trusted MAC Address doit être renseignée. Le MAC filter ne s’applique pas aux paquets DHCP. IP-MAC pair filter vérifie si la combinaison entrante adresse IP/adresse MAC correspond à une paire connue.

C’est utile dans des réseaux statiques et clairement contrôlés, mais cela peut vite créer de la maintenance dans des environnements dynamiques. DHCP, roaming Wi-Fi, machines virtuelles, hyperviseurs, clusters, NAC, stations d’accueil ou remplacement d’appareils peuvent provoquer des changements MAC/IP légitimes. Pour ces réseaux, il vaut mieux observer d’abord et ne lier que les zones où la réalité opérationnelle est assez stable.

Pour savoir comment contrôler la table locale des voisins et créer de manière réfléchie une association statique entre IP, MAC et interface, consulter Contrôler le cache des voisins ARP et NDP.

Il faut bien distinguer les cas : si aucune Trusted MAC n’est configurée, le IP-MAC pair filter activé laisse passer tout le trafic à ce contrôle. Une liste Trusted MAC vide n’est pas la même chose qu’un paquet qui ne correspond pas à une liaison IP-MAC configurée. Avec des entrées présentes, le filtrage dépend des liaisons et de Restrict unknown IP on trusted MAC ; l’absence de paire correspondante ne signifie pas toujours un blocage indépendamment de cette option. La protection nécessite des liaisons maintenues et testées.

L’option Restrict unknown IP on trusted MAC est particulièrement stricte : les paquets provenant d’une Trusted MAC sans liaison IP correspondante peuvent être rejetés si l’IP est inconnue du point de vue du pare-feu. C’est un gain de sécurité dans des réseaux contrôlés, mais un piège avec DHCP, les migrations et les changements IP temporaires.

Pour créer une entrée Trusted MAC individuelle, ouvrir Intrusion prevention > DoS & spoof protection, puis utiliser Add dans la section Spoof protection trusted MAC. Après avoir saisi l’adresse MAC, sélectionner Static et indiquer une ou plusieurs adresses IPv4 ou IPv6 séparées par des virgules, ou sélectionner DHCP pour associer automatiquement les adresses attribuées. Après Save, tester un cas IP-MAC correspondant et un autre volontairement différent ; la présence de l’entrée ne confirme pas à elle seule l’application du filtre.

SFOS 23 documente les options de recherche et de filtrage de la liste Trusted MAC pour retrouver une entrée à maintenir. Cette vue ne modifie pas le filtrage des paquets et ne signifie pas que SFOS 22 ne dispose pas de tels contrôles.

Importer des Trusted MAC de manière contrôlée

Plusieurs Trusted MAC peuvent être importées sous Intrusion prevention > DoS & spoof protection depuis un fichier .csv ou .txt. La première ligne doit contenir exactement MAC Address,IP Association,IP Address. Les valeurs IP Association autorisées sont Static, DHCP, DHCPv6 et None. Avec Static, indiquer au maximum 16 adresses IP séparées par des virgules pour chaque MAC; avec les trois autres associations, laisser le champ IP vide.

Le pare-feu ignore lors de l’importation les adresses MAC, associations ou adresses IP non valides. Il ignore également les valeurs IP saisies avec DHCP, DHCPv6 ou None. Il faut donc commencer par quelques lignes pilotes, contrôler ensuite les liaisons visibles et tester un cas IP-MAC autorisé ainsi qu’un cas volontairement incorrect. Un téléchargement réussi ne prouve pas encore que la logique de filtrage attendue s’applique.

Planifier les DoS Settings

DoS Settings doit s’adapter à l’environnement. Il est rarement judicieux d’adopter les valeurs d’un autre exemple sans vérification. Un site avec quelques utilisateurs, VoIP et un petit WAN se comporte différemment d’un centre de données, d’un réseau scolaire ou d’un site avec des analyses et une surveillance régulières.

Avant de vous adapter, répondez à ces questions :

• Quels services publics sont exposés ?
• Existe-t-il des pics de charge, des analyses, une surveillance ou des contrôles de santé légitimes ?
• VoIP, VPN, WAF, DNAT ou des transferts de fichiers volumineux sont-ils utilisés ?
• Pour quels protocoles faut-il activer le flag Apply afin que le pare-feu rejette et journalise réellement les dépassements de seuil ?
• Qui vérifie les logs après l’activation ?

DoS Settings peut aider à limiter les types d’inondations simples. Toutefois, des seuils trop stricts peuvent également affecter le trafic légitime. Une attention particulière doit être portée à VoIP, aux systèmes de surveillance, aux tâches de sauvegarde, aux analyses de vulnérabilité et aux services publiés très utilisés.

Dans la page de configuration, il ne s’agit pas seulement de floods classiques. Il existe aussi des flags comme Dropped source routed packets, Disable ICMP/ICMPv6 redirect packet et ARP hardening. Ces options sont une bonne base de hardening, car elles peuvent réduire les manipulations du routage ou du comportement ARP. Il faut malgré tout les tester après activation, surtout dans des réseaux avec routeurs en aval, anciens segments ou designs Layer 2 inhabituels.

Deux notions sont importantes pour les seuils dans WebAdmin :

• Packet rate : nombre de paquets qu’un hôte peut envoyer ou recevoir par minute avant que le trafic soit rejeté.
• Burst rate : nombre de paquets initialement autorisés sans contrôle du Packet Rate. Ensuite, des pointes courtes et occasionnelles au-dessus du Packet Rate peuvent être tolérées, mais pas des dépassements fréquents ou prolongés.

L’Apply flag décide si la limite configurée est réellement appliquée au protocole concerné. Des valeurs trop hautes apportent peu. Des valeurs trop basses bloquent des pics légitimes. Les valeurs doivent donc être alignées sur le trafic réel, les services publiés et les fenêtres de maintenance connues.

Pour établir une référence fiable, relever d’abord les pics normaux et les charges exceptionnelles planifiées. Choisir ensuite la valeur de chaque protocole selon le pic légitime mesuré et la capacité du service protégé : Sophos ne fournit pas de valeur de production universelle. Après chaque modification, exécuter un test de charge défini et comparer Traffic dropped. Ce compteur étant cumulé depuis le dernier redémarrage du pare-feu, noter également l’heure du test et sa valeur initiale.

Lire correctement l’état DoS

Sous Intrusion prevention > DoS attacks, SFOS indique en temps réel pour quelle Source ou Destination une limite s’applique et combien de paquets ont été rejetés. Après une détection, la limitation s’applique d’abord pendant dix secondes. Si l’attaque continue, le pare-feu réinitialise ce compteur toutes les dix secondes et poursuit la limitation. Lorsque l’attaque cesse, les données disparaissent après 30 secondes. Un état vide ne prouve donc pas qu’aucun événement DoS n’a eu lieu auparavant; l’analyse rétrospective nécessite les événements enregistrés.

Utiliser les signatures DDoS uniquement sur les modèles pris en charge

Sophos fournit les signatures DDoS uniquement sur les XGS 5500 et les pare-feu de capacité supérieure. Sur un modèle pris en charge, la procédure est la suivante :

1. Sous Intrusion prevention > IPS policies > Add, créer une IPS Policy dédiée avec un nom unique librement choisi et l’enregistrer avec Save.
2. Pour cette Policy enregistrée, sélectionner Edit, puis Add et saisir un nom de règle unique.
3. Sélectionner Select all, saisir ddos dans Smart filter et appuyer sur Entrée pour appliquer le filtre. Définir délibérément Action sur Drop packet.
4. Enregistrer d’abord la règle avec Save, puis la Policy contenant cette règle avec le second Save.
5. Sous Rules and policies > Firewall rules, attribuer la Policy à la règle de pare-feu qui traite réellement le trafic prévu ; vérifier séparément l’attribution et la protection effective comme dans la procédure pilote IPS. Sans cette attribution, la Policy n’a aucun effet.

Ces signatures complètent les seuils DoS locaux, mais ne remplacent pas une protection DDoS chez le fournisseur. Si la liaison internet est déjà saturée, le pare-feu ne peut pas résoudre le goulot d’étranglement en amont de la connexion WAN. Le modèle, la licence, la règle appliquée et un test contrôlé doivent donc être vérifiés séparément.

Règles CLI avec system dos-config

La Device Console permet de créer des policies DoS personnalisées et les règles correspondantes. Cela est notamment nécessaire pour IP Flood, car ce type ne peut pas être configuré dans WebAdmin. Les unités diffèrent : WebAdmin utilise les paquets par minute, tandis que system dos-config utilise les paquets par seconde (pps).

Après la connexion SSH, sélectionner 4. Device Console dans le menu principal. Les commandes s’exécutent à l’invite console>, pas dans l’Advanced Shell.

La policy est d’abord créée avec le type d’attaque, le seuil et la méthode de comptage. La règle définit ensuite le trafic auquel elle s’applique. L’exemple SYN documenté prévoit la policy TestSYN et la règle TestRuleSYN pour la source 198.51.100.50, à 1000 pps par source.

Consulter l’aide de la version cible avant toute création : l’aide publiée pour SFOS 22 et SFOS 23 utilise rule_name pour add dos-rule dans les blocs de syntaxe et d’options, mais rule-name dans les exemples. Leur interchangeabilité n’est pas confirmée. Consulter d’abord l’aide de system dos-config dans la Device Console de la version installée et vérifier le token d’ajout accepté ainsi que les paramètres. Si le doute subsiste, ne pas créer de règle et demander une clarification à Sophos Support. La commande complète d’ajout de règle est volontairement omise comme modèle à copier-coller. Ne créer la policy ci-dessous qu’après cette vérification ; seule, elle n’associe pas encore le trafic d’exemple. Cet exemple n’est pas présenté comme testé avec succès.

system dos-config add dos-policy policy-name TestSYN SYN-Flood 1000 pps per-src

1000 pps est un exemple de syntaxe et non une recommandation pour un réseau de production. Pour une règle personnalisée, il faut au minimum adapter délibérément les éléments suivants :

• SYN-Flood : alternativement UDP-Flood, ICMP-Flood ou IP-Flood, disponible uniquement ici
• per-src : seuil par source ; alternativement per-dst par destination ou global pour tout le trafic correspondant
• les conditions réellement nécessaires pour la source, la destination, la zone, l’interface et le protocole
• le seuil selon une baseline mesurée et la capacité du service protégé

Le mode de comptage global ne s’applique pas aux compteurs sous Intrusion prevention > DoS attacks. Ces compteurs UI ne prouvent donc pas une limite CLI agrégée globalement. Vérifier la configuration avec show, puis évaluer séparément l’application de la protection à l’aide d’un flux de test précisément délimité dans le temps et de ses journaux.

Les limites et les champs de correspondance CLI sont définis plus précisément que ne le suggère la courte règle d’exemple :

system dos-config flush dos-rules supprime toutes les règles DoS CLI et ne constitue pas un retour arrière pour un seul test. Avant une telle action globale, les règles existantes sont relevées individuellement avec show et la configuration est sauvegardée. Pour un retour arrière normal, la règle nommée est supprimée de manière ciblée. L’aide publiée décrit flush pour les règles, pas comme une suppression des policies associées.

Après la création, il faut d’abord vérifier que les noms, le type, le seuil et la condition de la règle sont corrects :

system dos-config show dos-policies policy-name TestSYN
system dos-config show dos-rules rule-name TestRuleSYN

Pour revenir en arrière, supprimer d’abord la règle, puis la policy qui n’est plus utilisée :

system dos-config delete dos-rule rule-name TestRuleSYN
system dos-config delete dos-policy policy-name TestSYN

La syntaxe CLI est documentée dans la Sophos Firewall Command Line Help. Elle doit néanmoins être utilisée d’abord avec un flux de test contrôlé. Les règles DoS CLI prennent uniquement en charge IPv4. Avec une policy IP-Flood active, la colonne Applied sous Intrusion prevention > DoS attacks continue d’afficher No ; Sophos décrit ce comportement comme normal.

Cette limitation à IPv4 s’applique aux règles DoS CLI, et non aux DoS settings natifs sous Intrusion prevention > DoS & spoof protection dans WebAdmin : les paramètres DoS de cette page protègent aussi bien le trafic IPv4 que le trafic IPv6 lorsque les flags de protocole et les seuils appropriés sont configurés.

Pour SFOS 22, l’évaluation des règles et policies CLI avant les paramètres DoS et spoof de WebAdmin est documentée ; dans cet ordre, une règle bypass WebAdmin ne neutralise pas automatiquement une policy CLI correspondante. L’aide CLI SFOS 23 examinée ne précise pas cet ordre entre les deux niveaux. Cela ne prouve pas un changement de comportement : confirmer l’interaction pour la version installée avant de s’y fier. Dans WebAdmin, les deux versions documentent toujours les DoS bypass rules en premier, puis les DoS Settings pour le trafic restant.

N’utiliser les DoS bypass rules que de manière ciblée

Les DoS bypass rules sont utiles lorsqu’un flux clairement identifié serait autrement affecté à tort par les DoS Settings de WebAdmin. Les exemples typiques sont la surveillance, les Health Checks ou un service étroitement défini entre des adresses IP connues. L’exception doit alors être aussi précise que possible : source précise, destination précise, protocole adapté et plage de ports étroite.

Les règles larges avec de grands réseaux, une logique any ou des plages de ports générales sont dangereuses. Elles rendent l’inspection DoS aveugle précisément là où elle pourrait être nécessaire plus tard.

L’ordre des paramètres WebAdmin est important : Sophos Firewall vérifie d’abord si une DoS bypass rule correspond, puis applique les DoS Settings de WebAdmin au trafic restant. Une règle de bypass trop large peut donc rendre cette protection inefficace. Pour les règles bypass, source, destination, protocole, port source et port destination doivent être définis consciemment au lieu d’utiliser * par facilité.

Créer une exception sous Intrusion prevention > DoS & spoof protection, dans DoS bypass rule, avec Add. SFOS 22 exige IP version, les IP source et destination, Protocol, le port source et le port destination ; * signifie n’importe quelle adresse ou n’importe quel port. Pour un Health Check HTTPS de 198.51.100.20 vers 203.0.113.10, utiliser source 198.51.100.20, destination 203.0.113.10, protocole TCP, port source * et port destination 443. Remplacer les deux adresses de documentation par les véritables extrémités. Le port source reste variable uniquement parce qu’un client utilise généralement un port source dynamique. Après Save, tester ce flux et un autre : seul le Health Check défini doit contourner la protection DoS de WebAdmin.

Vérifier la modification et le failover en HA

Dans un cluster HA, le Primary synchronise vers l’Auxiliary la configuration du pare-feu, notamment règles, policies, settings et commandes CLI. Effectuer les modifications DoS et spoof sur le Primary actuel. Vérifier ensuite l’état HA sous System services > High availability, ainsi que les entrées WebAdmin et règles CLI. En Active-active, le test de charge doit couvrir les deux chemins de traitement ; en Active-passive, prévoir un failover contrôlé pendant la fenêtre de maintenance si la procédure d’exploitation l’autorise. Ne pas créer manuellement une configuration divergente sur l’Auxiliary.

Remarque pour SFOS 22.0 MR2

Les Release Notes de SFOS 22.0 MR2 Build 546 indiquent que l’anomalie NC-180226 est corrigée : WebAdmin n’affichait auparavant aucune erreur lors de l’ajout d’une adresse MAC en double sous Spoof protection trusted MAC. Sur un build 22.0 antérieur, l’absence de message d’erreur ne prouve donc pas que l’entrée est unique. Vérifier la liste et la liaison réelle, ou passer à un build corrigé.

Ce que ces paramètres ne résolvent pas

Spoof Protection et DoS Settings sont des éléments de base importants, mais ils ne résolvent pas tous les problèmes de sécurité.

• Le serveur est attaqué via des requêtes HTTP autorisées: Vérifiez WAF la protection des règles et du serveur Web.
• Attaques IP de source malveillante connue: Threat Feeds ou vérifiez le blocage du pays/IP.
• Tentative d’exploitation contre un service: Activer IPS-Policy selon la règle.
• La ligne Internet est pleine en raison de DDoS: Inclure la protection DDoS du fournisseur, du nettoyage ou en amont.
• La règle de pare-feu autorise trop de: Règles de nettoyage, NAT et modèle objet.
• Les suppressions sont incompréhensibles: Améliorer la journalisation, Packet Capture, syslog ou reporting central.

L’article Publier le serveur avec DNAT sur Sophos Firewall est également pertinent pour les serveurs accessibles au public. Il s’agit de NAT, des règles de pare-feu et des erreurs de publication typiques.

Journaux et contrôle de suivi

Après l’activation, vous ne devez pas seulement vérifier si l’accès normal à Internet fonctionne toujours. Ce qui est important est de savoir si le pare-feu affiche clairement les événements attendus et inattendus.

Vérifiez :

1. Log Viewer filtre le pare-feu et les événements de sécurité pertinents.
2. Déclenchez le trafic de test avec une adresse IP source, une adresse IP de destination et un service clairs.
3. Utilisez Packet Capture pour les gouttes peu claires.
4. Pour un stockage plus long, planifiez syslog vers SIEM ou serveur de journaux.
5. Lors de l’exécution de Sophos Fusion (anciennement Sophos Central), vérifiez si Central Firewall Reporting rend visibles les événements souhaités.

SFOS journalise le trafic rejeté par ces protections. Pour un test DoS, relever d’abord l’heure, la source, la destination, le protocole et les compteurs. Pendant le test, Intrusion prevention > DoS attacks affiche en temps réel la source ou la destination et les données rejetées. Comme l’état disparaît 30 secondes après la fin de l’attaque et que Traffic dropped est cumulé depuis le dernier redémarrage, seule une comparaison avant/après sur une période délimitée est probante. Le mode CLI global ne s’applique pas à ces compteurs UI ; même cette comparaison ne valide donc pas l’agrégation globale. Pour une policy CLI globale, séparer la vérification de configuration par show de celle du flux de test défini et de ses rejets/journaux. Packet Capture montre en plus l’interface d’entrée et les adresses du paquet, mais ne prouve pas à lui seul quel mécanisme a rejeté le flux.

Si un paquet est abandonné mais que la raison n’est pas claire, l’analyse systématique des abandons dans Sophos Firewall abandonne les paquets : vérifier les causes est utile. Il explique également pourquoi Log Viewer et Packet Capture répondent à des questions différentes.

Recherche d’erreurs après l’activation

Après une modification, les symptômes ne doivent pas être interprétés trop vite comme une attaque. L’analyse la plus rapide consiste généralement à comparer attente, observation et prochain test.

• Un seul réseau perd l’accès : le réseau source arrive peut-être sur une autre interface que prévu. Comparer route, VLAN, SD-WAN Route et Packet Capture.
• De nombreux clients derrière un NAT en amont sont affectés : si le trafic a déjà été NATé avant d’atteindre le pare-feu Sophos, celui-ci voit plusieurs clients comme une source commune. Vérifier le seuil, le chemin NAT et le pic de charge légitime.
• VoIP, monitoring ou scanner génère des drops : des taux de paquets réguliers peuvent ressembler à du flooding. Vérifier une fenêtre de test courte, Log Viewer et, si nécessaire, une règle de bypass précise.
• Des appareils ne fonctionnent plus après un changement DHCP : la liaison IP-MAC ou la logique Trusted MAC ne correspond peut-être plus. Contrôler lease, adresse MAC et liaison.
• Seul le trafic retour manque : un chemin asymétrique ou une mauvaise passerelle est probable. Vérifier séparément l’aller et le retour avec Packet Capture.
• Une modification ARP ou ICMP crée des effets de bord : ARP hardening, source-routed packets ou ICMP redirect peuvent toucher des designs réseau inhabituels. Vérifier les routeurs en aval, les segments Layer 2 et le chemin de routage.

Revenir en arrière en toute sécurité

Si du trafic légitime est touché et que la cause ne peut pas être établie pendant la fenêtre de maintenance, ne pas improviser une exception large. Restaurer les valeurs précédemment relevées : Packet Rate, Burst Rate, flags Apply, type de contrôle spoof, zones et Restrict unknown IP on trusted MAC ; supprimer uniquement les nouvelles entrées bypass ou Trusted MAC. Cliquer sur Apply ou Save, puis répéter le même flux de test. Pour une policy CLI, supprimer d’abord uniquement la règle nommée, puis sa policy dédiée devenue inutilisée. flush dos-rules ne fait pas partie de ce retour arrière.

Erreurs typiques

• Spoof Protection activer sans comprendre le routage: le trafic légitime peut être bloqué. Vérifier les zones, les interfaces, les routes et les chemins de retour au préalable.
• Appliquer les seuils DoS sans vérifier: VoIP, la surveillance, les analyses ou les services publiés peuvent être perturbés. Planifier la ligne de base et la phase de test.
• Confondre Packet Rate et Burst Rate : le taux de paquets durable et le pic court sont deux réglages différents. Les deux doivent correspondre au service.
• Résoudre chaque anomalie avec une large exception: Le renforcement devient inefficace et déroutant. Limiter la cause et documenter étroitement les exceptions.
• Créer une DoS bypass rule trop large : dans WebAdmin, le bypass est vérifié avant les DoS Settings et peut contourner entièrement ce contrôle. Définir source, destination, protocole et ports de manière stricte ; vérifier également les policies CLI séparées.
• Laisser IP-MAC pair filter vide : sans entrées maintenues, aucune liaison efficace n’existe. Toujours tester avec un client connu après activation.
• Vendre DoS Settings comme protection DDoS: fausses attentes en matière d’attaques de bande passante. Planifier séparément le fournisseur et la protection en amont.
• Ne pas vérifier les journaux: Les blocs incorrects ou les attaques restent invisibles. Définir Log Viewer, le reporting central ou syslog comme point de fonctionnement.
• Interpréter les suppressions d’usurpation d’identité comme une pure attaque: Les erreurs de routage ou VLAN sont négligées. Comparez l’IP source, l’interface, la route et Packet Capture.

Liste de contrôle opérationnelle

Avant l’activation :

• zones, interfaces et routage compris.
• Services critiques et cas de tests définis.
• Packet Rate, Burst Rate et flags activés évalués techniquement.
• Documentation de sauvegarde ou de modification disponible.
• Journalisation et évaluation préparées.
• Zone pilote ou fenêtre de maintenance définie.

Après activation :

• Internet, VPN, WAF, DNAT, VoIP et surveillance testés.
• Log Viewer a vérifié les baisses inattendues.
• Packet Capture utilisé pour au moins un scénario de test clair lorsque des baisses se produisent.
• Les exceptions ne sont faites que de manière limitée et motivées.
• DoS bypass rules vérifiées sur source, destination, protocole et ports.
• Résultat enregistré dans la documentation d’exploitation.

Régulièrement :

• Vérifiez les événements DoS et d’usurpation d’identité.
• Vérifiez la nécessité des exceptions.
• Testez à nouveau après des modifications du réseau, des changements de VPN ou de nouveaux VLANs. Corrélez les journaux
• avec IPS, le flux de menaces, WAF et les événements de règles de pare-feu.

FAQ