Sophos Firewall : Bloquer des pays et des IP malveillantes

Dès que des services sont accessibles depuis Internet, on observe souvent rapidement du trafic indésirable : scans de ports, tentatives de connexion, réseaux de bots connus ou accès depuis des pays d’où aucun utilisateur n’est attendu. Sur Sophos Firewall, il est possible de bloquer ces sources à plusieurs niveaux.

Cet article explique deux variantes typiques :

• Bloquer des pays ou des réseaux sources avec une règle de pare-feu
• Traduire des sources indésirables dans le vide avec une règle Black Hole DNAT

Nous recommandons également Sophos Firewall Threat Feeds, afin que les IP, domaines ou URL malveillants connus puissent être automatiquement bloqués.

Orientation

Avant de bloquer des sources, il faut savoir de quel trafic il s’agit : services publiés, services locaux du pare-feu, trafic client sortant ou trafic WAF. La méthode adaptée dépend exactement de cela.

Quelle méthode convient à quel moment ?

• Règle de pare-feu avec Drop: Bloque le trafic selon Source Country, Source Network ou Source Host. Cela convient aux blocages de pays, aux réseaux individuels ou aux listes de mauvaises IP maintenues manuellement.
• Black Hole DNAT: Redirige le trafic indésirable vers une IP interne inexistante. C’est utile lorsque du trafic vers des services publiés doit être intercepté tôt.
• WAF Blocked countries: S’applique aux serveurs web publiés via WAF. Les pays sont bloqués directement dans la règle WAF.
• Local service ACL exception rule: Contrôle les services locaux du pare-feu comme WebAdmin, User Portal, VPN Portal ou SSH. C’est le bon endroit lorsque le pare-feu lui-même doit être protégé.
• Threat Feeds: Utilisent des listes dynamiques de sources malveillantes connues. Cela convient aux botnets, scanners, infrastructures de malware et adresses IP d’attaquants connues.

La méthode appropriée dépend de l’endroit où le trafic est techniquement traité. Les règles de pare-feu ne s’appliquent pas toujours au trafic destiné à une adresse hébergée utilisée dans WAF. Dans de tels cas, une règle de pays WAF ou une règle Black Hole DNAT est souvent plus appropriée.

Entrant, sortant ou pare-feu local

Avant une règle de blocage, il est important de savoir quel type de trafic est concerné. Sinon, on risque de bloquer au mauvais endroit et de se demander plus tard pourquoi l’attaque est toujours visible ou pourquoi le trafic légitime échoue.

• Entrant vers un serveur publié: Redirection de port vers RDP, HTTPS, SMTP ou application propre. Ordre DNAT, règle WAF, règle de pare-feu, IPS et journalisation
• Entrant vers le pare-feu lui-même: WebAdmin, User Portal, VPN Portal, SSH, Ping ou DNS sur le pare-feu. Device Access et Local Service ACL Exception Rules
• Sortant de clients internes: Les clients contactent des cibles suspectes sur Internet. Règle de pare-feu, Threat Feeds, Web Protection, DNS Protection et journalisation
• Serveur web via WAF: Application web publique derrière Web Server Protection. Règle WAF, Blocked countries, authentification, MFA et journaux WAF

Cette distinction est importante car une règle de pays dans Rules and policies > Firewall rules ne sécurise pas automatiquement toutes les surfaces d’attaque du pare-feu. Pour les serveurs publiés, la chaîne NAT et WAF est généralement prioritaire. Pour les portails d’administration, il est d’abord important de savoir si le service de pare-feu local est accessible depuis la zone. Pour le trafic client sortant, les Threat Feeds, Web Protection et DNS Protection sont souvent les outils les plus appropriés.

Ne pas confondre avec Device Access

Le Country Blocking et le Black Hole DNAT protègent principalement le trafic traité par des règles de pare-feu ou NAT. Les services locaux de Sophos Firewall sont un autre cas. Cela inclut par exemple WebAdmin, SSH, User Portal, VPN Portal, DNS, Ping et parfois aussi les services d’accès à distance.

Pour ces services locaux, Administration > Device access est d’abord pertinent. C’est là que l’on décide depuis quelles zones un service est fondamentalement accessible. Si l’accès doit être autorisé uniquement pour certaines adresses IP d’administration, pays ou sources de support, les Local service ACL exception rules sont le bon point de contrôle. Le processus est décrit dans Sécuriser l’accès à Sophos Firewall : Configurer correctement Device Access.

