Registros de servidor web leídos

Cada línea del registro de acceso trae la dirección de origen, la hora, el método, la ruta, el código de estado, los bytes devueltos y el agente que el cliente declara. El código de estado es lo que el servidor contestó: un 200 es «atendido», un 302 es una redirección (en un inicio de sesión suele significar que entró), un 401 es «no autenticado», un 403 es «prohibido» y un 404 es «no existe».

Esa lectura es mecánica y por eso engaña. Un 200 a una ruta de datos de clientes dice que el servidor entregó algo; no dice si quien lo pidió tenía derecho a recibirlo. Esa decisión la toma el código de la aplicación, y si falla, falla en silencio con un 200.

Se busca lo que no encaja con el uso normal, no lo que parece malo. Un cliente se equivoca de contraseña una vez y entra a la segunda; un origen con varios 401 seguidos a la misma ruta de inicio de sesión, con un agente de automatización en vez de un navegador, es otra cosa. Contar los 401 por dirección es el primer filtro de casi toda lectura de registros de acceso.

El agente es un dato que el propio cliente escribe: sirve de pista, no de prueba.

Tras los fallos, la línea que importa es la primera en la que ese mismo origen entra: un POST al inicio de sesión que ya no devuelve 401 sino una redirección. Esa hora abre la cronología del abuso; todo lo anterior son intentos y todo lo posterior es lo que se hizo con la sesión.

Se anota la hora en UTC, tal como está en el registro, para no mezclarla con la hora local de nadie.

Después del acierto, el registro muestra una secuencia de peticiones a identificadores consecutivos de la misma ruta de datos. Nadie recorre sus propias pólizas una por una con un segundo de diferencia entre cada una: la regularidad es el patrón. Contar cuántas de esas peticiones tuvieron éxito acota lo que pudo entregarse, que es lo que importa para el alcance.

Cuidado con las respuestas 404: son identificadores que no existen, no datos entregados.

Antes de escribir el primer párrafo del informe se separa lo que el registro prueba de lo que sugiere y de lo que no sabe. El servidor web anota la petición y su resultado; la cuenta autenticada y el cuerpo de lo enviado dependen de cómo se configuró el registro, y aquí se puede comprobar cuáles de esos campos existen.

Un informe que afirma una cuenta que el registro nunca anotó sostiene su historia con una suposición.