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 des règles de pare-feu correctement conçues, 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 et SFOS 23, le chemin dans 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: rejette les paquets dont l’IP source est incohérente, réduit les tentatives simples d’usurpation et rend les paquets mal routés plus visibles. Cette fonction ne remplace toutefois pas une planification rigoureuse des zones, des interfaces et du routage.
• DoS Settings: limitent les schémas simples de flooding et permettent de repérer plus tôt les attaques générant beaucoup de trafic ou les erreurs de configuration. Cette fonction ne remplace toutefois ni une protection DDoS fournie par l’opérateur, ni une WAF, ni une architecture amont correctement 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 clients, invités ou IoT dans lesquelles aucun autre réseau interne ne doit apparaître comme source.
• Emplacements où le routage, les VLANs et les zones sont clairement documentés.
• Environnements dans lesquels les rejets de paquets doivent pouvoir être analysés ultérieurement à l’aide de Packet Capture et des 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é, alors que la conception du routage ou le chemin de retour présente en réalité des incohérences.

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. Documenter les zones, les interfaces, les VLANs, les bridges et les 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érifier dans Log Viewer et Packet Capture si des paquets sont rejetés de manière inattendue.
6. Ne pas contourner immédiatement les rejets inhabituels de trafic légitime par des exceptions trop larges ; vérifier d’abord le routage, la Source-IP et l’interface.

Une erreur fréquente consiste à traiter Spoof Protection comme une simple case à cocher de sécurité. En réalité, cette fonction vérifie une hypothèse sur la conception du réseau. Si cette hypothèse est incorrecte, cela ne signifie pas nécessairement que Spoof Protection est en cause. Souvent, une interface, une route, un VLAN ou un chemin de retour n’est alors pas configuré comme prévu.

Bien comprendre IP, MAC et paires IP-MAC

Sophos distingue plusieurs types de vérification. IP spoofing rejette le trafic si l’IP source ne correspond pas à la table de routage ou si le paquet ne provient pas d’un sous-réseau directement connecté. MAC filter rejette les paquets dont l’adresse MAC n’est pas enregistrée comme Trusted MAC ; au moins une Trusted MAC Address doit être renseignée pour cela. Le filtre MAC n’est pas appliqué aux paquets DHCP. IP-MAC pair filter vérifie si la combinaison entrante d’adresse IP et d’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.

Exemple avec un commutateur de cœur de réseau : le commutateur assure le routage inter-VLAN et utilise Sophos Firewall comme passerelle par défaut. Un client du VLAN 1 avec l’adresse 10.10.10.5 envoie une requête Internet qui arrive sur l’interface LAN du pare-feu. Le fait que le commutateur connaisse les VLANs ne rend pas leurs sous-réseaux directement connectés au pare-feu. Avant l’activation, vérifier sur le pare-feu la route pour 10.10.10.5 et les sous-réseaux directement connectés. Si les conditions documentées pour IP spoofing ne sont pas remplies, la requête peut être rejetée malgré l’adresse légitime du client. Un test d’accès WAN seul ne remplace pas cette vérification du chemin interne.

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 : lorsque IP-MAC pair filter est activé dans les zones sélectionnées et que cette option est cochée, Sophos décrit le rejet des paquets provenant d’une Trusted MAC sans association IP si l’IP est inconnue. « Inconnue » signifie ici : aucune entrée correspondante dans la table de routage ou aucune provenance d’un sous-réseau directement connecté. Cela renforce la sécurité dans les réseaux maîtrisés, mais peut poser problème avec DHCP, les migrations et les changements temporaires d’IP.

Lorsque l’option n’est pas cochée, l’aide générale de SFOS 22 et SFOS 23 indique qu’une Trusted MAC avec n’importe quelle IP ainsi qu’une Trusted MAC sans association IP sont autorisées. En revanche, le guide d’ajout distinct indique de manière générale que, lorsqu’une association existe, seule une paire IP-MAC correspondante est acceptée. Ces affirmations ne doivent pas être combinées pour en déduire une garantie de blocage inconditionnelle. Contrôler conjointement le type de vérification, la zone, l’association et la case à cocher, puis vérifier dans le build installé les cas autorisés nécessaires ainsi que les cas non conformes ; si l’effet reste incertain, le clarifier avec Sophos Support avant la mise en production.

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 MACs peuvent être importées sous Intrusion prevention > DoS & spoof protection à partir d’un fichier .csv ou .txt. Dans la section Spoof protection trusted MAC, sélectionner Import, choisir le fichier avec Browse, puis le téléverser avec Upload file. L’adresse MAC et IP Association doivent être indiquées sur chaque ligne. La première ligne doit contenir exactement MAC Address,IP Association,IP Address. Les valeurs autorisées pour IP Association sont Static, DHCP, DHCPv6 et None. Avec Static, il est possible d’indiquer au maximum 16 adresses IP par MAC, séparées par des virgules ; avec les trois autres associations, le champ IP reste vide.

