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; i valori predefiniti funzionano bene se il file /etc/rsyslog.conf non è stato completamente stravolto.
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à.
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 è 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 più o meno le stesse caratteristiche.
Il carico del processore, il traffico di rete e lo spazio libero su disco sono informazioni che variano costantemente. Mantenere uno storico della loro evoluzione spesso è utile nel determinare esattamente come viene utilizzato un computer.
Esistono molti strumenti dedicati a questo compito. La maggior parte può recuperare dati via SNMP (Simple Network Management Protocol) al fine di centralizzare l'informazione. 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.
This book deals with Munin in some detail (see
Sezione 12.4.1, «Impostazione di Munin») as part of
Capitolo 12: «Amministrazione avanzata». 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 into an unauthorized software system by performing multiple login attempts in a short period of time.
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. 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
[...]
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 10 minutes.
To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.
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. Rilevare le modifiche
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. 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 hacker), ma questo dovrebbe essere preso con le pinze. Per fare il proprio lavoro si basa su checksum memorizzati sul proprio database dpkg sull'hard disk (posso essere trovati in /var/lib/dpkg/info/package.md5sums); un hacker scrupoloso aggiornerà quindi questi file in modo da contenere i nuovi checksum per i file modificati.
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?????? /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.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. Controllo dei pacchetti: debsums e i suoi limiti
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).
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 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. 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 (in the Debian package of the same name) is an 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.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 it to define the network interface. 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).
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.
Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.
