Loading AI tools
De Wikipedia, la enciclopedia libre
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.
Es útil recolectar, registrar y analizar, por ejemplo:[1]
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.
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.
El mensaje enviado se compone de tres campos:
Entre todos no han de sumar más de 1024 bytes, pero no hay longitud mínima.
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 |
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 |
Para conocer la prioridad final de un mensaje, se aplica la siguiente fórmula:
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.
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.
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.
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.
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.
Algunos lenguajes de programación pueden comunicarse con el sistema operativo para tramitar o emular el uso de registro de eventos:
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.