L’exemple de format suivant présente des associations statiques IPv4 et IPv6 ainsi que les trois associations sans champ IP :

MAC Address,IP Association,IP Address
02:00:00:00:00:01,Static,192.0.2.10,192.0.2.11
02:00:00:00:00:02,Static,2001:db8::10,2001:db8::11
02:00:00:00:00:03,DHCP
02:00:00:00:00:04,DHCPv6
02:00:00:00:00:05,None

Les adresses MAC et IP sont des valeurs fictives utilisées à titre d’exemple, et non des appareils à autoriser. Remplacer chaque ligne par l’adresse MAC réelle de l’appareil et par l’association choisie délibérément. Static convient aux adresses fixes connues, DHCP ou DHCPv6 à l’association automatique au bail ; None ne contient aucune association IP et ne remplace donc pas une vérification de paire statique.

Le pare-feu rejette l’entrée entière lors de l’importation si elle contient une adresse MAC invalide, une IP Association invalide ou une adresse IP invalide. Il faut distinguer ce cas des valeurs IP renseignées malgré une association DHCP, DHCPv6 ou None : ces valeurs IP sont rejetées ; cela ne signifie pas automatiquement que l’entrée MAC entière est supprimée. Il faut donc commencer par importer quelques lignes pilotes, puis vérifier les associations visibles et tester un cas IP-MAC autorisé ainsi qu’un cas volontairement incorrect. Un téléversement réussi ne prouve pas encore que la logique de filtrage souhaitée 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 modifier les paramètres, 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.

Les types de flood correspondent à différentes charges : SYN flood génère de nombreuses connexions TCP semi-ouvertes ; le serveur répond par SYN-ACK, mais ne reçoit aucune réponse finale. TCP flood désigne un débit élevé de paquets TCP en général. UDP flood peut solliciter l’hôte cible par des vérifications de ports et des réponses ICMP pour les ports inutilisés. ICMP/ICMPv6 flood implique de nombreuses requêtes Echo Requests et peut consommer de la bande passante. Dans le cas d’un DDoS, la charge provient de plusieurs appareils de manière distribuée ; un seuil par source ne répond donc pas à la même question qu’un seuil par destination.

Les options suivantes sont également pertinentes dans cet écran :

• Dropped source routed packets: rejette les paquets dont l’itinéraire est défini par l’expéditeur. Cette possibilité de manipulation du routage est ainsi limitée.
• Disable ICMP/ICMPv6 redirect packet: n’accepte pas les redirections ICMP ou ICMPv6. Les routeurs en aval peuvent aussi envoyer légitimement de tels messages pour une route meilleure ou active ; cette option modifie donc une hypothèse de routage, et pas seulement la détection des attaques.
• ARP hardening: n’autorise les ARP Replies que si l’IP source et l’IP de destination se trouvent dans le même sous-réseau. Sophos décrit cette fonction comme une protection contre ARP Flood et ARP Poisoning.

Ces options constituent un durcissement de base utile, car elles peuvent réduire les manipulations du comportement de routage ou d’ARP. Il convient néanmoins de les tester après activation, en particulier dans les réseaux comportant des routeurs en aval, des segments anciens ou des architectures Layer-2 inhabituelles.

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 affiche en temps réel les sources ou destinations auxquelles un seuil s’applique et le nombre de paquets rejetés. Cliquer sur le type d’attaque pour ouvrir les détails ; le lien d’état depuis DoS & spoof protection mène également à cette vue. Après une détection, la limitation s’applique initialement pendant dix secondes. Si l’attaque est alors terminée, la limitation est levée. Si elle se poursuit, le pare-feu réinitialise ce compteur de manière glissante toutes les dix secondes et maintient la limitation. Une nouvelle attaque provenant de la même source ou visant la même destination réinitialise à nouveau le compteur et réactive la limitation. Lorsque l’attaque prend fin, 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 ; les événements journalisés sont nécessaires pour une analyse rétrospective.

