La línea de tiempo del host con tres fuentes

Ordenar los eventos de varias fuentes por la hora que cada una escribe parece lo más natural y es el camino directo al error. Las fuentes no tienen por qué coincidir en la zona (UTC, hora local) ni en la exactitud del reloj. Colombia usa UTC-5 todo el año, sin cambio de hora de verano, de modo que una hora local de Bogotá se pasa a UTC sumándole cinco horas; otras zonas no son tan estables y conviene confirmar la zona de cada fuente en vez de suponerla.

El método tiene dos pasos antes del orden: llevar todas las horas a una sola zona y corregir los relojes que se desvían, cuando la plataforma conoce el desfase. Solo entonces el orden de los eventos dice algo sobre qué pasó antes y qué después.

El resolutor DNS de la sede escribe la hora local sin decir la zona. La tabla de relojes de la plataforma lo deja anotado. Para ponerla junto a la del cortafuegos hay que convertirla.

Primero localiza la consulta de ese puesto al nombre que te indica el enunciado. Después aplica la conversión de la zona que dice la tabla de relojes y escribe el resultado como lo escribiría el cortafuegos, con horas, minutos y segundos.

La tabla de relojes dice que el proxy tiene el reloj adelantado: sus horas están por delante de la hora real en los segundos que indica la columna del desfase. Hay que restarlos a cada hora del proxy antes de compararla con las demás fuentes. Con una diferencia de minutos, un evento cambia de lugar en la historia.

El puesto hizo dos peticiones a través del proxy y entre las dos fuentes —el cortafuegos y el proxy— hay un acceso a archivos del mismo puesto. Con las horas corregidas, una de las dos peticiones ocurrió antes de ese acceso y la otra después.

Ordenar las tres fuentes por la hora tal como vienen no produce un error visible: produce una historia coherente y falsa. La conversión de zona mueve cinco horas a unos eventos y no a otros, y el desfase del proxy mueve unos minutos a los suyos. El ticket que se escribe con ese orden dice cosas que no ocurrieron en ese orden, y quien lo lea después las usará para decidir qué se contiene primero.

Compara cómo quedarían las tres fuentes con las horas sin tocar y con las horas corregidas, sobre todo la consulta DNS, la petición del proxy y el acceso a los archivos.

Con la escala común hay una pregunta que la línea de tiempo responde sola: cuánto pasó entre el primer rastro del equipo y el primer intento que el cortafuegos cortó. Es un dato corto que se escribe en el ticket y sirve para comparar con otros casos. Se mide en segundos para no discutir minutos.

La respuesta sale de restar dos horas ya llevadas a UTC: la de la consulta DNS de la tarea 2 y la del primer intento denegado del puesto.