Nginx on KnightLi Blog

Cómo comprobar CVE-2026-42945: condiciones de Nginx Rift, revisión de versiones y recomendaciones de actualización

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 es una vulnerabilidad de seguridad en NGINX Open Source y NGINX Plus. También se la conoce como Nginx Rift. El problema está en ngx_http_rewrite_module, y el tipo de vulnerabilidad es heap-based buffer overflow.

Este tipo de noticia se convierte con facilidad en titulares como “oculta durante 18 años”, “control remoto sin contraseña” o “30% de servidores afectados”. Esas frases se propagan bien, pero al leer los parches y la descripción de NVD conviene separar el riesgo en hechos concretos: el problema es grave y no requiere una cuenta iniciada; pero no todos los Nginx quedan comprometidos automáticamente. Para activarlo hacen falta condiciones específicas de configuración rewrite y de solicitud.

Empezar por la descripción oficial

La descripción de NVD para CVE-2026-42945 puede resumirse así:

Afecta a NGINX Plus y NGINX Open Source.
La vulnerabilidad está en ngx_http_rewrite_module.
El problema puede activarse cuando una directiva rewrite va seguida de rewrite, if o set, se usan grupos de captura PCRE sin nombre como $1 y $2, y la cadena de reemplazo contiene un signo de interrogación ?.
Un atacante no autenticado puede enviar una solicitud construida para activar la vulnerabilidad.
El resultado puede ser un heap buffer overflow y el reinicio de un proceso worker de NGINX.
Si ASLR está desactivado en el sistema, la ejecución de código es posible.

F5, como CNA, asigna estas puntuaciones:

CVSS v4.0: 9.2, Critical.
CVSS v3.1: 8.1, High.
CWE: CWE-122 Heap-based Buffer Overflow.

Así que no se trata de un caso normal de “mala configuración que causa un 404”. Es una vulnerabilidad de seguridad de memoria cubierta por una corrección oficial de Nginx.

Qué afirmaciones necesitan contexto

Primero, “sin contraseña” debe entenderse como ataque no autenticado. Es decir, el atacante no necesita entrar a un panel de administración de Nginx, obtener SSH ni tener una cuenta de la aplicación. Pero eso no significa que cualquier Nginx expuesto a internet pueda tomarse sin más.

Segundo, “control remoto directo” depende de las condiciones. La formulación oficial más prudente es que la vulnerabilidad puede causar reinicios de procesos worker; en sistemas donde ASLR está desactivado, la ejecución de código es un resultado posible. En entornos con ASLR activado, endurecimiento de compilación de la distribución y permisos de ejecución restringidos, la ruta de riesgo es más compleja.

Tercero, “30% de servidores afectados” no debe interpretarse como “toda la cuota de mercado de Nginx equivale a superficie expuesta”. La exposición real depende de la versión, de si el módulo afectado está presente, de si existe la configuración rewrite concreta, de si la distribución ya aplicó backport del parche y del estado de endurecimiento del entorno donde corre Nginx.

La forma más precisa de decidirlo es sencilla: si ejecutas Nginx en producción, revísalo pronto; pero no decidas si estás afectado solo por el porcentaje de un titular.

Cómo determinar el alcance afectado

Según la información de publicación de nginx.org, las versiones nginx-1.30.1 stable y nginx-1.31.0 mainline publicadas el 13 de mayo de 2026 incluyen varias correcciones de seguridad, entre ellas el buffer overflow de ngx_http_rewrite_module registrado como CVE-2026-42945.

Si usas código fuente oficial de Nginx o paquetes oficiales, prioriza:

NGINX Open Source stable: actualizar a 1.30.1 o posterior.
NGINX Open Source mainline: actualizar a 1.31.0 o posterior.
NGINX Plus: revisar la versión corregida para la rama correspondiente de F5.

Si usas Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Alpine, imágenes de contenedor, Plesk, paneles de control, Ingress Controller o componentes administrados por un proveedor cloud, no mires solo la versión upstream que muestra nginx -v. Muchas distribuciones aplican backport de parches de seguridad a versiones antiguas de paquetes. La cadena de versión puede parecer vieja aunque el parche ya esté incorporado.

Comprobación de urgencia en un minuto

Usa estas preguntas para clasificar el riesgo rápidamente:

