Leer un script de parseo

Un script de parseo hace tres cosas: lee una línea de texto, la compara con un patrón y devuelve un diccionario con campos con nombre. Las reglas posteriores no ven nunca la línea original; solo ven lo que el script entregó. Por eso leer el script importa tanto como leer la regla: lo que él descarta no existe para la detección.

La pregunta que conviene hacerse siempre es la de las tres salidas posibles de una función de parseo: devuelve datos, lanza un error o devuelve «nada». Cada una tiene consecuencias distintas para quien detecta. Un error se nota; un «nada» que nadie cuenta, no.

Abre /scripts/parsea_vpn.py y lee las dos funciones: una procesa una línea y la otra recorre el archivo.

Una expresión regular se lee de izquierda a derecha, un trozo cada vez. En el patrón del script, cada paréntesis con nombre es un campo: (?P<usuario>\S+) toma una secuencia de caracteres que no sean espacios y la guarda como usuario. Las palabras fijas, como sesion, deben aparecer tal cual. Y el signo $ del final obliga a que, después del último campo, la línea termine.

El detalle que más sorprende al leer es una alternativa escrita así: ok|fallo. La expresión distingue mayúsculas de minúsculas salvo que se le indique lo contrario. El patrón no dice «cualquier valor de resultado»; dice «estas dos palabras exactas».

Abre /scripts/muestra_vpn.log y compara cada línea con el patrón. Cuenta cuántas de las doce no encajan.

Entre las líneas que no encajan hay una de especial: es un inicio de sesión fallido, justo el evento que una regla de fuerza bruta necesita. El script la descarta no porque esté mal formada, sino porque el patrón es más estricto que el registro. Cuando un parser es más estricto que su fuente, lo que se pierde suele ser lo más interesante.

Busca esa línea en la muestra y fíjate en cómo está escrito el valor del campo resultado.

Saber cuántas líneas se pierden es el primer paso; saber cuándo, el segundo. Si el registro empezó a cambiar de formato a cierta hora, la hora de la primera línea descartada es la pista para preguntar al equipo de la fuente qué cambió y cuándo.

Recorre la muestra de arriba abajo y anota la hora, tal como está escrita en el registro, de la primera línea que el patrón no acepta. Escribe solo horas, minutos y segundos.

Un parser que descarta en silencio produce un resultado limpio y falso: la regla no salta porque el dato nunca le llegó. La corrección no es relajar el patrón hasta que acepte cualquier cosa, porque entonces entrarían líneas con campos que no significan lo que parece. Tampoco es detener todo el programa por una línea rara.

Lo que se espera es que el script sea honesto sobre lo que no pudo leer: que lo cuente y lo diga al terminar, con ejemplos, para que alguien decida si el patrón o la fuente tienen que cambiar.