Générateur d’extrait allow/deny CIDR (nginx)

Le générateur de snippets CIDR Allow/Deny pour nginx crée des blocs de configuration nginx prêts à l'emploi avec les directives allow et deny à partir de listes d'adresses IP ou de blocs CIDR. Saisissez des adresses comme 192.168.1.0/24 et 10.0.0.0/8, choisissez le mode allowlist ou blocklist, et obtenez des directives correctement formatées que vous pouvez coller directement dans vos blocs server ou sauvegarder comme fichier d'inclusion.

Comprendre le contrôle d'accès nginx

Si vous utilisez nginx comme serveur web ou reverse proxy, le contrôle d'accès par IP est l'un des moyens les plus simples et les plus efficaces de protéger les ressources sensibles. Le module ngx_http_access_module est compilé dans nginx par défaut et ne nécessite aucune installation supplémentaire -- il suffit d'ajouter des directives allow et deny à votre configuration. C'est l'approche standard pour restreindre l'accès aux panneaux d'administration, aux API internes, aux serveurs de staging et à tout endpoint qui ne devrait pas être accessible publiquement.

Le concept est simple : vous listez les adresses IP ou blocs CIDR qui doivent être autorisés (ou refusés), et nginx vérifie chaque requête entrante contre la liste. Le détail qui piège beaucoup de monde est l'ordre d'évaluation. Nginx traite les directives allow et deny de haut en bas et s'arrête à la première correspondance. Si deny all apparaît avant vos lignes allow, chaque requête est refusée quelle que soit l'IP source. Le générateur gère cela automatiquement en plaçant toujours la règle par défaut à la fin, mais comprendre le modèle d'évaluation est important lorsque vous déboguez des problèmes d'accès.

Le contrôle d'accès nginx se complique avec les configurations multi-niveaux. Les directives d'un bloc location remplacent celles du bloc server englobant, qui remplacent celles du bloc http. Si vous définissez une allowlist dans votre bloc server mais oubliez de l'appliquer à un location spécifique, ce location hérite de ce que le parent définit. Pour les configurations complexes, l'approche la plus propre est de placer vos règles d'accès dans un fichier séparé et de l'inclure partout où nécessaire, ce qui correspond exactement au workflow que le générateur supporte.

Comment générer des directives Allow/Deny pour nginx

1. Saisissez vos adresses IP ou blocs CIDR -- un par ligne ou séparés par des virgules.
2. Sélectionnez le mode : allowlist (autoriser les IP listées, refuser toutes les autres) ou blocklist (refuser les IP listées, autoriser toutes les autres).
3. Le générateur formate chaque entrée en une directive nginx valide avec la syntaxe correcte.
4. Copiez la sortie dans votre bloc server, location ou http nginx, ou sauvegardez-la comme fichier d'inclusion.
5. Exécutez nginx -t pour tester la configuration, puis rechargez avec nginx -s reload.

Exemples de sortie Allow/Deny nginx

Mode allowlist

Entrée :

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Sortie :

allow 192.168.1.0/24;
allow 10.0.0.0/8;
allow 203.0.113.50;
deny all;

Mode blocklist

Entrée :

198.51.100.0/24
203.0.113.0/24

Sortie :

deny 198.51.100.0/24;
deny 203.0.113.0/24;
allow all;

Utilisation d'un fichier d'inclusion

server {
    listen 443 ssl;
    server_name admin.example.com;

    include /etc/nginx/conf.d/admin-allowlist.conf;

    location / {
        proxy_pass http://backend;
    }
}

Quand utiliser le générateur de snippets CIDR nginx

• Protection du panneau d'administration -- Restreindre l'accès à /admin ou /wp-admin uniquement aux plages IP du bureau et du VPN.
• Contrôle d'accès au serveur de staging -- Limiter les environnements de staging aux adresses IP des équipes de développement et de QA.
• Limitation de débit par IP pour les API -- Combiné avec limit_req_zone, autoriser des limites plus élevées pour les IP de partenaires connus tout en restreignant les sources inconnues.
• Blocage géographique -- Bloquer des plages CIDR de pays entiers pour l'accès à des ressources spécifiques.
• Exigences de conformité -- Restreindre l'accès aux endpoints de données sensibles aux plages de réseau d'entreprise approuvées.

Fonctionnement des directives de contrôle d'accès nginx

Ordre de traitement des règles

Nginx évalue les directives allow et deny dans l'ordre de haut en bas. La première règle correspondante l'emporte. Cela signifie :

# Ceci FONCTIONNE -- allow spécifique avant deny général
allow 192.168.1.0/24;
deny all;

# Ceci NE FONCTIONNE PAS -- deny all est évalué en premier
deny all;
allow 192.168.1.0/24;   # jamais atteint

Le générateur place toujours la règle par défaut (deny all ou allow all) à la fin pour garantir une évaluation correcte.

Portée des directives

Les directives de contrôle d'accès peuvent être placées à différents niveaux :

• Bloc http -- S'applique à tous les hôtes virtuels
• Bloc server -- S'applique à un hôte virtuel spécifique
• Bloc location -- S'applique à un chemin URL spécifique

location /api/internal {
    allow 10.0.0.0/8;
    deny all;

    proxy_pass http://internal-api;
}

Support IPv6

Le générateur gère les adresses IPv6 et les blocs CIDR avec la même syntaxe :

allow 2001:db8::/32;
allow 192.168.1.0/24;
deny all;

Combinaison avec les headers de proxy

Lorsque nginx se trouve derrière un load balancer ou un CDN, l'IP du client provient d'un header comme X-Forwarded-For plutôt que de la connexion TCP. Dans ce cas, utilisez le module ngx_http_realip_module pour définir la véritable IP client avant l'évaluation du contrôle d'accès :

set_real_ip_from 10.0.0.0/8;       # faire confiance à la plage de votre load balancer
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;              # autoriser en fonction de l'IP client réelle
deny all;

Conseils pratiques pour le contrôle d'accès nginx

L'erreur la plus fréquente avec le contrôle d'accès nginx est de ne pas tester la configuration avant de recharger. Un point-virgule manquant, un bloc CIDR invalide ou même un caractère parasite fera échouer nginx -t, et si vous rechargez sans tester, l'ancienne configuration reste active -- mais la prochaine fois que nginx redémarre (après un reboot serveur, par exemple), il refusera de démarrer car la configuration invalide est sur le disque. Exécutez toujours nginx -t avant nginx -s reload, et envisagez d'intégrer cette vérification dans vos scripts de déploiement comme un contrôle automatisé.

Lorsque vous protégez des panneaux d'administration, ne vous reposez pas uniquement sur le contrôle d'accès par IP. Utilisez-le comme une couche dans une approche de défense en profondeur : l'allowlist IP pour limiter qui peut même atteindre la page de connexion, une authentification forte derrière, et une limitation de débit pour prévenir les attaques par force brute depuis toute IP autorisée. Les adresses IP peuvent être usurpées au niveau applicatif (via des headers forgés), donc assurez-vous de configurer correctement real_ip_header si vous êtes derrière un reverse proxy, et ne faites jamais confiance directement à X-Forwarded-For sans valider le proxy amont immédiat.

Pour les grandes allowlists (des centaines d'entrées), envisagez d'utiliser le module geo au lieu de directives allow/deny individuelles. Le module geo utilise un arbre de recherche binaire en interne, ce qui est plus rapide que le parcours linéaire des directives allow/deny pour les grandes listes. Le compromis est une configuration légèrement plus complexe, mais pour les listes dépassant 50 à 100 entrées, la différence de performance est mesurable sur les serveurs à fort trafic.

Questions fréquentes

Pourquoi nginx refuse-t-il de démarrer après l'ajout de règles allow/deny ? La cause la plus fréquente est un point-virgule manquant à la fin d'une ligne de directive. Chaque ligne allow et deny doit se terminer par ;. Le générateur gère cela automatiquement. Exécutez nginx -t pour vérifier la syntaxe avant de recharger.

Puis-je mélanger les directives allow et deny dans un même bloc ? Oui, mais l'ordre est important. Nginx traite les règles de haut en bas et s'arrête à la première correspondance. En général, vous autorisez un ensemble d'IP et refusez toutes les autres, ou vous refusez un ensemble et autorisez toutes les autres. Mélanger allow et deny pour différentes plages IP dans le même bloc est valide mais plus difficile à maintenir.

Quelle est la différence entre deny all et return 403 ? deny all est une directive de contrôle d'accès qui renvoie une réponse 403 Forbidden. return 403 est une directive de contenu qui renvoie également un 403 mais ne participe pas à la chaîne d'évaluation allow/deny. Pour le contrôle d'accès basé sur l'IP, utilisez toujours les directives allow/deny.

Comment inclure le snippet généré dans ma configuration nginx ? Sauvegardez la sortie dans un fichier comme /etc/nginx/conf.d/allowlist.conf et utilisez la directive include dans votre bloc server ou location : include /etc/nginx/conf.d/allowlist.conf;

Que faire si mon nginx est derrière un CDN ou un load balancer ? Vous devez configurer le module ngx_http_realip_module pour extraire la véritable IP client du header approprié (généralement X-Forwarded-For ou X-Real-IP). Sans cela, nginx voit l'IP du CDN ou du load balancer pour chaque requête, et votre allowlist est comparée à la mauvaise adresse.

Y a-t-il une limite au nombre de règles allow/deny que nginx peut gérer ? Il n'y a pas de limite stricte, mais les performances se dégradent linéairement avec le nombre de règles car nginx les parcourt séquentiellement. Pour les listes dépassant 100 entrées, envisagez le module geo ou la directive map pour de meilleures performances. Pour la plupart des configurations avec moins de 50 règles, l'impact sur les performances est négligeable.

Outils associés

• Apache Require ip Snippet Generator - Générer des directives Apache Require ip
• Allowlist Builder - Construire une allowlist CIDR minimale à partir d'une liste d'IP
• Blocklist Builder - Construire une blocklist CIDR minimale à partir d'une liste d'IP
• iptables Rule Generator - Générer des règles iptables à partir d'un CSV
• IP:Port Allowlist Validator - Valider des entrées IP:port en masse