Qué está corriendo ahí dentro

Los archivos están quietos. Un proceso es un programa que está ejecutándose: ocupa memoria, consume procesador y hace cosas.

Cada proceso tiene tres datos que conviene mirar siempre juntos:

• Un número, el PID. Es su identificador mientras vive. Sirve para hablar de él y, si hace falta, para matarlo.
• Un usuario. El proceso corre como alguien, y solo puede hacer lo que ese alguien pueda. Un proceso que corre como el usuario del servidor web no puede leer los archivos privados de coordinación — a menos que alguien haya dejado los permisos abiertos, como viste en la sala anterior.
• Qué está ejecutando. La ruta del programa.

Ese tercer dato es el que más dice, y el que casi nadie lee con atención.

Abre el laboratorio y escribe:

ps

Vas a ver la lista de lo que corre en el servidor. Léela como leíste la tabla de tráfico del panel de la clínica: no buscando al malo, sino al que no se parece a los demás.

Casi todo tiene sentido. init es el primer proceso del sistema. sshd atiende las conexiones de administración. Dos procesos de nginx sirven las páginas web. postgres es la base de datos. bash es la terminal de coordinación — la tuya.

Y hay uno que desentona por tres razones a la vez:

Corre desde /tmp. Esa carpeta es para archivos temporales, y nada permanente debería ejecutarse desde ahí. Es de las señales más fiables que existen.

Está en una carpeta oculta. El punto delante de .cache la esconde de un ls normal. Los programas legítimos no necesitan esconderse.

Se está comiendo un tercio de la memoria. Treinta y un por ciento, más que la base de datos entera.

Y corre como el usuario del servidor web. Eso dice por dónde entró: alguien consiguió que el proceso que atiende las páginas ejecutara algo, y ese algo lleva un rato ahí.

Ya sabes qué se ejecuta y desde dónde. Ve a mirarlo:

cd /tmp/.cache
ls -l

Ahí está el binario, con permiso de ejecución y seis megas. Y hay una nota al lado.

Fíjate en el detalle del ls: la carpeta se llama .cache con un punto delante, y por eso no aparecía cuando hiciste ls en /tmp. Los nombres que empiezan por punto se consideran ocultos, y esa convención —pensada para archivos de configuración— se usa muchísimo para esconder cosas.

Lee la nota y te llevas el código.

Encontraste un proceso que no debería estar. La tentación es matarlo inmediatamente. Espera.

Acuérdate del módulo 2: lo que un proceso tiene en memoria desaparece cuando muere. Y ahí puede estar lo más valioso para entender qué pasó — a qué se estaba conectando, qué había recogido, con qué credenciales.

El orden que sigue quien sabe:

1. Aislar la máquina de la red, no apagarla. Corta el daño y conserva la memoria.
2. Registrar el estado: la lista de procesos, las conexiones abiertas, la memoria de ese proceso.
3. Después contenerlo.
4. Y al final averiguar por dónde entró, porque si no lo arreglas vuelve mañana.

Es el mismo razonamiento de la sala de defensa, con un matiz que ahí no aplicaba: allí bloqueabas una dirección desde fuera, sin tocar nada. Aquí ya hay algo dentro, y todo lo que hagas destruye pruebas.

Y la última pregunta, la que de verdad importa: ¿por dónde entró? El proceso corre como el usuario del servidor web. Ese usuario no ejecuta programas por su cuenta — alguien le hizo ejecutar uno. Eso apunta a la aplicación web, que es exactamente donde estaba el fallo que encontraste en la primera sala.