Dolor al eliminar un rootkit perl

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)

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.

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.

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

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.

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 :)