Sigo encontrando mi servidor con un uso de CPU del 100%, y es un proceso con un nombre ambiguo que está oculto en algún lugar de la carpeta /etc/ que se ejecuta en la raíz (siempre una carpeta diferente). La primera vez que lo encontré, lo busqué y confirmé que era un minero, eliminé el proceso kill -9 PID
y eliminé la carpeta. Pero lo encontré otras dos veces y decidí eliminarlo nuevamente, pero también cambiar las contraseñas de la cuenta que uso para ingresar al servidor mediante ssh y también para root, pero lo encontré nuevamente.
¿Hay alguna manera de identificar cómo llegó una carpeta allí? Debe haber algo todavía en mi servidor que revise periódicamente estos archivos y, si no los encuentra, los descargue o extraiga nuevamente.
El minero enviaba tráfico a la siguiente dirección: ip162.ip-5-135-85.eu que pertenece ahttps://aeon.miner.rocks/
Respuesta1
Considere reinstalar el servidor.
Consulta los siguientes lugares:
crontab -l
después de usarsudo -su
crontab -l
con tu usuario administrador- contenidos de
/etc/rc.local
y/etc/apt/sources.list
los directorios
/etc/systemd/system /usr/lib/systemd/system /lib/systemd/system
para servicios que no reconoce.
Esos serán los principales culpables.
aeon-stak-cpuzheck /bin/
para un archivo aeon-stak-cpu
.
Haz un locate aeon
. Eso podría hacer aparecer más directorios.
Aunque no puedo encontrar ningún malware. aeon se instala desde la línea de comando, por lo que espero que alguien tenga una conexión a su máquina.
Respuesta2
Así que finalmente llegué al fondo del asunto.
En primer lugar, tenía nginx ejecutándose como root, que probablemente era el punto de entrada original. Clamscan había encontrado y marcado un archivo llamado info.php oculto en /var/www, que probablemente fue la forma en que obtuvieron acceso al principio.
Seguí viendo procesos ssh para root@notty, lo cual al principio no sabía lo que significaba notty, y cuando miré netstat definitivamente no era ninguna de mis sesiones. Pero he estado cambiando las contraseñas por otras completamente aleatorias, por lo que no puede ser que las conocieran. Decidí mirar todas las carpetas /home/[usuario]/.ssh de mi usuario y encontré la misma clave ssh en el archivo autorizado_keys.
Eliminé la clave y también cambié el usuario de nginx y no he tenido problemas desde entonces.