Les seuils de WebAdmin s’appliquent par source ou destination, et non à une somme globale de tous les hôtes. Exemple purement explicatif avec Burst rate 100 : les 100 premiers paquets sont initialement autorisés sans vérification de Packet rate ; le débit est ensuite comparé. En dessous du débit configuré, le trafic est accepté ; au-dessus, il peut être rejeté. 100 n’est pas une valeur recommandée pour la production.

Ne pas confondre le déroulement de l’exemple avec le temporisateur d’état : l’aide générale de SFOS 22 et SFOS 23 qualifie ce déroulement de tentative d’ARP Flood et décrit d’autres rejets de paquets et entrées de journal si le paquet suivant de la même source arrive dans les 30 secondes. Elle décrit une autorisation si le paquet précédent remonte à plus longtemps, mais exclut explicitement toute inscription automatique dans l’Allow List sur la seule base de 30 secondes sans trafic. L’aide distincte sur l’état DoS décrit, en revanche, la limitation glissante de dix secondes expliquée ci-dessus. Il ne s’agit pas de délais universels fiables d’autorisation ou d’attente pour tous les types de flood. Ne pas déduire une autorisation sur la seule base d’un temporisateur : évaluer conjointement le type d’attaque, l’état en temps réel, les journaux et un flux de test légitime clairement délimité ; clarifier tout comportement inexpliqué avec Sophos Support.

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.

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. Si une exception large semble nécessaire, vérifier d’abord si les seuils, l’architecture ou le cas de test ont été mal évalués.

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é.

Une exception est créée sous Intrusion prevention > DoS & spoof protection, dans la section DoS bypass rule, avec Add. SFOS 22 et SFOS 23 exigent IP version, les IP source et de destination, Protocol, Source Port et Destination Port ; * représente n’importe quelle adresse ou n’importe quel port. Pour un contrôle de disponibilité HTTPS de 198.51.100.20 vers 203.0.113.10, une configuration adaptée serait : IP version IPv4, Source 198.51.100.20, Destination 203.0.113.10, Protocol TCP, Source Port * et Destination Port 443. Les deux adresses réservées à la documentation doivent être remplacées par les points de terminaison réels. Le Source Port reste variable uniquement parce que les clients utilisent généralement un port source dynamique. Après Save, tester précisément ce flux ainsi qu’un autre flux ; seul le contrôle de disponibilité défini doit pouvoir 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é.

Automatisation XML : conserver l’identité et les champs parents

Avant d’automatiser ces paramètres, vérifier la configuration enregistrée et l’API help propre à l’objet dans le build installé. Les correspondances suivantes précisent les champs SFOS 22/SFOS 23 ; elles ne constituent pas des requêtes complètes. Utiliser l’API XML en toute sécurité explique les opérations d’écriture explicites, la protection de l’accès et les contrôles distincts du transport, de la réponse XML et de l’objet enregistré.

Règle bypass : ancienne et nouvelle correspondance, pas un nom

DoSBypassRules n’a pas d’identité Name documentée. La correspondance comprend IPFamily (IPv4 ou IPv6), SourceIPNetmask, DestinationIPNetmask et Protocol (TCP, UDP, ICMP ou AllProtocol), avec SourcePort et DestinationPort en plus pour TCP/UDP. Les ports sont des valeurs individuelles de 1 à 65535 ou * ; la référence n’établit pas ici de payload pour une plage de ports. Pour l’ajout/la modification, le tableau indique * pour les deux adresses et TCP pour le protocole comme valeurs par défaut. Ne pas reprendre ces valeurs larges comme exception souhaitée, mais définir délibérément la correspondance complète.

Lors d’une mise à jour, DoSBypassRules/OldConfiguration contient l’ancienne combinaison des mêmes champs ; les enfants directs de DoSBypassRules contiennent la nouvelle correspondance souhaitée. OldConfiguration relève de l’identité de mise à jour, pas de l’ajout ni de la suppression. La référence de suppression désigne les champs de correspondance, pas un nom. Identifier donc la combinaison réellement enregistrée avant de la supprimer. La structure d’exemple Add/Edit indique expressément que les ports ne concernent que TCP/UDP, alors que les listes de paramètres, y compris Delete, déclarent les deux ports obligatoires sans réserve. Cela ne permet pas de déduire un payload de suppression fiable et exécutable pour ICMP/AllProtocol : clarifier l’aide propre à l’objet et le build, sans envoyer de valeurs de port inventées.

