Retour à l'accueil

Protection du serveur ipset et CrowdSec contre les scanners

L'article décrit un système de filtrage de trafic à trois couches basé sur ipset, autoblocage et CrowdSec. Le blocage au niveau du noyau réduit le trafic indésirable à 0,3 % et la charge. Code pour la mise à jour des ensembles, métriques et limitations fournis.

Trois couches WAF : ipset + CrowdSec pour serveur Linux
Advertisement 728x90

Filtrage multi-couches du trafic : ipset, blocage auto et CrowdSec pour sécuriser les serveurs

Un système de filtrage basé sur ipset avec blocage automatique des IP suspectes et CrowdSec réduit le trafic parasite de 12 % à moins de 0,3 %. Le blocage s'effectue au niveau du noyau Linux (L3/L4), avant même que nginx et PHP-FPM ne traitent les requêtes. Cela allège la charge sur les serveurs de production Bitrix, où les scans de .env, wp-login.php et config.php faisaient grimper les échecs jusqu'à 99 %.

Avantages clés : visibilité totale sur les blocages, mises à jour atomiques des listes d'IP et conception modulaire pour des ajustements rapides par projet.

Avantages par rapport aux WAF externes et CDN

Les WAF externes et CDN excellent pour les applications mondiales massives, mais pour des configurations locales à faible trafic, un filtrage auto-hébergé est idéal.

Google AdInline article slot

Principales raisons de le mettre en place soi-même :

  • Contrôle total : Voir précisément quelles IP sont bloquées, par quelle règle et pour combien de temps.
  • Blocage avant l'application : Pas de gaspillage de ressources nginx/PHP sur du trafic pourri.
  • Flexibilité : Ajout facile de règles pour des patterns spécifiques à Bitrix comme .env ou .git.
  • Simplicité : Pas de couches supplémentaires alourdissant la pile.

L'analyse se fait sur les logs HTTP (L7), mais les drops de paquets se produisent dans iptables avec ipset au niveau du noyau.

Structure de défense en trois couches

Le système est étagé pour un filtrage progressif.

Google AdInline article slot

Couche 1 : Géoblocage. Les paquets des pays non pertinents sont rejetés immédiatement — pas besoin d'analyse HTTP.

Couche 2 : Blocage auto des IP suspectes. Après le géoblocage, détection de patterns comme wp-login.php, shell.php, .env. Les coupables sont bannis 2 heures.

Couche 3 : CrowdSec. Le bouncer alimente une liste noire globale dans ipset avec TTL.

Google AdInline article slot

La modularité permet d'activer/désactiver les couches indépendamment, minimisant les faux positifs.

ipset : La base de la scalabilité

iptables classique avec des milliers de règles IP implique des scans linéaires O(n), ce qui plombe les perfs sous charge.

ipset utilise hash:ip ou hash:net pour des lookups O(1) :

-m set --match-set blocked_ips src

Les mises à jour de listes sont atomiques via des sets temporaires et des swaps, sans interruption :

ipset create "${country}_temp" hash:net 2>/dev/null || ipset flush "${country}_temp"
if [[ -s "$temp_file" ]]; then
    while read network; do
        ipset add "${country}_temp" "$network"
    done < "$temp_file"
    ipset swap "${country}_temp" "$country"
fi
ipset destroy "${country}_temp"

Cela maintient une protection infaillible même lors des rafraîchissements massifs de listes.

Détection des scanners par patterns

Le script auto-block-suspicious.sh suit les logs en temps réel et cible les requêtes louches :

  • wp-login.php (même sur Bitrix).
  • shell.php, shoha.php.
  • .env, .git, .aws/credentials.

Les IP sont auto-bannies 2 heures. Exemple : une salve de 200+ /wp-login.php neutralisée en 20–30 s, charge normalisée instantanément.

Stats de blocage :

  • Chine : 8 802 IP.
  • Suspectes : 10 IP (ex. 4.193.97.168, 195.178.110.109).

Intégration CrowdSec

Le bouncer CrowdSec peuple l'ipset crowdsec_blacklist avec TTL :

  • Synchronisation auto des signatures globales.
  • Expiration auto à l'échéance.

CrowdSec renforce les modules custom en gérant les menaces connues sans remanier la logique.

Résultats de mise en œuvre

Comparaison des métriques (2025 sans WAF vs. 2026 avec WAF) :

| Métrique | Sans protection | Avec WAF |

|-------------------|-----------------|--------------|

| Trafic parasite | ~12 % | < 0,3 % |

| Charge moyenne | 1,8–2,5 | 0,9–1,2 |

| Taux d'échec | Jusqu'à 40 % | 12–15 % |

Les pics de scans RPS meurent au noyau ; les analytics sont désormais sans bots.

Limites :

  • Pas de défense contre les attaques L4 massives.
  • Nécessite des mises à jour CMS (Bitrix).
  • Faible contre les IP résidentielles.
  • Pas pour des projets à l'échelle CDN globale.

Points clés

  • Scalabilité : ipset offre des vérifications O(1) pour des millions d'IP.
  • Atomicité : Les swaps évitent les trous de filtrage.
  • Modularité : Couches indépendantes (géoblocage, suspectes, CrowdSec) pour un réglage fin.
  • Efficacité : Trafic parasite à 0,3 %, charge moyenne divisée par deux.
  • Transparence : Visibilité totale, pas de boîtes noires.

— Editorial Team

Advertisement 728x90

Lire ensuite