El administrador de un sistema Linux tiene a su disposición un programa de generación de registros que monitoriza todos los eventos que se producen en el mismo. Syslog guarda, analiza y procesa todos los archivos de registro sin requerir apenas intervención por parte del administrador. Aunque útil y sencilla, es tanta la falta de personalización y seguridad que se echa en falta en este componente, que ya han empezado a surgir proyectos que tienen como objetivo tapar todos estos huecos. Syslog-NG es uno de esos proyectos que, poco a poco, se va imponiendo como un estándar en las distribuciones existentes. 

Inconvenientes de syslog

Aunque el estándar de Syslog queda documentado en el RFC 3164 hacia principios de este siglo, el software data de principios de los años ochenta. Que el programa sea antiguo no debería ser sinónimo de mala calidad. De hecho, la funcionalidad del demonio syslogd es casi perfecta, la configuración es bastante simple y apenas consume recursos. No obstante tenemos un problema si queremos que el Syslog tradicional abarque temas como la seguridad o extienda su funcionalidad a una configuración que soporte las necesidades de unas redes que no existían hace treinta años. La transferencia de mensajes a través del protocolo TCP, la información del origen del registro, la encriptación de los mensajes o una configuración más flexible son asuntos que escapan por completo al dominio del obsoleto syslogd.

Syslog-NG

Como hemos reseñado en la introducción, en la actualidad se están configurando varios proyectos que vienen a cubrir las muchas necesidades que no abarca el antiguo Syslog. Entre estos proyectos podemos resaltar la extensión del RFC 3164 llamada Syslog-Sign, que basa su desarrollo en la implementación de una huella digital que protege los mensajes, aunque por compatibilidad con el estándar sigue usando el protocolo UDP para la transmisión de los mismos y éstos no terminan de estar encriptados, lo que hace de este sistema algo demasiado vulnerable a ciertos ataques maliciosos. Otro proyecto que trata de extender las posibilidades de Syslog es el llamado Reliable Syslog, estandarizado en el RFC 3195. Este proyecto si que está desarrollado para el uso de TCP, tiene mecanismos de autenticación y es poco propenso a los ataques externos. De los modos de mensajes disponibles, hay algunos que no cumplen con el estándar del RFC 3164 y puede que, a medida que el proyecto avance, la incompatibilidad con su predecesor se haga más grande.

Syslog-NG es un desarrollo basado en el Syslog tradicional y respeta la compatibilidad con el RFC 3164. En el árbol de desarrollo del proyecto (roadmap) se augura el soporte para SSL y la transferencia de mensajes por BEEP (Block Extensible Exchange Protocol), lo que añadiría mecanismos de encriptación y autenticación de mensajes. Puede sin embargo implementarse una encriptación bajo SSL mediante la creación de una pasarela entre máquinas soportada por el programa Stunnel. Syslog-NG puede usar el protocolo TCP para asegurar la fiabilidad, comprometida con el uso de UDP, en la entrega de mensajes. La licencia GPL bajo la cual se acogió el producto en su lanzamiento hace que muchas distribuciones de linux hayan adoptado Syslog-NG como una parte, si no de su estructura, sí de su paquetería y actualizaciones, por lo que la instalación, actualización y soporte del producto se hace algo fundamental a la hora de tomar la decisión de abandonar nuestro antiguo gestor de registro por uno más completo y compatible.

Instalación del producto

Existen paquetes pre-compilados de Syslog-NG para la gran mayoría de las distribuciones, por lo que su obtención desde los repositorios principales no debería ser un problema. La instalación del paquete se puede realizar mediante la extracción e instalación del binario correspondiente (rpm, deb, etc.) o desde herramientas como Yum o Apt-get, que resolverán cualquier dependencia sin causar molestia alguna. Por ejemplo, si instalamos el programa haciendo uso de la herramienta Yum, procederemos de una forma tan simple como la que sigue a continuación:

[root@server ~]# yum install syslog-ng
Running Transaction
  Installing: syslog-ng  ################# [1/1]

Installed: syslog-ng.i386 0:1.6.11-1.fc5
Complete!

Para que la instalación quede completada, el demonio syslog-ng tiene que sustituir al antiguo syslogd (y a klogd en bastantes sistemas), así que pararemos el antiguo demonio y configuraremos el nuevo para su uso como programa de registro de sistema por defecto. Aunque los sistemas de registro de los que estamos hablando son compatibles entre si, siempre es una buena idea mantener el programa antiguo por si tenemos problemas o no nos acaba de convencer el funcionamiento de algo. En un sistema con Fedora Core, la sustitución de los demonios la haríamos de la siguiente manera:

[root@server ~]# /sbin/chkconfig syslog off
[root@server ~]# /sbin/service syslog stop
[root@server ~]# /sbin/chkconfig syslog-ng on
[root@server ~]# /sbin/service syslog-ng start

En suSE comprobaremos que la línea SYSLOG_DAEMON='syslog-ng' queda escrita en el fichero /etc/syslog-ng/syslog-ng.conf y nos aseguraremos de reiniciar el servicio. En sistemas basados en Debian, el paquete eliminará la instalación de sysklogd e iniciará el nuevo demonio.

Configuración (syslog-ng.conf)

El fichero de configuración de Syslog-NG suele situarse en la rama /etc/syslog-ng/syslog-ng.conf y puede observarse, una vez abierto, que su complejidad es mayor que que la del demonio tradicional syslogd. Mientras que los ficheros de configuración antiguos se formaban con líneas de dos parámetros más dos subparámetros (selector, con original y priority, y action), el fichero de configuración de Syslog-NG cambia el nombre del parámetro selector por logpaths e incluye los subparámetros source, filter y destination. Por lo tanto, cada ruta de mensaje quedará formada por tres componentes: una fuente, un destino y unas reglas de filtrado. Todos los componentes se unirán finalmente entre sí mediante el uso del comando log, que describe cada una de las rutas de registro que formarán el sistema de mensajes. Como parte adicional del fichero tenemos a nuestra disposición una sección llamada options, donde se establecen una serie de opciones globales del sistema de registro.

A continuación vamos a repasar cada una de las tres partes que conforman la configuración de syslog-ng.conf más el apartado especial options.

• Fuentes

La definición de la fuente sigue el esquema source <nombre> { <driver> parámetros; ... }; donde <nombre> queda a la libre elección del usuario y actúa como identificador del grupo de mensajes y <driver> hace referencia al nombre del controlador.

Existen ocho controladores fuente (drivers), siendo el controlador internal obligatorio. Cada uno de los controladores tiene una o más opciones que se especifican entre paréntesis y se separan entre si mediante un punto y coma (;). Un ejemplo de parámetro puede ser el nombre de archivo o la construcción de la tubería en los controladores file y pipe, respectivamente, o los números de puerto en los controladores udp y tcp. Un listado completo de todas las opciones disponibles para cada controlador se puede encontrar en la documentación del producto que adjuntamos como referencia a este artículo en el apartado final del mismo. Más abajo se puede ver una tabla con todos los controladores disponibles.

• Filtros

Una de las características que más diferencian a Syslog-NG de su predecesor es el sistema de filtrado de mensajes. Los mensajes se pueden ordenar, cambiar de sitio, eliminar, redirigirse a otros destinos, etc. siguiendo unas reglas específicas concretas. Mediante el filtrado podemos redirigir mensajes provenientes de varias fuentes hacia su destino concreto. La definición de un filtro ha de seguir la regla filter <nombre> { expresión; }; donde expresión es una regla simple que se iguala únicamente a dos valores: verdadero o falso. La expresión puede formarse a partir de varias reglas, que uniremos entre si mediante los operadores condicionales and, or y not. La aplicación del filtro se lleva a cabo cuando el valor de la expresión se iguala a verdadero. Para formar las expresiones, Syslog-NG pone a disposición del administrador varias funciones que quedan explicadas en la tabla inferior.

• Destinos

Un destino especifica hacia dónde se redirige y cómo se procesará un mensaje determinado. La definición de la llamada de un controlador de destino sigue el patrón destination <nombre> { <driver> parámetros; ...}; Tenemos hasta nueve controladores de destino disponibles con sus diferentes opciones, que quedan listadas en la documentación oficial del producto. Cada controlador se ejecuta de forma interna y se mantiene hasta su finalización para añadir seguridad frente ataques externos.

• Opciones globales (options)

Las opciones globales se definen mediante la figura options { <opción_1>; <opción_n>; ... }; y permiten especificar una serie de condiciones que se aplicarán al funcionamiento general del programa. Tenemos a nuestra disposición casi una treintena de opciones por lo que es bastante recomendable leer el manual en línea (syslog-ng.conf(5)) o bien atender a la sección del propio manual de referencia oficial.

Un ejemplo de configuración

Para tener una idea más clara de lo explicado anteriormente, vamos a repasar una a una las secciones de un fichero de configuración. Para ello, vamos a reproducir el fichero de configuración distribuido con la versión 1.6.11 de Syslog-NG y el sistema Fedora Core 5. He aquí el fichero en cuestión:

01 options {
02     sync (0);
03     time_reopen (10);
04     log_fifo_size (1000);
05     long_hostnames (off);
06     use_dns (no);
07     use_fqdn (no);
08     create_dirs (no);
09     keep_hostname (yes);
10 };
11
12 source s_sys {
13     file ("/proc/kmsg" log_prefix("kernel: "));
14     unix-stream ("/dev/log");
15     internal();
16     # udp(ip(0.0.0.0) port(514));
17 };
18
19 destination d_cons { file("/dev/console"); };
20 destination d_mesg { file("/var/log/messages"); };
21 destination d_auth { file("/var/log/secure"); };
22 destination d_mail { file("/var/log/maillog" sync(10)); };
23 destination d_spol { file("/var/log/spooler"); };
24 destination d_boot { file("/var/log/boot.log"); };
25 destination d_cron { file("/var/log/cron"); };
26 destination d_mlal { usertty("*"); };
27
28 #filter f_filter1 { facility(kern); };
29 filter f_filter2 { level(info..emerg) and
30                      not facility(mail,authpriv,cron); };
31 filter f_filter3 { facility(authpriv); };
32 filter f_filter4 { facility(mail); };
33 filter f_filter5 { level(emerg); };
34 filter f_filter6 { facility(uucp) or
35                 (facility(news) and level(crit..emerg)); };
36 filter f_filter7 { facility(local7); };
37 filter f_filter8 { facility(cron); };
38
39 #log {source(s_sys); filter(f_filter1); destination(d_cons); };
40 log {source(s_sys); filter(f_filter2); destination(d_mesg); };
41 log {source(s_sys); filter(f_filter3); destination(d_auth); };
42 log {source(s_sys); filter(f_filter4); destination(d_mail); };
43 log {source(s_sys); filter(f_filter5); destination(d_mlal); };
44 log {source(s_sys); filter(f_filter6); destination(d_spol); };
45 log {source(s_sys); filter(f_filter7); destination(d_boot); };
46 log {source(s_sys); filter(f_filter8); destination(d_cron); };

• 01-10 - Sección options

En esta sección se definen varios parámetros globales. sync establece el número de líneas a almacenar en memoria antes de procesar la escritura en el fichero de mensajes correspondiente; time_reopen cuenta el tiempo que ha de transcurrir entre una conexión finalizada y la siguiente reconexión; log_fifo_size establece el número de líneas que entrarán en la cola de salida, presente en todos los destinos; long_hostnames activa o desactiva el formato de mensajes con el hostname encadenado (el servidor de registro añade su propio nombre al nombre de host existente en el mensaje, lo cual tiene mucha utilidad si queremos trazar una ruta hasta el origen del mensaje, sobre todo en redes con una envergadura notable); use_dns se encarga de activar o desactivar la resolución de nombres, siendo una buena idea su desactivación para evitar ataques inesperados; con use_fqdn  activado se resolverán las entradas con nombres de dominio cualificados, quedándose en su forma corta si la opción se desactiva; create_dirs se encarga de decirle al programa de registro si se pueden crear o no directorios durante la escritura de los ficheros de mensajes; keep_hostname escribe, si está activado, el nombre del host desde el cual se ha producido el mensaje y lo guarda junto al mensaje mismo.

