14.3. Supervisión: prevención, detección, disuasión
La monitorización es una parte integral de cualquier política de seguridad por varias razones. Entre ellas, que el objetivo de la seguridad generalmente no se limita a garantizar la confidencialidad de los datos, sino que también incluye garantizar la disponibilidad de los servicios. Por tanto, es imprescindible comprobar que todo funciona como se espera y detectar de manera oportuna cualquier desvío en la conducta o cambio en la calidad de los servicios prestados. Monitorizar la actividad puede ayudar con la detección de intentos de intrusión y permitir una reacción rápida antes que ocurran graves consecuencias. Esta sección revisa algunas de las herramientas que puede utilizar para monitorizar varios aspectos de un sistema Debian. Como tal, esto completa
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.
La lista de archivos a monitorizar se almacena en /etc/logcheck/logcheck.logfiles
; los valores predeterminados funcionan bien si no modificó completamente el archivo /etc/rsyslog.conf
.
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.
When the system seems to be overloaded, top
is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.
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.
La herramienta gráfica gnome-system-monitor
es similar al programa top
y proporciona aproximandamente las mismas características.
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.
This book deals with Munin in some detail (see
Sección 12.4.1, “Configuración de Munin”) as part of
Capítulo 12: “Administración avanzada”. Debian also provides a similar tool,
cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (
/usr/share/doc/cacti/html/Table-of-Contents.html
) should be considered a prerequisite.
14.3.3. Avoiding Intrusion
Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log in to an unauthorised software system by performing multiple login attempts in a short period of time.
The best way to stop a brute-force atack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.
Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attemps to a log file. It can be found in the package fail2ban.
Fail2Ban is configured through a simple protocol by fail2ban-client
, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server
. It has four configuration file types, all stored in /etc/fail2ban
:
fail2ban.conf
. Global configuration (such as logging).
filter.d/*.conf
. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.
action.d/*.conf
. Actions defining the commands for banning and unbanning of IP addresses.
jail.conf
. It is where jails, the combinations of filters and actions, are defined.
Let us have a look at the configuration of sshd
in /etc/fail2ban/jail.conf
to better understand how Fail2Ban works...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attepts for sshd
using Python regular expressions defined in /etc/fail2ban/filters.d/sshd.conf
against the log file of sshd
, which is defined in the variable sshd_log
in the file /etc/fail2ban/paths_common.conf
. If Fail2Ban detects five failed login attempts in a row, it will ban the IP address where those attempts originated.
Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.
14.3.4. Detección de cambios
Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).
14.3.4.1. Auditoría de paquetes mediante dpkg --verify
dpkg --verify
(o dpkg -V
) es una orden interesante, puesto que permite averiguar qué archivos han sido modificados (potencialmente por un atacante). Sin embargo esta información se tiene que tomar con precaución. Para hacer su trabajo, dpkg utiliza las sumas de verificación (checksums) almacenadas en el disco duro (se pueden encontrar en /var/lib/dpkg/info/package.md5sums
); un atacante minucioso podría actualizar estos archivos de forma que contengan las nuevas sumas de verificación de los archivos modificados.
Le comando dpkg -V
comprueba todos los paquetes instalados e imprime una línea por cada archivo en el que falle el test de integridad. El formato de salida es el mismo que el del comando rpm -V
, conde cada carácter corresponde a una comprobación sobre un metadato específico. Desgraciadamente dpkg
no almacena todos los metadatos requeridos para todas las comprobaciones, y por lo tanto imprimirá signos de interrogación para la mayor parte de los mismos. En la actualidad únicamente el test de suma de verificación podría impirmir un « 5 » (en la tercera columna) en caso de no pasar la comprobación.
#
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
En el ejemplo anterior, dpkg muestra un cambio realizado por el administrador en el archivo de servicio de SSH contenido en el paquete, en lugar de modificar la configuración mediante un archivo /etc/systemd/system/ssh.service
(almacenado en /etc
como deberían estar todos los archivos de configuración). dpkg también muestra varios archivos de confirugación (identificados con la letra « c » en el segundo campo) que han sido modificados (de forma legítima).
14.3.4.2. Auditoría de paquetes: debsums
y sus límites
debsums
es el antecesor de dpkg -V
y por lo tanto está prácticamente obsoleto. Tiene las mismas restricciones que dpkg. Afortunadamente, algunas de sus limitaciones pueden ser obviadas (lo que no es posible con dpkg).
Como no es posible confiar en los archivos almacenadados en el disco, debsums
permite efectuar sus comprobaciones a partir de los archivos .deb
además de a partir de la base de datos de dpkg. Para descargar los archivos .deb
confiables de todos los paquetes instalados, se pueden utilizar las descargas autenticadas de APT. Lo malo es que esta operación puede ser lenta y tediosa y, por lo tanto, no debe considerarse como una técnica proactiva a utilizar de forma regular.
#
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.
debsums
can be run frequently as a cronjob setting CRON_CHECK
in /etc/default/debsums
. To ignore certain files outside the /etc
directory, which have been altered on purpuse or which are expected to change (like /usr/share/misc/pci.ids
) you can add them to /etc/debsums-ignore
.
14.3.4.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.5. 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.
La configuración de Suricata se realiza a travśe del archivo /etc/suricata/suricata-debian.yaml
, que es muy extenso, puesto que cada parámetro está descrito ampliamente. Como mínimo se requireconfigurar el rango de direcciones de la red local (el parámetro HOME_NET
). En la práctica esto quiere decir el conjunto de todos los blancos de ataque potenciales. Pero para sacar el mayor partido a esta utilidad, se debería leer todo el archivo y adaptarlo de la mejor manera a la situación local.
Igualmente, se debería configurar /etc/default/suricata
para establecer qué interfaz de red supervisar y para activar el script de inicialización (estableciendo RUN=yes
). Además se puede establecer LISTENMODE=pcap
, porque el valor predeterminado (nfqueue
) no funciona sin una configuración adicional (el cortafuegos netfilter debe configurarse mediante el destino NFQUEUE
para pasar los paquetes a un archivo de cola en espacio de usuario gestionado por suricata).
To detect bad behavior, 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.
Otra posibilidad es utilizar oinkmaster
(en el paquete homónimo), que es capaz de descargar conjuntos de relgas de Snort desde fuentes externas.