14.3. Supervisió: Prevenció, detecció, dissuassió
La monitorització forma part integral de qualsevol política de seguretat per diverses raons. Entre elles, que l'objectiu de la seguretat no es limita normalment a garantir la confidencialitat de les dades, sinó que també inclou garantir la disponibilitat dels serveis. Per tant, és imperatiu comprovar que tot funciona com s'espera, i detectar de manera oportuna qualsevol comportament desviat o canvis en la qualitat dels serveis prestats. L'activitat de seguiment pot ajudar a detectar intents d'intrusió i permetre una reacció ràpida abans que causin greus conseqüències. Aquesta secció revisa algunes eines que es poden utilitzar per supervisar diversos aspectes d'un sistema Debian. Com a tal, això completa
Secció 12.4, «Monitorització».
14.3.1. Monitoritzar els registres amb logcheck
El programa logcheck monitoritza els fitxers de registre, per defecte, cada hora. Envia missatges de registre inusuals en correus electrònics a l'administrador per a una anàlisi posterior.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles and /etc/logcheck/logcheck.logfiles.d/; the default values work fine with systemd and rsyslog if their configuration files have not been completely overhauled.
logcheck pot treballar en un dels tres modes més o menys detallats: paranoid, server i workstation. El primer és molt detallat, i probablement hauria de ser restringit a servidors específics com ara tallafocs. El segon mode (per defecte) es recomana per a la majoria de servidors. L'últim està dissenyat per a estacions de treball, i és fins i tot concís (filtra més missatges).
En els tres casos, logcheck probablement s'hauria de personalitzar per excloure alguns missatges addicionals (depenent dels serveis instal·lats), llevat que l'administrador realment desitgi rebre cada hora correus llargs i poc interessants. Atès que el mecanisme de selecció de missatges és bastant complex, /usr/share/doc/logcheck-database/README.logcheck-database.gz és una lectura requerida, i difícil.
Les regles aplicades es poden dividir en diversos tipus:
aquells que qualifiquen un missatge com un intent d'intrusió (desats en un fitxer al directori /etc/logcheck/cracking.d/);
els que cancel·len aquesta qualificació (/etc/logcheck/cracking.ignore.d/);
aquells que classifiquen un missatge com a alerta de seguretat (/etc/logcheck/violations.d/);
els que cancel·len aquesta classificació (/etc/logcheck/violations.ignore.d/);
Finalment, els que s'apliquen als missatges restants (considerats com esdeveniments del sistema).
Un esdeveniment del sistema sempre s'indica llevat que una regla en una dels directoris /etc/logcheck/ignore.d.{paranoid,server,workstation}/ determinia que l'esdeveniment s'ha d'ignorar. Per descomptat, els únics directoris que es tenen en compte són els que corresponen a nivells de detall iguals o superiors al mode d'operació seleccionat.
14.3.2. Monitorització de l'activitat
top és una eina interactiva que mostra una llista de processos actualment en execució. L'ordenació per defecte es basa en la quantitat actual d'ús del processador i es pot obtenir amb la tecla P. Altres ordres d'ordenació inclouen una ordeació per memòria ocupada (teclaM), per temps total de processador (tecla T) i per identificador de procés (tecla N). La tecla k permet matar un procés introduint el seu identificador de procés. La tecla r permet «renicing» un procés, és a dir, canviar la seva prioritat.
Quan el sistema sembla estar sobrecarregat, top és una gran eina per veure quins processos competeixen pel temps del processador o consumeixen massa memòria. En particular, sovint és interessant comprovar si els processos que consumeixen recursos coincideixen amb els serveis reals que se sap que la màquina allotja. Un procés desconegut que s'executa com a usuari de www-data s'hauria de destacar i ser investigat, ja que és probablement una instància de programari instal·lat i executat en el sistema a través d'una vulnerabilitat en una aplicació web.
top és una eina molt flexible i la seva pàgina manual proporciona detalls sobre com personalitzar la seva pantalla i adaptar-la a les necessitats i hàbits personals.
The gnome-system-monitor graphical tool is similar to top and it provides roughly the same features. Alternatives are atop and htop, which provide similar functionality, but differ in usability features, like the scrolling ability.
Processor load, memory usage, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.
There are many dedicated tools for this task. The sysstat package, for example, collects and displays system performance statistics locally. The data can then be visualized with the sar command. Most tools, though, can fetch data via SNMP (Simple Network Management Protocol) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.
Aquest llibre tracta de Munin amb un cert detall (vegeu
Secció 12.4.1, «Configuració de Munin») com a part de
Capítol 12: «Administració avançada». Debian també proporciona una eina similar,
cacti. El seu desplegament és lleugerament més complex, ja que es basa únicament en SNMP. Tot i tenir una interfície web, agafar els conceptes implicats en la configuració encara requereix cert esforç. Llegir la documentació HTML (
/usr/share/doc/cacti/html/Table-of-Contents.html) s'ha de considerar un requisit previ.
14.3.3. Evitar les intrusions
Els atacants tracten d'obtenir accés als servidors mitjançant l'endevinació de les contrasenyes, és per això que sempre s'han d'utilitzar contrasenyes fortes. Fins i tot així, també haurien d'establir-se mesures contra els atacs de força bruta. Un atac de força bruta és un intent d'iniciar sessió en un sistema no autoritzat mitjançant la realització de múltiples intents d'inici de sessió en un període curt de temps.
La millor manera d'aturar un atac de força bruta és limitar el nombre d'intents d'entrada procedents del mateix origen, generalment prohibint temporalment una adreça IP.
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 està configurat a través d'un protocol simple per fail2ban-client, que també llegeix els fitxers de configuració i emet les ordres de configuració corresponents al servidor, fall2ban-server. Té quatre tipus de fitxers de configuració, tots emmagatzemats en /etc/fail2ban/:
fail2ban.conf and fail2ban.d/*.conf. Global configuration (such as logging).
filter.d/*.conf. Filtres que especifiquen com detectar errors d'autenticació. El paquet Debian ja conté filtres per a molts programes habituals.
action.d/*.conf. Accions que defineixen les ordres per prohibir o permetre les adreces IP.
jail.conf and jail.d/*.conf. It is where jails, the combinations of filters and actions, are defined.
Si es fa un cop d'ull a la configuració d'sshd a /etc/fail2ban/jail.conf es pot entendre millor com funciona Fail2Ban...
[...]
[DEFAULT]
[...]
bantime = 1h
[...]
findtime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.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 within 10 minutes, it will ban the IP address where those attempts originated for 1 hour.
The default backend used now is systemd. The old log files, like auth.log are only available if rsyslog has been installed and enabled.
Per activar, desactivar o configurar «jails» (“presons”), se suposa que el fitxer de configuració principal /etc/fail2ban/jail.conf no s'ha de modificar. En lloc d'això, se suposa que s'ha de fer a /etc/fail2ban/jail.d/defaults-debian.conf o en fitxers dins del mateix directori.
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 és una forma molt senzilla i eficaç de protegir-se contra els atacs de força bruta més comuns, però no pot protegir contra atacs de força bruta distribuïda, que és quan un atacant utilitza un gran nombre de màquines escampades per 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ó de canvis
Una vegada que el sistema està instal·lat i configurat, i exceptuant les actualitzacions de seguretat, no hi ha cap raó perquè la majoria dels fitxers i directoris evolucionin, tret de les dades. Per tant, és interessant assegurar-se que els arxius no canvien realment: d'aquesta manera valdria la pena investigar qualsevol canvi inesperat. Aquesta secció presenta algunes eines que poden usar per monitoritzar els fitxers i advertir a l'administrador quan es produeix un canvi inesperat (o simplement per llistar aquests canvis).
14.3.4.1. Auditar els paquets amb 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. The same is true for debsums.
En executar dpkg -V es verificaran tots els paquets instal·lats i s'imprimirà una línia per a cada fitxer que no passi el test. El format de sortida és el mateix que el de rpm -V on cada caràcter denota una prova en algunes metadades específiques. Malauradament dpkg no emmagatzema les metadades necessàries per a la majoria de les proves i per tant mostrarà interrogants en elles. Actualment només la prova de suma de verificació pot produir un "5" al tercer caràcter (quan falla).
# 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
En la mostra anterior, dpkg informa d'un canvi al fitxer de servei d'SSH que l'administrador va fer al fitxer empaquetat en lloc d'utilitzar el corresponent «override» o “reemplaçament” /etc/systemd/system/ssh.service.d/override.conf (que s'emmagatzemaria per sota de /etc com qualsevol canvi de configuració). També llista diversos fitxers de configuració (identificats per la lletra "c" en el segon camp) que havien estat modificats legítimament.
14.3.4.2. Auditoria de paquets: debsums i les seves limitacions
debsums és l'avantpassat de dpkg -V i per tant és majoritàriament obsolet. Pateix de les mateixes limitacions que el dpkg. Afortunadament, algunes de les limitacions es poden esquivar (mentre que dpkg no ofereix alternatives similars).
Com que les dades del disc no són confiables, debsums ofereix fer les seves comprovacions basades en fitxers .deb en lloc de confiar en la base de dades del dpkg. Per descarregar fitxers .deb de confiança per tots els paquets instal·lats, podem confiar en les descàrregues autenticades d'APT. Aquesta operació pot ser lenta i tediosa, i per tant no ha de considerar-se una tècnica proactiva per ser utilitzada de manera regular.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Tingueu en compte que aquest exemple utilitza l'ordre grep-status del paquet dctrl-tools, que no està instal·lat per defecte.
debsums es pot executar periòdicament com una tasca cron CRON_CHECK a /etc/default/debsums. Per ignorar certs fitxers fora del directori /etc que es puguin haver alterat expressament o que s'espera que canviïn (com /usr/share/misc/pci.ids) es poden afegir a /etc/debsums-ignore.
14.3.4.3. Monitorització de fitxers: AIDE
L'eina AIDE («Advanced Intrusion Detection Environment» o “entorn avançat de detecció d'intrusions”) permet comprovar la integritat de l'arxiu i detectar qualsevol canvi contra una imatge prèviament registrada del sistema vàlid. Aquesta imatge s'emmagatzema com a base de dades (/var/lib/aide/aide.db) que conté la informació rellevant sobre tots els fitxers del sistema (empremtes, permisos, marques temporals, etc.). Aquesta base de dades s'inicia per primera vegada amb aideinit; després s'utilitza diàriament (per l'script /etc/cron.daily/aide) per comprovar que res rellevant no ha canviat. Quan es detecten canvis, l'AIDE els registra en els arxius de registre (/var/log/aide/*.log) i envia els seus descobriments a l'administrador per correu electrònic.
Moltes opcions a /etc/default/aide es poden utilitzar per ajustar el comportament del paquet aide. La configuració adequada de l'AIDE s'emmagatzema a /etc/aide/aide.conf i /etc/aide/aide.conf.d/ (realment, aquests fitxers només s'utilitzen per update-aide.conf per generar /var/lib/aide/aide.conf.autogenerated). La configuració indica quines propietats dels fitxers s'han de comprovar. Per exemple, el contingut dels arxius de registre canvia de manera rutinària, així aquests canvis es poden ignorar sempre que els permisos d'aquests fitxers romanguin iguals, però tant el contingut com els permisos dels programes executables han de ser constants. Encara que no és molt complexa, la sintaxi de configuració no és completament intuïtiva, i per tant es recomana llegir la pàgina del manual aide.conf(5).
Una nova versió de la base de dades es genera diàriament a /var/lib/aide/aide.db.new; si tots els canvis registrats fossin legítims, es pot utilitzar per reemplaçar la base de dades de referència.
14.3.5. Detecció d'intrusions (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. The tool can be considered the successor of
snort, which has been removed from Debian.
La configuració de suricata implica revisar i editar /etc/suricata/suricata.yaml, que és molt llarg perquè cada paràmetre està molt comentat. Una configuració mínima requereix descriure l'interval d'adreces que cobreix la xarxa local (paràmetreHOME_NET). A la pràctica, això significa el conjunt de tots els possibles objectius d'atac. Però per treur'n tot el profit requereix llegir-lo íntegrament i adaptar-lo a la situació local.
On top of this, you should also edit to 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).
Per detectar un comportament maliciós, suricata necessita un conjunt de regles de seguiment: es poden trobar aquestes regles al paquet snort-rules-default. snort és la referència històrica a l'ecosistema IDS i suricata és capaç de reutilitzar les regles escrites per a ell.
Alternativament, oinkmaster (al paquet del mateix nom) es pot utilitzar per descarregar conjunts de regles Snort de fonts externes.
Unfortunately, the mentioned packages are not part of the current Debian
Bookworm release. But they can still be retrieved via the Debian package search or from the Debian snapshot archive.