Trusted MAC : clé MAC et familles d’adresses distinctes

Pour TrustedMAC, MACAddress est l’identité ; lors d’une mise à jour, TrustedMAC/OldConfiguration/MACAddress conserve l’ancienne clé, tandis que TrustedMAC/MACAddress contient l’adresse MAC souhaitée. Delete ne désigne que MACAddress, pas Name ni OldConfiguration. Sauvegarder l’entrée précise et ses associations avant Update ou Delete, puis vérifier à nouveau la liste.

TrustedMAC/IPV4Association et TrustedMAC/IPV6Association sont des associations indépendantes avec Static, DHCP ou None ; le tableau API indique Static comme valeur par défaut pour chacune. Les champs d’adresses CSV associés s’appellent exactement IPV4Address et IPV6Address. L’import de fichier utilise aussi DHCPv6 : ne pas transférer cette valeur dans IPV6Association sans vérification. Pour AssociateIP, la valeur d’exemple et la description se contredisent ; aucune valeur d’écriture autorisée n’en est déduite ici. Les réserves précédentes sur le filtrage IP-MAC effectif restent nécessaires pour les entrées gérées par API.

L’import de fichier est une opération distincte Upload_TrustedMAC, avec Upload_TrustedMAC/TrustedMACListFile pour .csv ou .txt. L’exemple indique le nom du fichier transmis en multipart, mais n’établit ni un nom précis de partie multipart ni son association à ce champ XML. Ne pas en déduire une requête de téléversement prête à l’emploi ; clarifier d’abord le contrat d’import propre au build, puis contrôler les associations importées.

Ne pas aplatir Spoof Prevention ni DoS Settings

Le nom répété est intentionnel dans la structure d’exemple : SpoofPrevention est la racine, SpoofPrevention/SpoofPrevention l’option d’activation. SpoofPrevention/RestrictUnknownIPOnTrustedMAC est une option distincte. Les trois types de contrôle ont des listes de zones séparées : SpoofPrevention/IPSpoofing/EnableOnZone/Zone, SpoofPrevention/MACFilter/EnableOnZone/Zone et SpoofPrevention/IPMACFilter/EnableOnZone/Zone. L’exemple montre Enable/Disable, le tableau des paramètres indique plutôt on/off, et la note de désactivation est ambiguë. Ni ces indications ni des listes de zones omises ou vides ne confirment une syntaxe d’effacement ou de désactivation. Clarifier les valeurs et le retour arrière dans le build installé avant toute écriture.

Sous DoSSettings, SYNFlood, UDPFlood, TCPFlood et ICMPFlood ont chacun leurs propres parents Source et Destination. Sous Source figurent PacketRatePerSource, BurstRatePerSource et ApplyFlag ; sous Destination, PacketRatePerDestination, BurstRatePerDestination et ApplyFlag. Par exemple, DoSSettings/UDPFlood/Destination/ApplyFlag concerne uniquement la limite UDP de destination. Le tableau autorise des débits de paquets de 1–600000 et des valeurs burst de 1–10000 ; sa valeur par défaut 1 et les nombres de l’exemple ne sont pas une référence de production. Les flags supplémentaires se trouvent sous DoSSettings/DroppedSourceRoutedPackets/Destination/ApplyFlag, DoSSettings/DisableICMPRedirectPacket/Destination/ApplyFlag et DoSSettings/DisableARPFlooding/Destination/ApplyFlag. Ne pas fusionner les libellés répétés du tableau en un PacketRate, BurstRate ou ApplyFlag global ; conserver les valeurs enregistrées avec leur chemin parent.

Lire les codes avec l’opération et l’état enregistré

La référence énumère les codes propres aux opérations suivants, pas des résultats HTTP universels :

• Add DOS ByPass Rules : 200, 400, 401, 403, 409, 500 ; Edit DOS ByPass Rules : 200, 400, 401, 403, 404, 500. Ne pas confondre notamment le 409 d’ajout et le 404 de modification.
• Configure Spoof Prevention et Configuration DOS Settings : chacun 200, 400, 401, 403, 404, 500.
• Upload Trusted MAC List : 200, 400, 401, 403, 404, 409, 500.
• Delete DOS ByPass Rule et Delete Trusted MAC : seulement 200, 500 sur ces pages.
• Add Trusted MAC et Update Trusted MAC : chacun 200 avec Operation Successful. et 500 avec Operation Fail..

Pour les autres opérations citées, les messages restent des symboles JavaScript dans les sources complètes, et non des textes de réponse résolus :