⚠️ Une règle de blocage de pays ne remplace pas une configuration propre de Device Access. Si WebAdmin, User Portal, VPN Portal ou SSH sont trop largement accessibles, le pare-feu lui-même reste une surface d’attaque. Le Country Blocking peut réduire le risque, mais ne remplace pas le durcissement fondamental de l’accès.

Pour les services locaux particulièrement sensibles, WAN ne doit pas être activé largement sous Local service ACL. Une exception rule qui autorise uniquement les sources attendues ou bloque les pays indésirables est préférable. Pour WebAdmin, une IP d’administration fixe ou un VPN de gestion est généralement plus propre qu’un filtre de pays, car Geo-IP n’est pas une véritable vérification d’identité.

Planifier les règles de blocage

Les règles de blocage doivent être planifiées afin de ne pas interrompre du trafic légitime par erreur.

Bloquer des pays avec une règle de pare-feu

Pour un blocage général de pays, on peut créer une règle de pare-feu avec Drop.

Chemin du menu :

Rules and policies > Firewall rules

Champs recommandés :

• Rule name: Nom explicite, par exemple BLOCK_COUNTRY_PANAMA
• Rule position: Top
• Action: Drop
• Source zones: Any
• Source networks and devices: Pays, groupe de pays, liste d’IP ou groupe d’hôtes
• During scheduled time: All the time
• Destination zones: Any
• Destination networks: Any
• Services: Any ou un service défini

Pour le Country Blocking, il est important que les zones source et destination ne soient pas trop restreintes. Si l’on ne saisit que WAN comme zone source, la règle peut ne pas s’appliquer à tous les chemins de trafic pertinents.

Les pays et groupes de pays sont utilisés comme objets sous Hosts and services. Pour plusieurs pays, une Country host group est plus claire que de nombreux pays individuels directement dans chaque règle. Les listes de mauvaises IP doivent être placées dans des objets IP host ou IP host group adaptés. Il faut toutefois connaître les limites : les listes IP host ne sont pas prévues pour de grands flux dynamiques arbitraires. Pour une infrastructure d’attaque qui change constamment, les Threat Feeds sont plus faciles à maintenir.

Le Country Blocking doit également être compris comme un contrôle de meilleure effort. Les données Geo-IP peuvent être incorrectes, les utilisateurs voyagent, les attaquants utilisent des proxys ou des systèmes compromis dans des pays autorisés, et les services cloud utilisent une infrastructure distribuée dans le monde entier. Par conséquent, une règle de pays ne devrait jamais être la seule mesure de protection.

Quand ne pas bloquer trop largement

Une règle de blocage est rapidement créée, mais peut ensuite générer des effets secondaires difficiles à comprendre. Il faut être particulièrement prudent lorsque des applications productives dépendent de plateformes externes, de CDN, de fournisseurs de paiement, de services cloud, de fournisseurs de surveillance ou de partenaires de support.

Avant un blocage large de pays ou d’IP, il faut donc clarifier :

• Y a-t-il des utilisateurs, partenaires ou prestataires dans les pays concernés ?
• Une application utilise-t-elle une infrastructure cloud ou CDN avec des adresses sources changeantes ?
• Les mises à jour, webhooks, surveillances, sauvegardes ou accès de support sont-ils déclenchés par des services externes ?
• Existe-t-il une possibilité de d’abord enregistrer uniquement ou de tester la règle de manière limitée dans le temps ?
• Est-il clair qui vérifie les faux positifs et comment une exception est approuvée ?

Pour les services Internet avec une véritable connexion utilisateur, les règles de pays ne sont souvent qu’une mesure supplémentaire. MFA, des règles de pare-feu strictes, des systèmes cibles à jour, IPS, protection WAF, journalisation et Threat Feeds restent plus importants qu’une liste de blocage aussi longue que possible.

Planifier une liste d’autorisation avant une liste de blocage

Pour les services critiques, une liste d’autorisation est souvent plus propre qu’une liste de blocage toujours plus longue. Si un service doit être accessible uniquement par des partenaires fixes, des filiales, des systèmes de surveillance ou des sites d’administration, il faut d’abord autoriser ces sources et bloquer le reste. Cela réduit les efforts de maintenance et empêche de devoir réagir en bloquant chaque nouvelle IP de scanner individuellement.

Une liste d’autorisation convient particulièrement pour :

