La línea base de un servidor

La línea base de un servidor no es un número: es un inventario de hábitos. Cuatro bastan para empezar. Los procesos, con la cuenta que los ejecuta y en cuántos días de la ventana estuvieron. Las sesiones, es decir, qué cuentas entran, desde qué origen y con qué frecuencia. Los puertos en escucha, con el servicio que los abre y desde cuándo. Y los destinos salientes, a quién llama el servidor, por qué puerto y cuántos días.

Un servidor de aplicación es aburrido a propósito: pocos procesos, pocos administradores, un salto para entrar y cuatro o cinco destinos de siempre. Esa uniformidad es la que vuelve visible lo que cambia. En un puesto de oficina, el mismo inventario sería un desorden y la línea base no serviría.

Abre procesos. Cada fila trae el proceso, su cuenta, los días de los 29 anteriores en que estuvo activo y si corre hoy, 30 de septiembre. La mayoría tiene 29: están siempre. Los que no, son las desviaciones de proceso. Con procesos | where dias_en_base == 0 aparece lo que corre hoy sin haber corrido nunca en la ventana.

Que algo no esté en la línea base no lo hace malo; lo hace no medido. La tarea del analista es la siguiente: ver con qué cuenta corre, si coincide con un cambio aprobado y a quién se le pregunta.

La segunda dimensión son las sesiones. Ejecuta sesiones_ssh | summarize veces = count() by cuenta, origen | sort by veces desc. Una cuenta de servicio de respaldo entra casi todas las noches desde su servidor; los administradores entran desde el servidor de salto de la empresa. Una sesión que combina una cuenta conocida con un origen que no es de las habituales es la desviación que importa: la cuenta es normal, el origen no.

Es el mismo patrón de las cuentas de servicio que viste en el módulo de cacería, pero ahora se lee en una tabla de frecuencias, no en una búsqueda.

Casi todo el mundo busca lo que aparece. Una línea base también detecta lo que falta. Ejecuta procesos | where hoy == "no". Salen dos filas. Una, cuadre-semanal, se ve en 4 de los 29 días: su patrón es de una vez por semana, así que que hoy falte es esperable. La otra, agente-respaldo, estuvo los 29 días y hoy no está.

Aquí hay una trampa de razonamiento: la ausencia de un agente de respaldo no prueba una intrusión ni la descarta. Lo que dice es que el control dejó de funcionar y que durante ese tiempo no hay copia ni quien la verifique.

La tercera dimensión son los puertos. Ejecuta puertos_escucha: tres puertos están desde antes de la ventana, y el 9100 aparece desde el 22 de septiembre. Es un puerto nuevo y lo abre un proceso que sí está en la tabla de procesos con 7 días. Antes de pensar nada más, se mira el calendario de cambios del servidor con cambios | where fecha == "09-22". Si hay un cambio aprobado que lo explica, la desviación pasa a ser parte de la línea base nueva; si no lo hay, es un caso.