Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes
Sección 12.4, “Monitorización”.
14.3.1. Monitorización de los registros con logcheck
El programa logcheck
monitoriza los archivos de registro, de forma predeterminada, cada hora. Envía los mensajes de registro inusuales en correos electrónicos al administrador para su posterior análisis.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles
; the default values work fine if the /etc/rsyslog.conf
file has not been completely overhauled.
logcheck
puede funcionar en una de tres modalidades más o menos detalladas: paranoid, server y workstation. El primero es muy detallado y, probablemente, debería restringirlo a servidores específicos como firewalls. El segundo (y predeterminado) es el modo recomendado para la mayoría de los servidores. El ultimo está diseñado para estaciones de trabajo y es aún más conciso (filtra la mayoría de los mensajes).
En los tres casos, probablemente debería personalizar logcheck
para excluir algunos mensajes adicionales (dependiendo de los servicios instalados) a menos que el administrador realmente desee recibir a cada hora correos electrónicos enormes y poco interesantes. Dado que el mecanismo de selección de mensajes es bastante complejo, /usr/share/doc/logcheck-database/README.logcheck-database.gz
es una lectura — aunque difícil — necesaria.
Las reglas aplicadas se puede dividir en varios tipos:
aquellas que clasifican un mensaje como un intento de intrusión — «cracking» (almacenado en un archivo en el directorio /etc/logcheck/cracking.d/
);
aquellas que cancelan esta clasificación (/etc/logcheck/cracking.ignore.d/
);
aquellos que clasifican un mensaje como una alerta de seguridad (/etc/logcheck/violations.d/
);
aquellos que cancelan esta clasificación (/etc/logcheck/violations.ignore.d/
);
finalmente, aquellas que son aplicadas a los mensajes restantes (considerados como eventos del sistema).
Siempre se indicará un evento de sistema a menos que una regla en alguno de los directorios en /etc/logcheck/ignore.d.{paranoid,server,workstation}/
indique que el evento debe ser ignorado. Por supuesto, sólo se tomarán en cuenta los directorios que corresponden a los niveles de detalle igual o mayor al modo de funcionamiento seleccionado.
14.3.2. Monitorización de actividad
top
es una herramienta interactiva que muestra una lista de los procesos en ejecución. La ordenación predeterminada es según la cantidad de procesador utilizada y se puede obtener mediante la tecla P. Entre otros criterios de ordenación podemos encontrar: según la cantidad de memoria ocupada (tecla M), según el tiempo total de uso de procesador (tecla T) y según el identificador de proceso (tecla N). La tecla k permite matar un proceso ingresando su identificador de proceso. La tecla r permite ejecutar renice sobre un proceso, es decir: cambiar su prioridad.
Cuando el sistema aparenta estar sobrecargado, top
es una herramienta excelente para ver qué procesos estan compitiendo por el tiempo de procesador o consumiendo demasiada memoria. En particular, a menudo es interesante comprobar si los procesos que están consumiendo los recursos se corresponden con los servicios reales que la máquina debe albergar. Por ejemplo, un proceso desconocido ejecutándose como el usuario www-data debería llamar su atención y ser investigado puesto que posiblemente sea algún tipo de software instalado y ejecutado en el sistema a través de una vulnerabilidad en una aplicación web.
top
es una herramienta muy flexible y su página de manual detalla cómo personalizar su presentación y adaptarla a las necesidades y hábitos particulares.
The gnome-system-monitor
graphical tool is similar to top
and it provides roughly the same features.
La carga del procesador, el tráfico de red y el espacio libre en disco son datos que varían constantemente. A menudo es útil disponer de un historial con su evolución para determinar cómo se utiliza exáctamente la máquina.
Existen muchas herramientas dedicadas para esta tarea. La mayoría puede obtener datos a través de SNMP (protocolo simple de gestión de red: «Simple Network Management Protocol») para centralizar esta información. Un beneficio adicional es que permite recoger datos de elementos de red que pueden no ser equipos de propósito general, tal como switches o routers dedicados.
Este libro habla de Munin con cierto detalle (ver la
Sección 12.4.1, “Configuración de Munin” como parte del
Capítulo 12: “Administración avanzada”. Debian también proporciona una herramienta similar:
cacti. Su despliegue es algo más complejo puesto que se basa exclusivamente en SNMP. A pesar de que dispone de una interfaz web, entender los conceptos involucrados en la configuración requiere de todas formas un poco de esfuerzo. Debería considerar como prerequisito leer la documentación HTML (
/usr/share/doc/cacti/html/index.html
).
14.3.3. Detección de cambios
Una vez que el sistema está instalado y configurado, dejando al margen las actualizaciones de seguridad, normalmente no hay razón para que los archivos y directorios cambien con excepción de los datos. Por lo tanto, es interesante asegurarse que efectivamente los archivos no cambian: debería investigar cualquier cambio inesperado. Esta sección presenta algunas herramientas capaces de monitorizar archivos y advertir al administrador en caso de que se produzca algún cambio inesperado (o simplemente enumerar estos cambios).
14.3.3.1. Auditing Packages with dpkg --verify
dpkg --verify
(or dpkg -V
) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums
); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.
Running dpkg -V
will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V
where each character denotes a test on some specific meta-data. Unfortunately dpkg
does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
#
dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service
override (which would be stored below /etc
like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.
14.3.3.2. Auditoría de paquetes: debsums
y sus límites
debsums
is the ancestor of dpkg -V
and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar work-arounds).
Since the data on the disk cannot be trusted, debsums
offers to do its checks based on .deb
files instead of relying on dpkg's database. To download trusted .deb
files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
#
apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
#
debsums -p /var/cache/apt/archives --generate=all
Sepa que este ejemplo utiliza el programa grep-status
del paquete dctrl-tools que no se instala de forma predeterminada.
14.3.3.3. Monitorización de archivos: AIDE
La herramienta AIDE (entorno avanzado de detección de intrusión: «Advanced Intrusion Detection Environment») permite comprobar la integridad de los archivos y detectar cualquier cambio frente a una imagen guardada previamente del sistema válido. Se almacena esta imagen como una base de datos (/var/lib/aide/aide.db
) que contiene la información relevante de todos los archivos del sistema (huella digital, permisos, marcas temporales, etc.). Se inicializa esta base de datos con aideinit
; luego se la utiliza diariamente (por el script /etc/cron.daily/aide
) para comprobar que nada importante haya cambiado. Cuando se detectan cambios, AIDE los almacena en archivos de registro (/var/log/aide/*.log
) y envía lo encontrado en un email al administrador.
Puede utilizar numerosas opciones en el archivo /etc/default/aide
para configurar el comportamiento del paquete aide. Se almacena la configuración de AIDE en sí en /etc/aide/aide.conf
y /etc/aide/aide.conf.d/
(de hecho, sólo update-aide.conf
utiliza estos archivos para generar /var/lib/aide/aide.conf.autogenerated
). La configuración indica qué propiedades se deben comprobar. Por ejemplo, el contenidos de los archivos de registro cambia continuamente, y se puede ignorar estos cambios mientras que los permisos de los archivos permanezcan inalterados, pero tanto el contenido como los permisos de los programas ejecutables debe permanecer constante. Aunque no es excesivamente compleja, la sintaxis de la configuración no es del todo intuitiva y, por lo tanto, recomendamos leer su página de manual aide.conf(5).
Cada día se genera una nueva versión de la base de datos en /var/lib/aide/aide.db.new
; si todos los cambios registrados son legítimos, puede utilizarla para reemplazar la base de datos de referencia.
14.3.4. Detección de intrusiones (IDS/NIDS)
suricata
(in the Debian package of the same name) is a NIDS — a
Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in
/var/log/suricata
. There are third party tools (Kibana/logstash) to better browse all the data collected.
Configuring suricata involves reviewing and editing /etc/suricata/suricata-debian.yaml
, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET
parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.
On top of this, you should also edit /etc/default/suricata
to define the network interface to monitor and to enable the init script (by setting RUN=yes
). You might also want to set LISTENMODE=pcap
because the default LISTENMODE=nfqueue
requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE
target).
To detect bad behaviour, suricata
needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort
is the historical reference in the IDS ecosystem and suricata
is able to reuse rules written for it. Unfortunately that package is missing from Debian Jessie and should be retrieved from another Debian release like Testing or Unstable.
Alternatively, oinkmaster
(in the package of the same name) can be used to download Snort rulesets from external sources.