¿Este Nginx está expuesto directamente a internet, o forma parte de un API Gateway, proxy inverso, balanceador de carga o capa de entrada Ingress?
¿Usas paquetes oficiales de Nginx, compilaciones desde código fuente, paneles de terceros o imágenes de contenedor sin haber confirmado el estado de corrección de CVE-2026-42945?
¿La configuración contiene reglas rewrite complejas, especialmente rewrite, if o set consecutivos y capturas sin nombre como $1 y $2?
¿Algún destino rewrite incluye rutas de solicitud, parámetros de consulta u otra entrada controlada por el usuario?
¿El sistema está poco endurecido, por ejemplo con ASLR desactivado, workers con demasiados privilegios o permisos de contenedor demasiado amplios?

Si se cumplen los dos primeros puntos y todavía no se revisó la configuración rewrite, trátalo como alta prioridad. Los puntos de entrada públicos, entornos compartidos, Kubernetes Ingress, proxies de borde y Nginx que transportan tráfico de login o API deben actualizarse o sustituirse primero por paquetes con corrección confirmada.

Cómo confirmar la corrección en Debian / Ubuntu / RHEL / Alpine

Los usuarios de distribuciones no deben mirar solo nginx -v. Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux y Alpine suelen aplicar backport de parches de seguridad a ramas estables, así que la versión visible puede seguir siendo inferior a 1.30.1 o 1.31.0 de nginx.org.

En Debian / Ubuntu, revisa advisories de seguridad, changelog del paquete y candidatos de actualización:

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

En RHEL / AlmaLinux / Rocky Linux, revisa actualizaciones de seguridad y changelog del paquete:

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

En Alpine, revisa la versión instalada y las actualizaciones de la rama de seguridad:

1
2

apk info -v nginx
apk version -v nginx

Si el gestor de paquetes, el advisory de la distribución o el advisory del proveedor dice explícitamente que CVE-2026-42945 está corregido, puedes tratarlo como backport aplicado aunque el número de versión upstream parezca antiguo. A la inversa, si la versión parece alta pero el origen no está claro, confirma igualmente la fecha de compilación y el origen del parche.

Cómo comprobar imágenes de contenedor e Ingress Controller

En entornos de contenedores, revisa el Nginx dentro de la imagen, no solo el host. Primero confirma la versión realmente incluida:

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

También revisa si la imagen base fue actualizada. Si la imagen se construye sobre Debian, Ubuntu, Alpine o paquetes de distribución, el criterio vuelve a ser el advisory y el changelog de esa distribución. Reiniciar una imagen vieja no sirve; la imagen en sí debe reconstruirse o reemplazarse.

En Kubernetes Ingress, confirma tres cosas:

Si el proyecto Ingress Controller publicó un advisory o una versión corregida para CVE-2026-42945.
Si el digest de la imagen del controller que corre en el clúster realmente cambió, no solo el tag.
Si la versión de Nginx integrada, los parámetros de compilación y la configuración de plantillas del controller siguen conteniendo reglas rewrite de alto riesgo.

Puedes empezar revisando la imagen en ejecución:

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

Si usas un Ingress o gateway administrado por un proveedor cloud, revisa también el advisory del servicio correspondiente. Los componentes administrados normalmente no se corrigen con un apt upgrade ejecutado por el usuario; necesitas la corrección del proveedor o cambiar a una versión ya corregida.

Qué patrones rewrite merecen atención

Esta vulnerabilidad está relacionada con la configuración rewrite. Empieza buscando en la configuración de Nginx:

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

Presta atención a patrones como este:

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

Las capturas sin nombre como $1 y $2, junto con el ? en el destino de reemplazo, forman parte de las condiciones clave descritas por las fuentes oficiales. Durante la revisión, presta especial atención a:

Un rewrite seguido de otro rewrite, if o set.
Capturas amplias como (.*) o (.+) reutilizadas como $1 o $2.
Destinos rewrite que contienen ? para añadir o descartar parámetros de consulta.
Entradas rewrite que provienen de rutas públicas, Host, URI, parámetros o valores controlados por upstream.
Reglas rewrite generadas por paneles, gateways, anotaciones de Ingress o plantillas.

Si no puedes actualizar de inmediato, aplica mitigaciones temporales:

Reducir reglas rewrite complejas.
Sustituir capturas sin nombre por capturas con nombre más claras.
Evitar concatenar ? innecesarios en cadenas de reemplazo.
Añadir reglas WAF o de proxy inverso para entradas de alto riesgo.
Confirmar que ASLR está activado.
Reducir privilegios de los workers de Nginx y verificar systemd sandbox, SELinux/AppArmor y otros endurecimientos.

