¿Por qué son tan peligrosos los rootkits?
A diferencia de otros tipos de malware más visibles, un rootkit puede pasar semanas o meses operando sin ser detectado, robando información confidencial, registrando pulsaciones de teclado o usando tu servidor como parte de una red de bots, todo mientras el sistema parece funcionar con total normalidad. Esa capacidad de ocultamiento es precisamente lo que hace indispensable un escaneo periódico con herramientas especializadas.
Hay un matiz incómodo que conviene entender desde el principio: un rootkit bien instalado modifica las mismas herramientas que usarías para detectarlo. Si reemplaza ls, ps o netstat por versiones alteradas, esos comandos te mostrarán exactamente lo que el atacante quiere que veas. Por eso el valor real de RKHunter y Chkrootkit no está en el escaneo de hoy, sino en la comparación contra una línea base tomada cuando el sistema estaba limpio.
RKHunter y Chkrootkit: en qué se diferencian
Las dos herramientas buscan lo mismo, pero por caminos distintos, y ahí está la razón de usarlas juntas:
| Aspecto | RKHunter | Chkrootkit |
|---|---|---|
| Método principal | Compara los archivos del sistema contra una línea base propia y revisa configuraciones | Busca firmas conocidas de rootkits en binarios y memoria |
| Necesita línea base | Sí, con rkhunter --propupd | No |
| Revisa configuración de SSH y permisos | Sí | No |
| Detecta interfaces en modo promiscuo | Sí | Sí |
| Salida | Extensa, con log detallado en /var/log/rkhunter.log | Breve, directa en la terminal |
| Falsos positivos | Frecuentes tras actualizar paquetes | Menos frecuentes, pero ocurren |
| Actualización de firmas | rkhunter --update | Ligada a la versión del paquete |
En la práctica: RKHunter es mejor detectando que algo cambió en tu servidor, y Chkrootkit es mejor identificando qué rootkit conocido podría ser. Ninguna sustituye a la otra.
Paso 1: Instalar RKHunter
En distribuciones basadas en Debian/Ubuntu:
sudo apt update
sudo apt install rkhunter -yEn distribuciones basadas en Red Hat (AlmaLinux, Rocky Linux, RHEL):
sudo dnf install epel-release -y
sudo dnf install rkhunter -yPaso 2: Instalar Chkrootkit
En distribuciones basadas en Debian/Ubuntu:
sudo apt install chkrootkit -yEn distribuciones basadas en Red Hat (con el repositorio EPEL ya habilitado):
sudo dnf install chkrootkit -yNota sobre las guías antiguas: CentOS Linux 7 llegó a su fin de vida el 30 de junio de 2024, y en las distribuciones vigentes de esa familia el gestor de paquetes es dnf. Si tu servidor todavía corre CentOS 7, ese es un problema de seguridad más grave que cualquier rootkit que puedas encontrar, porque lleva dos años sin parches oficiales.
Actualizar las bases de datos de firmas de RKHunter
Antes del primer escaneo, actualiza las bases de datos de firmas conocidas y genera una línea base de los archivos del sistema:
sudo rkhunter --update
sudo rkhunter --propupdEl comando --propupd es especialmente importante: crea una "foto" de referencia de los archivos del sistema en su estado actual (asumiendo que está limpio), para que futuros escaneos puedan detectar cambios sospechosos comparando contra esta línea base.
Realizar un escaneo completo con RKHunter
sudo rkhunter --checkallEste comando revisa binarios del sistema, módulos del kernel, puertos de red sospechosos y firmas conocidas de rootkits. Si ves varias advertencias marcadas como [ Warning ], no entres en pánico de inmediato: muchas corresponden a falsos positivos, especialmente en sistemas con configuraciones no estándar. Revisa cada advertencia con calma antes de concluir que hay un compromiso real.
Revisar el registro detallado de resultados
RKHunter guarda un log detallado de cada escaneo que puedes consultar en cualquier momento:
cat /var/log/rkhunter.logEste archivo es útil para investigar advertencias específicas con más contexto del que se muestra en la salida resumida de la terminal.
Realizar un escaneo básico con Chkrootkit
sudo chkrootkitSi la salida muestra INFECTED en algún elemento, tampoco es momento de asumir lo peor de inmediato: es una señal de alerta que requiere investigación adicional, no una confirmación automática de compromiso. Busca el nombre específico del hallazgo para determinar si es un falso positivo conocido o algo que amerita más investigación.
Escanear directorios específicos con Chkrootkit
Si necesitas enfocar el análisis en una ruta particular (por ejemplo, tras detectar actividad sospechosa en un directorio concreto):
sudo chkrootkit /ruta/directorioAutomatizar los escaneos con Cron
Para no depender de recordar ejecutar estos escaneos manualmente, prográmalos con Cron.
Escaneo automático con RKHunter todos los días a las 3:00 a.m.:
sudo crontab -e0 3 * * * /usr/bin/rkhunter --checkall --quietEscaneo automático con Chkrootkit media hora después, a las 3:30 a.m.:
30 3 * * * /usr/sbin/chkrootkitLa bandera --quiet en RKHunter reduce la salida solo a hallazgos relevantes, ideal para que los reportes automáticos por correo no se saturen de información innecesaria.
Qué hacer si confirmas un compromiso real
Si tras investigar una advertencia confirmas que efectivamente hay un rootkit activo, las acciones recomendadas son:
- Aísla el servidor de la red inmediatamente para evitar que el atacante siga operando o se mueva lateralmente.
- No confíes en el sistema comprometido para investigar: usa un medio de arranque externo o herramientas forenses desde otro equipo.
- Restaura desde un backup previo al compromiso, si está disponible, en lugar de intentar "limpiar" un sistema comprometido, ya que los rootkits suelen dejar puertas traseras adicionales difíciles de detectar por completo.
- Cambia todas las credenciales asociadas al servidor comprometido, incluyendo llaves SSH y contraseñas de bases de datos.
La detección de rootkits no es una tarea que se hace una sola vez: es un proceso continuo que debe formar parte de la rutina de mantenimiento de cualquier servidor expuesto a internet. Instalar y automatizar RKHunter y Chkrootkit te da visibilidad temprana ante señales de compromiso, pero recuerda siempre interpretar sus advertencias con criterio: no todo hallazgo es una infección real, y no toda infección real se detecta a la primera.
Y una prioridad que conviene tener clara: detectar rootkits es la última capa, no la primera. Un servidor con acceso SSH solo por llave, firewall restrictivo, Fail2Ban activo y paquetes al día casi nunca llega al punto de tener un rootkit encima. Esas capas están explicadas en la guía de seguridad para servidores Linux y en la de Fail2Ban contra ataques de fuerza bruta. Si administras un VPS o un servidor dedicado en producción, aplicar ese orden ahorra mucho más trabajo que cualquier escaneo. Si tienes dudas durante la implementación, nuestro equipo de soporte técnico está disponible 24/7 para ayudarte.
Hosting con LiteSpeed, NVMe y soporte 24/7 desde $3/mes.