Après chaque modification, comparer la réponse aux zones, débits, associations ou combinaisons bypass réellement enregistrés. En cas d’erreur ou de réponse incertaine, relire l’état actuel avant de réessayer ; ne pas recréer l’entrée à l’aveugle ni déduire l’efficacité du filtrage de 200 seul. Vérifier ensuite séparément un flux de test correspondant et un autre non correspondant, comme expliqué plus haut.

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é au moyen de requêtes HTTP autorisées : vérifier la règle WAF et Webserver Protection.
• Une adresse IP source connue comme malveillante lance une attaque : vérifier les Threat Feeds ou le blocage par pays/adresse IP.
• Tentative d’exploitation d’une vulnérabilité d’un service : activer une politique IPS adaptée à la règle.
• La liaison Internet est saturée par une attaque DDoS : faire intervenir le fournisseur d’accès, un service de scrubbing ou une protection DDoS en amont.
• La règle de pare-feu autorise trop de trafic : revoir et nettoyer l’ensemble des règles, le NAT et le modèle d’objets.
• Les rejets de paquets ne sont pas explicables : améliorer la journalisation, Packet Capture, Syslog ou Central Reporting.

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. Filtrer Log Viewer sur les événements Firewall et les événements Security pertinents.
2. Générer du trafic de test avec une IP source, une IP de destination et un service clairement définis.
3. Utiliser Packet Capture lorsque les rejets de paquets ne sont pas clairement expliqués.
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

• Activer Spoof Protection sans comprendre le routage : le trafic légitime peut être bloqué. Vérifier au préalable les zones, les interfaces, les routes et les chemins de retour.
• Appliquer les seuils DoS sans vérification : la VoIP, la supervision, les scans ou les services publiés peuvent être perturbés. Prévoir une mesure de référence et une phase de test.
• Confondre Packet Rate et Burst Rate : le débit de paquets soutenu et les pics de courte durée sont deux paramètres de réglage distincts. Tous deux doivent être adaptés au service.
• Résoudre chaque anomalie par une exception trop large : le durcissement devient inefficace et difficile à gérer. Cerner la cause et documenter précisément les exceptions à portée restreinte.
• Définir une DoS bypass rule trop large : dans WebAdmin, le bypass est évalué avant les DoS Settings qui y sont configurés et peut entièrement contourner ce contrôle. Restreindre Source, Destination, le protocole et les ports ; vérifier également les politiques CLI distinctes.
• Laisser IP-MAC-Pair-Filter vide : sans entrées tenues à jour, aucune association efficace n’est établie. Après l’activation, toujours vérifier avec un client de test connu.
• Présenter DoS Settings comme une protection DDoS : cela crée de fausses attentes face aux attaques qui saturent la bande passante. Planifier séparément la protection du fournisseur d’accès et la protection en amont.
• Ne consulter aucun journal : les blocages injustifiés ou les attaques restent invisibles. Intégrer la consultation de Log Viewer, Central Reporting ou Syslog aux tâches d’exploitation.
• Interpréter les rejets de paquets liés au spoofing uniquement comme une attaque : les erreurs de routage ou de VLAN passent inaperçues. Comparer la Source-IP, l’interface, la route et les données de Packet Capture.

Liste de contrôle opérationnelle

Avant l’activation :

• Zones, interfaces et routage compris.
• Services critiques et cas de test définis.
• Packet Rate, Burst Rate et options activées évalués sur le plan technique.
• Sauvegarde ou documentation du changement disponible.
• Journalisation et analyse préparées.
• Périmètre pilote ou fenêtre de maintenance défini.

Après l’activation :

• Internet, VPN, WAF, DNAT, VoIP et supervision testés.
• Log Viewer vérifié pour repérer les rejets de paquets inattendus.
• Packet Capture utilisé pour au moins un cas de test clairement défini si des rejets de paquets se produisent.
• Exceptions définies uniquement avec un périmètre restreint et une justification.
• DoS bypass rules vérifiées quant à la source, à la destination, au protocole et aux ports.
• Résultat consigné dans la documentation d’exploitation.

Régulièrement :

• Examiner les événements DoS et d’usurpation.
• Vérifier la nécessité des exceptions.
• Effectuer de nouveaux tests après des modifications du réseau, des changements de VPN ou l’ajout de VLANs.
• Corréler les journaux avec les événements IPS, Threat-Feed, WAF et ceux des règles de pare-feu.

FAQ