SERIE
Endurecer Nginx, desde el borde hacia dentro
Cinco guías que suelen leerse como recetas sueltas. En este orden son un solo proyecto: llevar un Nginx público desde sirve TLS hasta decide quién puede abrir una conexión, qué puede ejecutar su navegador, cómo viajan los bytes, qué parte del disco es alcanzable y qué ocurre con lo que sigue siendo hostil.
Por qué estas cinco van juntas
Cada uno de estos artículos responde a una pregunta que solo queda bien planteada cuando la anterior está resuelta. Limitar la tasa de una petición es un problema distinto según sepas o no quién la envía. Elegir una Content Security Policy es un problema distinto según las páginas que sirves salgan de disco o se sinteticen. Una configuración no está endurecida porque acumule directivas: lo está porque se tomó una secuencia de decisiones en un orden en el que cada una acota a la siguiente.
Comparten además una espina dorsal que se pierde al leerlos por separado: empujar cada decisión tan pronto en la ruta de la petición como sea posible. El TLS mutuo rechaza durante el handshake, antes de analizar un solo byte de HTTP. La CSP saca una decisión de ejecución del servidor y la lleva al navegador, que es donde aterriza el ataque. QUIC baja la recuperación de pérdidas por debajo de HTTP para que un paquete perdido deje de bloquear flujos ajenos. Un fichero virtual responde sin consultar el sistema de ficheros. Un tarpit gasta el presupuesto de conexiones del atacante en vez del tuyo. El mismo instinto, cinco capas.
Lo último que tienen en común es la procedencia. Las cinco cosas corren en la máquina que sirve esta página. Los bloques de configuración están citados de un servidor en producción, no montados para el artículo; los números de versión son los que están desplegados; y el tráfico del que habla el artículo del tarpit es tráfico que llegó a este host. Por eso también merece la pena leer la serie en orden en lugar de ojearla: los compromisos que se describen hubo que convivir con ellos, no se propusieron y abandonaron.
Léelas en este orden
Cada entrada indica qué decide y qué da por supuesto. Se sostienen solas si solo necesitas una, pero el orden es aquel en el que las decisiones se condicionan de verdad entre sí.
Parte 1
Dominando Mutual TLS (mTLS) con Nginx: Una Guía Completa
Empieza aquí, porque es la única decisión que cambia quién puede abrir una conexión siquiera. Todo lo que viene después —cabeceras, enrutado, límites de tasa— es una conversación con alguien a quien ya has admitido. El artículo monta una autoridad certificadora, emite certificados de cliente y luego dedica la mayor parte de su extensión a lo que las guías cortas se saltan: la revocación. CRL y OCSP son el punto en el que el TLS mutuo pasa de ser un flag de configuración a un compromiso operativo, porque emitir credenciales es fácil y retirarlas es lo que de verdad vas a necesitar con prisa.
Parte 2
Content Security Policy (CSP) con Nginx: La Guía Completa
Con la conexión ya legítima, la siguiente decisión es qué puede ejecutar el navegador con lo que le mandas. Aquí es donde se atasca la mayoría de los intentos de endurecimiento: la política ingenua o rompe el sitio o contiene un comodín que la vuelve decorativa. Es el artículo más largo de los cinco y el que documenta más modos de fallo: nonces frente a hashes, cómo strict-dynamic cambia lo que significa tu lista de permitidos, y cómo se puede saltar una política que aun así puntúa bien en un informe. Léelo antes de tocar el transporte: un sitio rápido con una política inaplicable es el intercambio equivocado.
Parte 3
Dominando QUIC y HTTP/3 con Nginx: La Guía Completa
El transporte va en tercer lugar porque cambia el rendimiento y el comportamiento ante fallos, no quién entra. QUIC sustituye el handshake de TCP+TLS por uno con menos vueltas y cifrado casi de extremo a extremo, y HTTP/3 elimina el bloqueo de cabecera de línea que hacía que un solo paquete perdido detuviera todos los flujos de la conexión. El artículo cubre lo que muerde en producción: los requisitos de compilación, el baile del anuncio Alt-Svc y la advertencia sobre la repetición en 0-RTT, que es un problema de corrección y no un parámetro de ajuste.
Parte 4
Domina los archivos virtuales en Nginx: Guía completa
El artículo más corto y la reducción de superficie de ataque más barata de los cinco. Una respuesta que el servidor sintetiza no tiene una ruta detrás, así que no hay nada que recorrer, enlazar simbólicamente ni condicionar por carrera. Es además donde root frente a alias frente a try_files se vuelve por fin concreto: tres directivas responsables de buena parte de la exposición accidental de ficheros en configuraciones reales de Nginx, porque su diferencia es una barra final y un cambio silencioso de semántica. Léelo después de los tres primeros: es la pieza que hace más pequeña la superficie que acabas de endurecer.
Parte 5
Implementar un Tarpit en Nginx: Atrapa a los Escáneres Maliciosos
La última pregunta es qué hacer con el tráfico al que se le ha negado todo lo anterior y sigue llegando. Un tarpit responde despacio a propósito, mantiene abierta la conexión del escáner y consume su presupuesto de concurrencia en vez de tu CPU, y luego alimenta con esas direcciones una lista de bloqueo que aplican las capas anteriores. Va al final a propósito: da por hecho que las decisiones previas ya están tomadas, y es la única de las cinco cuya eficacia puedes ver ocurrir en un log en tiempo real.
Hacia dónde sigue esto
La continuación natural va hacia abajo, a la red sobre la que se apoya el servidor web: el router que termina el enlace del ISP, reparte las direcciones a las que se atan estos virtual hosts y descarta la mayor parte del tráfico hostil antes de que Nginx vea siquiera un SYN. Esa es otra serie, enlazada más abajo.
Hacia arriba, la continuación es operativa más que arquitectónica. Ninguna de estas cinco decisiones sobrevive sin una forma de enterarse cuando se rompe: una CSP que bloquea en silencio un script legítimo, un certificado de cliente que caduca sin avisar, un listener de HTTP/3 que una actualización de firmware dejó de reenviar. Cada artículo termina con la comprobación concreta que detecta su propio modo de fallo, y esas comprobaciones merecen ir al sistema de monitorización en lugar de ejecutarse a mano una vez.
Qué no cubre esta serie
Aquí no hay ningún firewall de aplicación ni ajuste de conjuntos de reglas. Es una omisión deliberada: un WAF es un comparador de patrones atornillado encima de las decisiones que estos cinco artículos toman estructuralmente, y recurrir a él primero suele tapar un borde que nunca se acotó bien. Tampoco hay capítulo de ingress controller: las configuraciones están escritas para un Nginx que administras directamente, y traducirlas a un recurso anotado de Kubernetes es otro ejercicio con otros modos de fallo.