| registro del sistema | |
|---|---|
| Nombre | Protocolo Syslog |
| Nivel (según el modelo OSI ) | Aplicado |
| Familia | UDP/TCP |
| Puerto/ID | 514/ UDP , 601/ TCP , 6514/ UDP , 6514/ TCP |
| Propósito del protocolo | Transmisión y registro de mensajes de eventos |
| Especificación | RFC 3164 , RFC 3195 , RFC 5424 , RFC 5425 , RFC 5426 , RFC 5427 , RFC 5674 , RFC 5675 , RFC 5676 , RFC 5848 , RFC 6012 , RFC 6587 |
| Implementaciones principales (clientes) | Integrado en la mayoría de los sistemas operativos de red y muchos dispositivos de red |
| Implementaciones principales ( servidores ) | Integrado en la mayoría de los sistemas operativos de red |
| Códigos de gravedad del mensaje | |
|---|---|
| 0 | El sistema (de emergencia) no está operativo |
| una | El sistema (de alerta) requiere una intervención inmediata |
| 2 | (Crítico) el estado del sistema es crítico |
| 3 | (Errores) mensajes de error |
| cuatro | (Advertencia) advertencias sobre posibles problemas |
| 5 | (Aviso) mensajes sobre eventos normales pero importantes |
| 6 | Mensajes de información (informativos) |
| 7 | (Depurar) mensajes de depuración |
| Códigos de categorías de sujetos que forman mensajes. | |
|---|---|
| 0 | núcleo del sistema operativo |
| una | software de usuario |
| 2 | sistema postal |
| 3 | servicios del sistema (demonios) |
| cuatro | mensajes de seguridad (autorización) |
| 5 | mensajes syslogd nativos |
| 6 | subsistema de impresión |
| 7 | subsistema de grupos de noticias (teleconferencias, NNTP) |
| ocho | subsistema UUCP |
| 9 | servicios de tiempo |
| diez | mensajes de seguridad (autorización) |
| once | servicio ftp |
| 12 | subsistema NTP |
| 13 | registro de auditoría |
| catorce | registro de emergencia |
| quince | servicios de tiempo |
| dieciséis | local 0 |
| 17 | local 1 |
| Dieciocho | locales 2 |
| 19 | locales 3 |
| veinte | locales 4 |
| 21 | local 5 |
| 22 | locales 6 |
| 23 | local 7 |
syslog ( ing. registro del sistema - registro del sistema) es un estándar para enviar y registrar mensajes sobre eventos que ocurren en el sistema (es decir, crear registros de eventos ) utilizado en redes informáticas que utilizan el protocolo IP . El término "syslog" se refiere tanto al protocolo de red syslog ahora estandarizado como al software (aplicación, biblioteca) que envía y recibe mensajes del sistema.
El estándar fue implementado por primera vez en la plataforma BSD por Eric Allman como parte del proyecto Sendmail [1] y, más tarde, debido a su simplicidad y escalabilidad, se generalizó en las plataformas Unix y Linux y se implementó en muchos dispositivos de red.
El estándar establece que las fuentes formen mensajes de texto simples sobre los eventos que ocurren en ellos y los transfieran al servidor Syslog (llamado "syslogd", "syslog daemon" o "syslog server") para su procesamiento utilizando uno de los protocolos de red de la familia IP . ( UDP o TCP ). La formación de mensajes de eventos y su transmisión se produce de acuerdo con ciertas reglas, denominadas protocolo Syslog. Por regla general, el mensaje tiene un tamaño pequeño (hasta 1024 bytes [2] ) y se envía sin cifrar. Sin embargo, al utilizar herramientas especiales (como Stunnel, sslio o sslwrap), es posible cifrar los mensajes y enviarlos a través de SSL / TLS .
Dado que las fuentes de mensajes y el servidor Syslog pueden estar ubicados en diferentes máquinas, esto le permite organizar la recopilación y el almacenamiento de mensajes de muchas fuentes heterogéneas dispersas geográficamente en un solo almacenamiento (repositorio), lo cual es extremadamente importante para los administradores de red que pueden no tener acceso físico a todos los dispositivos a la vez y computadoras en la red.
Además, los servidores Syslog, por regla general, no solo pueden registrar mensajes, sino también reenviarlos a otros servidores Syslog, según el nivel de importancia del mensaje ( Gravedad ) y la categoría del asunto que generó el mensaje ( Facilidad ), que permite organizar, por ejemplo, un sistema de almacenamiento jerárquico. Y esto puede ayudar, por ejemplo, a reducir el tiempo de respuesta del personal ante eventos críticos. Supongamos que existe una gran red que consta de varios segmentos. Cada fragmento tiene su propio servidor Syslog, que recibe mensajes solo de fuentes dentro de su fragmento. Si estos servidores descendentes están configurados para reenviar mensajes de un nivel de importancia crítica y superior a un servidor principal común, será más fácil para el administrador de la red, que controla toda la red a través de él, rastrear la ocurrencia de una situación crítica, ya que hay pocos mensajes de este tipo y no se ahogarán en el flujo de mensajes necesarios pero menos importantes.
La versión actual del protocolo Syslog ofrece un formato de mensaje mejorado que permite el uso de una marca de tiempo precisa de la creación de un mensaje y una fuerte identificación de la fuente del mensaje, así como el uso de la codificación UTF-8 para el mensaje. organismo, que resuelve el problema de la internacionalización. Se pueden usar campos adicionales opcionales (datos estructurados) para transmitir información diversa, por ejemplo, el error del reloj local de la fuente del mensaje y la precisión de su sincronización con un reloj externo de hora exacta, el idioma en el que está escrito el mensaje , etc. Debido a la desvinculación de un transporte específico, el protocolo Syslog puede usar cualquiera de los mecanismos de entrega de mensajes descritos en RFC independientes, pero se prefieren los transportes TLS .
Durante mucho tiempo, syslog se utilizó como un estándar de facto sin ninguna especificación formal, lo que resultó en muchas implementaciones, algunas de las cuales eran incompatibles entre sí. Los primeros pasos para resolver este problema se dieron en 2001 : el protocolo syslog se describió en RFC 3164 . En 2005 se publicó una especificación formal, la estandarización del contenido de los mensajes y un mecanismo para su transmisión .
El RFC 3164 informativo de agosto de 2001 "The BSD Syslog Protocol" describía el estado del arte en el momento de la publicación. Como resultado del análisis de las implementaciones existentes, se determinó el lugar y la importancia del protocolo Syslog en los sistemas de información, se formalizó la estructura del mensaje, se consideraron modelos básicos de implementación y se formularon posibles problemas de seguridad. UDP (puerto 514) de la familia IPv4 fue declarado como mecanismo de transporte y se introdujeron algunas restricciones relacionadas con el uso de este transporte.
En noviembre de 2001, se publicó el RFC 3195 "Reliable Delivery for Syslog" , que proponía una solución para mejorar la fiabilidad del protocolo Syslog mediante el uso de cierta implementación de marcos BEEP [3] como portador de mensajes y el uso de TCP (puerto 601) de la familia IPv4 como transporte.
Marzo de 2009 estuvo marcado por el lanzamiento de un grupo completo de RFC que proponían mejoras bastante serias al protocolo Syslog.
RFC 5424 "The Syslog Protocol" ( Protocolo Syslog ), en primer lugar, postuló que cualquier transporte puede ser utilizado como mecanismo de entrega de mensajes, por lo que las definiciones de mecanismos de transporte y, en consecuencia, la descripción de restricciones y problemas de seguridad, fueron excluidas de la descripción del protocolo, directamente relacionado con un transporte específico. En segundo lugar, propuso un nuevo formato de mensaje que implica la presencia en el cuerpo del mensaje, además del encabezado y el texto, también de datos estructurados, cuyos elementos o bien se registran directamente en la IANA , o bien se delega su gestión a empresas que han registrado su número personal con IANA de acuerdo con SMIv2 . Además, el nuevo formato de mensaje le permite localizar con mayor precisión la fuente y la hora del mensaje. En tercer lugar, continuando con el proceso de internacionalización, sugirió utilizar la codificación UTF-8 para el texto del mensaje como la preferida.
RFC 5425 "Transport Layer Security (TLS) Transport Mapping for Syslog" describe el uso del mecanismo TLS para entregar mensajes usando TCP ( puerto 6514) de la familia IPv4 / v6 como transporte, sus limitaciones y problemas de seguridad.
RFC 5426 "Transmisión de mensajes Syslog a través de UDP" describía un mecanismo de entrega de mensajes sin TLS a través de UDP (puerto 514) de la familia IPv4 / v6 como transporte, sus limitaciones y problemas de seguridad.
RFC 5427 "Convenciones textuales para la administración de Syslog" definió un conjunto de convenciones textuales que describen la gravedad y la facilidad de los mensajes MIB de Syslog para que otros módulos MIB puedan usarlos en el proceso de definición de objetos administrados.
En octubre de 2009, se publicó otro RFC que vinculaba la gestión de objetos con el protocolo Syslog.
RFC 5674 "Alarmas en Syslog" allanó el camino para usar la base de alarmas IETF (Alarm MIB) en los mensajes de Syslog.
RFC 5675 " Asignación de notificaciones del Protocolo simple de administración de redes (SNMP) a mensajes SYSLOG" y RFC 5676 " Definiciones de objetos administrados para asignar mensajes SYSLOG a notificaciones del Protocolo simple de administración de redes (SNMP)" ( Definiciones de entidades administradas para el mecanismo de traducción de mensajes Syslog a Notificaciones del Protocolo simple de administración de red ( SNMP )) se explica por sí mismo a partir de los títulos de los documentos.
Lanzado en mayo de 2010, RFC 5848 "Mensajes de Syslog firmados" describía el uso de una firma criptográfica en los mensajes de Syslog.
En octubre de 2010, se lanzó el RFC 6012 "Datagram Transport Layer Security ( DTLS ) Transport Mapping for Syslog" , proponiendo el uso del mecanismo TLS para entregar mensajes usando UDP (puerto 6514) de la familia IPv4/v6 como transporte, sus limitaciones y cuestiones de seguridad.
Lanzado en abril de 2012, RFC 6587 "Transmisión de mensajes Syslog sobre TCP" describe los mecanismos establecidos para entregar mensajes que no utilizan TLS sobre TCP de la familia IPv4/v6 como transporte, sus limitaciones y problemas de seguridad.
Por lo tanto, los siguientes RFC emitidos por el IETF describen el protocolo syslog [4] :