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.

Le chemin de menu typique, en fonction de la version SFOS, est compris dans la plage :

Intrusion prevention > DoS & spoof protection

Si l’interface est étiquetée légèrement différemment dans une version plus récente, vous devez rechercher DoS, protection contre l’usurpation d’identité ou prévention des intrusions. Ce qui est important n’est pas le chemin de clic exact, mais plutôt que la fonction soit consciemment planifiée, testée et ensuite enregistrée.

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.

Ne pas confondre les types de protection

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.

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.

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.

Spoof Protection activez soigneusement

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. Commencez par une zone ou une interface claire, par exemple WAN ou une zone client proprement séparée.
3. Enregistrer l’activation.
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.

L’attente doit être claire : un IP-MAC pair filter activé sans Trusted MAC ou paires IP-MAC maintenues ne protège pas automatiquement. Si aucune entrée correspondante n’existe, le trafic n’est pas bloqué mais autorisé. La protection commence seulement avec 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.

DoS Settings plan

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 ?
• Quels événements doivent être uniquement enregistrés et lesquels doivent réellement être bloqués ?
• 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 :

• Packet rate : nombre de paquets qu’un hôte peut envoyer ou recevoir par minute avant que le trafic soit rejeté.
• Burst rate : pic court au-dessus du Packet Rate autorisé sans être immédiatement considéré comme un flood permanent.

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.

Cas particulier : selon Sophos, la configuration IP flood n’est pas disponible dans l’interface web, mais uniquement via CLI. Ces paramètres ne devraient pas être modifiés au passage, mais avec change, documentation et plan de retour arrière.

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

Les DoS bypass rules sont utiles lorsqu’un flux clairement connu est sinon touché à tort de manière fiable. 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 est important : Sophos Firewall vérifie d’abord si une DoS bypass rule correspond, puis applique DoS Protection au trafic restant. Une règle de bypass trop large peut donc rendre inefficace même une bonne configuration DoS. Pour les règles bypass, source, destination, protocole, port source et port destination doivent être définis consciemment au lieu d’utiliser * par facilité.

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 Central, vérifiez si Central Firewall Reporting rend visibles les événements souhaités.

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 NAT sont affectés : le seuil DoS compte le trafic du point de vue d’une source partagée. Vérifier le seuil, le chemin NAT et un 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.

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 : le bypass est évalué avant DoS Protection et peut contourner complètement le contrôle. Définir source, destination, protocole et ports de manière stricte.
• 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