• 12-17 - La fuente

Con s_sys identificamos el grupo que contiene la serie de fuentes que se van a usar al levantar el servicio. El controlador file se encarga de leer los mensajes del kernel de la ruta /proc/kmsg y el parámetro aplicado (log_prefix()) indica la cadena que se añadirá al comienzo del mensaje (los mensajes del kernel en Fedora Core no empiezan por kernel: por defecto). El siguiente controlador, unix-stream, abre el dispositivo /dev/log. El controlador internal queda definido de forma obligatoria y procesa los mensajes internos del servidor de registro. Por último, comentado, tenemos un ejemplo de uso del controlador udp, que abre la conexión especificada por el parámetro ip en el puerto que define port.

• 19-26 - Los destinos

Podemos observar como todas las líneas que conforman los destinos tienen un formato común: se establece el nombre del destino y se carga el controlador. El controlador más común es file, que escribe los mensajes al archivo de registro especificado. Este controlador maneja un número elevado de opciones y merece la pena tenerlas en cuenta a la hora de formar las estructuras de los destinos. Como ya hemos reiterado en otras ocasiones, las opciones disponibles se documentan en el manual oficial del producto. Por ejemplo, la línea 22 utiliza el parámetro sync, que se encarga de sincronizar el archivo cuando se han procesado un número de mensajes determinado (en el ejemplo, 10). En la línea 26 podemos ver el uso del controlador usertty, que en este caso se configura para mandar los mensajes a las consolas de todos los usuarios.

• 28-37 - Filtrado

Los filtros conforman la parte del programa peor documentada y el uso de expresiones regulares para formarlos hacen elevar la complejidad de los mismos, no llegando nunca a ser tarea imposible su aprendizaje. En lineas generales, tendremos tantos filtros como ficheros de mensajes queramos formar. Como podemos ver en el fichero de ejemplo, menos la primera línea comentada (correspondiente al filtrado de los mensajes que origina la utilidad kern del kernel), todas las demás se corresponden con los diferentes destinos que fueron definidos en el apartado anterior. Por ejemplo, el filtro de la línea 32 (f_filter4) se correspondería con el destino de la línea 22 (d_mail). Dicho filtro establece, mediante el uso de la función facility(), que serán apartados todos los mensajes originados por la utilidad mail. En la definición del filtro f_filter2 de la línea 29 podemos observar una estructura más compleja que hace uso de la función level() para establecer los niveles de prioridad que queremos filtrar y que se une a una función negada facility() que excluye del filtro todo aquello que provenga de las utilidades mail, authpriv y cron (en definitiva, se prepara la construcción del típico fichero de registro /var/log/messages). Otra función, que se hace bastante útil cuando no disponemos de una aplicación concreta que genere los avisos, es match(), mediante la cual filtraremos los mensajes por la coincidencia de una cadena simple. Por ejemplo, podríamos construir la siguiente regla de filtrado que nos apartaría todos los mensajes que tengan alguna relación con el servidor de FTP:

filter f_filter_ftp { match("ftp"); };

Y, si queremos observar hasta qué punto puede elevarse la complejidad de una regla de filtrado, podemos echar un vistazo al siguiente apartado de este artículo, donde se reproduce una regla de filtrado compleja como parte del ejemplo de escritura sobre PostgreSQL.

• 39-46 - Las reglas de registro

Como hemos explicado anteriormente, la orden log es la encargada de unir las tres partes fundamentales de un registro determinado: la fuente, el filtrado y el destino final. Todos los componentes se pueden reutilizar para formar diferentes reglas y cada regla puede estar formada por cuantos componentes sean necesarios, aunque habitualmente y si el sistema administrado no es muy complejo, terminaremos encontrándonos con una fuente y una cantidad muy similar de filtros y destinos que conformarán reglas que agrupen a no más de tres componentes.

Elevando la complejidad

Para ilustrar las posibilidades de Syslog-NG vamos a observar con un ejemplo cómo podemos insertar nuestros mensajes de registro en una base de datos PostgreSQL mediante el uso de un archivo temporal (o buffer).