• Accès administratifs à des services de gestion publiés
• Interfaces B2B avec des adresses IP de partenaires connues
• Surveillance, sauvegarde, webhooks ou points de terminaison API avec des systèmes sources fixes
• Accès de support temporaire avec ticket, date d’expiration et révision

Une liste de blocage est plus appropriée lorsqu’un service doit rester délibérément accessible au public, mais que les sources suspectes doivent être réduites. La règle doit alors être exploitée avec journalisation, date de révision et exceptions claires. Pour les serveurs web publiés via WAF, Sophos Firewall WAF : Publier des serveurs web en toute sécurité est également pertinent, car les pays, l’authentification et la protection des serveurs web y sont gérés plus près de l’application publiée.

Traiter séparément les filtres de pays WAF

Dans Web Server Protection, la règle WAF dispose de ses propres champs pour Allowed client networks, Blocked client networks, Blocked countries et Block IP addresses of unknown country-origin. Ces paramètres appartiennent à l’application web publiée et ne sont pas identiques à une règle de pare-feu Drop normale.

C’est pratique, car le filtre de pays est directement lié à la publication WAF. Il faut toutefois être prudent : Block IP addresses of unknown country-origin peut exclure des utilisateurs légitimes si leur adresse IP ne peut pas être attribuée clairement. Avant l’activation, il faut vérifier sa propre adresse IP externe avec la GeoIP2 Databases Demo. Cette option ne doit être activée que si son effet a été testé et connu du processus de support.

Pour les règles WAF, les filtres de pays ne sont qu’un élément. Authentification, MFA, certificat, Web Server Protection, signatures IPS/WAF, journalisation et serveur backend à jour restent plus importants qu’une longue liste de pays bloqués.

Black Hole DNAT et Threat Feeds

Pour les services publiés, il peut être utile d’intercepter des sources indésirables avant la règle DNAT productive. Pour l’infrastructure d’attaque dynamique, les Threat Feeds sont également utiles.

Black Hole DNAT pour les sources indésirables

Une règle Black Hole DNAT traduit le trafic vers une cible qui n’existe pas sur le réseau. Le trafic est ainsi dirigé dans le vide et n’atteint pas le service réel.

C’est particulièrement utile lorsqu’un service est publié via DNAT et que l’on souhaite intercepter certaines sources avant la redirection de port réelle.

Le Black Hole DNAT doit être utilisé de manière ciblée. Il est particulièrement adapté au trafic vers des services publiés, où une règle DNAT normale est en dessous. Pour le trafic client sortant général, les services de pare-feu locaux ou les serveurs web publiés via WAF, une règle de pare-feu, Device Access ou un paramètre WAF est généralement le meilleur point de contrôle.

Dans la règle NAT, il est important de ne pas confondre la vue originale de l’attaquant avec la destination fictive traduite. La règle doit se trouver dans Rules and policies > NAT rules au-dessus de la règle DNAT de production. Original source contient la liste d’IP bloquées, le pays ou le groupe de pays. Original destination est l’adresse WAN publique ou l’objet hôte WAN visé par l’attaquant. Translated destination est l’hôte fictif non routé. Dans ce modèle, la traduction de source et de service reste normalement sur Original.

Après l’enregistrement, il faut vérifier dans le Log Viewer si la NAT Rule ID attendue est bien touchée. Si la règle DNAT normale correspond toujours, la règle Black Hole est placée trop bas, la source ne correspond pas, ou le service ou la destination visé ne correspond pas au trafic de test.

La règle Black Hole DNAT nécessite toujours une règle de pare-feu adaptée ou un chemin de journalisation, afin que le hit reste traçable. NAT ne fait que traduire, ce n’est pas une autorisation d’accès indépendante. Si plus personne ne sait ensuite pourquoi l’hôte fictif existe ou quelle source est interceptée, cette technique devient rapidement une dette héritée.

Exemple :

• Rule name: BLOCK_BAD_IPS_COUNTRIES
• Rule position: Top
• Original source: Liste de mauvaises IP, pays ou groupe de pays
• Original destination: IP WAN publique ou objet hôte WAN
• Original service: Any ou le service publié
• Translated source (SNAT): Original
• Translated destination (DNAT): Hôte fictif qui n’existe pas
• Translated service (PAT): Original
• Inbound interface: Any
• Outbound interface: Any

L’hôte fictif doit utiliser une adresse IP qui n’existe pas sur votre réseau et qui n’est pas routée. Il est important que cette règle soit placée au-dessus des règles DNAT réelles. Les règles NAT sont traitées de haut en bas. Si la règle DNAT normale correspond d’abord, la règle Black Hole DNAT arrive trop tard.

