Qué está corriendo y quién lo arrancó

Los procesos son los programas vivos del sistema. Cada uno corre con un usuario y atiende algo: la web, la base de datos, el acceso remoto. Un proceso que corre como administrador y atiende conexiones de fuera es superficie de ataque; uno que apareció a una hora rara con un nombre que no reconoces es, para el defensor, lo primero que mirar. En Salitre, el proceso de la web corre como un usuario de servicio: eso es lo normal, y conocer lo normal es el radar.

No se puede reconocer lo raro sin conocer lo normal. Por eso el primer trabajo es saber qué debería estar corriendo.

Los programas que deben estar siempre disponibles —la web, la base de datos, el acceso remoto— los gestiona el sistema como «servicios»: los arranca al encender y los reinicia si se caen. Saber qué servicios arrancan solos es media administración y media defensa. Un servicio es una decisión que alguien tomó y quizá olvidó; revisarlos es revisar decisiones viejas que siguen vivas. En Salitre, varios servicios arrancan al encender, y uno de ellos sobra.

Un servicio habilitado que nadie recuerda haber activado es exactamente el tipo de puerta que el que ataca busca y el que defiende debería haber cerrado.

El criterio no es apagar servicios al azar: es que cada servicio activo tenga un motivo. Un acceso remoto que manda todo sin cifrar es peor que no tener acceso remoto, porque ofrece la puerta y además regala lo que pasa por ella. Distinguir un servicio esperado de uno que sobra es lo que separa administrar de solo encender la máquina. En Salitre, conviven el acceso remoto cifrado (esperado) y uno viejo sin cifrar (que sobra).

Reducir lo que corre a lo que hace falta es la forma más barata de encoger la superficie de ataque. Lo que no está activo no se puede atacar.

El servicio que sobra no se adivina: se encuentra listando lo que arranca solo. Abre el laboratorio, revisa los servicios activos del servidor de Salitre y baja hasta el código de sala al pie del informe.