Messa a punto di Veriexec
Da Wiki di NetBSD Italia.
Questo breve articolo introduce i concetti basilari del sottosistema di integritàdei file Veriexec, proponendo una rapida procedura per la messa a punto del kernel con una configurazione, in userland, di base.
Indice |
Introduzione
Veriexec è il sottosistema per l'integritàdei file di NetBSD. La sua implementazione totalmente a livello kernel, rilasciata col sistema di base a partire dalla versione 2.0 di NetBSD, consente di mantenere l'integrit/à dei dati anche in caso di corruzione del filesystem radice (root). Il meccanismo di verifica è basato sugli algoritmi unilaterali più diffusi (altri potrebbero essere inseriti in futuro) come MD5, SHA512, RMD160, etc., i quali vengono utilizzati per verificare che i file appartenenti ad un determinato insieme specificato dall'utente siano stati effettivamente modificati. In questo caso il sistema reagisce in base a dei criteri ben precisi specificati in fase di configurazione garantendo un livello di sicurezza elevato (non assoluto) in caso di compromissione del sistema.
Installazione
Il sottosistema Veriexec è abilitato di default sul kernel GENERIC di NetBSD. In caso in cui si utilizzi un kernel personalizzato sar/à sufficiente includere il supporto (qualora non sia giàpresente) decommentando la seguente riga:
pseudo-device Veriexec
A questo punto abilitare gli algoritmi di hash che si desiderano utilizzare:
options VERIFIED_EXEC_FP_MD5 options VERIFIED_EXEC_FP_SHA1 options VERIFIED_EXEC_FP_RMD160 options VERIFIED_EXEC_FP_SHA512 options VERIFIED_EXEC_FP_SHA384 options VERIFIED_EXEC_FP_SHA256
Quindi ricompilare e reinstallare il kernel. Per maggiori dettagli inerenti a questa procedura consultare l'articolo relativo alla compilazione del kernel.
Configurazione
La fasi più importanti del processo di configurazione sono fondamentalmente due: la scrittura del file di configurazione e la scelta delle modalitàdi restrizione. Questo capitolo tratter/à entrambe nella maniera più efficace possibile.
Signatures
Questa fase si basa su un unico file, /etc/signatures, che mantiene la lista dei file da controllare con i relativi hash e le varie impostazioni. Ogni elemento vàspecificato secondo una sintassi ben precisa nella forma seguente:
nome_file algoritmo fingerprint lista_flag
dove nome_file corrisponde al percorso assoluto del file che si desidera monitorare, algoritmo rappresenta uno degli algoritmi supportati ed esplicitamente abilitati nel kernel, fingerprint è la chiave unilaterale generata dal programma di hash relativo all'algoritmo in questione e lista_flag è un elenco di valori che determinano le caratteristiche del file (vedi sotto). Per generare il fingerprint è sufficiente utilizzare il comando cksum(1) come segue:
$ cksum -a algoritmo
dove naturalmente il valore di algoritmo è identico a quello di cui sopra. Ad esempio, l'hash md5 del file /etc/sysctl.conf può essere ottenuto con il seguente comando:
$ cksum -a md5 /etc/sysctl.conf
Per quanto riguarda la lista delle flag, qualsiasi combinazione delle seguenti direttive, separate da una virgola, può essere utilizzata:
| Direttiva | Descrizione |
|---|---|
| DIRECT | il file è eseguito in maniera diretta |
| INDIRECT | il file è eseguito in maniera indiretta (ad esempio all'interno di uno script o come shebang di quest'ultimo |
| FILE | il file è da considerarsi non eseguibile |
Inoltre, al fine di rendere più semplice e comprensibile la creazione del file signatures, i seguenti alias sono forniti:
| Alias | Espansione |
|---|---|
| PROGRAM | DIRECT |
| INTERPRETER | INDIRECT |
| SCRIPT | DIRECT, FILE |
| LIBRARY | FILE |
Un esempio di file signatures è il seguente:
/etc/daily.conf MD5 344c7c940814e4d5e62f9d482c5c1a48 FILE /usr/pkg/sbin/radiusd SHA1 59ca6d4e1774fe8f7495f5326253cd419c777420 PROGRAM /etc/rc RMD160 35d5b4497cd1bdd33064cc83978fbd73f6cfb2b0 SCRIPT
Livelli di rigore
A seconda del tipo di necessitàpuò essere molto utile se non indispesabile aumentare o diminuire il livello di rigore del sottosistema Veriexec attivando, a seconda dei casi, determinati meccanismi di protezione. Questi ultimi sono rappresentati da 4 livelli (da 0 a 3) detti scrict levels i quali possono essere schematizzati come segue:
| Indice | Nome modalit/à | Descrizione |
|---|---|---|
| 0 | learning | principalmente fornito per la messa a punto delle signatures in quanto il sottosistema agisce in modalitàpassiva limitandosi, in caso di eventuali anomalie, ad inviare semplici notifiche. Questo è l'unico livello in cui è permesso caricare nuove voci nel kernel. |
| 1 | IDS | previene l'accesso ai file il cui fingerprint non corrisponde a quello specificato nella relativa voce delle signatures |
| 2 | IPS | previene la scrittura e la rimozione dei file monitorati e rafforza i metodi d'accesso a questi ultimi secondo quanto specificato dalle relative signatures |
| 3 | lockdown | previene la creazione di nuovi file e l'accesso a tutti i file non monitorati da Veriexec |
Le caratteristiche di un livello sono ereditate per intero dai livelli di grado superiore. Ad esempio il livello IPS previene l'accesso ai file esattamente come il livello IDS, in più aggiunge ulteriori funzioni di protezione, e così via per i livelli successivi.
Il livello può essere cambiato con l'ausilio di sysctl(8) assegnando alla variabile kern.Veriexec.strict l'intero relativo all'indice come riportato nella tabella di cui sopra. Un esempio che mostra come impostare il livello 1 (IDS) è il seguente:
# sysctl -w kern.veriexec.strict=1
E' consigliato cominciare utilizzando i livelli 0 e 1 per assicurarsi che le signatures siano realmente funzionanti e solo dopo provvedere eventualmente ad incrementare il livello di rigore. Inoltre per ottenere più informazioni si suggerisce di abilitare l'output dettagliato attraverso la variabile kern.veriexec.verbose, come segue:
# sysctl -w kern.veriexec.verbose=1
Questa impostazione è utilizzata molto comunemente in modalitàIDS.
Verifica
La seguente procedura di verifica suppone che tutti i passi di configurazione descritti in questo articolo siano stati effettuati.
Creazione dispositivo
Innanzi tutto prima di effettuare qualsiasi operazione è necessario accertarsi che il file di dispositivo /dev/veriexec sia presente. In caso contrario, al fine di evitare errori durante l'avvio del sottosistema, come il seguente:
Loading fingerprints...veriexecctl: Cannot open `/dev/veriexec': No such file or directory
provvedere a creare il file di dispositivo in questo modo:
# cd /dev # ./MAKEDEV veriexec
A questo punto passare alla fase di verifica.
Prova di controllo
Di seguito saranno mostrate semplicemente le reazioni del sottosistema Veriexec al verificarsi di determinate condizioni senza scendere in dettagli relativi all'accesso ai file o al blocco di questi ultimi. La verifica si svolge come segue:
- Si crea un file di prova vetest all'interno della directory /tmp di cui si genera l'hash MD5 da inserire successivamente nel file /etc/signatures assieme al resto delle informazioni necessarie
$ :> /tmp/vetest $ cksum -a md5 /tmp/vetest MD5 (/tmp/vetest) = d41d8cd98f00b204e9800998ecf8427e # echo "/tmp/vetest md5 d41d8cd98f00b204e9800998ecf8427e FILE" > /etc/signatures
- Si avvia il sottosistema Veriexec il quale si preoccuperàdi inizializzare le variabili di configurazione del kernel secondo quanto specificato nel file /etc/sysctl.conf o utilizzando un valore nullo nel caso queste non siano state impostate. Il valore '0' per kern.veriexec.strict fa in modo che Veriexec agisca passivamente generando solo una notifica di sistema
# /etc/rc.d/veriexec forcestart Loading fingerprints... done. kern.veriexec.strict: 0 -> 0 kern.veriexec.verbose: 0 -> 0
- A questo punto è sufficiente tenere sotto controllo il registro degli eventi di sitsema /var/log/messages sul quale verrànotificato l'accesso in scrittura al file monitorato da Veriexec
$ tail -0f /var/log/messages & [1] 948
- Sullo stesso terminale su cui è stato mandato in background tail(1) eseguire il comando di scrittura al fine di ottenere tempestivamente il messaggio di notifica scritto sul registro degli eventi da parte del sottosistema Veriexec
$ :> /tmp/vetest Feb 7 00:05:24 testbox /netbsd: Veriexec: Write access request. [/tmp/vetest, pid=101, uid=0, gid=0]
In questo cose testbox è un nome fittizio. In un caso reale il suo valore corrisponderebbe a quello dell'output del comando:
$ hostname -s
Altri tipi di accesso al file come la rimozione o lo spostamento avrebbero causato messaggi analoghi. Così facendo ci si può rendere subito conto della potenza di questo meccanismo verificandone al contempo il corretto funzionamento. Adesso si può automatizzare l'avvio del sottosistema con la relativa configurazione.
Gestione
Una volta certi che il sistema funzioni correttamente è possibile fare in modo che tutte le operazioni di configurazione e avvio avvengano in automatico.
- Attivare il servizio
La prima cosa da fare è la stessa per tutti i servizi, ovvero attivarlo abilitando la relativa voce nel file /etc/rc.conf in questo modo:
# grep -c veriexec /etc/rc.conf || echo "veriexec=YES" >> /etc/rc.conf
Qualora la stringa veriexec fosse giàpresente all'interno del file basteràlimitarsi a cambiare eventualmente il suo valore in YES.
- Impostare i livelli
Prima di avviare il servizio può essere utile impostare i livelli di configurazione descritti nel capitolo precedente inserendo le relative opzioni all'interno del file /etc/sysctl.conf. Rispecchiando la configurazione di cui sopra un esempio potrebbe essere il seguente:
# echo -e "kern.veriexec.strict=1\nkern.veriexec.verbose=1" >> /etc/sysctl.conf
Nel caso in cui si desidera utilizzare dei valori nulli per entrambe le variabili si potràfare a meno di eseguire questo passo.
- Avviare il servizio
A questo punto si può avviare il sottosistema Veriexec (che verràin ogni caso avviato automaticamente all'avvio del sistema) eseguendo il comando:
# /etc/rc.d/veriexec start
Per ulteriori dettagli sull'avvio, l'arresto e la gestione in generale dei servizi di sistema e degli script correlati consultare la pagina di manuale rc.d(8).
Conclusioni
In questo documento si è trattato il sottosistema Veriexec cercando di incrementare la sicurezza del proprio sistema NetBSD. Molti altri meccanismi esistenti dovrebbero essere tenuti in considerazione al fine di ottenere un sistema realmente sicuro ed affidabile. Il meccanismo di verifica qui descritto vàcollocato all'interno di un quadro ben preciso di politiche per l'integritàdel sistema e la salvaguardia dei dati, per tanto è consigliabile utilizzarlo assieme ad altri software di analoga potenza.
Approfondimenti
Per saperne di più sul sottosistema Veriexec sia per quanto riguarda la configurazione che il funzionamento, è consigliato cominciare con la lettura del capitolo 19 della guida ufficiale di NetBSD assieme all relativa pagina di manuale. Per conoscere i dettagli progettuali e andare a fondo con lo studio dell'implementazione consultare la pagina inerente al sottosistema in-kernel e il relativo codice sorgente.
