Capítulo 9: Administración de los sistemas operativos

Publicado por P. Ruiz en

9.7. Seguimiento de la actividad del sistema

No pasa nada importante en un sistema operativo moderno sin que sea anotado en un registro de eventos (también llamado log o bitácora). Dichas anotaciones incluyen mensajes de aviso y errores, y es importante supervisarlas periódicamente para asegurarnos de que no existen incidencias destacables. Y si las hay, tener la oportunidad de resolverlas antes de que tengan repercusiones graves.

Consultar los eventos de Windows

El complemento de Windows que permite consultar y administrar los eventos anotados, tanto por los servicios del propio sistema, como por las diferentes aplicaciones, se llama Visor de eventos, y nos ofrece una forma potente y centralizada de conocer lo que está pasando en nuestro sistema operativo.

El Visor de eventos resulta imprescindible para supervisar el funcionamiento del servidor y resolver cualquier incidencia. Desde él podremos realizar las siguientes tareas:

  • Consultar los eventos que se hayan producido.

  • Crear filtros para los eventos que más nos interesen y almacenarlos como vistas personalizadas que podemos volver a utilizar en cualquier momento.

  • Programar una tarea para que se ejecute en respuesta a una situación específica.

  • Establecer suscripciones a determinados eventos.

Los eventos se clasifican en diferentes categorías:

  1. Vistas personalizadas: Permiten restringir los eventos mostrados en función de nuestras preferencias.

  2. Registros de Windows: Almacenan eventos relacionados con todo el sistema y los relativos a aplicaciones heredadas.

  3. Registros de aplicaciones y servicios: Contienen eventos relacionados con aplicaciones o componentes particulares.

  4. Suscripciones: Se utiliza para recopilar los eventos de otros equipos de la red y almacenarlos localmente.

Quizás, la categoría más interesante sea Registros de Windows, que actúa como un contenedor de varias subcategorías que, en su mayoría, resultarán familiares para los usuarios avanzados de otros sistemas de escritorio de Microsoft. En concreto, encontramos las siguientes:

  • Aplicación: Aquí anotan sus eventos las aplicaciones y los servicios que no forman parte del sistema.

  • Seguridad: Incluye la información de los eventos relacionados con la seguridad del sistema.

  • Instalación: Donde se anotan la información de los eventos relativos a la configuración de roles y características.

  • Sistema: Contiene información relativa a los eventos del sistema y de sus componentes.

  • Eventos reenviados: Contiene información reenviada por otros sistemas de la red.

En SomeBooks.es ya publicamos un artículo práctico que nos explicaba cómo modificar las Directivas de seguridad local para lograr que el sistema tenga en cuenta determinados eventos:

Además, también aprendimos a comprobar cuándo se ha producido un determinado evento y a filtrar la lista de eventos para que se muestren sólo aquellos que nos interesan:

Dispones de una lista completa de identificadores de eventos en el siguiente enlace: https://support.microsoft.com/en-us/kb/977519.

Son para Windows 7 y Windows Server 2008 R2, pero puedes aplicarlos perfectamente a las versiones más modernas.

Actividad 8: Supervisar eventos de inicio de sesión en Windows

Cada vez que iniciamos sesión en Windows de forma satisfactoria, se genera una entrada en el registro de eventos.

Con esta idea en mente, debes averiguar el identificador para este tipo de evento y crear un nuevo filtro que te permita averiguar, de una forma sencilla, las veces que se ha utilizado el ordenador en la última semana.

Consultar los eventos de Ubuntu

Los sistemas operativos GNU/Linux suelen guardar las situaciones anómalas o los problemas que surjan durante la ejecución del sistema en una serie de archivos que se almacenan en el directorio /var/log.

En versiones antiguas de Linux, era el demonio syslogd (Syslog Daemon) quien se encargaba de guardar información sobre el funcionamiento del sistema. Sin embargo, en la actualidad suelen utilizarse dos herramientas que ofrecen una mayor cantidad de opciones. Son estas:

  • syslog-ng: Es una implementación open source del demonio syslogd, pero ofreciendo más prestaciones, como la aplicación de filtros, ordenar la información según el origen, enviarla a distintos lugares, según su naturaleza, etc.

  • rsyslogd: Una versión mejorada de syslogd con capacidades de multi-hilo, que se centra en la seguridad y en la fiabilidad. Esta es la opción predeterminada en Ubuntu y por esto es en la que nos vamos a centrar aquí.

La mayor parte del comportamiento de rsyslogd se encuentra definido en el archivo /etc/rsyslog.conf, aunque algunas opciones también se establecen en /etc/rsyslog.d/.

Es posible modificar estos archivos para cambiar dicho comportamiento, pero se escapa de los objetivos de este texto explicar cómo hacerlo.

Los registros de sucesos que se vigilan de forma predeterminada desde rsyslogd son los siguientes:

Registros de sucesos

Como hemos dicho al principio de este apartado, si un servicio está produciendo sucesos, éstos estarán recogidos bajo el directorio /var/log. Por ejemplo, aquí encontraremos un archivo llamado auth.log.

También podemos encontrar subdirectorios que pueden contener los archivos de sucesos de algún subsistema particular como, por ejemplo, el directorio gdm3, que contiene varios archivos de sucesos relativos al gestor de sesiones GDM.

1

Contenido del archivo auth.log.

El formato de todos los archivos de sucesos es muy parecido, pero necesitamos conocerlo antes de poder analizar su contenido. En el caso de auth.log se estructura de la siguiente forma:

  • Fecha del suceso.

  • Hora del suceso.

  • Nombre del equipo donde se ha producido.

  • Programa / servicio que lo ha originado.

  • Opcionalmente, aparecerá el PID del proceso.

  • Mensaje informativo que describe el suceso.

Por ejemplo, una línea del archivo auth.log podría ser como esta:

Feb 15 21:00:41 usuario-VirtualBox sudo:  usuario : TTY=pts/0 ; PWD=/home/usuario ; USER=root ; COMMAND=/usr/bin/gedit /var/log/auth.log

Aquí vemos que el día 15 de febrero, a las 21:00, en el equipo usuario-VirtualBox el programa sudo informa de que usuario ejecuta desde la terminal, y con privilegios de root, el comando /usr/bin/gedit /var/log/auth.log. Podríamos ser algo más precisos en la explicación, pero creo que estaríamos siendo menos didácticos.

Observa que, en realidad, arriba no hemos mostrado el contenido de auth.log, sino el de auth.log.1. Esto es así para evitar que auth.log crezca en exceso. Periódicamente, el contenido de auth.log se copia a auth.log.1 y se deja vacío para seguir recibiendo eventos.

De hecho, el comportamiento habitual es que, justo antes de volcarle el contenido de auth.log, auth.log.1 se comprime y se renombra como auth.log.2.gz, para evitar que se pierda su contenido.

Así, es habitual que acabemos teniendo también auth.log.3.gz y auth.log.4.gz. Los eventos más viejos, suelen desecharse.

Para ver cómo funciona la herramienta de la interfaz gráfica que nos permite comprobar los eventos que han tenido lugar en el sistema, puedes consultar el siguiente artículo: