Syslog es el acrónimo de System Logging Protocol, que significa protocolo de registro del sistema. Se trata de un protocolo estándar utilizado para enviar mensajes de registro o eventos del sistema a un servidor específico, llamado servidor de syslog. El syslog se utiliza principalmente para recopilar varios registros de dispositivos de diversas máquinas diferentes en una ubicación central para la supervisión y su análisis.
El protocolo está habilitado en la mayoría de equipos de red, como routers, switches, cortafuegos e incluso en algunas impresoras y escáneres. Además, syslog está disponible en sistemas basados en Linux/Unix y en muchos servidores web como Apache. Syslog no está instalado de manera predeterminada en los sistemas Windows, que usan su propio registro de eventos; si bien es capaz de reenviarlos a través de herramientas de terceros u otras configuraciones utilizando el protocolo Syslog.
RFC 5424 define el Protocolo Syslog, haciendo obsoleto el RFC 3164 anterior.
Componentes de Syslog
En cualquier dispositivo dado, el sistema genera varios eventos en respuesta a las condiciones cambiantes del sistema. Generalmente, estos eventos se registran localmente para poder ser revisados y analizados por parte de un administrador. Sin embargo, supervisar numerosos registros provenientes de un gran número de routers, switches y sistemas derivaría en un proceso lento y poco práctico. Syslog permite resolver este problema al reenviar esos eventos a un servidor centralizado.
Transmisión de Syslog
Tradicionalmente, syslog usa el protocolo UDP en el puerto 514, si bien puede configurarse para usar cualquier otro puerto. Adicionalmente, ciertos dispositivos usan el puerto TCP 1468 para enviar datos de syslog a fin de obtener confirmaciones de entrega de los mensajes.
La transmisión de paquetes de syslog es asíncrona, y los mensajes se generan según se haya configurado en el equipo correspondiente, ya se trate de un router, un switch o un servidor. A diferencia de otros protocolos de supervisión, como SNMP, no existe un mecanismo para sondear los datos de syslog. En determinadas implementaciones, SNMP puede usarse para establecer o modificar parámetros de syslog de forma remota.
El mensaje de syslog consta de tres partes: PRI (un valor de prioridad calculado), HEADER (con información de identificación) y MSG (el mensaje en sí).
Los datos de PRI que se envían a través del protocolo syslog provienen de dos valores numéricos que ayudan a clasificar el mensaje. El primero es el valor de recurso (facility), que se trata de uno de los 15 valores predefinidos o localmente definidos, del 16 al 23. Estos valores clasifican el tipo de mensaje o qué sistema generó el evento.
| Número | Descripción del recurso |
| 0 | Mensajes del núcleo |
| 1 | Mensajes a nivel de usuario |
| 2 | Sistema de correo |
| 3 | Demonios del sistema |
| 4 | Mensajes de seguridad/autorización |
| 5 | Mensajes generados por syslog |
| 6 | Subsistema de impresión de línea |
| 7 | Subsistema de noticias de red |
| 8 | Subsistema UUCP |
| 9 | Demonio de reloj |
| 10 | Mensajes de seguridad/autorización |
| 11 | Demonio FTP |
| 12 | Subsistema NTP |
| 13 | Auditoría de registro |
| 14 | Alerta de registro |
| 15 | Demonio de reloj |
| 16 - 23 | Uso local 0 - 7 |
La segunda etiqueta de un mensaje de syslog clasifica la importancia o gravedad del mensaje mediante un código numérico de 0 a 7.
| Código | Gravedad | Descripción |
| 0 | Emergencia | El sistema no se puede usar |
| 1 | Alerta | Se deben adoptar medidas de inmediato |
| 2 | Crítico | Condiciones críticas |
| 3 | Error | Condiciones de error |
| 4 | Advertencia | Condiciones de advertencia |
| 5 | Aviso | Condición normal pero importante |
| 6 | Información | Mensajes informativos |
| 7 | Depuración | Mensajes de nivel de depuración |
Los valores de ambas etiquetas no tienen definiciones estrictas; por lo tanto, depende del sistema o la aplicación decidir cómo registrar un evento (es decir, en forma de advertencia, aviso u otro) y en qué recurso. Dentro de la misma aplicación o servicio, las cifras más bajas deberían corresponder a problemas más graves, en relación con el proceso específico.
Ambos valores se combinan para producir un valor de prioridad que se transmite con el mensaje. El valor de prioridad se calcula multiplicando el valor de recurso por ocho y, luego, agregando el valor de gravedad al resultado. Cuanto menor sea el valor de PRI, mayor será la prioridad.
(Valor de recurso * 8) + Valor de gravedad = PRI
De esta manera, un mensaje del kernel recibe un valor más bajo (mayor prioridad) que una alerta de registro, independientemente de la gravedad de la segunda. Hay otros identificadores en el paquete que incluyen el nombre de host, la dirección IP, la ID del proceso, el nombre de la aplicación y la marca de tiempo del mensaje.
El protocolo no define el texto o el contenido real del mensaje de syslog. Algunos mensajes son texto plano y fácilmente legible, mientras que otros pueden estar destinados únicamente a la máquina.
Los mensajes de syslog normalmente no superan los 1024 bytes de tamaño.
<165>1 2003-10-11T22:14:15.003Z mymachine.example.com - ID47 [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] BOMAn application log entry...
Partes del mensaje de syslog:
| Componente | Valor | Información |
| PRI | 165 | Recurso = 20, Gravedad = 5 |
| VERSION | 1 | Versión 1 |
| TIMESTAMP | 2017-05-11T21:14:15.003Z | Mensaje creado el 11 de mayo de 2017 a las 09:14:15 P.M., con 3 milisegundos |
| HOSTNAME | mymachine.example.com | Mensaje originado por el host “mymachine.example.com” |
| APP-NAME | su | Nombre de la aplicación: “su” |
| PROCID | - | PROCID desconocido |
| MSGID | ID47 | ID del mensaje: 47 |
| STRUCTURED-DATA | [exampleSDID@32473 iut="3" eventSource=" eventID="1011"] | Elemento de datos estructurados con un ID-SD no controlado por IANA del tipo “exampleSDID@32473”, que tiene tres parámetros |
| MSG | BOMAn application log entry... | BOM es un tipo de codificación UTF-8, el mensaje en sí es “An application log entry...” |
El servidor Syslog también se conoce como el colector o el receptor de syslog.
Los mensajes de syslog se envían desde el dispositivo emisor al receptor. Para ello, debe configurarse en el propio dispositivo emisor la dirección IP del servidor Syslog de destino, ya sea mediante la línea de comandos o a través de un archivo conf. Una vez configurado, todos los datos de syslog se enviarán a ese servidor. Dentro del protocolo Syslog no existe ningún mecanismo para que un servidor diferente solicite la información de syslog a un emisor.
Si bien la mayoría de las implementaciones de Unix y los fabricantes de dispositivos de red, como Cisco, tienen sus propios receptores de syslog, también pueden encontrarse otros.
El software de supervisión PRTG de Paessler ofrece un sensor receptor Syslog integrado. El receptor recopila todos los mensajes de syslog entregados. Para usar la función, el administrador debe agregar el receptor Syslog y, luego, configurar la dirección IP de dicho servidor como el destino de los datos syslog en todos los dispositivos que se supervisarán.
Tras la configuración y la recepción de mensajes, el panel de control muestra:
- El número de mensajes de syslog recibidos por segundo
- El número de mensajes clasificados como “advertencia” por segundo
- El número de mensajes clasificados como “error” por segundo
- El número de paquetes descartados por segundo
El protocolo Syslog puede generar muchos mensajes, y se dedica simplemente a reenviarlos tan rápido como pueda. A causa de ello, la capacidad más importante para un servidor Syslog es la de filtrar correctamente y reaccionar de forma adecuada a los datos de syslog entrantes.
El sensor Syslog Receiver de PRTG ofrece la capacidad de establecer reglas de filtrado que permiten que los mensajes de syslog se incluyan o excluyan como advertencias o errores, independientemente de cómo se generaron originalmente en el dispositivo. Este filtrado garantiza que los administradores reciban notificaciones sobre todos los errores que deseen conocer sin verse abrumados por los mensajes menos importantes.
El protocolo Syslog no ofrece ningún mecanismo de seguridad. No hay autenticación integrada para garantizar que los mensajes provengan del dispositivo que dice enviarlos, ni un sistema de cifrado que oculte la información que se envía al servidor, por lo que es particularmente susceptible a los llamados “ataques de reproducción” en los cuales un atacante genera una gran cantidad de advertencias para provocar una respuesta.
Configuración del dispositivo
La mayoría de las implementaciones de Syslog se pueden configurar con respecto a los mensajes que se reenviarán al servidor de syslog según los recursos y los valores de gravedad de los eventos generados. Es importante configurar esto correctamente para evitar ahogar tanto al servidor como a la red con tráfico innecesario. Por ejemplo, debe configurarse el recurso “debug” de modo que nunca envíe mensajes, excepto durante las pruebas, claro está.
Es aconsejable configurar los parámetros de syslog de forma que solo se pidan los mensajes de mayor recurso (menor valor) y gravedad posibles a fin de minimizar el tráfico. Pensemos en que el router nos informa de la inactividad de una interfaz de red, y este es un mensaje que debe informarse sin ninguna duda. Por otro lado, podríamos configurar una impresora de red de forma que genere únicamente tráfico de syslog para eventos críticos, puesto que es menos importante.
Windows
Los sistemas Windows no implementan Syslog dentro de su sistema estándar de registro de eventos, pero sí se pueden recopilar y reenviar eventos generados dentro del sistema de registro de Windows a un servidor Syslog utilizando herramientas de terceros. Estas herramientas supervisan el registro de eventos, usan la información contenida para crear un evento con formato Syslog y lo envían usando el protocolo Syslog estándar.
Limitaciones
Una limitación importante del protocolo Syslog es que el dispositivo a supervisar debe estar en funcionamiento y conectado a la red para generar y enviar eventos. Sin embargo, es posible que un error crítico del kernel haga que el equipo se cuelgue, se bloquee o se desconecte sin llegar a enviar error alguno. En otras palabras, Syslog no es una buena forma de supervisar el estado activo e inactivo de los dispositivos.
Por lo que hemos visto, sabemos que Syslog no es la mejor manera de supervisar el estado de los dispositivos de una red, pero sí puede ser una buena forma de monitorizar el estado general de los equipos de la misma. A pesar de que el software de supervisión de red, como PRTG, ofrece un conjunto de herramientas para vigilar una red, nada informa al administrador de que hay un problema más rápido que un registro de eventos que comienza a llenarse de advertencias. Configurar correctamente la supervisión de Syslog permite detectar un aumento repentino en el volumen y la gravedad de los eventos, y es posible que nos avise antes de que se produzca un problema detectable por los usuarios.
Seguridad/autorización/auditoría
Una red corporativa típica contiene numerosos dispositivos a los que nadie debería intentar acceder en circunstancias normales. Si un switch remoto que solo inicia sesión una vez por ciclo de auditoría sufre repentinos intentos de inicio de sesión diarios (ya sean exitosos o no), vale la pena comprobarlo. En estos tipos de dispositivos se puede configurar Syslog de modo que reenvíe los eventos de autenticación al servidor, sin la sobrecarga de tener que instalar y configurar un agente de supervisión completo.
Syslog también proporciona una forma de garantizar que se registren eventos críticos y se almacenen fuera del servidor original, ya que lo primero que intentará un atacante después de comprometer un sistema es cubrir el rastro que haya dejado en el registro. Los eventos enviados a través de Syslog quedarán fuera de su alcance.
Supervisión de aplicaciones
Hay muchas formas de controlar cómo se ejecuta una aplicación en un servidor; sin embargo, esos monitores pueden pasar por alto cómo afecta a otros procesos del servidor. Si bien es bastante fácil detectar un alto nivel de uso de la CPU o la memoria, los eventos registrados pueden ayudar a prever otros problemas. ¿Hay una aplicación intentando acceder a un archivo que está bloqueado continuamente? ¿Se están generando errores a causa de intentos de escritura en la base de datos? Este tipo de eventos pueden pasar desapercibidos cuando los causan aplicaciones especialmente preparadas para evitar errores, pero no deben ser ignorados. Syslog se asegurará de que dichos eventos registrados reciban la atención que se merecen.
Syslog como parte de la supervisión general de la red
Una supervisión completa de la red requiere del uso de múltiples herramientas. Syslog es un pilar importante en la supervisión de la red porque garantiza que aquellos eventos que no conlleven un resultado dramático no caigan en el olvido. La mejor práctica consiste en utilizar un software que combine todas las herramientas para tener siempre una visión general de lo que sucede en la red.
