Syslog

syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.

Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.

Usos

Es útil recolectar, registrar y analizar, por ejemplo:^[1]​

• Un intento de acceso con contraseña equivocada.
• Un acceso correcto al sistema.
• Anomalías: variaciones en el funcionamiento normal del sistema.
• Alertas cuando ocurre alguna condición especial.
• Información sobre las actividades del sistema operativo.
• Errores del hardware o el software.

También es posible registrar el funcionamiento normal de los programas; por ejemplo, guardar cada acceso que se hace a un servidor web, aunque esto suele estar separado del resto de alertas.

Protocolo

El protocolo syslog es muy sencillo: existe un ordenador servidor ejecutando el servidor de syslog, conocido como syslogd (demonio de syslog). El cliente envía un pequeño mensaje de texto (de menos de 1024 bytes).

Los mensajes de syslog se suelen enviar vía UDP, por el puerto 514, en formato de texto plano. Algunas implementaciones del servidor, como syslog-ng, permiten usar TCP en vez de UDP, y también ofrecen Stunnel para que los datos viajen cifrados mediante SSL/TLS.

Aunque syslog tiene algunos problemas de seguridad, su sencillez ha hecho que muchos dispositivos lo implementen, tanto para enviar como para recibir. Eso hace posible integrar mensajes de varios tipos de sistemas en un solo repositorio central.

Estructura del mensaje

El mensaje enviado se compone de tres campos:

• Prioridad
• Cabecera
• Texto

Entre todos no han de sumar más de 1024 bytes, pero no hay longitud mínima.

Prioridad

La prioridad es un número de 8 bits que indica tanto el recurso (tipo de aparato que ha generado el mensaje) como la severidad (importancia del mensaje), números de 5 y 3 bits respectivamente. Los códigos de recurso y severidad los decide libremente la aplicación, pero se suele seguir una convención para que clientes y servidores se entiendan.

Estos son los códigos observados en varios sistemas. Fuente: RFC 3164.

0	Mensajes del kernel
1	Mensajes del nivel de usuario
2	Sistema de correo
3	Demonios de sistema
4	Seguridad/
5	Mensajes generados internamente por syslogd
6	Subsistema de impresión
7	Subsistema de noticias sobre la red
8	Subsistema UUCP
9	Demonio de reloj
10	Seguridad/Autorización
11	Demonio de FTP
12	Subsistema de NTP
13	Inspección del registro
14	Alerta sobre el registro
15	Demonio de reloj
16	Uso local 0
17	Uso local 1
18	Uso local 2
19	Uso local 3
20	Uso local 4
21	Uso local 5
22	Uso local 6
23	Uso local 7

Códigos de severidad

Los 3 bits menos significativos del campo prioridad dan 8 posibles grados. Fuente: RFC 3164.

0	Emergencia: el sistema está inutilizable
1	Alerta: se debe actuar inmediatamente
2	Crítico: condiciones críticas
3	Error: condiciones de error
4	Peligro: condiciones de peligro
5	Aviso: normal, pero condiciones notables
6	Información: mensajes informativos
7	Depuración: mensajes de bajo nivel

Cálculo de la prioridad

Para conocer la prioridad final de un mensaje, se aplica la siguiente fórmula:

Prioridad = Recurso * 8 + Severidad

Por ejemplo, un mensaje de kernel (Recurso=0) con Severidad=0 (emergencia), tendría Prioridad igual a 0*8+0 = 0. Uno de FTP (11) de tipo información (6) tendría 11*8+6=94. Como se puede ver, valores más bajos indican mayor prioridad.

Cabecera

El segundo campo de un mensaje syslog, la cabecera, indica tanto el tiempo como el nombre del ordenador que emite el mensaje. Esto se escribe en codificación ASCII (7 bits), por tanto es texto legible.

El primer campo, tiempo, se escribe en formato Mmm dd hh:mm:ss, donde Mmm son las iniciales del nombre del mes en inglés, dd, es el día del mes, y el resto es la hora. No se indica el año.

Justo después viene el nombre de ordenador (hostname), o la dirección IP si no se conoce el nombre. No puede contener espacios, ya que este campo acaba cuando se encuentra el siguiente espacio.

Texto

