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:​

• 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.​ 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​ La estandarización del contenido del mensaje y de las diferentes capas de abstracción están contenidas en la norma RFC 5424.​ (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:
  • HDC Syslog: parte de los productos HDC
  • Kiwi Syslog Daemon
  • NetDecision LogVision
  • WinSyslog
  • NTsyslog
  • Syslserve
  • Syslog Watcher
  • NXLOG
  • Windows SysLog Archivado el 26 de septiembre de 2015 en Wayback Machine.

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().​

Enlaces externos

• RFC 3164, donde se estudia (pero no se define) cómo han implementado syslog diversos fabricantes. Agosto de 2001. En inglés.
• Proceso de estandarización de syslog (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