Auditoría de sistemas UNIX. Parte 25. Registros de auditoría

Buenas,

Por retomar un poco el hilo de la serie de Auditoría UNIX, comentaros que en la última entrada hablamos sobre usuarios y grupos. De esto hace ya algún tiempo, con lo que perdonad los que estáis siguiendo estos capitulillos.

Me gustaría poder acabar este tipo de análisis cuanto antes, para así abrir otros tipos de auditorías. Tengo en mente abrir el tema de base de datos, posiblemente ejemplificado con Sybase y Oracle, pero para eso antes hay que cerrar el capítulo de UNIX :)

Así pues, vamos a ir finalizando la serie (algún punto final hay que establecer, si no podemos hacer esto eterno) y qué mejor manera que hablando sobre los controles de auditoría inherentes a los sistemas UNIX y sus derivados. Para ello acotaremos el estudio al funcionamiento de una herramienta de trazas muy extendida y conocida, syslog, no perdiendo de vista que cada sistema tiene sus propias particularidades (véase este ejemplo en FreeBSD, o este ejemplo sobre accounting en AIX) y que tratar de analizar todos y cada uno de los mecanismos intrínsecos de auditoría de los mismos es una tarea fuera de la pretensión de esta entrada.

Dicho esto, y para poder ilustrar cómo deben verificarse los registros de auditoría, vamos a utilizar, tal y como hemos comentado, una herramienta universal y extendida, y esa no es otra que syslog. El auditor deberá, en cada caso, indentificar y analizar el resto de registros de auditoría de cada sistema en particular, y proceder según la configuración del sistema y sus planes de trabajo para poder opinar de todos y cada uno de los mecanismos existentes.

Syslog

Bueno, lo primero es lo primero. ¿Qué es syslog? Sencillamente es un protocolo para envío de mensajes de registros log a través de redes IP. Es frecuente que también se llame syslog a la aplicación que efectúa el negociado de mensajes. Para los que gustamos de consultar los RFCs asociados a algún servicio, comentar que syslog se rige principalmente por los RFCs RFC 3164 – The BSD syslog Protocol y RFC 3195 – Reliable Delivery for syslog.

Un paquete syslog está limitado a 1024 bytes, y debería transportar la siguiente información:

* Categoría
* Severidad
* Nombre de maquina
* Timestamp
* Mensaje

El campo categoría admite valores enteros, dependiendo si se refiere a eventos de sistema operativo, procesos o aplicaciones. Un ejemplo de línea de syslog puede ser la siguiente:

Aug 2 07:35:07 localhost postfix/pickup[22396]: 30991371EFA: uid=0 from=

Esta línea informa sobre la actividad del demonio de recogida de correo Postfix.

Syslog tiene múltiples implementaciones que van más allá del mundo UNIX. Algunos ejemplos son sysklogd, rsyslog, syslog-ng, mysyslog o socklog. Existen implementaciones no UNIX, como las que hay para Microsoft Windows, pero éstas no tienen interés alguno en un curso de auditoría de derivados de UNIX.

¿Corre syslog en mi máquina?

shernando@shernando:~$ ps -ef | grep syslog
root 4193 1 0 Jul09 ? 00:00:05 /sbin/syslogd

En caso de que no esté funcionando, puedes activar syslog a mano.

Analizando el funcionamiento de syslog

La auditoría básica de syslog es aquella en la que revisamos qué configuración tiene el demonio syslogd, con el propósito de comprender qué información log vamos a transportar. Para ello lo que hay que hacer es solicitar al auditado que nos proporcione los contenidos del fichero syslog.conf (ubicado generalmente en /etc/syslog.conf)

A continuación reproduzco el fichero syslog.conf que acompaña a las distribuciones Debian por defecto:

# /etc/syslog.conf Configuration file for syslogd.
#
# For more information see syslog.conf(5)
# manpage.

