Los relojes que no son malos

5 tareas · 40 min · Principiante

Casi todo lo que late en una red es legítimo: las comprobaciones de actualizaciones, la telemetría de un producto, la sincronización del calendario, un sensor. Una caza que enseña cada reloj como hallazgo se queda sin crédito en una semana. Aquí tienes el tablero de siete pares recurrentes de Textiles Quebrada Honda, con su abanico de equipos, su variación y la antigüedad del destino, y los vas filtrando con criterios medibles hasta que queda uno sin explicación. El criterio, no la intuición, es lo que separa lo que se escala de lo que se documenta.

0 de 5 · 0%

Objetivo de la sala

Abre SELECT * FROM pares. Cada fila es un destino con más de 200 llamadas en la jornada. Un reloj legítimo y uno malicioso se parecen en el intervalo, y se separan en otras columnas. Las que más pesan:

Abanico (equipos): lo instalado en todos los puestos late en todos; un reloj propio de un solo puesto es raro.
Antigüedad (visto_hace_dias): un destino conocido desde hace años tiene historia; uno que aparece hace días, no.
Excepción: alguien ya lo miró y lo aprobó con un ticket.
Variación de los bytes: un programa que repite la misma consulta envía lo mismo; una persona, no.

Ninguna sola decide. El filtro es la combinación, y cada criterio recorta ruido sin perder el caso.

Responde para continuar

Dos pares tienen un reloj casi perfecto. ¿Qué combinación de columnas los separa mejor?

Que el primero tenga una mediana de intervalo menor, ya que los canales de mando llaman siempre con más frecuencia Que uno use el puerto 443 y el otro no, porque el puerto delata siempre a un canal de mando Que uno lo hable un solo puesto, sin excepción y con destino nuevo, y el otro decenas de puestos desde hace años

Ver pista de ayuda

Piensa en el abanico de equipos, la antigüedad del destino y si hay excepción aprobada.

Un primer filtro por el reloj y el abanico: pares con variación de intervalo baja (cv_pct menor de 25) y un solo equipo (equipos igual a 1). El 25 es el umbral de este ejercicio; en la práctica se ajusta con los datos de la casa.

Tras este filtro todavía no se escala nada: se cuenta cuántos candidatos hay y cuál es la causa de cada uno. Un filtro que devuelve cincuenta filas no sirve; uno que devuelve dos, sí.

Responde para continuar

¿Cuántos pares tienen un cv_pct menor de 25 y un solo equipo?

Ver pista de ayuda

Recorre `SELECT * FROM pares` fila a fila aplicando las dos condiciones.

Entre los dos candidatos, uno ya tiene explicación documentada. Abre SELECT * FROM excepciones y descarta lo que está ahí con su motivo y su ticket: si un destino aparece en la lista, alguien ya verificó qué es.

Lo que queda no es una baliza demostrada: es un par regular, con un solo puesto y sin nadie que lo haya explicado. Eso es un candidato, y lo que hace un cazador con un candidato es identificar quién lo origina.

Responde para continuar

¿Qué dominio queda como candidato sin excepción aprobada tras el filtro de reloj y abanico?

Ver pista de ayuda

Cruza `SELECT * FROM pares` con `SELECT * FROM excepciones`; de los dos candidatos de la tarea anterior, uno aparece en la lista.

En el tablero hay un reloj con un 9 % de variación, 18 equipos y casi un año de historia, que no está en la lista de excepciones: la telemetría de la aplicación de contabilidad. No es candidato por el abanico y la antigüedad, pero tampoco está «aprobado».

La acción correcta no es escalarlo ni ignorarlo: se confirma con el dueño de la aplicación qué es y se registra como excepción con su ticket. Así la próxima caza no lo encuentra, y el tablero queda más corto. Mantener la lista de excepciones al día es parte de la caza.

Responde para continuar

La telemetría de contabilidad es regular, la usan 18 puestos desde hace más de un año y no tiene excepción. ¿Qué haces?

La escalas como posible canal de mando, porque cualquier reloj fuera de la lista de excepciones es sospechoso por definición La confirmas con su dueño y la registras como excepción con su ticket, sin escalarla como incidente de seguridad La ignoras, porque con 18 puestos nadie va a revisar nunca qué es y la lista de excepciones es solo trámite

Ver pista de ayuda

El abanico y la antigüedad la explican. Lo que falta es dejarlo escrito para que no vuelva a aparecer.

Un candidato sin dueño no se puede investigar. Con el destino que quedó, SELECT * FROM origenes WHERE destino = '198.51.100.143' te da la dirección del único puesto que habla con él, y SELECT * FROM inventario la convierte en equipo, área y responsable.

Ese es el dato que se lleva al ticket de investigación: el siguiente paso ya no es la red, es lo que ese equipo tiene instalado.

Responde para continuar

¿Cómo se llama el equipo que habla con el destino candidato?

Ver pista de ayuda

Primero la dirección en `origenes`, después el nombre en `inventario`.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Regular no es sospechoso Lab

2 Contar los candidatos Lab

3 Quitar lo explicado Lab

4 El regular que sí tiene explicación Lab

5 Quién es el candidato Lab

Whoami-Labs Pro utiliza cookies