La alerta del runner

5 tareas · 45 min · Principiante

Simulacro. Martes 12 de octubre de 2027, 10:30. Guayacán Logística, una empresa ficticia de transporte, no es ninguna de las empresas de los módulos anteriores. A las 09:52 una regla del equipo de seguridad avisó de un destino nuevo en la red de los runners de construcción. Tú no escribiste el código de ninguno de los servicios: respondes desde seguridad de plataforma. Tienes el acta, las trece ejecuciones del pipeline de la noche y el registro de salida del cortafuegos. Nadie te dice dónde mirar, y la consola solo lee. Esta sala es la primera lectura: qué pasó, desde dónde y cuántas veces.

0 de 5 · 0%

Objetivo de la sala

Un destino nuevo no es un incidente por sí solo: los equipos cambian de proveedor, de repositorio y de escáner. Lo que lo convierte en caso es lo que el registro permite atribuir: quién abrió la conexión, cuándo, y qué tienen en común las ejecuciones donde ocurrió. Lee el registro de salida del runner y quédate con el dato que separa esto de un cambio legítimo.

Responde para continuar

¿Qué dato del registro separa este caso de un destino nuevo legítimo del equipo?

Que la conexión salga de un runner de construcción, porque un runner nunca debería hablar con internet y eso ya basta para declarar el incidente Que el destino use el puerto 443, un puerto que solo se emplea para tráfico malicioso y por eso es la señal definitiva de este caso Que el script de instalación de un paquete, y no el gestor, abra la conexión, solo en las ejecuciones que bajaron una versión concreta

El registro del cortafuegos no solo dice a dónde se conectó el runner: dice qué proceso abrió la conexión. En una etapa de dependencias hay procesos esperados, y uno que no lo es.

Responde para continuar

Escribe el nombre del paquete cuyo script de instalación abrió las conexiones al destino externo.

Para fijar el inicio de la ventana de exposición necesitas la primera ejecución en la que ocurrió. Ordénalas por hora y no te quedes con la del aviso: la alerta saltó horas después.

Responde para continuar

Escribe el identificador de la primera ejecución del pipeline que se conectó al destino externo.

El alcance empieza por contar. Cruza el registro de salida con la lista de ejecuciones: cada ejecución afectada aparece una vez en el registro con la conexión al destino externo.

Responde para continuar

¿Cuántas ejecuciones distintas del pipeline se conectaron al destino externo?

Antes de contener hay que decidir qué se hace con lo que ya existe. Los registros del runner, del proxy y del cortafuegos son la única prueba de qué se ejecutó y cuándo, y suelen rotar solos.

Responde para continuar

¿Qué haces primero con la evidencia disponible?

Copiar los registros del runner, del proxy y del cortafuegos y listar las ejecuciones afectadas, antes de limpiar o reconstruir nada en ellos Esperar el aviso del mantenedor y no tocar nada hasta confirmar que el origen es el paquete, para no actuar sobre una sospecha sin comprobar Reconstruir cuanto antes los dos runners desde una imagen limpia para que el paquete deje de ejecutarse, y revisar después qué quedó en los registros

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

Entrar · Registrarse

1 Qué hace de esto un incidente Lab

2 Quién abrió la conexión Lab

3 El primer caso Lab

4 Cuántas veces Lab

5 Lo primero con la evidencia Lab

Whoami-Labs Pro utiliza cookies