L’hôte fictif ne doit pas être choisi au hasard. Il est judicieux d’utiliser une adresse d’un réseau de documentation ou fictif interne non utilisé, qui n’est pas routé et qui n’est pas prévu pour de vrais systèmes plus tard. La règle doit clairement décrire pourquoi cet hôte existe, afin qu’il ne soit pas accidentellement supprimé ou utilisé de manière productive.

Pourquoi l’ordre est crucial

Pour les règles NAT, la première règle correspondante l’emporte. Une règle Black Hole DNAT doit donc être très haut placée, généralement tout en haut de la table des règles NAT.

Ordre exemplaire :

1. Black Hole DNAT pour la liste des mauvaises IP et les pays bloqués
2. Règles DNAT spécifiques pour les services publiés
3. Règles SNAT spéciales
4. Règle MASQ générale pour le trafic sortant

Pour les règles de pare-feu, le même principe s’applique : les règles de blocage spécifiques sont placées au-dessus des règles d’autorisation générales. Sinon, il peut arriver que le trafic soit déjà autorisé avant que la règle de suppression ne soit vérifiée.

Ne pas laisser la source inutilement sur Any

Pour les services publiés, il faut restreindre autant que possible la source.

Les sources pertinentes peuvent être :

• Adresses IP publiques individuelles
• Réseaux de partenaires ou de filiales
• Pays d’où l’accès est attendu
• Hôtes FQDN ou groupes d’hôtes DNS, si approprié
• Groupes d’hôtes entretenus avec des adresses IP d’administration autorisées

Any n’est pertinent que si le service doit vraiment être accessible dans le monde entier. Dans ce cas, des mesures de protection supplémentaires doivent être activées : journalisation, IPS, MFA si possible, authentification forte, systèmes cibles à jour et Threat Feeds.

IPv6 doit être planifié séparément. Une règle de pays IPv4 ne prouve pas que la même application est également protégée via IPv6. Dans les environnements dual-stack, il faut des règles IPv6 adaptées, une journalisation et un chemin de test. Si IPv6 n’est pas utilisé en production, il doit être désactivé, bloqué ou introduit avec documentation.

Utiliser également les Threat Feeds

Les listes manuelles et les règles de pays sont statiques. L’infrastructure des attaquants change constamment. C’est pourquoi nous recommandons également Sophos Firewall Threat Feeds.

Les Threat Feeds sont particulièrement utiles pour :

• Adresses IP de scanners connues
• Réseaux de bots
• Infrastructure de malware
• Hôtes compromis
• Listes de mauvaises IP dynamiquement entretenues

Ainsi, il n’est pas nécessaire de gérer chaque IP individuellement. Le pare-feu peut déjà bloquer les mauvaises sources connues avant qu’elles n’atteignent le service publié.

Tests et exploitation

Après la modification, les compteurs, les logs et les chemins d’accès attendus doivent être vérifiés consciemment.

Exploitation et révision des listes de blocage

Les listes de blocage ne sont utiles que si elles restent compréhensibles en exploitation. Une règle de pays ou une liste de mauvaises IP ne doit donc pas simplement croître indéfiniment sans que quelqu’un vérifie les correspondances, les exceptions et les effets secondaires.

Pour chaque liste de blocage manuelle, il doit être documenté :

• pourquoi la source a été bloquée
• s’il s’agit d’un blocage temporaire ou permanent
• qui entretient la liste
• quand la règle sera à nouveau vérifiée
• quels services ou règles DNAT sont concernés
• comment un faux positif est approuvé

Il faut être prudent avec les réseaux cloud, CDN, d’hébergement ou de support. Une adresse IP unique peut appartenir plus tard à un autre client, une plage CDN peut contenir des services légitimes, et un prestataire externe peut changer son IP de sortie. Si un accès légitime est bloqué, il ne faut pas désactiver immédiatement toute la règle. Il est préférable de créer une exception étroite avec raison, ticket et date de révision.

Pour les serveurs publiés, il faut également vérifier si la liste de blocage s’applique vraiment avant la règle DNAT productive. Le contrôle d’exploitation dans Publier un serveur via DNAT sur Sophos Firewall aide à évaluer conjointement les services publiés, les règles NAT et la journalisation. Si les sources bloquées passent par une règle de pare-feu, Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est le chemin de test approprié.

