Hardening y vulnerabilidades
El control de hardening y la auditoría de software de InfraFence - qué se comprueba, las correcciones de un clic con verificación y reversión, las CVE contra OSV y CISA KEV, y las actualizaciones de seguridad.
Última actualización:
Bloquear los ataques es la mitad del trabajo; la otra mitad es cerrar lo que los dejó entrar. Cada servidor ejecuta un control de hardening y una auditoría de software 10 minutos después de que arranque el agente, y después una vez al día. Comprobar ahora y Comprobar software ahora, en la pestaña Seguridad del servidor, los ejecutan en el momento.
El control de hardening
Revisa:
- SSH: inicio de sesión de root, autenticación por contraseña, el puerto predeterminado, el reenvío X11, el número máximo de intentos de autenticación;
- archivos: permisos de
/etc/shadow,/etc/passwd,sshd_configy elauthorized_keysde root; - puertos: servicios que escuchan en la red pública;
- usuarios: cuentas con UID 0 distintas de root, cuentas sin contraseña;
- firewall y procesos (zombis);
- credenciales: archivos
.envlegibles por todos, directorios.gitexpuestos en las raíces web, los permisos de los directorios.ssh; - servidor web: divulgación de la versión, listado de directorios, el método TRACE, protocolos TLS, cabeceras de seguridad, limitación de peticiones, tamaño del cuerpo de las peticiones y ajustes de rendimiento;
- versiones: sistema operativo al final de su vida útil, kernel, actualizaciones de seguridad pendientes, PHP, MySQL, OpenSSH y el servidor web.
- PHP: la configuración de cada runtime de PHP y de cada pool de PHP-FPM (consulta Hardening de PHP más abajo).
Cada control explica qué es, por qué importa y cómo corregirlo.
Los controles de SSH leen la configuración que sshd usa de verdad: sshd -T o, cuando no se puede ejecutar, los archivos en el mismo orden que sshd (agente 1.0.35 o posterior). sshd se queda con el primer valor que lee, y en las distribuciones actuales sshd_config incluye los drop-ins de /etc/ssh/sshd_config.d/ al principio, así que gana un drop-in: en un servidor cloud recién creado, el 50-cloud-init.conf de cloud-init a menudo vuelve a activar el acceso con contraseña. El hallazgo indica el archivo y la línea que fijan el valor, por ejemplo /etc/ssh/sshd_config.d/50-cloud-init.conf:1: cámbialo ahí.
Cuántos controles recibe un servidor depende del servidor: de 40 a 50 en la mayoría. Los controles del servidor web dependen de si están instalados nginx, Apache o los dos, y los controles de PHP (de seis a nueve) se hacen para cada runtime de PHP y cada pool de PHP-FPM, así que un servidor con muchos pools recibe más.
Correcciones con un clic
Diez controles se pueden corregir con Corregir automáticamente:
| Control | Cambio |
|---|---|
| Reenvío X11 | X11Forwarding no |
| Máximo de intentos de autenticación | MaxAuthTries 4 |
Permisos de /etc/shadow |
0640 o más estrictos |
Permisos de /etc/passwd |
0644 o más estrictos |
Permisos de sshd_config |
0600 o más estrictos |
Permisos del authorized_keys de root |
0600 o más estrictos |
| Divulgación de la versión de nginx | server_tokens off |
| Divulgación de la versión de Apache | ServerTokens Prod |
| Firma de Apache | ServerSignature Off |
| Método TRACE | TraceEnable Off |
InfraFence escribe cada cambio en un archivo propio (/etc/ssh/sshd_config.d/00-infrafence-hardening.conf, o zz-infrafence-hardening.conf para nginx y Apache), prueba la configuración (sshd -t, nginx -t, apachectl configtest) y recarga el servicio: las sesiones y conexiones abiertas no se cortan. Deshacer corrección lo revierte.
Algunos controles nunca son automáticos, porque hechos mal podrían dejarte fuera o cambiar el comportamiento de tus sitios: el inicio de sesión de root, la autenticación por contraseña, el puerto SSH, el listado de directorios, los protocolos TLS y las cabeceras de seguridad. Su página explica cómo corregirlos a mano. En un servidor cuya configuración gestiona un panel de hosting o una herramienta de gestión de la configuración, solo las correcciones de permisos son automáticas.
Hardening de PHP
El control lee la configuración efectiva de cada runtime de PHP del servidor: el PHP de la distribución, ondrej, remi, cPanel EA4, Plesk y CloudLinux alt-php. Sigue php.ini y el directorio de escaneo en el mismo orden que PHP, y revisa cada pool de PHP-FPM con sus sustituciones php_value y php_admin_value. El PHP de línea de comandos no se revisa.
| Ajuste | Se informa cuando | Corrección |
|---|---|---|
allow_url_include |
activado (crítico) | automática, también con AutoMode |
display_errors |
activado (alto) | automática, también con AutoMode: display_errors = Off, log_errors = On |
expose_php |
activado (bajo) | automática, también con AutoMode |
cgi.fix_pathinfo |
1 en PHP-FPM con nginx instalado |
con aprobación: 0 |
disable_functions |
exec, system, passthru, shell_exec, proc_open o popen permitidas (recomendación) |
con aprobación: se añaden las que faltan |
open_basedir |
sin definir en un pool que sirve dos o más sitios (recomendación) | a mano: el hallazgo indica la línea para el pool |
session.cookie_httponly |
desactivado | a mano |
session.cookie_secure |
desactivado en un pool cuyos sitios usan HTTPS | a mano |
allow_url_fopen |
activado (informativo) | a mano |
"Con aprobación" requiere la autenticación en dos pasos. Las correcciones de
cgi.fix_pathinfoydisable_functionssolo las aplica un propietario o administrador con la sesión iniciada con autenticación en dos pasos: con Revisar y aplicar en la pestaña Seguridad del servidor, o en Aprobaciones cuando AutoMode lo pide. Sin 2FA el panel no las aplica. Actívala en Ajustes › Seguridad.
Cada hallazgo indica el runtime, el pool, el valor y el archivo y la línea de donde viene. Antes de aprobar una corrección de disable_functions, el panel lista los archivos de los sitios que llaman a esas funciones (hasta 20).
Las correcciones van en un archivo propio de InfraFence, zz-infrafence-hardening.ini en el directorio de escaneo del runtime; php.ini y los archivos de tus pools nunca se editan. Cuando un pool define el valor en su propio archivo, un drop-in no puede sustituirlo: el hallazgo indica entonces la línea exacta que hay que cambiar a mano en ese archivo. El agente prueba la configuración (php-fpm -t), comprueba que el nuevo valor es el efectivo, recarga PHP-FPM sin cortes (nunca un reinicio) y hace la misma comprobación de sitios que las demás correcciones: si un sitio deja de responder, el cambio se deshace. Una corrección en el archivo del runtime se aplica a todos los pools de ese runtime que no definen el valor por su cuenta.
El agente también vigila estos archivos. Cuando se activa allow_url_include o display_errors, el evento Apareció un ajuste de PHP arriesgado indica el archivo, una vez por cambio. Si otra persona o herramienta cambia el archivo de InfraFence (un panel, un paquete, alguien), también recibes un evento.
En cPanel, Plesk y CloudLinux la configuración de PHP se informa, nunca se cambia, y los archivos por sitio (el php.ini de Plesk, el .user.ini de cPanel) solo se informan.
Es hardening y vigilancia de la configuración. No se carga nada en PHP y no detiene un ataque dentro de tu aplicación: de eso se encargan el firewall web y el escáner de malware.
Verificación y reversión
Antes de una corrección, el agente anota qué puertos SSH aceptan conexiones y qué sitios responden sin un error del servidor, por HTTP y HTTPS (hasta 20 sitios). Después de la recarga los vuelve a comprobar durante un máximo de 20 segundos. Si uno deja de responder, deshace el cambio por sí solo y el resultado dice Revertida por el servidor. Las correcciones de permisos no tienen reversión: un modo más estricto no rompe ningún servicio.
La misma verificación protege el cierre de puertos, los bloqueos de salida y los parches virtuales.
Vulnerabilidades (CVE)
La auditoría de software envía la lista de paquetes instalados al panel, que la compara con la base de datos OSV. Funciona en Debian, Ubuntu, AlmaLinux y Rocky Linux. El apartado Vulnerabilidades (CVE) lista los paquetes que tienen una corrección disponible y marca los que están en la lista de CISA de vulnerabilidades que se sabe que se están explotando (Explotada activamente (CISA KEV)): actualiza esos primero.
Actualizaciones de seguridad
Actualizar todos o Actualizar este paquete instala las versiones corregidas. El agente actualiza solo esos paquetes (no instala ni elimina nada más), mantiene tus archivos de configuración, se niega a empezar mientras haya otra operación de paquetes en curso y nunca reinicia el servidor. La propia actualización de un paquete puede reiniciar su servicio un momento. Cuando hace falta reiniciar, o un servicio sigue ejecutando código antiguo, el resultado lo indica.
Puntuación de seguridad
Los resultados alimentan la puntuación de seguridad del servidor, de 0 a 100, con las principales correcciones primero. Consulta Servidores.