Registro del sistema
Sistema y protocolo de registro de eventos de red
Registro del sistema
Autor(es) original(es)Eric Allman
Lanzamiento inicialDécada de 1980
Sistema operativoSimilar a Unix
TipoRegistro del sistema
Sitio webdatatracker.ietf.org/wg/syslog/charter/ 

En informática , syslog / ˈsɪslɒɡ / es un estándar para el registro de mensajes . Permite separar el software que genera los 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 de información general, análisis y depuración. 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 datos de registro de diferentes tipos de sistemas en un repositorio central. Existen implementaciones de syslog para muchos sistemas operativos.

Cuando opera a través de una red, syslog utiliza 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 . [1] Fue rápidamente adoptado por otras aplicaciones y desde entonces se ha convertido en la solución de registro estándar en sistemas tipo Unix . [2] También existe una variedad de implementaciones en otros sistemas operativos y se encuentra comúnmente en dispositivos de red, como enrutadores . [3]

Syslog funcionó originalmente como un estándar de facto , sin ninguna especificación publicada autorizada, 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 en agosto de 2001. Fue estandarizado por RFC 5424 en marzo de 2009. [4]

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

Componentes del mensaje

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

Instalación

Se utiliza un código de facilidad para especificar el tipo de sistema que registra el mensaje. Los mensajes con distintas facilidades pueden manejarse de forma diferente. [7] La ​​lista de facilidades disponibles se describe en el estándar: [4] : 9 

Código de instalaciónPalabra claveDescripción
0núcleoMensajes del kernel
1usuarioMensajes a nivel de usuario
2correoSistema de correo
3demonioDemonios del sistema
4autentificaciónMensajes de seguridad/autenticación
5registro del sistemaMensajes generados internamente por syslogd
6LPR-LPRSubsistema de impresora de línea
7noticiasSubsistema de noticias en red
8UUCPSubsistema UUCP
9cronSubsistema Cron
10autenticación privadaMensajes de seguridad/autenticación
11FTPDemonio FTP
12PNTSubsistema NTP
13seguridadAuditoría de registros
14consolaAlerta de registro
15solaris-cronDemonio de programación
16–23local0 – local7Instalaciones de uso local

La correlación entre el código de instalación y la palabra clave no es uniforme en diferentes sistemas operativos e implementaciones de syslog. [8]

Nivel de gravedad

La lista de severidades también está descrita por la norma: [4] : 10 

ValorGravedadPalabra clavePalabras clave obsoletasDescripciónCondición
0Emergenciaemergpanic[9]El sistema no se puede utilizarUn estado de pánico. [10]
1AlertaalertSe deben tomar medidas inmediatamenteUna condición que debe corregirse inmediatamente, como una base de datos del sistema dañada. [10]
2CríticocritCondiciones críticasErrores de dispositivos duros. [10]
3Errorerrerror[9]Condiciones de error
4Advertenciawarningwarn[9]Condiciones de advertencia
5AvisonoticeCondiciones normales pero significativasCondiciones que no son condiciones de error, pero que pueden requerir un manejo especial. [10] [11]
6InformativoinfoMensajes informativosConfirmación de que el programa está funcionando como se esperaba.
7DepurardebugMensajes a nivel de depuraciónMensajes que contienen información que normalmente sólo se utiliza cuando se depura un programa. [10]

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 ocurra al intentar mostrar el código postal del cliente se le puede asignar el nivel de Error o incluso de Advertencia .