En primer lugar, crearemos una regla que establezca cuales serán las fuentes:

source s_sys { unix-stream ("/dev/log"); internal(); };
   source s_udp { udp(); };
   source s_tcp { tcp(); };
   source s_local { internal(); };

Continuamos estableciendo el destino hacia la base de datos, utilizando el controlador file para escribir una cadena en un archivo que contiene, como extensión, el momento en el cual se está generando el mensaje. Con el uso del parámetro template establecemos el formato con el cual se grabará dicho mensaje. Con template_escape evitamos que el servidor de SQL interprete los parámetros acotados como ordenes. Finalmente, owner establece que el propetario del archivo es el usuario postgres.

destination d_postgres {
 file("/spool/log_sql/log.$YEAR.$MONTH.$DAY.$HOUR.$MIN.$SEC"
 template("INSERT INTO msg_table VALUES
    \( '$R_ISODATE', '$S_ISODATE', '$HOST',   
       '$FACILITY', '$PRIORITY', '$MSG'\)\;\n")
 template_escape(yes)
 owner(postgres));
};

Ahora es el momento de escribir una regla más o menos compleja que filtre nuestros mensajes. En nuestro caso, se ha optado por una regla que aparte todo aquello que sea intrascendente y que no merezca ser guardado en la base de datos. Observesé como se tiende en la primera parte de la regla a quitar todo aquello que puede ser poco interesante y el la segunda parte se guarda todo lo que sí interesa. Las dos últimas partes de la regla filtran el mensaje según su procedencia y cuidan que se cumplan ciertas coincidencias que filtren por el acceso a la máquina (auth).

filter f_postgres { not(
  (host("syslogdb") and facility(cron) and level(info))
 or (facility(user) and level(notice)
  and ( match(" gethostbyaddr: ")
   or match("last message repeated ")
  )
 )
 or ( facility(local3) and level(notice)
  and match(" SYSMON NORMAL "))
 or ( facility(mail) and level(warning)
  and match(" writable directory")
 )
 or (  ( host("dbserv1.somecompany.com")
  or host("dbserv2.somecompany.com")
 )
 and facility(auth) and level(info)
 and match("su oracle")
 and match(" succeeded for root on /dev/")
 )
); };

Para finalizar con el ejemplo, reuniremos los componentes mediante la orden log:

log {
source(s_sys);
source(s_udp);
source(s_tcp);
filter(f_postgres);
destination(d_postgres);   
};

Otra alternativa a la escritura de mensajes de registro sobre una base de datos puede ser la creación de un destino formado mediante la orden pipe o la orden program. Veamos su uso en los dos ejemplos siguientes, que establecen destinos hacia una base de datos MySQL:

destination d_mySQL {
pipe("/tmp/mysql.pipe"
template("INSERT INTO logs (host, facility,
 priority, level, tag, date, time, program,
 msg)
 VALUES ( '$HOST', '$FACILITY', '$PRIORITY',
 '$LEVEL', '$TAG', '$YEAR-$MONTH-$DAY',
 '$HOUR:$MIN:$SEC', '$PROGRAM', '$MSG' );\n")
template-escape(yes)); };

destination database {
  program("/usr/local/sbin/sqlsyslogd -u
  sqlsyslogd -t logs sqlsyslogs2 -p");
};

Conclusión

Si bien el mantenimiento o hasta la propia documentación del programa no son todo lo maravilloso que nos gustaría que fueran, el programa Syslog-NG parece conformarse como la herramienta de sustitución perfecta para un sistema de registro de eventos que ha quedado obsoleto y casi inservible si hablamos de una implantación del servicio en grandes redes corporativas. La necesidad creciente de toma de decisiones críticas en el menor tiempo posible y con la máxima fiabilidad, hacen necesario el uso de herramientas que vayan más allá de lo tradicional. Syslog-NG es una de esas herramientas.

Recursos

• Página oficial del proyecto .
• Documentación oficial de la versión 1.6 (en inglés).
• Ejemplos de configuración .

Sólo los usuarios registrados pueden escribir comentarios.
Por favor, valídate o regístrate.

Powered by AkoComment 2.0!