En informática , syslog / ˈsɪslɒɡ / es un estándar para el registro de mensajes . Permite separar el software que genera los mensajes, el sistema que los almacena y el software que los informa y analiza . Cada mensaje está etiquetado con un código de instalación, que indica el tipo de sistema que genera el mensaje, y se le asigna un nivel de gravedad.
Los diseñadores de sistemas informáticos pueden utilizar syslog para la gestión del sistema y la auditoría de seguridad, así como para mensajes de información general, análisis y depuración. Una amplia variedad de dispositivos, como impresoras, enrutadores y receptores de mensajes en muchas plataformas, utilizan el estándar syslog. Esto permite la consolidación de datos de registro de diferentes tipos de sistemas en un repositorio central. Existen implementaciones de syslog para muchos sistemas operativos.
Cuando opera a través de una red, syslog utiliza una arquitectura cliente-servidor donde un servidor syslog escucha y registra los mensajes provenientes de los clientes.
Syslog fue desarrollado en la década de 1980 por Eric Allman como parte del proyecto Sendmail . [1] Fue rápidamente adoptado por otras aplicaciones y desde entonces se ha convertido en la solución de registro estándar en sistemas tipo Unix . [2] También existe una variedad de implementaciones en otros sistemas operativos y se encuentra comúnmente en dispositivos de red, como enrutadores . [3]
Syslog funcionó originalmente como un estándar de facto , sin ninguna especificación publicada autorizada, y existían muchas implementaciones, algunas de las cuales eran incompatibles. El Grupo de Trabajo de Ingeniería de Internet documentó el status quo en RFC 3164 en agosto de 2001. Fue estandarizado por RFC 5424 en marzo de 2009. [4]
Varias empresas han intentado reclamar patentes para aspectos específicos de las implementaciones de syslog. [5] [6] Esto ha tenido poco efecto en el uso y la estandarización del protocolo. [ cita requerida ]
La información proporcionada por el creador de un mensaje de syslog incluye el código de la instalación y el nivel de gravedad. El software de syslog agrega información al encabezado de información antes de pasar la entrada al receptor de syslog. Dichos componentes incluyen un ID de proceso del creador, una marca de tiempo y el nombre de host o la dirección IP del dispositivo.
Se utiliza un código de facilidad para especificar el tipo de sistema que registra el mensaje. Los mensajes con distintas facilidades pueden manejarse de forma diferente. [7] La lista de facilidades disponibles se describe en el estándar: [4] : 9
La correlación entre el código de instalación y la palabra clave no es uniforme en diferentes sistemas operativos e implementaciones de syslog. [8]
La lista de severidades también está descrita por la norma: [4] : 10
El significado de los niveles de gravedad distintos de Emergencia y Depuración es relativo a la aplicación. Por ejemplo, si el propósito del sistema es procesar transacciones para actualizar la información del saldo de la cuenta del cliente, a un error en el paso final se le debe asignar el nivel de Alerta. Sin embargo, a un error que ocurra al intentar mostrar el código postal del cliente se le puede asignar el nivel de Error o incluso de Advertencia .
El proceso del servidor que maneja la visualización de mensajes normalmente incluye todos los niveles inferiores (más severos) cuando se solicita la visualización de niveles menos severos. Es decir, si los mensajes están separados por gravedad individual, también se incluirá una entrada de nivel de Advertencia al filtrar mensajes de Aviso , Información y Depuración . [12]
En RFC 3164, se especificó que el componente del mensaje (conocido como MSG) tiene estos campos: TAG , que debe ser el nombre del programa o proceso que generó el mensaje, y CONTENT, que contiene los detalles del mensaje.
Descrito en RFC 5424, [4] "MSG es lo que se denominaba CONTENT en RFC 3164. La ETIQUETA ahora forma parte del encabezado, pero no como un campo único. La ETIQUETA se ha dividido en APP-NAME, PROCID y MSGID. Esto no se parece en absoluto al uso de la ETIQUETA, pero proporciona la misma funcionalidad para la mayoría de los casos". Las herramientas de syslog populares, como Rsyslog, se ajustan a este nuevo estándar.
El campo de contenido debe estar codificado en un conjunto de caracteres UTF-8 y se deben evitar los valores de octetos en el rango de caracteres de control ASCII tradicional. [13] [4]
Los mensajes de registro generados pueden dirigirse a varios destinos, entre ellos, la consola , archivos, servidores syslog remotos o relés. La mayoría de las implementaciones proporcionan una utilidad de línea de comandos, a menudo denominada logger , así como una biblioteca de software , para enviar mensajes al registro. [14]
Para visualizar y monitorear los registros recopilados, es necesario utilizar una aplicación cliente o acceder al archivo de registro directamente en el sistema. Las herramientas de línea de comandos básicas son tail y grep . Los servidores de registro se pueden configurar para enviar los registros a través de la red (además de los archivos locales). Algunas implementaciones incluyen programas de informes para filtrar y mostrar mensajes de syslog.
Cuando se opera sobre una red, syslog utiliza una arquitectura cliente-servidor donde el servidor escucha en un puerto conocido o registrado las solicitudes de protocolo de los clientes. Históricamente, el protocolo de capa de transporte más común para el registro de red ha sido el Protocolo de datagramas de usuario (UDP), con el servidor escuchando en el puerto 514. [15] Debido a que UDP carece de mecanismos de control de congestión, se utiliza el puerto 6514 del Protocolo de control de transmisión (TCP); la seguridad de la capa de transporte también es necesaria en las implementaciones y se recomienda para uso general. [16] [17]
Dado que cada proceso, aplicación y sistema operativo se escribió de forma independiente, existe poca uniformidad en la carga útil del mensaje de registro. Por este motivo, no se hace ninguna suposición sobre su formato o contenido. Un mensaje de syslog está formateado (RFC 5424 proporciona la definición de formato Backus–Naur aumentado (ABNF)), pero su campo MSG no.
El protocolo de red es una comunicación simplex , sin medios para reconocer la entrega al originador.
Varios grupos están trabajando en borradores de estándares que detallan el uso de syslog para algo más que el registro de eventos de red y seguridad, como su aplicación propuesta dentro del entorno de atención médica. [18]
Las normativas, como la Ley Sarbanes-Oxley , PCI DSS , HIPAA y muchas otras, exigen que las organizaciones implementen medidas de seguridad integrales, que a menudo incluyen la recopilación y el análisis de registros de muchas fuentes diferentes. El formato syslog ha demostrado ser eficaz para consolidar registros, ya que existen muchas herramientas de código abierto y de propiedad exclusiva para la generación de informes y el análisis de estos registros. Existen utilidades para la conversión del registro de eventos de Windows y otros formatos de registro a syslog.
Los proveedores de servicios de seguridad gestionados intentan aplicar técnicas analíticas y algoritmos de inteligencia artificial para detectar patrones y alertar a los clientes sobre los problemas. [19]
El protocolo Syslog está definido por los documentos de Solicitud de comentarios (RFC) publicados por el Grupo de trabajo de ingeniería de Internet ( estándares de Internet ). A continuación, se incluye una lista de RFC que definen el protocolo Syslog: [20]
Las palabras clave error, warn y panic están en desuso y no deberían utilizarse más.
LOG_NOTICE Condiciones que no son condiciones de error, pero que pueden requerir un manejo especial.
LOG_NOTICE El mensaje describe un evento normal pero importante.