El proceso del servidor que maneja la visualización de mensajes normalmente incluye todos los niveles inferiores (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 mensajes de Aviso , Información y Depuración . [12]

Mensaje

En RFC 3164, se especificó que el componente del mensaje (conocido como MSG) tiene 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, [4] "MSG es lo que se denominaba CONTENT en RFC 3164. La ETIQUETA ahora forma parte del encabezado, pero no como un campo único. La ETIQUETA se ha dividido en APP-NAME, PROCID y MSGID. Esto no se parece totalmente al uso de la ETIQUETA, pero proporciona la misma funcionalidad para la mayoría de los casos". Las herramientas de syslog populares, como NXLog y Rsyslog, se ajustan a este nuevo estándar.

El campo de contenido debe estar codificado en un conjunto de caracteres UTF-8 y deben evitarse los valores de octetos en el rango de caracteres de control ASCII tradicional. [13] [4]

Registrador

Los mensajes de registro generados pueden dirigirse a varios destinos, entre ellos, la consola , archivos, servidores syslog remotos o relés. La mayoría de las implementaciones proporcionan una utilidad de línea de comandos, a menudo denominada logger , así como una biblioteca de software , para enviar mensajes al registro. [14]

Para visualizar y monitorear los registros recopilados, es necesario utilizar una aplicación cliente o acceder al archivo de registro directamente en el sistema. Las herramientas de línea de comandos básicas 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 se opera sobre una red, syslog utiliza una arquitectura cliente-servidor donde el servidor escucha en un puerto conocido o registrado 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. [15] Debido a que UDP carece de mecanismos de control de congestión, se utiliza el puerto 6514 del Protocolo de control de transmisión (TCP); la seguridad de la capa de transporte también es necesaria en las implementaciones y se recomienda para uso general. [16] [17]

Limitaciones

Dado que cada proceso, aplicación y sistema operativo se escribió de forma independiente, existe poca uniformidad en la carga útil del mensaje de registro. Por este motivo, no se hace ninguna suposición sobre su formato o contenido. Un mensaje de syslog está formateado (RFC 5424 proporciona la definición de formato Backus–Naur aumentado (ABNF)), pero su campo MSG no.

El protocolo de red es una comunicación simplex , sin medios para reconocer la entrega al originador.

Perspectiva

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

Las normativas, como la Ley Sarbanes-Oxley , PCI DSS , HIPAA y muchas otras, exigen que las organizaciones implementen medidas de seguridad integrales, que a menudo incluyen la recopilación y el análisis de registros de muchas fuentes diferentes. El formato syslog ha demostrado ser eficaz para consolidar registros, ya que existen muchas herramientas de código abierto y de propiedad exclusiva para la generación de informes y el análisis de 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 los problemas. [19]

Documentos estándar de Internet

El protocolo Syslog está definido por los documentos de Solicitud de comentarios (RFC) publicados por el Grupo de trabajo de ingeniería de Internet ( estándares de Internet ). A continuación, se incluye una lista de RFC que definen el protocolo Syslog: [20]

  • El protocolo syslog BSD . RFC  3164 .(obsoleto por el Protocolo Syslog . RFC 5424 . )
  • Entrega confiable para syslog . RFC  3195 .
  • El protocolo Syslog . RFC  5424 .
  • Mapeo 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 seguridad de la capa de transporte de datagramas (DTLS) para syslog . RFC  6012 .
  • Transmisión de mensajes de syslog a través de TCP . RFC  6587 .

Véase también

Referencias

  1. ^ "Eric Allman". Salón de la fama de Internet . Consultado el 30 de octubre de 2017 .
  2. ^ "3 excelentes puestos de ingeniería para los que postularse esta semana". VentureBeat . 2021-08-06 . Consultado el 2021-08-16 .
  3. ^ "Análisis de syslog eficiente y robusto para dispositivos de red en redes de centros de datos".
  4. ^ abcde Gerhards, Rainer. El protocolo Syslog. doi : 10.17487/RFC5424 . RFC 5424.
  5. ^ "LXer: La patente pone en peligro el estándar syslog de IETF".
  6. ^ "Divulgación de propiedad intelectual del IETF sobre las reclamaciones de patentes de HUAWEI".
  7. ^ "Instalación de Syslog" . Consultado el 22 de noviembre de 2012 .
  8. ^ "Los pormenores del registro del sistema mediante Syslog". SANS Institute .
  9. ^ abc "syslog.conf(5) - Página del manual de Linux" . Consultado el 29 de marzo de 2017 . Las palabras clave error, warn y panic están en desuso y no deberían utilizarse más.
  10. ^ abcde "closelog, openlog, setlogmask, syslog - registro del sistema de control" . Consultado el 29 de marzo de 2017 . LOG_NOTICE Condiciones que no son condiciones de error, pero que pueden requerir un manejo especial.
  11. ^ "La biblioteca C de GNU: syslog, vsyslog" . Consultado el 19 de julio de 2024 . LOG_NOTICE El mensaje describe un evento normal pero importante.
  12. ^ "Niveles de gravedad de los mensajes de Syslog". cd.delphix.com . Consultado el 2 de octubre de 2024 .
  13. ^ "Transmisión de mensajes de Syslog a través de TCP". www.ipa.go.jp . Consultado el 16 de agosto de 2021 .
  14. ^ "Comando logger". www.ibm.com . Consultado el 16 de agosto de 2021 .
  15. ^ "Servidor Syslog". www.howtonetwork.com . Consultado el 16 de agosto de 2021 .
  16. ^ Gerhards, Rainer (marzo de 2009). "RFC 5424 - El protocolo Syslog". tools.ietf.org . doi :10.17487/RFC5424.
  17. ^ Fuyou, Miao; Yuzhi, Ma; Salowey, Joseph A. (marzo de 2009). Miao, F; Ma, Y; Salowey, J (eds.). "RFC 5425 - Mapeo de transporte TLS para Syslog". tools.ietf.org . doi :10.17487/RFC5425.
  18. ^ "ATNA + SYSLOG es lo suficientemente bueno". Estándares de intercambio de atención médica. 2 de enero de 2012. Consultado el 6 de junio de 2018 .
  19. ^ Yamanishi, Kenji; Maruyama, Yuko (21 de agosto de 2005). "Minería dinámica de registros del sistema para la monitorización de fallos de red". Actas de la undécima conferencia internacional ACM SIGKDD sobre descubrimiento de conocimiento en minería de datos . KDD '05. Chicago, Illinois, EE. UU.: Association for Computing Machinery. págs. 499–508. doi :10.1145/1081870.1081927. ISBN . 978-1-59593-135-1.S2CID 5051532  .
  20. ^ "Problemas de seguridad en el registro de eventos de red (syslog)". IETF.
  • Grupo de trabajo de ingeniería de Internet: Datatracker: grupo de trabajo de syslog (concluido)
  • Instituto Nacional de Estándares y Tecnología: "Guía para la gestión de registros de seguridad informática" (publicación especial 800-92) (documento técnico)
  • Software de gestión de redes: "Comprensión de Syslog: servidores, mensajes y seguridad"
  • Explicación de Paessler IT: Syslog
  • MonitorWare: Todo sobre Syslog
Obtenido de "https://es.wikipedia.org/w/index.php?title=Syslog&oldid=1254372586"