Sophos Firewall Spoof Protection et DoS Settings vérifient
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 :
Protect > 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
| Fonction | Ce qui est utile | Ce qui ne suffit pas |
|---|---|---|
| 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.
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 :
- Zones de documents, interfaces, VLANs, ponts et LAGs.
- Vérifiez les routes statiques, les routes SD-WAN, les routes VPN et les chemins asymétriques.
- Identifiez les services publiés via DNAT ou WAF.
- Notez les services critiques tels que VoIP, la surveillance, la sauvegarde, les analyses, le VPN et les connexions au site.
- Préparez la journalisation et l’évaluation centrale si les événements doivent être traçables ultérieurement.
- 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 :
- Enregistrez la configuration actuelle ou au moins documentez les paramètres concernés.
- Commencez par une zone ou une interface claire, par exemple WAN ou une zone client proprement séparée.
- Enregistrer l’activation.
- Exécutez les connexions de test planifiées : accès Internet, VPN, services publiés, serveurs centraux, surveillance.
- Vérifiez Log Viewer et Packet Capture pour les chutes inattendues.
- 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.
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.
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é.
| Problème | Meilleur module supplémentaire |
|---|---|
| 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 :
- Log Viewer filtre le pare-feu et les événements de sécurité pertinents.
- Déclenchez le trafic de test avec une adresse IP source, une adresse IP de destination et un service clairs.
- Utilisez Packet Capture pour les gouttes peu claires.
- Pour un stockage plus long, planifiez syslog vers SIEM ou serveur de journaux.
- 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.
Erreurs typiques
| Erreur | Impact | Meilleure approche |
|---|---|---|
| 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 |
| Résoudre chaque anomalie avec une large exception | Le renforcement devient inefficace et déroutant | Limiter la cause et documenter étroitement les exceptions |
| 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.
- 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.
- 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.