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; y /etc/logcheck/logcheck.logfiles.d/; los valores predeterminados funcionan bien con systemd y rsyslog si sus archivos de configuración no se han revisado por completo.
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.
La herramienta gráfica gnome-system-monitor es similar al programa top y proporciona aproximandamente las mismas características. Las alternativas son atop y htop, que proporcionan una funcionalidad similar, pero difieren en las características de usabilidad, como la capacidad de desplazamiento.
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 exactamente la máquina.
Hay muchas herramientas dedicadas para esta tarea. El paquete sysstat, por ejemplo, recopila y muestra estadísticas de rendimiento del sistema localmente. A continuación, los datos se pueden visualizar con el comandosar. Sin embargo, la mayoría de las herramientas pueden obtener datos a través de SNMP (Protocolo Simple de Administración de Red) para centralizar esta información. Un beneficio adicional es que esto permite obtener datos de elementos de red que pueden no ser computadoras de propósito general, como enrutadores o conmutadores de red 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/Table-of-Contents.html).
14.3.3. Evitando los Intrusos
Los ataques tratan de obtener acceso a servidores adivinando contraseñas, por lo que se deben usar siempre contraseñas fuertes. Incluso así debería establecer también medidas contra ataques de fuerza bruta. Un ataque de fuerza bruta es un intento de iniciar sesión en un sistema de software al que no se está autorizado realizando varios intentos de inicio de sesión en un corto periodo de tiempo.
The best way to stop a brute-force attack 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 attempts to a log file or the system journal. 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 y fail2ban.d/*.conf. Configuración global (cosas como registros).
filter.d/*.conf. Filtros que especifican cómo detectar fallos de autentificación. El paquete de Debian ya contiene filtros para muchos programas comunes.
action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.
jail.conf y jail.d/*.conf. Es donde jails, las combinaciones de filtros y acciones, se definen.
Echémosle un vistazo a la configuración de sshd en /etc/fail2ban/jail.conf para comprender mejor cómo funciona Fail2Ban...
[...]
[DEFAULT]
[...]
bantime = 1h
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban buscará intentos de inicio fallidos para sshd usando expresiones regulares de Python definidas en /etc/fail2ban/filters.d/sshd.conf dirigidas al archivo de registro de sshd, que está definido en la variable sshd_log en el archivo /etc/fail2ban/paths_common.conf. Si Fail2Ban detecta cinco intentos fallidos de acceso seguidos en 10 minutos, prohibirá la dirección IP donde se originaron esos intentos durante 1 hora.
El backend predeterminado que se usa ahora es systemd. Los archivos de registro antiguos, como auth.log solo están disponibles si se instalado y habilitado rsyslog.
Para habilitar, deshabilitar o configurar las “jaulas” («jails»), no se debe modificar el archivo de configuración principal /etc/fail2ban/jail.conf. En su lugar, las modificaciones deben hacerse en el archivo /etc/fail2ban/jail.d/defaults-debian.conf o en archivos dentro del mismo directorio.
If Docker containers are involved, the rules injected into iptables by fail2ban to block traffic from specific IPs must be applied to the right chain by chain = DOCKER-USER. Otherwise, the ban will not work.
Fail2Ban es una manera muy simple y efectiva de protegerse contra los ataques de fuerza bruta más comunes, pero no puede proteger contra ataques de fuerza bruta distribuidos, que es cuando un atacante usa un gran número de máquinas distribuidas por todo Internet.
A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt. It is also possible to increase the block time with each ban for the same IP.
14.3.4. 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.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. Es igual de cierto para debsums.
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?????? c /etc/logcheck/logcheck.logfiles.d/syslog.logfiles
??5?????? c /etc/logrotate.d/apt
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/systemd/journald.conf
??5?????? c /etc/lvm/lvm.conf
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.d/override.conf 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.4.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 workarounds).
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 purpose 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 (del paquete Debian con el mismo nombre) es un NIDS — un
sistema de detección de intrusiones de red («Network Intrusion Detection System»). Su función es escuchar la red y tratar de detectar intentos de infiltración y/o actos hostiles (incluídos ataques de denegación de servicio). Todos estos eventos son registrados en varios archivos dentro de
/var/log/suricata. Existen utilidades de terceros (Kibana/logstash) para poder examinar todos los datos recogidos. La herramienta puede considerarse la sucesora de
snort, que se ha eliminado de Debian.
La configuración de Suricata se realiza a través del archivo /etc/suricata/suricata-debian.yaml, que es muy extenso, puesto que cada parámetro está descrito ampliamente. Como mínimo se requiere configurar 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.
On top of this, you should also define the network interface. You might also want to set LISTENMODE=pcap in /etc/default/suricata 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).
Para detectar un funcionamiento malicioso, suricata necesita un conjunto de reglas de supervisión: puede encontrar esas reglas en el paquete snort-rules-default. snort es la referencia dentro del ecosistema de IDSs, y suricata puede reutilizar las reglas escritas para este programa.
Otra posibilidad es utilizar oinkmaster (en el paquete homónimo), que es capaz de descargar conjuntos de reglas Snort de fuentes externas.
Desafortunadamente, los paquetes mencionados no forman parte de la versión actual de Debian
Bookworm. Pero aún se pueden recuperar a través de la búsqueda de paquetes de Debian o del archivo de instantáneas de Debian.