Un examen sensé ne consiste pas seulement à jeter un coup d’œil à la règle. Il faut vérifier dans le Log Viewer si la règle correspond encore, quelles sources sont concernées et si les correspondances correspondent au risque attendu. Pour une évaluation à plus long terme, Central Firewall Reporting ou Envoyer les journaux Sophos Firewall Syslog à un SIEM sont meilleurs que les journaux locaux seuls.

Procédure de test après modification

Après une nouvelle règle de blocage, il ne faut pas seulement vérifier si l’accès indésirable disparaît. Il est également important de vérifier si le trafic souhaité fonctionne toujours et si le pare-feu enregistre la correspondance de manière compréhensible.

Procédure pratique :

1. Créer une règle avec un nom explicite, une journalisation et une description précise.
2. Si possible, tester d’abord avec une petite liste de sources ou un seul pays.
3. Vérifier le blocage attendu depuis une source externe appropriée.
4. Filtrer dans le Log Viewer par source, destination, service, ID de règle de pare-feu et ID de règle NAT.
5. Tester un accès légitime depuis une source autorisée.
6. Pour les serveurs publiés, vérifier si la règle DNAT productive s’applique toujours aux sources autorisées.
7. Documenter la date de révision et le propriétaire de la règle.

Si aucun test propre de l’extérieur n’est possible, la modification doit au moins être surveillée avec Log Viewer, Packet Capture et une fenêtre de maintenance étroite. Une règle de blocage sans correspondances visibles et sans propriétaire est difficilement distinguable d’un héritage après quelques mois.

Dépannage

Si le résultat attendu manque, il faut vérifier pas à pas les logs, le matching des règles et le comportement des policies.

Erreurs typiques

• Black Hole DNAT est en dessous de la règle DNAT normale: La règle DNAT normale correspond d’abord, la règle de blocage ne s’applique pas
• La cible fictive existe dans le réseau: Le trafic atterrit de manière inattendue sur un système réel
• La source est gérée différemment dans la règle NAT et la règle de pare-feu: Les règles deviennent difficiles à comprendre et divergent
• Le Country Blocking est utilisé comme seule mesure de protection: Les bots des pays autorisés peuvent toujours attaquer
• WAF et DNAT sont confondus: Une règle de pare-feu Drop ne protège pas automatiquement chaque publication WAF. Vérifier séparément WAF Blocked countries.
• Les services locaux du pare-feu sont protégés avec des règles de pare-feu normales: Pour WebAdmin, User Portal, VPN Portal et SSH, vérifier d’abord Device Access et Local Service ACL.
• IPv6 est oublié: Une règle IPv4 ne bloque pas un chemin IPv6.
• Les blocages IP temporaires ne sont jamais vérifiés: Les anciennes entrées bloquent plus tard des accès légitimes ou créent une complexité inutile
• Les plages cloud ou CDN sont trop largement bloquées: Les applications métier, les mises à jour ou les prestataires externes peuvent échouer
• La journalisation est désactivée: Dans le Log Viewer, il n’est pas clair quelle règle a été appliquée

Dépannage

Si une règle de blocage ne s’applique pas, il faut vérifier dans cet ordre :

1. La règle NAT ou de pare-feu est-elle vraiment au-dessus des règles d’autorisation ?
2. L’IP source correspond-elle à la liste des mauvaises IP ou au pays choisi ?
3. Le trafic est-il traité par une règle WAF, une règle DNAT ou une règle de pare-feu ?
4. La journalisation est-elle activée sur la règle de pare-feu concernée ?
5. Le Log Viewer affiche-t-il l’ID de règle de pare-feu ou l’ID de règle NAT attendu ?
6. Le trafic est-il visible dans Diagnostics > Packet capture ?
7. Existe-t-il une exception plus récente, un groupe d’hôtes ou une exclusion de Threat Feed qui influence le blocage attendu ?
8. Un blocage temporaire après un incident a-t-il été laissé en place de manière permanente ?

Pour l’analyse, La règle de pare-feu ne s’applique pas : vérifier l’ordre, la correspondance et les journaux, Utiliser l’outil Packet Capture dans WebAdmin et Comprendre NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT sont également utiles.

Si le trafic bloqué appartient en fait à un serveur publié, la règle DNAT productive doit également être vérifiée : la règle Black Hole DNAT est-elle vraiment au-dessus, la même adresse cible publique est-elle atteinte et le service est-il identique ou délibérément plus large ? Pour la publication complète, Publier un serveur via DNAT sur Sophos Firewall convient.

FAQ