Lo que queda de paquete syslog al llenar la prioridad y la cabecera es el propio texto del mensaje. Éste incluirá información sobre el proceso que ha generado el aviso, normalmente al principio (en los primeros 32 caracteres) y acabado por un carácter no alfanumérico (como un espacio, ":" o "["). Después, viene el contenido real del mensaje, sin ningún carácter especial para marcar el final.

Historia

syslog fue desarrollado por Eric Allman en la Universidad de California en Berkeley ( año 1981) como parte del proyecto Sendmail e inicialmente solo para este proyecto.^[2]​ Sin embargo, se comprobó que era muy útil, y otras aplicaciones empezaron también a usar syslog. Hoy en día syslog está presente por defecto en casi todos los sistemas Unix y GNU/Linux, y también se encuentran diversas implementaciones de syslog para otros sistemas operativos, como Microsoft Windows.

 

Syslog capas según norma RFC 5424

Es ahora, después de tantos años, cuando syslog está en proceso de convertirse en estándar, para -entre otras cosas- poder mejorar la seguridad de sus implementaciones. IETF asignó un grupo de trabajo, y en 2001, se documentó su funcionamiento bajo normas RFC y quedó registrado con el número RFC 3164 ^[3]​ La estandarización del contenido del mensaje y de las diferentes capas de abstracción están contenidas en la norma RFC 5424.^[4]​ (marzo de 2009) la cual incluye la norma RFC 3164 y la releva.

Implementaciones

Sistemas Operativos

• UNIX:
  • sysklogd
  • rsyslogd: Implementa syslog sobre TCP y sigue el RFC 3195
  • syslog-ng: TCP, SSL, SQL
• Windows 2000, 2003, XP:
  • : parte de los productos
  • Kiwi Syslog Daemon
  • WinSyslog
  • NTsyslog
  • Syslserve
  • Syslog Watcher
  • NXLOG
  • Windows SysLog

Lenguajes de programación

Algunos lenguajes de programación pueden comunicarse con el sistema operativo para tramitar o emular el uso de registro de eventos:

• PHP: se debe utilizar un proceso de apertura con el comando openlog(), luego -si ocurre alguna excepción- es registrada con syslog() y finaliza el proceso con closelog().^[5]​

Referencias

1. (html). Eximbanker. Archivado desde el original el 24 de julio de 2018. Consultado el 23 de julio de 2018. «Linux y los administradores de sistemas Unix han utilizado los servidores syslog durante años para capturar eventos de dispositivo de red en tiempo real. Configurado correctamente, los servidores syslog proporcionan un servicio esencial no sólo para la visualización de errores en dispositivos como routers y switches, pero también para archivar esos errores en una base de datos para futuros análisis.» 
2. . O'Reilly Community (en inglés). 29 de marzo de 2017. Archivado desde el original el 29 de marzo de 2017. Consultado el 11 de noviembre de 2017. «Eric Allman authored sendmail and syslog in 1981 while at the University of California at Berkeley.» 
3. C. Lonvick (agosto de 2001). . The Internet Society (Network Working Group) (en inglés). Archivado desde el original el 9 de febrero de 2007. Consultado el 11 de noviembre de 2017. «This document describes the observed behavior of the syslog protocol.» 
4. R. Gerhards (marzo de 2009). . IETF (Network Working Group) (en inglés). Archivado desde el original el 3 de abril de 2009. Consultado el 11 de noviembre de 2017. «This document describes the syslog protocol, which is used to convey event notification messages.» 
5. (html). PHP net. Archivado desde el original el 2 de diciembre de 2008. Consultado el 23 de julio de 2018. «syslog() genera un mensaje de registro que será distribuido por el registro del sistema. Información sobre la forma de preparar un gestor de registro definido por el usuario puede encontrarse en la página de manual Unix para syslog.conf (5). Más información sobre los recursos y opciones de syslog puede encontrarse en las páginas man para syslog (3) en máquinas Unix.» 

Enlaces externos

• RFC 3164, donde se estudia (pero no se define) cómo han implementado syslog diversos fabricantes. Agosto de 2001. En inglés.
• (en inglés).
• RFC 3195 (en inglés): envío fiable para syslog
• Gestión de archivos de registro del sistema Tutorial para aprender a administrar e interpretar los archivos de registro generados por el demonio rsyslog.

•   Datos: Q1425501