LinuxParty

Las herramientas de seguridad como Chkrootkit y Rkhunter permiten buscar indicios de rootkits en servidores Linux. Sin embargo, sus avisos deben interpretarse con cuidado: una alerta no significa necesariamente que el sistema esté infectado.

Un ejemplo habitual es recibir un mensaje como este:

Warning: Network TCP port 33369 is being used by
/opt/plesk/php/8.1/sbin/php-fpm.

Possible rootkit: Volc Rootkit SSH server (divine)

El puerto TCP 33369 se ha relacionado históricamente con el rootkit Volc, pero también puede ser utilizado legítimamente por cualquier aplicación. El número de puerto, por sí solo, no demuestra la existencia de malware.

1. Comprobar si el puerto está escuchando

La primera prueba consiste en averiguar si existe realmente un servicio escuchando en el puerto señalado:

sudo ss -lntp | grep ':33369'

También podemos utilizar lsof:

sudo lsof -nP -iTCP:33369 -sTCP:LISTEN

Si los comandos no devuelven ningún resultado, actualmente no existe ningún proceso escuchando en ese puerto.

Si aparece una línea con LISTEN, debemos observar la dirección:

127.0.0.1:33369

En este caso, el servicio solamente acepta conexiones procedentes del propio servidor.

Si aparece:

0.0.0.0:33369

o:

[::]:33369

el proceso está escuchando en todas las interfaces de red. Eso no significa necesariamente que pueda alcanzarse desde Internet, ya que el cortafuegos podría bloquearlo.

2. Buscar conexiones que no estén escuchando

Un puerto también puede aparecer como parte de una conexión saliente. Para comprobar todas las conexiones relacionadas con él:

sudo ss -antp | grep ':33369'

Un programa legítimo puede utilizar temporalmente el puerto 33369 como puerto local de origen. Algunos detectores de rootkits solamente reconocen el número asociado históricamente al malware y generan una alerta, aunque no exista ningún servidor malicioso.

Esta es una causa frecuente de falsos positivos.

3. Identificar el proceso responsable

Si el puerto está siendo utilizado, podemos identificar el proceso mediante:

sudo lsof -nP -iTCP:33369

Otra alternativa es:

sudo ss -antp | grep ':33369'

Después de conocer el PID, podemos consultar sus detalles:

sudo ps -fp PID

Y comprobar qué ejecutable está utilizando realmente:

sudo readlink -f /proc/PID/exe

Debemos sustituir PID por el número correspondiente. Por ejemplo:

sudo readlink -f /proc/18452/exe

Conviene no finalizar inmediatamente el proceso. En servidores administrados mediante Plesk, cPanel u otros paneles, podría tratarse de un proceso legítimo necesario para alojar una página web.

4. Verificar los procesos PHP-FPM

Si la alerta señala a PHP-FPM, podemos listar todos sus procesos:

pgrep -a php-fpm

Para comprobar el ejecutable empleado por cada uno:

for pid in $(pgrep php-fpm); do
    printf '%s: ' "$pid"
    sudo readlink -f "/proc/$pid/exe"
done

Es importante tener cuidado al utilizar pgrep dentro de una sustitución de comandos. Si no encuentra ningún proceso, una orden como esta:

readlink -f /proc/$(pgrep ...)/exe

puede terminar consultando /proc/exe y producir un resultado engañoso.

5. Comprobar a qué paquete pertenece el archivo

En distribuciones basadas en RHEL, AlmaLinux, Rocky Linux o CentOS podemos consultar el paquete propietario del ejecutable:

rpm -qf /opt/plesk/php/8.1/sbin/php-fpm

Una salida como esta indica que el archivo pertenece a un paquete de Plesk:

plesk-php81-fpm-8.1.34-0redhat.8.251222.0806.x86_64

A continuación podemos comprobar su integridad:

rpm -V "$(rpm -qf /opt/plesk/php/8.1/sbin/php-fpm)"

Si no aparece ninguna salida, los archivos verificables del paquete coinciden con la información registrada por RPM.

Esto constituye un buen indicio de legitimidad, aunque no debe utilizarse como única prueba: un atacante con privilegios de root podría alterar tanto los archivos como la información local de la base de datos de paquetes.

En Debian y Ubuntu pueden realizarse comprobaciones equivalentes con:

dpkg -S /ruta/al/archivo
debsums -s nombre-del-paquete

Es posible que sea necesario instalar previamente debsums.

6. Buscar configuraciones relacionadas con el puerto

Si PHP-FPM utiliza un puerto poco habitual, debemos localizar dónde se ha configurado:

sudo grep -Rni '33369' /opt/plesk/php/8.1/etc/ /etc/ 2>/dev/null