Estas medidas son mitigaciones, no sustituyen al parche.

Prioridad de remediación

Prioriza por superficie expuesta:

Puntos de entrada Nginx expuestos a internet.
Proxies inversos, API Gateway y gateways de borde.
Nginx en entornos multiinquilino.
Kubernetes Ingress Controller.
Plesk, paneles de control, imágenes de marketplace cloud y otros componentes que incluyen Nginx.
Nginx internos que transportan tráfico crítico de negocio.

Cómo verificar después de actualizar: nginx -t, reload y estado de workers

Después de actualizar, no te quedes solo con el mensaje de éxito del gestor de paquetes. Confirma que la configuración, los procesos y el binario real ya cambiaron. Primero valida la configuración:

`1`	`nginx -t`

Si no hay errores, recarga de forma suave:

`1`	`systemctl reload nginx`

Si la actualización del paquete sustituyó el binario, confirma que los workers antiguos salieron:

`1`	`ps aux \| grep nginx`

También puedes revisar la hora de inicio del proceso master y la ruta del binario para asegurarte de que el servicio en ejecución no sea un proceso antiguo que sigue residente. Si hace falta, programa una ventana de mantenimiento y reinicia el servicio para evitar que workers o contenedores antiguos sigan procesando solicitudes.

En contenedores e Ingress, confirma también que el rollout de la nueva imagen se completó de verdad:

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

La verificación clave no es “el comando se ejecutó”, sino “el tráfico en producción ya lo atienden procesos Nginx que incluyen la corrección”.

No ignores el mismo lote de correcciones de Nginx

Las versiones 1.30.1 y 1.31.0 publicadas por nginx.org el mismo día no solo corrigen CVE-2026-42945. La información de publicación también menciona HTTP/2 request injection, SCGI/uWSGI buffer overread, charset module buffer overread, HTTP/3 address spoofing, OCSP resolver use-after-free y otros problemas.

Eso significa que un entorno de producción no debería limitarse a una regla temporal para un solo CVE. Conviene tratar esta ronda de seguridad de Nginx como una actualización completa.

Resumen

El punto clave de CVE-2026-42945 no es “todos los Nginx pueden tomarse al instante”. Es una vulnerabilidad de seguridad de memoria presente durante mucho tiempo en el módulo rewrite, que puede activarse mediante solicitudes no autenticadas bajo configuraciones concretas. El resultado directo más claro es el fallo y reinicio de workers; en entornos más débiles, como sistemas con ASLR desactivado, el riesgo de ejecución de código aumenta.

Para equipos de operaciones, el orden de actuación es simple:

Confirmar el origen y la versión de Nginx.
Revisar advisories de la distribución, F5, nginx.org o proveedor cloud.
Actualizar cuanto antes a una versión corregida o a un paquete de seguridad de la distribución.
Revisar configuraciones rewrite complejas, especialmente combinaciones de $1, $2 y ?.
Confirmar ASLR, aislamiento de privilegios y estado de recarga del servicio.

El titular puede asustar. La corrección debe ser tranquila: confirmar exposición, actualizar y después limpiar reglas rewrite de alto riesgo.

Referencias

Limitación de velocidad en Nginx: añadir rate limit para solicitudes de escaneo 404 y 400 de alta frecuencia

Fri, 01 May 2026 05:41:31 +0800

Si los logs de un sitio empiezan a mostrar una gran cantidad de respuestas 404 y 400, muchas veces no se debe a usuarios haciendo clic en enlaces rotos. Lo habitual es que un escáner automático esté probando rutas como .env, .git, wp-admin, phpmyadmin o xmlrpc.php.

Estas solicitudes generan varios problemas:

el access log crece rápido;
el error log se llena de ruido inútil;
sitios estáticos o servicios de proxy inverso desperdician conexiones en solicitudes inválidas;
los problemas reales quedan enterrados bajo ruido de escaneo.

Nginx puede controlar esto con limit_req y limit_conn. Pero hay un punto importante: Nginx no puede limitar directamente por “el código de respuesta será 404 o 400”, porque el rate limit se aplica antes de generar la respuesta.

La práctica correcta es limitar por adelantado las rutas de escaneo, orígenes sospechosos y solicitudes globales de alta frecuencia que normalmente terminan produciendo 404 / 400.

Idea básica

Conviene dividirlo en tres capas:

