Dolor al eliminar un rootkit perl

8

Por lo tanto, tenemos un servidor web de geoservicios en la oficina.

Aparentemente, alguien irrumpió en esta caja (probablemente a través de ftp o ssh) y puso algún tipo de rootkit administrado por irc.

Ahora estoy tratando de limpiar todo, encontré el proceso pid que intenta conectarse a través de irc, pero no puedo entender quién es el proceso de invocación (ya lo miré con ps, pstree, lsof) El proceso es un perl script propiedad del usuario www, pero ps aux | grep muestra una ruta de archivo falsa en la última columna.

¿Hay otra forma de rastrear ese pid y atrapar al invocador?

Olvidé mencionar: el kernel es 2.6.23, que es explotable para convertirse en root, pero no puedo tocar esta máquina demasiado, así que no puedo actualizar el kernel

EDITAR: lsof podría ayudar:

lsof -p 9481
COMANDO PID USUARIO FD TIPO DISPOSITIVO TAMAÑO NODO NOMBREss
perl 9481 www cwd DIR 8,2 608 2 / ss
perl 9481 www rtd DIR 8,2 608 2 / ss
perl 9481 www txt REG 8,2 1168928 38385 / usr / bin / perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2.5.soss
perl 9481 www mem REG 8,2 1602809 23289 / lib64 / libc -2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / IO / IO.soss
perl 9481 www mem REG 8,2 21328 38877 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / Socket / Socket.soss
perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 tuberías
perl 9481 www 1w FIFO 0,5 1071920 tuberías
perl 9481 www 2w FIFO 0,5 1068894 tuberías
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

paul.ago
fuente
2
A menos que actualice el kernel, ¿qué impide que el hacker repita el hack tan pronto como elimine el rootkit? Bien puede haber un módulo de núcleo troyano que oculta los procesos.
pjc50
esto se ve muy similar al bot irc ddos ​​que acabo de limpiar mis vps: serverfault.com/questions/639699/…
Hayden Thring

Respuestas:

37

Si puedo darle algún consejo, es dejar de perder el tiempo limpiando. Haga una imagen del sistema operativo para material forense para más adelante y simplemente reinstale el servidor.

Lo sentimos, pero es la única forma segura de resolver tu problema de rootkit.

Más tarde puede verificar la imagen, por ciertas razones, por qué sucedió.

Desde mi propia experiencia personal, hice esto, y luego encontré un usuario interno que tenía una clave SSH que contenía la falla de openssl en 2008.

Espero que aclare las cosas.

Nota:
Si va a crear una imagen / copia de seguridad del servidor antes de volver a instalar, tenga mucho cuidado de cómo hacer esto. Como dijo @dfranke, arranque desde un medio confiable para hacer una copia de seguridad.

No debe conectarse a otras máquinas desde un servidor rooteado, ya que se sabe que los grandes rootkits pueden propagarse a través de sesiones confiables como SSH.

Arenstar
fuente
11
Apoyo fuertemente este consejo. Has encontrado un rootkit, pero no tienes ni idea de qué más ha manipulado el atacante. Una vez enraizado, siempre enraizado. Arranque desde un medio confiable, ponga a cero la unidad. Fdisk, formatear, reinstalar, doo dah, doo dah.
dfranke
Yah ... Los buenos kits de raíz se ejecutan bajo su núcleo ... No hay posibilidad de eliminarlos, sin MUCHO esfuerzo
Arenstar
44
+1 Para cualquier sistema de producción (realmente, cualquier sistema) no hay razón para limpiar. Mátalo con fuego y reconstruye.
phoebus
1
+1 para reinstalar. El rootkit probablemente se metió con sus binarios o kernel y todo lo que está viendo (rutas falsas, etc.) es probablemente una cortina de humo del rootkit para ocultarse.
coredump
1
Oblig. Cita : "Digo que despeguemos y destruyamos todo el sitio desde la órbita. Es la única manera de estar seguros".
Charles Stewart el
1

La línea de comando se puede cambiar si el proceso altera argv [0]. Tratarls -l /proc/[pid]/exe

Desde man 5 proc

Este archivo es un enlace simbólico que contiene el nombre de ruta real del comando ejecutado. Este enlace simbólico se puede desreferenciar normalmente; intentar abrirlo abrirá el ejecutable. Incluso puede escribir / proc / [número] / exe para ejecutar otra copia del mismo ejecutable que está ejecutando el proceso [número]. En un proceso multiproceso, el contenido de este enlace simbólico no está disponible si el hilo principal ya ha terminado

ps auxwf | less le brinda la "vista del bosque" de los procesos que le puede mostrar qué proceso inició este proceso (a menos que el rootkit lo esté ocultando, o el padre de la aplicación haya salido y haya sido reparented al init).

Esto sería principalmente académico y probablemente solo una pérdida de tiempo, pero strings -n 10 /proc/[pid]/mempodría ser divertido ver pasar más allá. También podría echo 0x7 > /proc/[pid]/coredump_filterusar gdb gcorepara forzar un coredump con todo lo posible en él, pero luego el proceso desaparece, lo que podría bloquear el análisis posterior.

Pero definitivamente sigue el consejo de Arenstar. Haga una copia de seguridad de los datos solamente, restaure todo lo ejecutable desde las copias de seguridad y comience de nuevo. Probablemente también deberías restaurar el sitio web a partir de copias de seguridad, podría agregarse JavaScript malicioso a cada archivo html o php. Si está considerando una acción legal, querrá dejar a un lado la máquina, desenchufarla de la red y detener lo que sea que esté haciendo hasta que los expertos forenses hayan hecho su trabajo.

DerfK
fuente
Muy buena respuesta.
paul.ago
desafortunadamente ls -l / proc / [pid] / exe devuelve la ruta bin bin perl5.8.8, y ps / pstree dice que el proceso padre es init, esto parece realmente bien oculto. Definitivamente comenzaría de nuevo con una instalación nueva, pero el desarrollador original de la aplicación que se está ejecutando está fuera del país por un tiempo, por lo que estaba buscando una solución temporal. Por cierto
paul.ago
0

Pruebe con "cat / proc / [Id. De proceso] / cmdline" Aunque si es un rootkit verdadero, puede modificar el kernel para ocultarse mejor.

mfarver
fuente
me da lo mismo de ps aux "/ usr / sbin / apache / logs" que es falso. Ni el directorio / usr / sbin / apache existe
paul.ago
0

Deberías reinstalar, estoy de acuerdo. ¿Has intentado escapar de los personajes en el camino? Tal vez una de esas barras es en realidad parte de un nombre de archivo y no un directorio. Como mínimo, debe usar iptables para bloquear el tráfico saliente a ese host o IRC general hasta que se solucione. Verifique netstat también.

sinping
fuente
no, el camino parece "real". Lamentablemente, parece que iptables está instalado, pero falta el módulo del kernel, por lo que debo recompilar el kernel. Probablemente iría por ese camino para solucionar el problema por unos días hasta que me ponga en contacto con el tipo que tiene el código fuente de la aplicación, para poder reinstalar el servidor
Paul.ago
0

Creo que a estas alturas ya has reinstalado. Su desperdicio de tiempo justo tratando de rastrear los procesos y hacer análisis forenses ya que las posibilidades de que algo se desarrolle legalmente a partir de él serían muy pequeñas y las posibilidades de encontrar al pirata informático serían inútiles de todos modos. A menos que solo le interese investigar y revertir rootkits que pueden ser divertidos :)

nulo
fuente