14.3. Supervisione: prevenire, rilevare, dissuadere
Il monitoraggio è parte integrante di ogni politica di sicurezza per svariati motivi. Tra questi, il fatto che l'obiettivo della sicurezza non è solitamente limitato soltanto alla garanzia della riservatezza dei dati, ma include anche l'assicurazione alla disponibilità dei servizi. È quindi obbligatorio verificare che tutto funzioni come previsto, e rilevare in maniera tempestiva ogni comportamento anomalo o variazione nella qualità dei(l) servizi(o) erogati(o). L'attività di monitoraggio permette di evidenziare tentativi di intrusione e permette di reagire rapidamente prima che si possa arrivare a gravi conseguenze. Questa sezione passa in rassegna alcuni strumenti che possono essere usati per monitorare molti degli aspetti di un sistema Debian. Come tale, completa
Sezione 12.4, «Monitoraggio».
14.3.1. Monitorare i log con logcheck
Il comando logcheck monitora i file di log ogni ora per impostazione predefinita. Invia messaggi di log inconsueti via email all'amministratore per analisi più approfondite.
La lista dei file monitorati è salvata in /etc/logcheck/logcheck.logfiles e /etc/logcheck/logcheck.logfiles.d/;i valori predefiniti funzionano bene con systemd e rsyslog se i loro file di configurazione non sono stati modificati.
logcheck lavora in uno di tre modi più o meno dettagliati: paranoid, server e workstation. Il primo è molto prolisso, e dovrebbe essere usato solo per server specifici come i firewall. Il secondo modo (predefinito) è consigliato per la maggior parte dei server. L'ultimo è progettato per le workstation, ed è ancora più conciso (filtra maggiormente i messaggi).
In tutti e tre i casi, logcheck probabilmente dovrà essere personalizzato escludendo alcuni messaggi extra (a seconda dei servizi installati), a meno che l'amministratore non voglia veramente ricevere ammassi orari di lunghe e noiose email. Poiché il meccanismo di selezione dei messaggi è piuttosto complesso, il file /usr/share/doc/logcheck-database/README.logcheck-database.gz è una lettura consigliata, anche se impegnativa.
Le regole applicate possono essere suddivise in varie tipologie:
quelle che qualificano il messaggio come un tentativo di intrusione (memorizzato in un file nella directory /etc/logcheck/cracking.d/);
quelle che cancellano tale qualifica (/etc/logcheck/cracking.ignore.d/);
quelle che classificano il messaggio come un allarme di sicurezza (/etc/logcheck/violations.d/);
quelle che cancellano questa classificazione (/etc/logcheck/violations.ignore.d/);
infine, quelle che si applicano ai rimanenti messaggi (considerati come eventi di sistema).
Un evento di sistema è sempre segnalato a meno che una regola in una directory /etc/logcheck/ignore.d.{paranoid,server,workstation}/ stabilisca che l'evento debba essere ignorato. Le sole directory prese in considerazione sono esclusivamente quelle corrispondenti ad un livello di prolissità maggiore o uguale alla modalità di funzionamento selezionata.
14.3.2. Attività di monitoraggio
top è uno strumento interattivo che mostra l'elenco dei processi attualmente in esecuzione. L'ordinamento predefinito è basato sull'utilizzo corrente del processore e può essere ottenuto con il tasto P. Altri tipi di ordinamento sono per occupazione di memoria (tasto M), per tempo totale di processore (tasto T) e per identificatore di processo (tasto N). Il tasto k permette di terminare un processo inserendo il suo identificatore di processo. Il tasto r permette il renice di un processo, cioè la variazione della sua priorità.
Quando il sistema sembra essere sovraccarico, top è un ottimo strumento per individuare i processi richiedono il tempo del processore o consumano troppa memoria. In particolare, spesso è interessante controllare se il processo che utilizza le risorse corrisponde realmente ad un servizio che la macchina mette a disposizione. Un processo sconosciuto in esecuzione con utente www-data dovrebbe subito saltare all'occhio ed essere controllato, dato che potenzialmente potrebbe essere l'istanza di un programma installato ed eseguito nel sistema attraverso una vulnerabilità di un'applicazione web.
top è uno strumento molto flessibile e le pagine del manuale riportano i dettagli di come modificarne la visualizzazione e adattarla alle abitudini e bisogni personali.
Lo strumento grafico gnome-system-monitor è simile a top e fornisce grossomodo le stesse caratteristiche. Le alternative sono atop e htop, che forniscono funzionalità simili ma che differiscono nelle caratteristiche di usabilità, come la capacità di scorrimento.
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.
Esistono molti strumenti dedicati a questo compito. Il pacchetto sysstat, ad esempio, raccoglie e visualizza localmente statistiche sulle prestazioni del sistema. I dati possono quindi essere visualizzati con il comando sar. La maggior parte degli strumenti, tuttavia, possono recuperare i dati tramite SNMP (Simple Network Management Protocol) al fine di centralizzare le informazioni. Un ulteriore beneficio è che si possono recuperare dati da elementi di rete che non necessariamente sono computer generici, come ad esempio switch di rete o router dedicati.
Questo libro tratta Munin in dettaglio (vedere
Sezione 12.4.1, «Impostazione di Munin») come parte di
Capitolo 12: «Amministrazione avanzata». Debian fornisce anche un altro strumento simile,
cacti. La sua installazione è leggermente più complessa, poiché si basa solo su SNMP. Pur disponendo di un'interfaccia web, capire i concetti coinvolti nella configurazione richiede qualche sforzo. La lettura della documentazione HTML (
/usr/share/doc/cacti/html/Table-of-Contents.html) dovrebbe essere considerata un prerequisito.
14.3.3. Evitare intrusioni
Gli attaccanti tentano di aver accesso ai server cercando di individuare le password, questo è il motivo per il quale devono essere sempre usate password robuste. Anche in questo caso bisogna stabilire misure contro attacchi di forza bruta. Un attacco di forza bruta è un tentativo di accedere ad un sistema software senza autorizzazione tramite l'effettuazione di tentativi di accesso ripetuti in un breve periodo di tempo.
Il miglior modo per fermare un attacco di forza bruta è quello di limitare il numero di tentativi di accesso a partire dalla stessa origine, normalmente bandendo temporaneamente un indirizzo 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 è configurato attraverso un semplice protocollo da fail2ban-client, che legge anche file di configurazione e invia i comandi di configurazione corrispondenti al server fail2ban-server. Ha quattro tipi di file di configurazione, tutti presenti in /etc/fail2ban/:
fail2ban.conf and fail2ban.d/*.conf. Global configuration (such as logging).
filter.d/*.conf. Filtri che specificano come individuare le autenticazioni fallite. Il pacchetto Debian già contiene i filtri per molti programmi comuni.
action.d/*.conf. Azioni che definiscono i comandi per bandire e "riabilitare" gli indirizzi IP.
jail.conf e jail.d/*.conf. È dove le jails e la combinazione di filtri ed azioni, sono definite.
Diamo un'occhiata alla configurazione di sshd in /etc/fail2ban/jail.conf per meglio comprendere come funziona 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.
Il backend utilizzato di default ora è systemd. I vecchi file di log, come auth.log sono disponibili solo se rsyslog è stato installato e abilitato.
Per abilitare, disabilitare o configurare "jails" (prigioni) non è previsto che venga modificato il file di configurazione principale /etc/fail2ban/jail.conf. Invece queste azioni si dovrebbero effettuare in /etc/fail2ban/jail.d/defaults-debian.conf o in file contenuti nella stessa directory.
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 è una modalità veramente semplice ed efficace per proteggersi contro gli attacchi a forza bruta più comuni, ma non può proteggere contro attacchi a forza bruta distribuiti, ovvero quando un utente malintenzionato utilizza un gran numero di macchine sparse su 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. Rilevare le modifiche
Una volta che il sistema è installato e configurato, a meno di aggiornamenti di sicurezza, la maggior parte dei file e directory rimangono statici, dati a parte. È allora interessante assicurarsi che i file in realtà non cambino: vale la pena di investigare ogni variazione inattesa. Questa sezione presenta alcuni strumenti che permettono di monitorare i file e di avvisare l'amministratore quando si verificano cambiamenti non previsti (o semplicemente di elencare tali modifiche).
14.3.4.1. Revisione dei Pacchetti con dpkg --verify
dpkg --verify (o dpkg -V) è un'interessante strumento che permette di trovare i file installati che sono stati modificati (potenzialmente da un attaccante), ma questo dovrebbe essere preso con le pinze. Per fare il proprio lavoro si basa su checksum memorizzati nel proprio natabase dpkg sull'hard disk (si trovano in /var/lib/dpkg/info/package.md5sums); un attaccante scrupoloso aggiornerà quindi questi file in modo da contenere i nuovi checksum per i file modificati. Lo stesso vale per debsums.
L'esecuzione di dpkg -V verificherà tutti i pacchetti installati e stamperà una riga per ogni file con test fallito. Il formato è uguale a quello di rpm -V dove ogni carattere indica un test su alcuni meta-dati specifici. Purtroppo dpkg non memorizza i meta-dati necessari per la maggior parte dei test e quindi questi saranno contrassegnati con un punto interrogativo. Attualmente solo il test di checksum può produrre un "5" sul terzo carattere (quando fallisce).
# 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
Nell'esempio sopra, dpkg riporta una modifica al file del servizio SSH che l'amministratore ha fatto al file del pacchetto invece di usare un appropriato file override /etc/systemd/system/ssh.service.d/override.conf (che verrebbe memorizzato sotto /etc come qualsiasi modifica di configurazione dovrebbe essere fatta). Elenca anche più file di configurazione (identificati dalla lettera "c" sul secondo campo) che sono stati legittimamente modificati.
14.3.4.2. Controllo dei pacchetti: debsums e i suoi limiti
debsums è l'antenato di dpkg -V ed è quindi in gran parte obsoleto. Ha gli stessi limiti di dpkg. Fortunatamente, alcune delle limitazioni possono essere aggirate (mentre dpkg non offre questa possibilità).
Dal momento che i dati su disco non possono essere sicuri, debsums offre la possibilità di fare i controlli sulla base dei file .deb anzichè affidarsi al database di dpkg. Per scaricare i file .deb fidati di tutti i pacchetti installati, possiamo contare solo sui download autenticati di APT. Questa operazione può essere lenta e noiosa, e quindi non dovrebbe essere considerata una tecnica proattiva da utilizzare in modo abituale.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Da notare che questo esempio utilizza il comando grep-status del pacchetto dctrl-tools, che non è installato in modo predefinito.
debsums può essere eseguito frequentemente come impostazione di un cronjob CRON_CHECK in /etc/default/debsums. Per ignorare alcuni file esterni alla directory /etc, che sono stati modificati intenzionalmente o che sappiamo verranno modificati (come /usr/share/misc/pci.ids) è possibile aggiungerli nel file /etc/debsums-ignore.
14.3.4.3. Monitorare i file: AIDE
Lo strumento AIDE (Advanced Intrusion Detection Environment) permette di verificare l'integrità dei file e rileva tutti i cambiamenti rispetto ad una immagine valida archiviata del sistema. Questa immagine viene memorizzata in un database (/var/lib/aide/aide.db) contenente le informazioni significative di tutti i file del sistema (impronte digitali, permessi, data e ora e così via). Questo database viene generato inizialmente con aideinit; esso viene poi utilizzato su base giornaliera (dallo script /etc/cron.daily/aide) per verificare che non sia cambiato nulla di significativo. Quando viene rilevata una modifica, AIDE la elenca nei file di log (/var/log/aide/*.log) e invia i risultati via email all'amministratore.
Sono presenti molte opzioni in /etc/default/aide per modificare il comportamento del pacchetto aide. La configurazione vera e propria di AIDE viene memorizzata in /etc/aide/aide.conf e /etc/aide/aide.conf.d/ (in realtà, questi file vengono utilizzati da update-aide.conf per generare /var/lib/aide/aide.conf.autogenerated). La configurazione indica quali proprietà di quali file devono essere controllate. Per esempio, il contenuto dei file di log cambia regolarmente, e tali cambiamenti possono essere ignorati fino a quando i permessi di questi file rimangono invariati, ma sia il contenuto che i permessi dei programmi eseguibili devono rimanere costanti. Anche se non molto complessa, la sintassi della configurazione non è del tutto intuitiva, ed è quindi consigliato leggere la pagina di manuale aide.conf(5).
Una nuova versione del database è generata giornalmente in /var/lib/aide/aide.db.new; se tutte le variazioni raccolte sono legittime, viene usato per sostituire il database di riferimento.
14.3.5. Rilevare intrusioni (IDS/NIDS)
suricata (nel pacchetto Debian con lo stesso nome) è un NIDS — un
Network Intrusion Detection System (Sistema di Intercettazione delle Intrusioni di Rete). La sua funzione è quella di mettersi in ascolto sulla rete e cercare di rilevare tentativi di infiltrazione e/o atti ostili (inclusi attacchi denial of service). Tutti questi eventi vengono raccolti in file multipli in
/var/log/suricata. Ci sono strumenti di terze parti (Kibana/logstash) per consultare al meglio i dati raccolti. Questo strumento può essere considerato il successore di
snort, che è stato rimosso da Debian.
La configurazione di suricata implica la revisione e la modifica di /etc/suricata/suricata.yaml, che è molto lunga poiché ogni parametro è abbondantemente commentato. Una configurazione minima richiede che venga descritto l'intervallo di indirizzi coperti dalla rete locale (parametro HOME_NET). In pratica, questo significa l'insieme di tutti i potenziali obiettivi d'attacco. Ma per sfruttarlo al meglio è richiesto leggerlo completamente e adattarlo alla situazione locale.
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).
Per rilevare un comportamento malevolo, suricata ha bisogno di un insieme di regole di monitoraggio: è possibile trovare le regole nel pacchetto snort-rules-default. snort è il riferimento storico nell'ecosistema IDS e suricata è in grado di riutilizzare le regole scritte per esso.
In alternativa, può essere usato oinkmaster (nel pacchetto omonimo) per scaricare di set di regole di Snort da fonti esterne.
Purtroppo, i pacchetti menzionati non fanno parte dell'attuale rilascio di Debian
Bookworm. Tuttavia possono ancora essere recuperati tramite la ricerca dei pacchetti o dall'archivio snapshot Debian.
