# Status de auditoría de infraestructura - 2026-04-07 Fecha: 2026-04-07 Servidor: `srv1112606.hstgr.cloud` Sistema: AlmaLinux 9.7 (KVM) Fuente: evidencia SSH capturada en sesión de diagnóstico. --- ## 1) Resumen ejecutivo - Estado general: **Operativo con riesgos de seguridad y hardening**. - Disponibilidad: **Estable** (uptime 76 días, carga baja). - Capacidad: **CPU/disco correctos**; **presión de memoria/swap resuelta** tras eliminar el stack Wazuh (ver sección siguiente). - Riesgo global actual: **Medio** (baja la carga de recursos; persisten firewall/SSH/logrotate). --- ## 1.1) Actualización: stack Wazuh eliminado (misma fecha) Acciones realizadas: `systemctl stop/disable`, `dnf remove` de `wazuh-dashboard`, `wazuh-manager`, `wazuh-indexer`, `filebeat`; limpieza de rutas bajo `/etc/wazuh-*`, `/usr/share/wazuh-*`, `/var/lib/wazuh-*`, `/var/log/wazuh-*`, `/var/ossec`. **Verificación post-remoción:** - Sin procesos `wazuh` / `opensearch`; sin escucha en `1514`, `1515`, `55000`, `8443`, `9200`, `9300`. - **RAM:** `Mem` ~**3.1 GiB** usados, **~12 GiB** `available` (salida `free -h` tras reinicio de servicios base). - **Swap:** **~475 MiB** usados, **~548 MiB** libres sobre **1.0 GiB** total; archivo `/usr/swpDSK` (prioridad -2). Uso de swap **normalizado** respecto al ~100% previo con Wazuh. **Systemd:** tras `systemctl reset-failed` y `daemon-reload`, **`systemctl --failed`** sin unidades (0 listed). **Pendiente operativo:** `logrotate.service` y `nftables.service` (ver sección de servicios fallidos actual). --- ## 2) Hallazgos confirmados (evidencia de hoy) ### Host y sistema - Hostname: `srv1112606.hstgr.cloud`. - OS: AlmaLinux 9.7. - Kernel en ejecución: `5.14.0-570.58.1.el9_6.x86_64`. - Uptime: 76 días. ### Recursos **Estado inicial (antes de quitar Wazuh):** - Load average: `0.23, 0.16, 0.11` (correcto para el tamaño del host). - RAM: 15 GiB total, ~11 GiB usada, ~3.7 GiB disponible. - Swap: 1 GiB total, ~100% en uso. - Disco: `/` al 42% (82/199 GiB), sin alerta de capacidad inmediata. **Estado tras eliminar Wazuh:** ~3.1 GiB RAM usados, ~12 GiB `available` (ver §1.1). #### Memoria: desglose por proceso (histórico, antes de remover Wazuh) | Proceso | PID | %MEM | RSS (aprox.) | Nota | |--------|-----|------|----------------|------| | **Wazuh Indexer** (OpenSearch/Java) | 415592 | ~52.5% | ~8.1 GiB | JVM con `-Xms7865m -Xmx7865m` → **heap fijada ~7.7 GiB**. Es el principal consumidor de RAM del host. | | **MariaDB** (`mariadbd`) | 2285761 | ~3.0% | ~480 MiB | Normal en servidor con BD. | | **Suricata** | 396345 | ~1.4% | ~232 MiB | IDS/IPS en `eth0`. | | **Wazuh Dashboard** (Node) | 419773 | ~1.2% | ~190 MiB | Parte del stack Wazuh. | | **spamd** (cPanel) | varios | ~1% c/u | ~170–180 MiB | Antispam. | | **PowerDNS**, **WP Toolkit**, **php-fpm**, **httpd** | varios | < 0.3% c/u | — | Resto del hosting. | **Conclusión:** En un VPS de **~15 GiB RAM**, tener solo el **Wazuh Indexer** reservando **~7.7 GiB de heap** deja poco margen para MariaDB, Suricata, cPanel, picos de PHP y el propio sistema. Eso **explica de forma directa** la **swap casi llena** (1 GiB): ante picos o arranques, el kernel desaloja páginas al disco. **Líneas de mejora (sin ejecutar aún):** revisar documentación Wazuh/OpenSearch para **heap menor** acorde a índices y carga real; valorar **más RAM** o **mover el indexer** a otro nodo; ajustar `vm.swappiness` solo después de medir. #### Swap por proceso (comando corregido) El bucle con `awk` debe pasar el PID explícito; si no, solo ves KiB sin saber de qué proceso: ```bash for pid in /proc/[0-9]*; do pid=${pid##*/} [ -r "/proc/$pid/smaps" ] || continue swap=$(awk '/^Swap:/{s+=$2} END {print s+0}' "/proc/$pid/smaps" 2>/dev/null) [ "${swap:-0}" -gt 0 ] && echo "$swap $pid $(tr '\0' ' ' < /proc/$pid/cmdline 2>/dev/null | cut -c1-80)" done | sort -nr | head -n 15 ``` ### Servicios fallidos - `logrotate.service` (failed) — persiste. - `nftables.service` (failed) — persiste. - `wazuh-manager.service` (`not-found` / failed) — **artefacto** tras desinstalar; no es un servicio real instalado. ### Exposición de red/puertos - Puertos esperados abiertos para cPanel/WHM/web/mail: 22, 80, 443, 2082/2083, 2086/2087, 25/465/587, 110/995, 143/993, DNS 53. - Detectado también: - `3306` (MariaDB) abierto en `0.0.0.0` y `[::]`. - `8080` (nginx) público. - Múltiples puertos `7891-7920` (goaccess) públicos. - `111` (rpcbind) público. - **Cerrados tras quitar Wazuh:** `8443`, `1514`, `1515`, `55000`, `9200`, `9300` (validar con `ss -tulpen` en próxima revisión). ### Firewall - `firewall-cmd: command not found` -> no se detecta `firewalld` por CLI. - `csf` no está instalado (`command not found`). - Reglas observadas: - `iptables -S` con políticas por defecto `INPUT ACCEPT`, `FORWARD ACCEPT`, `OUTPUT ACCEPT`. - `nft` muestra cadenas parciales (principalmente OUTPUT y reglas cphulk), sin política restrictiva general visible. - Conclusión: **no hay firewall host-based restrictivo correctamente aplicado** (alto riesgo). ### SSH hardening - `PermitRootLogin yes` (riesgo alto si se permite password o acceso irrestricto). - `PasswordAuthentication yes` (confirmado). - `PubkeyAuthentication yes` (confirmado). - Conclusión: acceso SSH está **demasiado permisivo** para entorno productivo. ### Actualizaciones - Hay updates pendientes (incluye kernel `5.14.0-611.45.1.el9_7`). - Kernel corriendo no es el último disponible. --- ## 3) Riesgos prioritarios (ordenados) 1. **Firewall host-based no restrictivo + puertos públicos amplios** Exposición innecesaria de `3306`, `goaccess` y `rpcbind` (Wazuh ya no aplica). 2. **Acceso root SSH permisivo (`PermitRootLogin yes`)** Aumenta riesgo de fuerza bruta y compromiso de credenciales. 3. **Servicio de rotación de logs fallando (`logrotate.service`)** Riesgo de crecimiento de logs y degradación operativa. 4. **logrotate fallando por ruta de WP Toolkit en modo solo lectura** Falla diaria acumulada en mantenimiento de logs. 5. **Presión de memoria y swap (histórico)** Causa principal era **Wazuh Indexer** (~7.7 GiB heap). Tras desinstalar Wazuh, la RAM vuelve a un perfil **sano** (~12 GiB `available`). Revisar swap tras unas horas o reinicio. --- ## 4) Plan de acción inmediato (24-48 horas) - [ ] Confirmar firewall activo real (CSF o equivalente) y política por defecto. - [ ] Implementar firewall restrictivo (nftables o CSF) con allowlist mínima. - [ ] Cerrar/restringir puertos no requeridos públicamente: `3306`, `7891-7920`, `111` (según necesidad operativa). - [ ] Endurecer SSH: - [ ] `PermitRootLogin prohibit-password` (o `no` + usuario admin con sudo). - [ ] `PasswordAuthentication no`. - [ ] Limitar acceso SSH por IPs de administración. - [ ] Corregir `logrotate.service` y validar ejecución. - [x] Eliminar stack Wazuh (completado). - [ ] Limpiar estado systemd residual (`wazuh-manager.service not-found`): `systemctl reset-failed` y `systemctl daemon-reload`. - [ ] Programar update de kernel y reinicio controlado en ventana. --- ## 5) Plan 30-60-90 días ### 30 días - Hardening completo SSH + firewall + puertos. - Baseline de monitoreo y alertas (CPU, RAM, swap, disco, servicios). - Validación formal de backups y restore de prueba. ### 60 días - Afinar MariaDB y PHP-FPM según métricas reales. - Revisar seguridad mail (SPF/DKIM/DMARC por dominio). - Estandarizar runbook de incidentes. ### 90 días - Auditoría de cumplimiento interna trimestral. - Reducción adicional de superficie de ataque. - Documentación técnica cerrada para handover. --- ## 6) Comandos de verificación pendientes (siguiente ronda) Ejecutar y adjuntar salida para cerrar diagnóstico: ```bash # Firewall y exposición actual iptables -S nft list ruleset ss -tulpen # SSH y auth grep -E '^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' /etc/ssh/sshd_config sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication' # Servicios fallidos systemctl status logrotate --no-pager -l journalctl -u logrotate --since "7 days ago" --no-pager | tail -n 120 # WP Toolkit (causa read-only en logrotate) mount | grep -i /usr/local/cpanel/3rdparty/wp-toolkit ls -ld /usr/local/cpanel/3rdparty/wp-toolkit/var/logs grep -R "wp-toolkit" /etc/logrotate* /usr/local/cpanel/etc/logrotate.d 2>/dev/null # Memoria y swap swapon --show cat /proc/sys/vm/swappiness ps aux --sort=-%mem | head -n 20 # DB exposure grep -R "bind-address" /etc/my.cnf /etc/my.cnf.d 2>/dev/null ``` --- ## 7) Estado de checklist (2026-04-07) - [x] Identidad del servidor - [x] CPU/RAM/Disk (foto inicial) - [x] Estado general de puertos - [x] Estado inicial de actualizaciones - [x] Firewall validado (no restrictivo) y documentado - [ ] Hardening SSH completo - [ ] Corrección de servicios failed (`logrotate`, `nftables`; limpiar fantasma Wazuh en systemd) - [ ] Verificación de backups/restore - [ ] SSL/AutoSSL por cuentas - [ ] Inventario final de mejoras cerradas --- ## 8) Remediación recomendada (borrador técnico) > Ejecutar en ventana de mantenimiento y con acceso de rescate de proveedor disponible. ### SSH (prioridad alta) - Cambiar a: - `PermitRootLogin prohibit-password` - `PasswordAuthentication no` - Mantener `PubkeyAuthentication yes`. - Aplicar allowlist por IP administrativa en firewall antes de endurecer SSH. ### Firewall (prioridad alta) - Definir política default deny en INPUT/FORWARD. - Abrir solo: - `22` (idealmente por IP) - `80`, `443` - `2087`, `2083` (si son requeridos públicamente) - puertos mail solo si realmente el server recibe/envía correo directo. - Restringir a localhost o red privada: - `3306` - puertos `goaccess` (`7891-7920`) ### Logrotate/WP Toolkit (prioridad media-alta) - El error recurrente indica ruta de logs de WP Toolkit no escribible (read-only). - Corregir montaje/permisos o excluir temporalmente esa ruta de logrotate para restablecer rotación global.