Resumen

  • Según RFC 3164, un relay que recibía un paquete con prioridad válida pero sin marca temporal válida debía insertar su hora local y, preferiblemente, la identidad del dispositivo tal como la conocía.
  • Después de ampliar el encabezado, el paquete todavía tenía que caber en 1.024 bytes. Si no cabía, el relay debía eliminar bytes del final del contenido original.
  • Las normas posteriores delimitaron mejor originador, relay, colector y transporte, pero una sintaxis correcta, un marco completo o un par TLS autenticado no demostraban por sí solos el origen íntegro del mensaje.

Hacer más interpretable el paquete podía hacerlo menos completo

El RFC 3164, publicado en 2001, no estrenó syslog: dejó por escrito prácticas que ya circulaban en sistemas BSD. Distinguía entre el dispositivo que generaba un mensaje, el relay que lo recibía y reenviaba, y el colector que lo almacenaba o analizaba sin volver a transmitirlo. El emisor no tenía por qué saber cuál de las dos funciones había al otro lado.

La interoperabilidad dependía de reconocer una forma mínima. Al recibir un paquete, el relay examinaba primero PRI, la prioridad entre signos angulares, y después TIMESTAMP. Si ambos parecían válidos y su configuración exigía reenviar esa prioridad, debía transmitir el paquete sin modificarlo. No estaba obligado a comprobar si la hora era verdadera ni si HOSTNAME coincidía con la dirección desde la que llegaban los bytes.

Ese detalle separa formato de evidencia. Una fecha que encajaba en el patrón podía estar equivocada. Un nombre bien formado podía haber sido declarado por otra máquina. La ruta rápida protegía la continuidad del paquete, no certificaba su historia.

Cuando PRI era válido pero TIMESTAMP faltaba o tenía una forma inválida, el relay debía intervenir. Inmediatamente después de PRI añadía una marca temporal y un espacio. La marca era la hora local actual del propio relay. No intentaba reconstruir el instante del evento original. También debía procurar añadir HOSTNAME: el nombre del dispositivo según el conocimiento del relay o, si no lo sabía, su dirección IP. El resto de lo recibido se anexaba como CONTENT.

Entonces aparecía la aritmética destructiva. RFC 3164 exigía que el paquete completo midiera como máximo 1.024 bytes. Tras insertar hora y nombre, el relay debía volver a contar. Si el resultado rebasaba el límite, debía truncarlo a 1.024 bytes. La especificación advertía que así podía perderse información vital del final del paquete original.

La reparación no ampliaba el recipiente. Competía con su carga. Un mensaje podía ganar una hora aproximada de llegada y una identidad inferida, pero perder el código de error, el objeto afectado o la conclusión escrita al final. El colector veía un encabezado más ordenado y un relato menos entero.

La prioridad predeterminada también alteraba la historia

Si PRI faltaba o era irreconocible, el relay insertaba la prioridad 13, añadía TIMESTAMP, preferiblemente añadía HOSTNAME y trataba todo el paquete recibido como contenido. Después aplicaba el mismo techo de 1.024 bytes. Cuanto más defectuosa era la cabecera de entrada, más espacio podía consumir su normalización.

Un relay posterior podía recibir el producto ya reparado, reconocer PRI y TIMESTAMP y reenviarlo sin tocarlo. La forma final no decía necesariamente qué campos procedían del originador y cuáles del primer relay. La transformación podía volverse invisible para quien solo conservaba la última copia.

La antigua fecha tenía otra carencia: mes, día y hora local, pero no año ni zona horaria. El colector podía inferir el año al archivar, aunque los retrasos y los cambios de año hacían frágil esa asociación. La fecha insertada indicaba con más seguridad cuándo observó el relay que cuándo ocurrió el hecho.

Un marco exacto no recupera un sufijo perdido

El RFC 5424 formalizó en 2009 las funciones de originator, relay, collector, transport sender y transport receiver. Amplió el encabezado con VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID y MSGID, además de datos estructurados. También hizo depender el tamaño de cada transporte: todo receptor debía aceptar hasta 480 octetos y, de preferencia, hasta 2.048.

Si un mensaje excedía lo soportado, el receptor debía preferir truncar la carga o podía descartarlo. Toda truncación debía producirse al final. Con ello sobreviven primero los campos iniciales, aunque el corte pueda dejar UTF-8 inválido o datos estructurados incompletos. La sección de seguridad advierte que un atacante puede aprovechar el corte para ocultar información vital y recomienda situar pronto lo indispensable.

El RFC 5425 usa para TLS un conteo decimal de octetos, un espacio y el mensaje. Ese marco indica exactamente dónde acaba el mensaje entregado en ese salto, incluso si atraviesa varios registros TLS. Pero el propio documento aclara que la identidad autenticada del emisor de transporte no tiene por qué corresponder con HOSTNAME. TLS protege el salto; no convierte el encabezado en una declaración firmada por el originador remoto.

El RFC 5426 exige un solo mensaje syslog por datagrama UDP, completo o truncado. El RFC 6587 recoge para TCP el conteo de octetos y el encuadre no transparente mediante un terminador. Ambos ayudan a delimitar lo que viaja. Ninguno puede reponer bytes que un relay anterior ya eliminó.

El registro de parámetros syslog de IANA asigna números de facility, severity, versión e identificadores de datos estructurados. Es un diccionario para interpretar campos, no un testimonio de que un mensaje llegó completo, que un producto implementó una opción o que HOSTNAME era auténtico.

RFC 5424 ofrece además timeQuality, un elemento estructurado con el que el originador puede declarar si conoce su zona horaria, si está sincronizado y qué precisión cree tener. Es una mejora importante frente a la fecha sin año ni zona de RFC 3164, pero sigue siendo una declaración del originador. El colector puede usarla para correlacionar con prudencia; no debe convertirla en una medición independiente.

Los mínimos de UDP también muestran por qué “el límite de syslog” dejó de ser una sola cifra. RFC 5426 obliga a un receptor IPv4 a aceptar hasta 480 octetos y a uno IPv6 hasta 1.180; recomienda 2.048 para todos. Esas cifras procuran evitar la fragmentación en redes con MTU mínimos, no garantizan que una ruta, un equipo o un archivo conserve mensajes mayores. La capacidad de recibir, la probabilidad de transportar y la política de guardar son límites distintos.

Por eso una investigación no puede deducir la truncación solo de una longitud redonda. Un mensaje de 1.024 bytes puede haber nacido así, haber sido cortado por una regla antigua o haber sido reducido por otro componente. El RFC explica mecanismos posibles; atribuir uno a una incidencia concreta exige comparar copias y configuración.

Fuentes