Aplicar un límite suave para todo el sitio y evitar que una sola IP golpee demasiado.
Aplicar un límite estricto a rutas comunes de escaneo y devolver 404 directamente.
Limitar conexiones concurrentes por IP.

Una forma segura de desplegarlo es empezar con reglas de rutas de escaneo y access_log off, observar un día y, si todavía hay muchas rutas aleatorias con 404, añadir limit_req global.

Definir primero las zonas en http

limit_req_zone y limit_conn_zone deben estar dentro de http {}. No pueden colocarse dentro del server {} de un sitio concreto.

Puedes añadirlas al bloque http {} de /etc/nginx/nginx.conf:

http {
    # Rate limit por IP de cliente para páginas normales
    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;

    # Más estricto para rutas sospechosas de escaneo
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;

    # Límite de conexiones concurrentes
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

También puedes crear un archivo nuevo:

`1`	`sudo nano /etc/nginx/conf.d/limit-zones.conf`

Con este contenido:

1
2
3

limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

Esto presupone que tu nginx.conf incluye dentro de http {}:

`1`	`include /etc/nginx/conf.d/*.conf;`

Usar las zonas dentro de server

La configuración de un sitio suele estar en algo como /etc/nginx/sites-enabled/www.example.com y normalmente contiene un bloque server {}. Ahí no debes volver a escribir limit_req_zone; solo se usan las zonas ya definidas.

Ejemplo:

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # Límite suave para todo el sitio, permitiendo ráfagas cortas
    limit_req zone=perip_general burst=30 nodelay;
    limit_conn addr_conn 20;

    # Rutas comunes de escaneo: límite estricto y sin access log
    location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
        access_log off;
        limit_req zone=perip_scan burst=5 nodelay;
        return 404;
    }

    # El resto de location /, listen ssl y demás configuración va aquí
}

Si te preocupa afectar tráfico normal con el límite global, empieza solo con la regla de rutas de escaneo:

location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
    access_log off;
    limit_req zone=perip_scan burst=5 nodelay;
    return 404;
}

Qué significan estos parámetros

Esta línea:

`1`	`limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;`

significa:

limit_req_zone: define la zona de contabilidad para limitar solicitudes.
$binary_remote_addr: usa la IP del cliente como clave y consume menos memoria que $remote_addr.
zone=perip_general:20m: crea una zona de memoria compartida llamada perip_general de 20m.
rate=5r/s: cada IP puede hacer, en promedio, 5 solicitudes por segundo.

Esta línea:

`1`	`limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;`

es similar, pero más estricta:

perip_scan: zona dedicada a rutas sospechosas de escaneo.
rate=1r/s: cada IP solo puede hacer 1 solicitud por segundo.

Para conexiones concurrentes:

1
2

limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
limit_conn addr_conn 20;

Esto limita cada IP a un máximo de 20 conexiones simultáneas.

Cómo entender burst y nodelay

Ejemplo:

`1`	`limit_req zone=perip_general burst=30 nodelay;`

Se puede leer así:

rate=5r/s: la tasa media a largo plazo es de 5 solicitudes por segundo.
burst=30: se permiten 30 solicitudes extra en una ráfaga corta.
nodelay: si se supera la tasa media pero no el burst, Nginx procesa inmediatamente; solo rechaza cuando se supera el burst.

Sin nodelay, Nginx intenta retrasar y encolar parte de las solicitudes. Para páginas normales, nodelay suele ser más fácil de razonar. Para APIs sensibles, conviene ajustar según el comportamiento real.

Error común: limit_req_zone en el lugar equivocado

Si ves un error como:

`1`	`2026/04/30 21:33:48 [emerg] 2290771#2290771: "limit_req_zone" directive is not allowed here in /etc/nginx/sites-enabled/example.com:9`

significa que limit_req_zone está en un contexto no permitido.

Un error típico es ponerlo dentro de server {}:

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;

    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
}

Esto no funciona.

Regla sencilla:

limit_req_zone define la zona, va en http {}.
limit_req usa la zona, va en server {} o location {}.
limit_conn_zone define la zona de conexiones, va en http {}.
limit_conn usa la zona de conexiones, va en server {} o location {}.

Bloquear temporalmente IPs claramente anómalas

Si los logs confirman que algunas IPs envían escaneos de forma continua, puedes bloquearlas temporalmente:

deny 45.95.42.164;
deny 185.177.72.51;
deny 185.177.72.5;
deny 185.177.72.56;
deny 185.177.72.58;

