Automatisation des blocklists pare-feu : intégrer des flux IP et domaines sans panne

Tirer un flux de menace dans votre pare-feu semble simple : pointer la liste dynamique externe (EDL) vers une URL HTTPS, planifier un rafraîchissement, laisser l'appareil bloquer IP et domaines malveillants. En pratique, la différence entre une blocklist utile et une panne production tient souvent aux allowlists, à la taille de liste, au choix de catégorie et à ce qui se passe quand le flux ne se télécharge pas.

isMalicious publie des blocklists IP et domaines mises à jour toutes les 15 minutes, couvrant malware, C2, phishing, spam, nœuds de sortie Tor, VPN/proxy et trafic scanner/crawler. Listes disponibles en TXT, JSON, CSV et formats éditeur en tailles 10K, 100K et 1M entrées. La page solution pare-feu décrit les patterns d'intégration ; ce guide approfondit les décisions opérationnelles qui rendent l'automatisation sûre.

Avant de pointer le pare-feu vers une URL

Répondez à ces questions d'abord. Les ignorer, c'est bloquer son propre CDN, casser un fournisseur de paie ou remplir le helpdesk de tickets faux positifs.

Que voulez-vous bloquer ?

| Catégorie | Bloque | Profil de risque FP | |-----------|--------|---------------------| | Malware | Hôtes de distribution malware connus | FP faible si liste curatée | | C2 | Serveurs commandement et contrôle | FP faible–moyen | | Phishing | Sites de vol d'identifiants | FP moyen (hébergement partagé) | | Spam | IP/domaines à l'origine du spam | FP moyen | | Tor exit nodes | Sorties réseau Tor | FP élevé | | VPN/proxy | IP VPN et proxy commerciaux | FP élevé (télétravail) | | Scanner/crawler | Scanners de ports, crawlers agressifs | FP faible entrant ; revoir sortant |

Commencer par une catégorie — typiquement malware ou C2 — avant d'activer des listes plus larges. La liste agrégée « block all » est pratique mais offre le moins de contrôle sur les faux positifs.

Quelle capacité de liste pour votre pare-feu ?

Les pare-feu ont des limites mémoire et de performance de lookup. Une liste 1M entrées sur un Palo Alto PA-5220 peut étouffer un appareil plus petit. Vérifier la taille EDL maximale documentée et mesurer les temps de commit après import.

isMalicious propose des tailles filtrées (10K, 100K, 1M) pour adapter la liste au matériel. Commencer à 10K, mesurer les hits deux semaines, monter en charge si la liste bloque mais manque des menaces.

Fail-open ou fail-closed ?

Quand le flux HTTPS est injoignable pendant une mise à jour :

• Fail open : Conserver la dernière liste téléchargée avec succès. Le trafic correspondant aux entrées obsolètes reste bloqué ; les nouvelles menaces attendent la reprise du flux. Choix majoritaire en production.
• Fail closed : Retirer la liste ou bloquer tout le trafic que la liste aurait couvert. Empêche les blocs obsolètes mais peut provoquer un afflux soudain de trafic malveillant non bloqué — ou, mal implémenté, tout bloquer.

Configurer le pare-feu pour conserver la liste précédente en cas d'échec de téléchargement et alerter l'équipe si le rafraîchissement échoue plus de deux cycles consécutifs.

Le pattern HTTPS EDL

La plupart des pare-feu modernes supportent les listes dynamiques externes via HTTPS. Le pattern est identique entre éditeurs :

1. Générer une URL de flux depuis votre compte isMalicious avec clé API intégrée ou en en-tête (voir docs API).
2. Configurer l'EDL dans l'interface de gestion :
   • URL : https://api.ismalicious.com/blocklist/<category>?format=txt&size=100k
   • Intervalle de rafraîchissement : 15–60 minutes (aligné sur la fréquence de mise à jour du flux).
   • Type : liste IP, domaine ou URL selon la catégorie.
3. Attacher l'EDL à une politique de sécurité — typiquement deny sortant ou entrant sur zones non fiables.
4. Commit et vérifier que la liste a importé le nombre d'entrées attendu.

Notes spécifiques éditeur

