Generador de Fragmentos Allow/Deny CIDR (nginx)

El Generador de snippets CIDR Allow/Deny para nginx crea bloques de configuración nginx listos para usar con directivas allow y deny a partir de listas de direcciones IP o bloques CIDR. Ingresa direcciones como 192.168.1.0/24 y 10.0.0.0/8, elige modo allowlist o blocklist, y obtén directivas correctamente formateadas que puedes pegar directamente en tus bloques server o guardar como archivo include.

Entendiendo el control de acceso en nginx

Si ejecutas nginx como servidor web o reverse proxy, el control de acceso basado en IP es una de las formas más simples y efectivas de proteger recursos sensibles. El módulo ngx_http_access_module se compila en nginx por defecto y no requiere instalación adicional -- simplemente agregas directivas allow y deny a tu configuración. Este es el enfoque estándar para restringir paneles de administración, APIs internas, servidores de staging y cualquier endpoint que no deba ser accesible públicamente.

El concepto es directo: listas las direcciones IP o bloques CIDR que deben ser permitidos (o denegados), y nginx verifica cada solicitud entrante contra la lista. El detalle clave que confunde a la gente es el orden de evaluación. Nginx procesa las directivas allow y deny de arriba hacia abajo y se detiene en la primera coincidencia. Si deny all aparece antes de tus líneas allow, cada solicitud es denegada independientemente de la IP de origen. El generador maneja esto automáticamente colocando siempre la regla predeterminada al final, pero entender el modelo de evaluación es importante cuando estás depurando problemas de acceso.

Donde el control de acceso de nginx se complica es en configuraciones de múltiples niveles. Las directivas en un bloque location anulan las del bloque server que las contiene, que a su vez anulan las del bloque http. Si configuras una allowlist en tu bloque server pero olvidas aplicarla a una ubicación específica, esa ubicación hereda lo que defina el padre. Para configuraciones complejas, el enfoque más limpio es poner tus reglas de acceso en un archivo separado e incluirlo donde sea necesario, que es exactamente el flujo de trabajo que soporta el generador.

Cómo generar directivas allow/deny de nginx

1. Ingresa tus direcciones IP o bloques CIDR -- uno por línea o separados por comas.
2. Selecciona el modo: allowlist (permite las IPs listadas, deniega todas las demás) o blocklist (deniega las IPs listadas, permite todas las demás).
3. El generador formatea cada entrada como una directiva nginx adecuada con sintaxis correcta.
4. Copia la salida en tu bloque server, location o http de nginx, o guárdala como archivo include.
5. Ejecuta nginx -t para probar la configuración, luego recarga con nginx -s reload.

Ejemplos de salida allow/deny de nginx

Modo allowlist

Entrada:

192.168.1.0/24
10.0.0.0/8
203.0.113.50

Salida:

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

Modo blocklist

Entrada:

198.51.100.0/24
203.0.113.0/24

Salida:

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

Usando un archivo include

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

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

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

Cuándo usar el generador de snippets CIDR para nginx

• Protección de panel de administración -- Restringe el acceso a /admin o /wp-admin solo a rangos de IP de oficina y VPN.
• Control de acceso a servidor de staging -- Limita entornos de staging a direcciones IP del equipo de desarrollo y QA.
• Limitación de tasa de API por IP -- Combinado con limit_req_zone, permite límites más altos para IPs de socios conocidos mientras restringe fuentes desconocidas.
• Bloqueo geográfico -- Bloquea rangos CIDR de nivel país completos para que no accedan a recursos específicos.
• Requisitos de cumplimiento -- Restringe el acceso a endpoints de datos sensibles a rangos de red corporativa aprobados.

Cómo funcionan las directivas de control de acceso de nginx

Orden de procesamiento de reglas

Nginx evalúa las directivas allow y deny en orden de arriba hacia abajo. La primera regla que coincide gana. Esto significa:

# Esto FUNCIONA -- allow específico antes de deny general
allow 192.168.1.0/24;
deny all;

# Esto NO FUNCIONA -- deny all se evalúa primero
deny all;
allow 192.168.1.0/24;   # nunca se alcanza

El generador siempre coloca la regla predeterminada (deny all o allow all) al final para asegurar una evaluación correcta.

Alcance de directivas

Las directivas de control de acceso pueden colocarse en diferentes niveles:

• Bloque http -- Aplica a todos los virtual hosts
• Bloque server -- Aplica a un virtual host específico
• Bloque location -- Aplica a una ruta URL específica

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

    proxy_pass http://internal-api;
}

Soporte IPv6

El generador maneja direcciones IPv6 y bloques CIDR con la misma sintaxis:

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

Combinación con headers de proxy