Estas directivas deny pueden ir en server {} o en un location {} concreto. Mantenerlas a largo plazo depende del riesgo de falsos positivos y del origen del tráfico.

Comprobar y recargar

Primero comprueba la configuración:

`1`	`sudo nginx -t`

Si no hay errores, recarga:

`1`	`sudo systemctl reload nginx`

No reinicies directamente el servicio. reload permite que Nginx cargue la nueva configuración de forma suave y con menos riesgo.

Parámetros recomendados

Para un sitio personal o estático, puedes empezar con:

páginas normales: rate=5r/s a 10r/s;
rutas de escaneo: rate=1r/s;
rutas de escaneo: burst=5;
límite global: burst=30;
concurrencia por IP: 10 a 20.

Si el tráfico normal es muy bajo, puedes ser más estricto. Si el sitio tiene muchas imágenes, scripts o API, relaja el límite de páginas normales para no afectar visitas reales.

La forma más estable es desplegar por fases:

Aplicar primero access_log off + return 404 a rutas de escaneo.
Añadir después el límite estricto perip_scan.
Observar logs durante un día.
Si siguen apareciendo muchos 404 aleatorios, activar el límite global suave.

Notas más recientes sobre la compilación desde el código fuente de GoAccess: desde la instalación del código fuente hasta los informes HTML en tiempo real

Wed, 29 Apr 2026 00:08:00 +0800

Esto está organizado para el 2026-04-29.
En este punto, la última versión estable que figura en el archivo README oficial es “1.10.2”.

1. Instale primero las dependencias de compilación

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. Descargue el paquete fuente más reciente

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. Configurar las opciones de compilación

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

Si también desea compatibilidad con TLS para informes HTML en tiempo real:

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. Construir e instalar

1
2

sudo make
sudo make install

5. Verificar la versión

1
2

goaccess --version
which goaccess

6. Ver informes directamente en la terminal

Para registros combinados comunes de Nginx o Apache:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Si la ruta del registro es Apache:

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. Generar un informe HTML estático

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

También puedes escribirlo en el directorio actual:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. Genere un informe HTML en tiempo real

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Para cambiar el puerto:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

Para vincularse solo a localhost:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. Siga los registros continuamente

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

Desde el principio del archivo y mantenlo activo:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. Mire solo ciertas solicitudes

Por ejemplo, solo solicitudes que contengan firefox:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

Por ejemplo, sólo 5xx y 3xx:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. Analizar varios registros juntos

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

Lea registros comprimidos y sin comprimir juntos:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. Habilitar subprocesos múltiples

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

Aumentar el tamaño del trozo:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. Procesamiento incremental

Primero persista en un registro antiguo:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

Luego agregue el registro actual:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

Solo lectura de datos persistentes:

`1`	`goaccess --restore`

14. El conjunto de comandos que ejecutaría primero

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

Básicamente eso es todo.
Si su objetivo es claro, instalar la última versión fuente y hacer que --log-format=COMBINED más --real-time-html funcione primero suele ser suficiente. Después de eso, la mayoría de los cambios se refieren solo a rutas de registro, archivos de salida y puertos.

Renovar automáticamente los certificados Let's Encrypt en Ubuntu (Certbot + Nginx)

Fri, 03 Apr 2026 00:00:00 +0000

Los certificados Let’s Encrypt son válidos solo por 90 días, por lo que los sitios de producción siempre deben habilitar la renovación automática para evitar el tiempo de inactividad de HTTPS.

Si ya emitiste el certificado con Certbot, generalmente quedan dos cosas:

Configurar una tarea de renovación programada
Verifique que el flujo de trabajo de renovación realmente funcione

Primero, verifique si Certbot ya creó un programador

Dependiendo de su distribución, es posible que Certbot ya haya instalado un programador (por ejemplo, un systemd timer o /etc/cron.d/certbot).

Puedes consultar con:

`1`	`systemctl list-timers \| grep certbot`

Si ya existe un temporizador válido, normalmente no necesitará una entrada adicional en el crontab.

Agregar un trabajo de Crontab manualmente (ejemplo recomendado)

Si prefiere administrar la renovación explícitamente, edite el crontab raíz:

`1`	`sudo crontab -e`

Agregue esta línea (se publica todos los días a las 03:00):

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

Lo que significa:

0 3 * * *: se ejecuta a las 03:00 todos los días
certbot renew: renueva los certificados que están próximos a caducar
--pre-hook: detiene Nginx antes de la renovación (común para el modo independiente)
--post-hook: inicia Nginx después de la renovación
>> /tmp/certbot-renew.log 2>&1: agregar registros para solucionar problemas

Ejecute una prueba en seco antes de confiar en Cron

Después de agregar la tarea, valide el flujo completo manualmente:

`1`	`sudo certbot renew --dry-run`

Si el ensayo tiene éxito, podrá confiar con seguridad en el trabajo programado.

Notas comunes

Si utiliza el complemento webroot o nginx, a menudo no necesita detener Nginx. En muchas configuraciones, recargar Nginx después de la renovación es suficiente:

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew solo realiza una renovación real cerca del vencimiento, por lo que ejecutarla diariamente es normal.
Para el mantenimiento a largo plazo, considere escribir registros en una ruta persistente como /var/log/letsencrypt/.

Resumen

La renovación automática de certificados confiable no consiste solo en escribir un comando. La clave es confirmar que el flujo de trabajo puede ejecutarse de un extremo a otro.

Una configuración estable suele consistir sólo en estos tres pasos:

Verifique si la programación a nivel del sistema ya existe
Agregue cron si es necesario y mantenga registros
Valide una vez con --dry-run

Cómo verificar si Certbot puede renovar correctamente un certificado Let's Encrypt

Thu, 08 Dec 2022 00:00:00 +0000

Después de emitir un certificado gratuito de Let’s Encrypt con Certbot, la pregunta más importante es si la renovación automática funcionará.

Los certificados de Let’s Encrypt tienen una validez limitada. Si la renovación falla sin que nadie lo note, HTTPS puede romperse cuando el certificado caduque. Certbot ofrece un modo dry-run para simular la renovación sin reemplazar el certificado real.

Usar Certbot Dry Run

Ejecuta:

`1`	`certbot renew --dry-run`

Este comando simula la renovación del certificado. Comprueba si la cuenta actual, el método de validación del dominio, la integración con el servidor web y la configuración de renovación todavía pueden completar el proceso.

Si todo va bien, Certbot mostrará un mensaje similar a:

`1`	`Congratulations, all simulated renewals succeeded`

Eso significa que el flujo de renovación funciona en este momento.

Qué Comprueba Dry Run

El dry run no solo revisa el archivo del certificado. También valida el camino completo de renovación:

si el dominio todavía puede validarse;
si la configuración del servidor web permite el challenge;
si Certbot puede leer la configuración de renovación existente;
si la cuenta y los plugins de Certbot están disponibles;
si los hooks de despliegue o recarga pueden ejecutarse.

Por eso es más útil que revisar únicamente la fecha de caducidad del certificado.

Causas Comunes De Fallo

Si certbot renew --dry-run falla, las causas habituales son:

el dominio ya no apunta al servidor;
los puertos 80 o 443 están bloqueados;
cambió la configuración de Nginx o Apache;
la ruta webroot ya no coincide con la configuración de renovación;
el firewall bloquea la validación de Let’s Encrypt;
falta el plugin de Certbot usado al emitir el certificado;
fallan los hooks o comandos de recarga.

Corrige el error indicado por Certbot y vuelve a ejecutar el dry run.

Revisar El Timer De Renovación

En sistemas con systemd, Certbot suele instalar un timer:

`1`	`systemctl status certbot.timer`

También puedes listar los timers programados:

`1`	`systemctl list-timers \| grep certbot`

Si el timer está activo y el dry-run funciona, la renovación automática debería ejecutarse correctamente.

Resumen

Para comprobar si Certbot puede renovar un certificado de Let’s Encrypt, el comando más directo es:

`1`	`certbot renew --dry-run`

Conviene ejecutarlo después de cambiar la configuración del servidor web, el firewall, el DNS del dominio o los plugins de Certbot. Esta comprobación sencilla evita que un certificado caducado rompa HTTPS por sorpresa.

Instale GoAccess en Ubuntu + Nginx para análisis de sitios en tiempo real

Thu, 14 Apr 2022 00:00:00 +0000

Instalar GoAccess

1
2

# distro repo
apt-get install goaccess

O repositorio oficial:

wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
sudo apt-get update
sudo apt-get install goaccess

Generar informe

`1`	`goaccess /var/log/nginx/www.knightli.com.access.log -o /www/www.knightli.com/r.html --log-format=COMBINED`