Palo Alto Networks : Les EDL supportent IP, domaine et URL. Les listes domaine matchent les FQDN ; la politique doit s'appliquer aux événements de résolution DNS, pas seulement aux connexions IP directes.

Fortinet : Les connecteurs externes tirent des listes texte vers des groupes d'adresses. Surveiller l'impact mémoire sur les petits FortiGate.

Autres : Si l'éditeur accepte un fichier texte une entrée par ligne, le format TXT par défaut convient. Pour les formats éditeur, sélectionner l'export approprié sur la page blocklists.

Tester dans une politique lab avant d'attacher l'EDL à la règle deny production.

Allowlists : la partie que la plupart des équipes oublient

Les blocklists bloquent le connu-mauvais. Les allowlists protègent le connu-bon d'être bloqué quand même. Il faut les deux.

Ce qui appartient à l'allowlist :

• Plages IP CDN et cloud dont l'entreprise dépend (Cloudflare, Akamai, AWS, Azure, Google Cloud).
• Domaines et IP fournisseurs SaaS (Microsoft 365, Google Workspace, Salesforce, paie).
• Votre propre infrastructure publique.
• Endpoints partenaires et fournisseurs requis pour l'activité.
• Résolveurs DNS et serveurs NTP.

Comment la maintenir :

1. Exporter le journal de hits blocklist sur une semaine.
2. Identifier les entrées bloquées ayant généré des tickets helpdesk ou plaintes métier.
3. Investiguer chacune avec Bulk Check ou lookups IP / domaine individuels.
4. Si l'entrée est légitime pour votre environnement, l'ajouter à l'allowlist avec raison documentée et date d'expiration.
5. Revoir l'allowlist trimestriellement. Des entrées ajoutées pendant un incident ne sont peut-être plus nécessaires.

Précédence allowlist : Configurer le pare-feu pour que les entrées allowlist l'emportent sur les matches blocklist (ordre de politique Palo Alto ; override d'action Fortinet).

Déploiement par étapes : de la surveillance au bloc

Ne basculez pas une blocklist 100K entrées en mode deny le jour un.

Phase 1 : Import et comptage (semaine 1)

• Tirer la liste dans le pare-feu comme EDL.
• L'attacher à une politique log-only qui enregistre les matches sans dropper le trafic.
• Mesurer les hits quotidiens par catégorie.

Phase 2 : Alerte sur les hits (semaine 2)

• Envoyer les logs EDL vers votre SIEM.
• Corréler les hits avec les alertes existantes. Bloquez-vous ce que l'IDS a déjà attrapé, ou voyez-vous de nouveaux matches ?
• Échantillonner 20 hits aléatoires et investiguer. Estimer le taux de faux positifs.

Phase 3 : Bloc sur zones non critiques (semaine 3)

• Activer l'action deny sur Wi-Fi invité, réseaux lab ou trafic sortant de VLAN non production.
• Surveiller tickets helpdesk et SIEM pour plaintes ou trafic légitime manqué.

Phase 4 : Rollout production (semaine 4+)

• Étendre la politique deny aux zones production.
• Maintenir l'allowlist à jour.
• Configurer l'alerte sur échec de téléchargement de flux.

Documenter chaque gate de phase. Si la Phase 2 montre 5 % de FP sur domaines phishing, corriger l'allowlist avant de continuer — ne pas espérer que ça s'améliore à l'échelle.

Faux positifs CDN et hébergement partagé

Les faux positifs blocklist les plus courants viennent de l'infrastructure partagée :

• Une page phishing sur un WordPress compromis fait bloquer toute l'IP d'hébergement. Le blog marketing sur le même hébergeur ne charge plus.
• Une IP de bord CDN sert contenu malveillant et légitime. Bloquer l'IP casse tous les sites derrière ce nœud.
• Une URL cloud function partage l'infrastructure avec le bucket de staging d'un attaquant.

Stratégies de mitigation :

