Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes
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.
The list of monitored files is stored in /etc/logcheck/logcheck.logfiles
; the default values work fine if the /etc/rsyslog.conf
file has not been completely overhauled.
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 r permette il renice di un processo, cioè la variazione della sua priorità.
Quando il sistema sembra essere sovraccarico, top
è uno strumento fondamentale per capire quali processi competono per il tempo di 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 la 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.
The gnome-system-monitor
graphical tool is similar to top
and it provides roughly the same features.
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/index.html
) should be considered a prerequisite.
14.3.3. 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 fare in modo che i file realmente non possano cambiare: ogni variazione inattesa dovrebbe perciò catturare la nostra attenzione. 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 elencarli).
14.3.3.1. Auditing Packages with 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.
Running dpkg -V
will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V
where each character denotes a test on some specific meta-data. Unfortunately dpkg
does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).
#
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
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.3.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 work-arounds).
Since the data on the disk cannot be trusted, debsums
offers to do its checks based on .deb
files instead of relying on dpkg's database. To download trusted .deb
files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.
#
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.
14.3.3.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.4. Rilevare intrusioni (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.
Configuring suricata involves reviewing and editing /etc/suricata/suricata-debian.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 /etc/default/suricata
to define the network interface to monitor and to enable the init script (by setting RUN=yes
). 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).
To detect bad behaviour, 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. Unfortunately that package is missing from Debian Jessie and should be retrieved from another Debian release like Testing or Unstable.
Alternatively, oinkmaster
(in the package of the same name) can be used to download Snort rulesets from external sources.