Syslog - Syslog

Syslog
Autor (es) original (es) Eric Allman
Versión inicial Decenio de 1980
Sistema operativo Tipo Unix
Escribe Registro del sistema
Sitio web datatracker .ietf .org / wg / syslog / charter / Edita esto en Wikidata

En el cálculo de , syslog / s ɪ s l ɒ ɡ / es un estándar para el registro de mensajes . Permite la separación del software que genera 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 informativos, de análisis y de depuración generales. 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 los datos de registro de diferentes tipos de sistemas en un depósito central. Existen implementaciones de syslog para muchos sistemas operativos.

Cuando opera en una red, syslog usa una arquitectura cliente-servidor donde un servidor syslog escucha y registra los mensajes provenientes de los clientes.

Historia

Syslog fue desarrollado en la década de 1980 por Eric Allman como parte del proyecto Sendmail . Fue adoptado fácilmente por otras aplicaciones y desde entonces se ha convertido en la solución de registro estándar en sistemas similares a Unix. También existe una variedad de implementaciones en otros sistemas operativos y se encuentra comúnmente en dispositivos de red, como enrutadores .

Syslog originalmente funcionaba como un estándar de facto , sin ninguna especificación autorizada publicada, 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. Fue estandarizado por RFC 5424.

Varias empresas han intentado reclamar patentes para aspectos específicos de las implementaciones de syslog. Esto ha tenido poco efecto en el uso y estandarización del protocolo.

Componentes del mensaje

La información proporcionada por el creador de un mensaje de Syslog incluye el código de instalación y el nivel de gravedad. El software syslog agrega información al encabezado de información antes de pasar la entrada al receptor syslog. Dichos componentes incluyen un ID de proceso originador, una marca de tiempo y el nombre de host o la dirección IP del dispositivo.

Instalaciones

Se utiliza un código de instalación para especificar el tipo de sistema que registra el mensaje. Los mensajes con diferentes facilidades pueden manejarse de manera diferente. La lista de instalaciones disponibles está definida por el estándar:

Código de instalación Palabra clave Descripción
0 kern Mensajes del kernel
1 usuario Mensajes a nivel de usuario
2 correo Sistema de correo
3 demonio Demonios del sistema
4 auth Mensajes de seguridad / autenticación
5 syslog Mensajes generados internamente por syslogd
6 lpr Subsistema de impresora de línea
7 Noticias Subsistema de noticias de la red
8 uucp Subsistema UUCP
9 cron Subsistema cron
10 authpriv Mensajes de seguridad / autenticación
11 ftp Demonio FTP
12 ntp Subsistema NTP
13 seguridad Auditoría de registros
14 consola Alerta de registro
15 solaris-cron Demonio de programación
16-23 local0 - local7 Instalaciones de uso local

El mapeo entre el código de la instalación y la palabra clave no es uniforme en diferentes sistemas operativos e implementaciones de syslog.

Nivel de severidad

La lista de gravedad también está definida por el estándar:

Valor Gravedad Palabra clave Palabras clave obsoletas Descripción Condición
0 Emergencia emerg panic El sistema es inutilizable Una condición de pánico.
1 Alerta alert Se deben tomar medidas de inmediato Una condición que debe corregirse de inmediato, como una base de datos del sistema dañada.
2 Crítico crit Condiciones criticas Errores de dispositivo duro.
3 Error err error Condiciones de error
4 Advertencia warning warn Condiciones de advertencia
5 Aviso notice Condiciones normales pero significativas Condiciones que no son condiciones de error, pero que pueden requerir un tratamiento especial.
6 Informativo info Mensajes informativos
7 Depurar debug Mensajes de nivel de depuración Mensajes que contienen información que normalmente se usa solo cuando se depura un programa.

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 se produzca en un intento de mostrar el código postal del cliente se le puede asignar un nivel de Error o incluso de Advertencia .

El proceso del servidor que maneja la visualización de mensajes generalmente incluye todos los niveles más bajos (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 los mensajes de notificación , información y depuración .

Mensaje

En RFC 3164, el componente del mensaje (conocido como MSG) se especificó con 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, "MSG es lo que se llama CONTENT en RFC 3164. El TAG ahora es parte del encabezado, pero no como un solo campo. El TAG se ha dividido en APP-NAME, PROCID y MSGID. Esto no se asemeja totalmente al uso de TAG, pero proporciona la misma funcionalidad en 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 codificarse en un juego de caracteres UTF-8 y deben evitarse los valores de octetos en la gama de caracteres de control ASCII tradicional .

Registrador

Los mensajes de registro generados pueden dirigirse a varios destinos, incluida la consola , los archivos, los servidores de registro del sistema remotos o los relés. La mayoría de las implementaciones proporcionan una utilidad de línea de comandos, a menudo llamada registrador , así como una biblioteca de software , para enviar mensajes al registro.

Para mostrar y monitorear los registros recopilados, es necesario utilizar una aplicación cliente o acceder al archivo de registro directamente en el sistema. Las herramientas básicas de la línea de comandos 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.

Protocolo de red

Cuando opera en una red, syslog usa una arquitectura cliente-servidor donde el servidor escucha en un puerto conocido o registrado para 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. Como UDP carece de mecanismos de control de congestión, se requiere compatibilidad con la seguridad de la capa de transporte en las implementaciones y se recomienda para uso general en la transmisión. Puerto 6514 del protocolo de control (TCP).

Limitaciones

Dado que cada proceso, aplicación y sistema operativo se escribió de forma independiente, hay poca uniformidad en la carga útil del mensaje de registro. Por esta razón, no se asume nada sobre su formato o contenido. Un mensaje de syslog está formateado (RFC 5424 proporciona la definición de formulario Augmented Backus – Naur (ABNF)), pero su campo MSG no lo está.

El protocolo de red es una comunicación simplex , sin ningún medio de acusar recibo de la entrega al originador.

panorama

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 seguridad y red, como su aplicación propuesta dentro del entorno de atención médica.

Las regulaciones, como la Ley Sarbanes-Oxley , PCI DSS , HIPAA y muchas otras, requieren que las organizaciones implementen medidas de seguridad integrales, que a menudo incluyen la recopilación y análisis de registros de muchas fuentes diferentes. El formato syslog ha demostrado su eficacia en la consolidación de registros, ya que existen muchas herramientas patentadas y de código abierto para informar y analizar 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 problemas.

Documentos estándar de Internet

El protocolo Syslog se define mediante documentos de Solicitud de comentarios (RFC) publicados por el Grupo de trabajo de ingeniería de Internet ( estándares de Internet ). La siguiente es una lista de RFC que definen el protocolo syslog:

  • El protocolo BSD syslog . RFC  3164 .(obsoleto por el protocolo Syslog . RFC  5424 .)
  • Entrega confiable para syslog . RFC  3195 .
  • El protocolo Syslog . RFC  5424 .
  • Asignación de transporte TLS para Syslog . RFC  5425 .
  • Transmisión de mensajes de Syslog a través de UDP . RFC  5426 .
  • Convenciones textuales para la gestión de Syslog . RFC  5427 .
  • Mensajes de Syslog firmados . RFC  5848 .
  • Mapeo de transporte de Datagram Transport Layer Security (DTLS) para Syslog . RFC  6012 .
  • Transmisión de mensajes de Syslog a través de TCP . RFC  6587 .

Ver también

Referencias

enlaces externos