1. Préférer les blocklists domaine aux blocklists IP quand le modèle de menace le permet. Le bloc au niveau domaine est plus précis que l'IP sur hébergement partagé.
2. Utiliser des listes par catégorie plutôt que block-all. Une liste IP C2 contient moins d'entrées hébergement partagé qu'une liste phishing large.
3. Vérifier avant de bloquer. Pour zones à fort impact, faire passer les matches blocklist par une étape d'enrichissement (API) avant l'action deny.
4. Maintenir agressivement les allowlists CDN. Les grandes plages IP CDN doivent être en allowlist sauf raison spécifique d'inspecter le trafic origine CDN.

Lors d'un faux positif, utiliser Bulk Check pour voir combien d'entrées blocklist partagent l'hébergement avec des services légitimes. Si le ratio est élevé, passer à une catégorie plus petite ou ciblée.

Mesurer les taux de hit

Une blocklist jamais maintenue bloque soit rien (mal configurée), soit les mauvaises choses (entrées obsolètes). Mesurer mensuellement :

| Métrique | Comment mesurer | Plage saine | |----------|-----------------|-------------| | Hits de bloc quotidiens | Logs trafic pare-feu | Non nul, tendance stable | | Hits par catégorie | Filtrer par source EDL | Correspond au modèle de menace | | Tickets faux positifs | Helpdesk tagué « blocklist » | Proche de zéro après réglage allowlist | | Succès rafraîchissement flux | Statut EDL pare-feu | 100 % sur 7 jours | | Nombre d'entrées liste | Log import EDL | Stable ±5 % entre rafraîchissements | | Corrélation SIEM | Alertes matchant IP/domaines bloqués | Couverture détection croissante |

Zéro hit sur 30 jours ? La politique n'est peut-être pas attachée, la liste vide, ou le trafic contourne la zone inspectée. Vérifier avant de supposer être protégé.

Hits ×10 en une semaine ? Soit vous subissez une attaque (investiguer), soit le flux a ajouté une grande plage IP chevauchant l'infrastructure légitime (correction allowlist).

Combiner blocklists et autres contrôles

Les blocklists au pare-feu sont une couche. Elles fonctionnent mieux avec :

• Filtrage passerelle email pour domaines phishing avant le clic (sécurité email).
• Filtrage URL proxy pour trafic HTTPS que le pare-feu ne peut pas inspecter.
• Filtrage DNS pour blocs domaine avant établissement de connexion.
• Corrélation SIEM pour confirmer que le trafic bloqué était réellement malveillant.

La page blocklist montre la couverture live sur les réseaux clients — utile pour valider que votre choix de catégorie correspond à l'activité de menace réelle.

Gestion blocklist pilotée par API

Si le pare-feu manque de support EDL natif ou si vous avez besoin de filtrage custom, tirez les listes par programmation :

curl -u "$API_KEY:$API_SECRET" \
  "https://api.ismalicious.com/blocklist/malware?format=txt&size=100k" \
  -o /var/lib/firewall-edl/malware.txt

Planifier via cron, systemd timer ou outil d'orchestration, valider le fichier (non vide, nombre de lignes dans la plage attendue), puis déclencher un reload pare-feu. Ce pattern offre une validation pré-import que les téléchargements EDL natifs n'ont pas — vous pouvez annuler si le fichier est corrompu ou anormalement petit.

Voir la référence API complète pour authentification, paramètres de catégorie et rate limits.

Checklist opérationnelle

1. Sélectionner une catégorie blocklist correspondant à la menace prioritaire (commencer par malware ou C2).
2. Choisir la taille de liste (10K) adaptée au modèle pare-feu.
3. Construire une allowlist CDN, SaaS et endpoints métier critiques.
4. Importer la liste en mode log-only une semaine.
5. Échantillonner et investiguer les hits ; ajuster l'allowlist.
6. Activer deny sur une zone non critique ; surveiller une semaine.
7. Déployer en production avec alerte échec de flux configurée.
8. Revoir hits et faux positifs mensuellement.
9. Monter en taille ou ajouter des catégories seulement quand la liste actuelle est stable.

Les blocklists automatisées réduisent le travail manuel de copie d'IOC dans les règles pare-feu. Elles n'éliminent pas le besoin d'allowlists, de déploiement par étapes et de mesure continue. Les équipes qui sautent ces étapes apprennent souvent les faux positifs depuis le bureau du DAF — pas depuis leur SIEM.