#
# First some standard logfiles. Log by facility.
#

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
uucp.* /var/log/uucp.log

#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err

#
# Some `catch-all’ logfiles.
#
*.=debug;\
auth,authpriv.none;\
-/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
-/var/log/messages

#
# Emergencies are sent to everybody logged in.
#
*.emerg *

#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
#daemon,mail.*;\
# news.=crit;news.=err;news.=notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn /dev/tty8

# The named pipe /dev/xconsole is for the `xconsole’ utility. To use it,
# you must invoke `xconsole’ with the `-file’ option:
#
# $ xconsole -file /dev/xconsole […] #
# NOTE: adjust the list below, or you’ll go crazy if you have a reasonably
# busy site..
#
daemon.*;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole

Como seguramente ya sepáis, las líneas que comienzan con # son comentarios y por tanto, no contienen configuración operativa. Lo más importante es, en la mayoría de los casos, comprobar si existe un escalado de cirticidad de eventos y si los mensajes están permitidos o no para cada evento. También es importante conocer qué acciones son disparadas por los eventos definidos. Los permisos de los ficheros syslog serán igualmente revisados:

1. Comprobamos propietario, grupo y permisos de los ficheros y nivel de permisos de los ficheros syslog.conf syslog.pid. El usuario por defecto suele ser root, si bien, siempre y cuando la política de usuarios lo respalde, puede ser cambiado. En cuanto a permisos, se considera mínimo nivel de protección permisos 644 (-rw-r–r–)

2. Examinamos el tipo de alertas que se gestionan con syslog. Para facilitar la lectura de syslog, mostramos las líneas que no contienen el síombolo #

shernando@shernando:~$ cat /etc/syslog.conf | grep -v «#»

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log
uucp.* /var/log/uucp.log

mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err

*.=debug;\
auth,authpriv.none;\
-/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
-/var/log/messages

*.emerg *

daemon.*;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole

Llegados a este punto conviene repasar el tipo de eventos declarados y las acciones asociadas en el fichero de configuración. Es más o menos frecuente que syslog gestione acciones del tipo *.crit (críticas) *.err (errores), *.alert (alertas), *.emerg (emergencia) y *.info (informativo), aunque dependiendo del despliegue, se puede prescindir de los eventos menos relevantes, sobre todo si el rendimiento se ve penalizado, o si el espacio de almacenamiento es limitado. Todo esto se discutirá y justificará antes de emitir una opinión, ya que en un despliegue real puede admitirse como válido, por ejemplo, que no haya alertas informativas por que su gestión y transmisión consuman recursos excesivos en máquinas de producción.

Sobre las acciones que dispara cada evento, las hay de múltiples clases. Desde avisos por consola hasta envío de logs a servidores centralizados de log, o envíos por correo. Deben investigarse todas las acciones y debe conocerse perfectamente qué acción se dispara en cada caso. Toda esta información se recoge en el fichero de configuración syslog.conf.

Resumen

Los sistemas UNIX pueden tener múltiples y diferenciados registros de auditoría. Algunos estarán integrados en el sistema, y otros serán productos comerciales o libres aplicados al sistema con posterioridad. La labor del auditor es identificarlos, y en función de los métodos que aparezcan, ejecutar un programa de trabajo adecuado.

En cualquier caso, el principal foco de atención será siempre determinar si el registro de auditoría analizado proporciona pistas suficientes o no, y si éstas pistas son gestionadas de un modo seguro para que en caso de ser necesario, se acepten como evidencias no contaminadas. En el informe se opinará sobre esta cuestión, y se recomendará, si procede, ampliar o reducir el espectro de eventos registrados.

Otros ejemplos frecuentes en el mundo UNIX, similares a syslog, pueden ser messages, wtmp, utmp, lastlog, faillog, loginlog, btmp, sulog o debug. Todos ellos son trazas importantes para auditar no sólo la seguridad, sino el funcionamiento general de la máquina.