Cuando nginx está detrás de un load balancer o CDN, la IP del cliente viene de un header como X-Forwarded-For en lugar de la conexión TCP. En este caso, usa el módulo ngx_http_realip_module para establecer la IP real del cliente antes de la evaluación del control de acceso:

set_real_ip_from 10.0.0.0/8;       # confía en tu rango de load balancer
real_ip_header X-Forwarded-For;
real_ip_recursive on;

allow 203.0.113.0/24;              # permite basándose en la IP real del cliente
deny all;

Consejos prácticos para el control de acceso en nginx

El error más común con el control de acceso de nginx es no probar tu configuración antes de recargar. Un punto y coma faltante, un bloque CIDR inválido o incluso un carácter extraño causará que nginx -t falle, y si recargas sin probar, la configuración anterior permanece activa -- pero la próxima vez que nginx se reinicie (después de un reinicio del servidor, por ejemplo), se rehusará a iniciar por completo porque la configuración inválida está en disco. Siempre ejecuta nginx -t antes de nginx -s reload, y considera poner esta verificación en tus scripts de despliegue como una compuerta automatizada.

Al proteger paneles de administración, no dependas únicamente del control de acceso basado en IP. Úsalo como una capa en un enfoque de defensa en profundidad: allowlisting de IP para limitar quién puede siquiera alcanzar la página de login, autenticación fuerte detrás de ella y limitación de tasa para prevenir ataques de fuerza bruta desde cualquier IP permitida. Las direcciones IP pueden ser falsificadas a nivel de aplicación (mediante headers forjados), así que asegúrate de configurar real_ip_header correctamente si estás detrás de un reverse proxy, y nunca confíes en X-Forwarded-For directamente sin validar el upstream inmediato.

Para allowlists grandes (cientos de entradas), considera usar el módulo geo en lugar de directivas individuales allow/deny. El módulo geo usa un árbol de búsqueda binaria internamente, que es más rápido que el escaneo lineal de allow/deny para listas grandes. La contrapartida es una configuración ligeramente más compleja, pero para listas más allá de 50-100 entradas, la diferencia de rendimiento es medible en servidores de alto tráfico.

Preguntas frecuentes

¿Por qué nginx falla al iniciar después de agregar reglas allow/deny? La causa más común es un punto y coma faltante al final de una línea de directiva. Cada línea allow y deny debe terminar con ;. El generador maneja esto automáticamente. Ejecuta nginx -t para verificar la sintaxis antes de recargar.

¿Puedo mezclar directivas allow y deny en un solo bloque? Sí, pero el orden importa. Nginx procesa las reglas de arriba hacia abajo y se detiene en la primera coincidencia. Típicamente permites un conjunto de IPs y deniegas todas las demás, o deniegas un conjunto y permites todas las demás. Mezclar allow y deny para diferentes rangos de IP en el mismo bloque es válido pero más difícil de mantener.

¿Cuál es la diferencia entre deny all y return 403? deny all es una directiva de control de acceso que devuelve una respuesta 403 Forbidden. return 403 es una directiva de contenido que también devuelve 403 pero no participa en la cadena de evaluación allow/deny. Para control de acceso basado en IP, siempre usa directivas allow/deny.

¿Cómo incluyo el snippet generado en mi configuración de nginx? Guarda la salida en un archivo como /etc/nginx/conf.d/allowlist.conf y usa la directiva include en tu bloque server o location: include /etc/nginx/conf.d/allowlist.conf;

¿Qué pasa si mi nginx está detrás de un CDN o load balancer? Necesitas configurar el módulo ngx_http_realip_module para extraer la IP real del cliente del header apropiado (usualmente X-Forwarded-For o X-Real-IP). Sin esto, nginx ve la IP del CDN o load balancer para cada solicitud, y tu allowlist coincide contra la dirección incorrecta.

¿Hay un límite de cuántas reglas allow/deny puede manejar nginx? No hay un límite estricto, pero el rendimiento se degrada linealmente con el número de reglas porque nginx las escanea secuencialmente. Para listas más allá de 100 entradas, considera usar el módulo geo o la directiva map para mejor rendimiento. Para la mayoría de las configuraciones con menos de 50 reglas, el impacto en el rendimiento es insignificante.

Herramientas relacionadas

• Generador de snippets Apache Require ip - Genera directivas Apache Require ip
• Constructor de allowlist - Construye una allowlist CIDR mínima desde una lista de IPs
• Constructor de blocklist - Construye una blocklist CIDR mínima desde una lista de IPs
• Generador de reglas iptables - Genera reglas iptables desde CSV
• Validador de allowlist IP:Port - Valida entradas masivas de IP:port