Los pools de PHP-FPM suelen escuchar mediante sockets Unix o puertos TCP locales. Una configuración legítima puede contener, por ejemplo:

listen = 127.0.0.1:33369

Si encontramos esa directiva dentro de un pool administrado por Plesk, probablemente se trata de una configuración normal. Aun así, debemos comprobar a qué dominio o suscripción pertenece.

7. Revisar los registros del detector

Para localizar el origen exacto de la alerta:

sudo grep -RniE '33369|Volc|divine' \
  /var/log/rkhunter* \
  /var/log/chkrootkit* \
  /var/log/messages* 2>/dev/null

En sistemas con systemd también podemos consultar el diario:

sudo journalctl --since "24 hours ago" | grep -Ei '33369|Volc|divine'

La hora del aviso es importante. Puede que el proceso utilizara el puerto durante unos segundos y ya hubiera terminado cuando realizamos la comprobación manual.

8. Comprobar si el puerto es accesible desde Internet

Que un servicio escuche en el servidor no implica necesariamente que sea accesible externamente. Debemos probarlo desde otro equipo:

nc -vz IP_PUBLICA_DEL_SERVIDOR 33369

Los resultados habituales son:

• succeeded u open: el puerto resulta accesible.
• Connection refused: no existe un servicio escuchando o la conexión se rechaza.
• timed out: probablemente algún cortafuegos está filtrando el tráfico.

También debemos revisar el firewall local:

sudo firewall-cmd --list-all

En sistemas que utilizan nftables:

sudo nft list ruleset

9. Ejecutar varias comprobaciones antimalware

Podemos repetir el análisis con Rkhunter:

sudo rkhunter --check

Y contrastarlo con Chkrootkit:

sudo chkrootkit

Antes de interpretar sus resultados conviene actualizar sus bases de datos, siempre mediante los mecanismos oficiales de la distribución o de la propia herramienta.

También podemos revisar procesos, puertos y servicios activos:

sudo ss -lntup
sudo ps auxf
sudo systemctl --type=service --state=running

Debemos prestar atención a ejecutables lanzados desde directorios como /tmp, /var/tmp o /dev/shm, servicios desconocidos, procesos sin archivos ejecutables visibles y conexiones persistentes hacia direcciones IP inesperadas.

10. ¿Cuándo podemos hablar de falso positivo?

Una alerta probablemente sea un falso positivo cuando se cumplen varias de estas condiciones:

• El puerto ya no está escuchando.
• No existen conexiones sospechosas asociadas.
• El proceso pertenece a una aplicación legítima.
• El ejecutable forma parte de un paquete oficial.
• La verificación del paquete no detecta modificaciones.
• La configuración explica por qué se utilizó ese puerto.
• No existen servicios, usuarios, tareas programadas o conexiones desconocidas.
• Un segundo detector no encuentra indicios adicionales.

En el caso analizado, el puerto 33369 no estaba escuchando, el ejecutable pertenecía al paquete oficial plesk-php81-fpm y rpm -V no detectó modificaciones. Todo apuntaba, por tanto, a un falso positivo provocado por la asociación histórica entre el puerto 33369 y el rootkit Volc.

11. ¿Qué hacer si aparecen indicios reales?

Si encontramos un proceso desconocido escuchando en todas las interfaces, un binario modificado o conexiones persistentes sospechosas, no debemos limitarnos a borrar el archivo.

Las medidas recomendadas son:

1. Aislar el servidor de la red si el riesgo es elevado.
2. Conservar los registros y evidencias disponibles.
3. Cambiar las credenciales desde otro equipo seguro.
4. Revisar accesos SSH, usuarios, claves autorizadas y tareas programadas.
5. Comprobar otros servidores y cuentas relacionados.
6. Realizar el análisis desde un sistema externo o un entorno de rescate.
7. Restaurar o reinstalar el servidor desde fuentes fiables si se confirma el compromiso.

Cuando un atacante obtiene privilegios de root, ya no puede confiarse completamente en las órdenes ni en la información proporcionada por el propio sistema afectado. En una infección confirmada, la reinstalación limpia suele ser la opción más segura.

Conclusión

Los detectores de rootkits son herramientas útiles, pero sus resultados no deben interpretarse como una sentencia definitiva. Una coincidencia con un puerto conocido solamente es un indicio inicial.

Antes de concluir que existe una infección debemos comprobar si el puerto está escuchando, identificar el proceso, verificar el paquete, revisar la configuración y contrastar la alerta con registros y otras herramientas.

En seguridad, una alerta merece investigación, pero “posible rootkit” no significa automáticamente “rootkit confirmado”.