Integrit: file verification system: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (verificata)
 
(10 versioni intermedie di 6 utenti non mostrate)
Riga 1: Riga 1:
''Torna all'indice: [[Linux Kernel in a Nutshell]]''
{{Versioni compatibili|Jessie|Stretch|Buster}}
== Introduzione ==
[http://integrit.sourceforge.net/ Integrit] è un "file verification system": è assimilabile alla famiglia degli [[Intrusion Detection System]] o '''IDS''' e ha la funzione di verificare che determinati file non subiscano modifiche.


__TOC__
Questi controlli sull'integrità dei file hanno molti vantaggi:
* non sono pesanti: infatti vengono eseguiti prevalentemente di notte e richiedono pochi minuti
* sono utili: un aggressore che vuole nascondere dei file, accessi o servizi potrebbe modificare file come <code>netstat</code>, <code>last</code>, <code>w</code>, <code>ls</code>...
* si affiancano a [[Intrusion Detection System|IDS]] di rete e software come [[rkhunter]]


Scaricare [da Internet, NdT], compilare, aggiornare e mantenere i sorgenti del kernel Linux comporta diversi passi, come questo libro illustra. Essendo per natura creature pigre, gli sviluppatori hanno creato alcuni programmi a supporto di queste attivit� di routine. Descriviamo alcuni di tali utili strumenti e le nozioni di base sul loro utilizzo.
Ovviamente non si tratta della soluzione di tutti i mali, in quanto potrebbe essere possibile che l'aggressore abbia modificato anche l'eseguibile di <code>integrit</code>, però un controllo in più non fa mai male!


Lo sviluppo del kernel Linux differisce per molti aspetti dal tradizionale processo di sviluppo software. A uno sviluppatore del kernel sono richieste alcune attivit� peculiari:
== Installazione ==
 
L'installazione è molto semplice, con [[privilegi di amministrazione]]:
* Applicare le modifiche ad un "bersaglio mobile" quale � il kernel, a causa della rapida pianificazione delle versioni di sviluppo.
* Risolvere i conflitti derivanti dalla fusione del proprio lavoro con quello dagli altri sviluppatori.
* Esportare i suoi cambiamenti in un formato che permetta agli altri sviluppatori di incorporarli facilmente nel proprio lavoro.
 
==patch e diff==
Questa sezione � basata su un articolo pubblicato originariamento su ''Linux Journal''.
 
Una delle modalit� pi� comuni per lavorare con il kernel � quella di usare i programmi ''patch'' e ''diff''. Per usare questi strumenti, sono necessarie due differenti directory: una "pulita" (clean) e una "di lavoro" (indicata con ''dirty'' in seguito). La directory clean contiene la versione originale del kernel, mentre quella dirty contiene le modifiche apportate dal programmatore alla stessa release.
Utilizzando ''patch'' e ''diff'' � possibile estrarre i cambiamenti apportati sul sorgente e portarli nella nuova release del kernel.
 
Per esempio, creiamo due directory contenenti l'ultima versione del kernel come descritto nel Capitolo 3.
 
<pre>
$ tar -zxf linux-2.6.19.tar.gz
$ mv linux-2.6.19 linux-2.6.19-dirty
$ tar -zxf linux-2.6.19.tar.gz
$ ls
linux-2.6.19/
linux-2.6.19-dirty/
</pre>
 
Ora � possibile apportare tutte le modifiche desiderate al sorgente presente nella directory dirty, lasciando inalterata quella clean. Dopo aver apportato le modifiche, si potr� creare una patch da inviare agli altri sviluppatori tramite i seguenti comandi:
 
<pre>
$ diff -Naur -X linux-2.6.19/Documentation/dontdiff linux-2.6.19/ \
linux-2.6.19-dirty/ > my_patch
</pre>
 
Questo comando creer� un file dal nome ''my_patch'' che conterr� tutti i cambiamenti apportati al sorgente del kernel rispetto alla versione pulita presente nella directory clean. Tale file potr� essere distribuito o inviato ad agli altri sviluppatori via email.
 
 
===Nuove versioni del kernel===
Al rilascio di una nuova versione del kernel, se si desidera portare i cambiamenti su questa nuova versione � necessario applicare la patch ad una versione ''pulita'' del kernel.
Questo pu� essere fatto seguendo questi passi:
* Creare la patch, come illustrato nell'esempio precedente.
* Utilizzare la patch ufficiale dal sito ''kernel.org'' e aggiornare la vecchia versione alla nuova release:
 
<pre>
$ cd linux-2.6.19
$ patch -p1 < ../patch-2.6.20
$ cd ..
$ mv linux-2.6.19 linux-2.6.20
</pre>
 
* Aggiornare la directory di lavoro rimuovendo la propria patch e, in seguito, applicando il nuovo aggiornamento:
<pre>
$ cd linux-2.6.19-dirty
$ patch -p1 -R < ../my_patch
$ patch -p1 < ../patch-2.6.20
$ cd ..
$ mv linux-2.4.19-dirty linux-2.6.20-dirty
</pre>
 
* Provare ad applicare la propria patch al nuovo aggiornamento:
<pre>
$ cd linux-2.6.20-dirty
$ patch -p1 < ../my_patch
</pre>
 
Se l'applicazione della patch provoca dei problemi, � necessario risolvere i conflitti creati (il comando ''patch'' informer� circa questi conflitti creando i file ''.rej'' e ''.orig'' per l'analisi e la correzioni da parte dello sviluppatore).
Questo processo di ''fusione'' (''merge'') pu� rappresentare la parte pi� difficile dell'intero processo se sono stati apportati cambiamenti a porzioni di codice che sono state modificate anche da altri.
 
Per applicare correttamente questo processo di sviluppo, consiglio vivamente di utilizzare l'eccellente insieme di programmi ''patchutils'' (reperibile qui: ''http://cyberelk.net/tim/patchutils''). Questi programmi permettono di manipolare le patch facilmente e hanno risparmiato agli sviluppatori molte ore di tedioso lavoro.
 
 
== Gestire le proprie patch con quilt ==
 
I programmi ''patch'' e ''diff'' risultano essere molto utili e funzionali per lo sviluppo del kernel. Ma dopo un certo periodo di utilizzo, molti si stancano di questo modo si procedere nello sviluppo e cercano altra strade che non coinvolgano le noiose attivit� di pacthing e merging. Fortunatamente, alcuni sviluppatori del kernel hanno realizzato un programma chiamato ''quilt'' che gestisce il processo di manipolazione delle patch in modo molto pi� semplice.
 
L'idea alla base di ''quilt'' discende da un insieme di script di Andrew Morton, realizzati originariamente per gestire il codice del sottosistema di gestione della memoria e, in seguito, utilizzati per l'intero kernel. I suoi script erano legati molto strettamente al processo di sviluppo, ma l'idea sottostante era molto potente.
Andreas Gruenbacher ha quindi ripreso questa idea creando ''quilt''.
 
L'idea principale sottostante ''quilt'' � di lavorare con una versione ''pulita'' del kernel alla quale aggiungere un insieme di patch. E&grave; possibile inserire e togliere diverse patch dal sorgente e mantenere una lista delle patch in modo molto semplice.
 
1. Per iniziare, creiamo una directory contenente il sorgente del kernel:
<pre>
$ tar -zxf linux-2.6.19.tar.gz
$ ls
linux-2.6.19/
</pre>
 
2. Spostiamoci in tale directory:
<pre>
$ cd linux-2.6.19
</pre>
 
3. Creiamo una directory ''patches'' che conterr� tutte le nostre patch:
<pre>
$ mkdir patches
</pre>
 
4. Tramite ''quilt'' creiamo una nuova patch chiamata ''patch1'':
<pre>
<pre>
$ quilt new patch1
# apt install integrit
Patch patches/patch1 is now on top
</pre>
</pre>


5. ''quilt'' necessita di sapere quali file saranno modificati da questa patch. Per fare questo, utilizziamo il comando ''add'':
== Configurazione ==
<pre>
I file di configurazione si trovano in <code>/etc/integrit</code>. Dopo l'installazione sono presenti i seguenti file:
$ quilt add Makefile
; <code>integrit.conf</code> : un template di file di configurazione (infatti è tutto commentato, e quindi <code>integrit</code> '''non''' effettuerà alcuna azione se non configurato!), lo utilizzeremo in seguito come punto di partenza;
File Makefile added to patch patches/patch1
; <code>integrit.debian.conf</code> : il file di configurazione utilizzato dal [[cron]] di Debian.
</pre>


6. Apriamo il file ''Makefile'' e modifichiamo la linea EXTRAVERSION, salvando poi il file. Alla fine, aggiorniamo la patch tramite ''quilt'':
=== Integrit ===
Il file di configurazione di integrit è semplice ed è composto dalle seguenti sezioni (inizialmente commentate):
; root : la directory di partenza (normalmente <code>/</code>)
; know : il [[path]] per il database contenente lo stato ''conosciuto'' del sistema (default <code>/var/lib/integrit/known.cdb</code>)
; current : il path del database usato per effettuare il confronto tra lo stato ''conosciuto'' e quello ''attuale'' (default <code>/var/lib/integrit/current.cdb</code>)


<pre>
seguito da un elenco di file da ignorare.
$ quilt refresh
Refreshed patch patches/patch1
</pre>


Il file ''patches/patch1'' conterr� una patch con tutti i cambiamenti appena fatti:
La sintassi dell'elenco è la seguente:
<pre>
<pre>
$ cat patches/patch1
[action]/directory [controlli]
Index: linux-2.6.19/Makefile
===================================================================
--- linux-2.6.19.orig/Makefile
+++ linux-2.6.19/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 19
-EXTRAVERSION =
+EXTRAVERSION = -dirty
NAME=Crazed Snow-Weasel
# *DOCUMENTATION*
</pre>
</pre>


Ora � possibile continuare a lavorare su una patch, o crearne una nuova in testa a quella attuale.
dove:
Ad esempio, se sono state create tre diverse patch ''patch1'', ''patch2'' e ''patch3'', esse saranno applicate una sopra l'altra.
; action : è facoltativa, e rappresenta l'azione da eseguire. L'azione di default è di esplorare la directory e tutto il suo contenuto. Le alternative sono:
Per vedere la lista delle patch attualmente applicate:
: <code>!</code> : l'operatore di negazione: <code>!/etc</code> indica di non controllare il contenuto della directory <code>/etc</code>;
<pre>
: <code>=</code> : indica di non esplorare ricorsivamente il contenuto della directory;
$ quilt series -v
: <code>$</code> : permette di creare una regola che non va ad agire sulle sottodirectory ma solo sulla directory (ed i file contenuti) indicata
+ patches/patch1
; /directory : indica il percorso su cui agire;
+ patches/patch2
; [controlli] : permette di specificare i controlli da eseguire;
= patches/patch3
: <code>s</code> : [[checksum]];
</pre>
: <code>i</code> : [[inode]];
: <code>p</code> : [[Filesystem: i permessi sui files|permessi]];
: <code>l</code> : numero di [[link]];
: <code>u</code> : [[UID]];
: <code>g</code> : [[GID]];
: <code>z</code> : la dimensione dei file (risulta essere un controllo ridondante se viene effettuato anche il controllo del checksum);
: <code>a</code> : la data di accesso;
: <code>m</code> : la data di modifica;
: <code>r</code> : reimposta la data di accesso (utilizzare con attenzione)
: le opzioni possono essere scritte in due modi: in minuscolo, il che indica che il controllo deve essere fatto, oppure in maiuscolo, per indicare che il controllo non deve essere effettuato.


Il risultato del comando mostra che tutte e tre le patch sono state applicate e che quella corrente � la ''patch3''.
È necessario decommentare le opzioni principali del file, personalizzandole se necessario, e aggiungere le altre azioni desiderate, per poter eseguire il comando. '''Non''' c'è infatti un'impostazione di default!
Al rilascio di una nuova versione del kernel, se si vuole portare i cambiamenti effettuati sulla versione precedente anche sulla nuova versione, � possibile utilizzare ''quilt'' secondo i seguenti passi:


1. Togliere le patch attualmente applicate al sorgente
=== Debian ===
<pre>
Il file di configurazione <code>/etc/integrit/integrit.debian.conf</code> viene utilizzato dal cron presente in <code>/etc/cron.daily/integrit</code>.
$ quilt pop -a
Removing patch patches/patch3
Restoring drivers/usb/Makefile
Removing patch patches/patch2
Restoring drivers/Makefile
Removing patch patches/patch1
Restoring Makefile
No patches applied
</pre>


2. Utilizzando la patch ufficiale da ''kernel.org'' aggiornare la vecchia versione del kernel:
Il file di configurazione è composto da quattro variabili:
<pre>
; <code>CONFIGS</code> : contiene l'elenco dei file di configurazione da far processare ad integrit. Dopo l'installazione è vuoto, quindi dovremo aggiungere quello che abbiamo precedentemente creato: <code>/etc/integrit/integrit.conf</code>;
$ patch -p1 < ../patch-2.6.20
; <code>EMAIL_RCPT</code> : l'indirizzo del destinatario di posta elettronica a cui inviare la mail di notifica (root va bene se sono stati correttamente modificati gli alias di posta, altrimenti potete tranquillamente inserire il vostro indirizzo);
$ cd ..
; <code>EMAIL_SUBJ</code> : l'oggetto della mail che riceverete. Normalmente non è necessario effettuare modifiche;
$ mv linux-2.6.19 linux-2.6.20
; <code>ALWAYS_EMAIL</code> : ''true'' se si desidera ricevere una mail di notifica anche quando non vengono riscontrate anomalia, ''false'' altrimenti.
</pre>
3. A questo punto, tramite ''quitl'' applicare nuovamente le patch sul nuovo sorgente:
<pre>
$ quilt push
Applying patch patches/patch1
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- rejects in file Makefile
Patch patches/patch1 does not apply (enforce with -f)
</pre>
 
4. Come risultato, le patch non si applicano immediatamente senza problemi. E&grave; possibile forzare l'applicazione della patch e poi procedere alle correzioni necessarie:
<pre>
$ quilt push -f
Applying patch patches/patch1
patching file Makefile
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file Makefile.rej
Applied patch patches/patch1 (forced; needs refresh)
$ vim Makefile.rej Makefile
</pre>
 
5. Dopo aver applicato manualmente la patch, aggiornare la patch:
<pre>
$ quilt refresh
Refreshed patch patches/patch1
</pre>


6. Procedere all'applicazione delle altre patch:
Una volta modificato il file di configurazione non ci resta che testare il tutto con un semplice
<pre>
<pre>
$ quilt push
# /etc/cron.daily/integrit
Applying patch patches/patch2
patching file drivers/Makefile
Now at patch patches/patch2
$ quilt push
Applying patch patches/patch3
patching file drivers/usb/Makefile
Now at patch patches/patch3
</pre>
</pre>
magari impostando <code>ALWAYS_EMAIL</code> a ''true'' per effettuare un po' di [[debug]].


== Funzionamento ==
Il funzionamento è semplice: ogni volta che viene effettuato un update, viene creato il database '''current''' che raccoglie lo stato attuale del sistema. Ogni volta che viene effettuato un check, invece, viene confrontato il database di tipo '''current''' con il '''known''', in caso di discrepanze (ed in base alle regole definite nel file di configurazione) viene generato il report.


''quilt'' ha anche delle opzioni che permettono di inviare automaticamente le nuove patch ad un gruppo di persone o a una mailing list, di eliminare specifiche patch all'interno della serie, di ricercare una specifica patch all'interno della serie e molte altre utili opzioni.
Una volta controllate le discrepanze e verificato che siano corrette (in caso di aggiornamento di un pacchetto, ad esempio) è necessario aggiornare il database '''know''' con un semplice:
 
''quilt'' � vivamente consigliato per qualsiasi attivit� di sviluppo del kernel, anche per tenere traccia di poche patch, invece di usare i pi� ostici ''diff'' e ''patch''. E&grave; decisamente pi� semplice e consente di risparmiare parecchio tempo e sforzi.
 
Come nota personale, non raccomander� mai abbastanza l'utilizzo di questo strumento, poich� lo utilizzo tutti i giorni per gestire centinaia di patch in diversi rami di sviluppo.
Esso � anche usato da numerose distribuzioni Linux per gestire il proprio kernel e pu� contare su una comunit� di sviluppo entusiasta e reattiva.
 
== git ==
 
''git'' � uno strumento di controllo del codice sorgente originariamente scritto da Linus Torvalds quando stava cercando un nuovo sistema di gestione del codice per il kernel di Linux.
 
&Egrave; un sistema distribuito che differisce dai sistemi tradizionali di gestione del codice (come ad esempio CVS) nel fatto che non � necessario essere connessi al server per effettuare un commit sul deposito.
 
''git'' � uno dei pi� potenti, flessibili e veloci sistemi di gestione del codice sorgente attualmente disponibili, e ha alle spalle un team di sviluppo molto attivo.
La pagina principale di ''git'' � ''http://git.or.cz/''.
Si consiglia ad ogni nuovo utente di seguire le guide pubblicate al fine di familiarizzare con la modalit� di funzionamento di git, in modo da poterlo utilizzare correttamente.
 
Il kernel di Linux � sviluppato utilizzando ''git'', e le ultime versioni possono essere trovate all'indirizzo ''http://www.kernel.org/git/'' insieme ad una vasta lista di altri depositi git.
 
Non � necessario utilizzare ''git'' per sviluppare il kernel di Linux, ma � molto utile per tenere traccia dei bug rilevati.
Se doveste segnalare un bug agli sviluppatori del kernel, essi potranno richiedevi di utilizzare ''git bisect'' al fine di identificare l'esatta modifica che ha causato il bug. In questo caso, potete seguire le indicazioni sulla documentazione di ''git'' per capire come procedere.
 
== ketchup ==
 
''ketchup'' � uno strumento molto comodo utilizzato per aggiornare una versione del kernel o per passare da una versione all'altra del codice sorgente.
 
Esso offre la possibilit� di:
* Trovare l'ultima versione del kernel, scaricarla e decomprimerla.
* Aggiornare una versione attualmente installata del codice sorgente del kernel, applicando le patch necessarie.
* Gestire i diversi rami di sviluppo del kernel, incluse le versioni -mm e -stable
* Scaricare qualsiasi patch o archivio tar necessario per l'aggiornamento, se non gi� presenti sulla macchina locale.
* Controllare la firma GPG dell'archivio e delle patch per verificarne l'integrit�.
 
''ketchup'' si trova all'indirizzo ''http://www.selenic.com/ketchup/'' insieme a molta documentazione presente nel wiki ''http://www.selenic.com/ketchup/wiki/''.
 
Di seguito un esempio che illustra quanto sia semplice utilizzare ''ketchup'' per fare scaricare una specifica versione del kernel e '''per passare ad un'altra versione''' con un numero minimo di comandi.'''VERIFICARE LA TRADUZIONE DELLA PARTE IN GRASSETTO [...and then have it switch the directory to another kernel version...]'''
 
Per scaricare il sorgente del kernel 2.6.16.24 in una directory, e rinominare la directory perch� abbia lo stesso nome della versione del kernel, utilizzare il seguente comando:
 
<pre>
<pre>
$ mkdir foo
mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb
$ cd foo
$ ketchup -r 2.6.16.24
None -> 2.6.16.24
Unpacking linux-2.6.17.tar.bz2
Applying patch-2.6.17.bz2 -R
Applying patch-2.6.16.24.bz2
Current directory renamed to /home/gregkh/linux/linux-2.6.16.24
</pre>
</pre>


Ora, per aggiornare il sorgente affinch� contenga l'ultimo rilascio stabile, digitare:
== Controllo manuale ==
In caso di problemi è possibile effettuare un controllo manuale richiamando lo script cron (<code>/etc/cron.daily/integrit</code>) oppure con un semplice:
<pre>
<pre>
$ ketchup -r 2.6
# integrit -cu -C /etc/integrit/integrit.conf
2.6.16.24 -> 2.6.17.11
Applying patch-2.6.16.24.bz2 -R
Applying patch-2.6.17.bz2
Downloading patch-2.6.17.11.bz2
--22:21:14-- http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.11.bz2
=> `/home/greg/.ketchup/patch-2.6.17.11.bz2.partial'
Resolving www.kernel.org... 204.152.191.37, 204.152.191.5
Connecting to www.kernel.org|204.152.191.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 36,809 (36K) [application/x-bzip2]
100%[====================================>] 36,809 93.32K/s
22:21:14 (92.87 KB/s) - `/home/greg/.ketchup/patch-2.6.17.11.bz2.partial'saved [36809/36809]
Downloading patch-2.6.17.11.bz2.sign
--22:21:14-- http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.17.11.bz2.sign
=> `/home/greg/.ketchup/patch-2.6.17.11.bz2.sign.partial'
Resolving www.kernel.org... 204.152.191.37, 204.152.191.5
Connecting to www.kernel.org|204.152.191.37|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 248 [application/pgp-signature]
100%[====================================>] 248 --.--K/s
22:21:14 (21.50 MB/s) - `/home/greg/.ketchup/patch-2.6.17.11.bz2.sign.
partial' saved [248/248]
Verifying signature...
gpg: Signature made Wed Aug 23 15:01:04 2006 PDT using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key >
ftpadmin@kernel.org<"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Applying patch-2.6.17.11.bz2
Current directory renamed to /home/greg/linux/tmp/x/linux-2.6.17.11
</pre>
</pre>


== Approfondimenti ==
* Home Page del progetto: http://integrit.sourceforge.net/
* esempi di configurazione contenuti in <code>/usr/share/doc/integrit/examples/</code>


Questo esempio mostra come ''ketchup'' determini in modo automatico che la nuova versione stabile del kernel � la 2.6.17.11 e scarichi le patch necessarie per aggiornare il sorgente.
{{Autori
 
|Autore = [[Utente:MaXeR|MaXeR]]
L'uso di ''ketchup'' � vivamente consigliato per scaricare qualsiasi sorgente del kernel di Linux. Esso si occupa di reperire le patch necessarie sul server e applicarle automaticamente nel modo corretto, dopo averne controllato l'autenticit� tramite la firma digitale.
}}
 
L'uso combinato di ''ketchup'' e ''quilt'' permette di avere tutto ci� che serve per gestire il kernel di Linux e per soddisfare le esigenze degli sviluppatori.
 
----
This is an indipendent translation of the book [http://www.kroah.com/lkn/ Linux Kernel in a Nutshell] by [http://www.kroah.com/log/ Greg Kroah-Hartman]. This translation (like the original work) is available under the terms of [http://creativecommons.org/licenses/by-sa/2.5/ Creative Commons Attribution-ShareAlike 2.5].
----


[http://www.kernel.org/pub/linux/kernel/people/gregkh/lkn/lkn_pdf/appa.pdf ''Capitolo originale'']
[[Categoria:Monitoraggio]]
[[Categoria:Linux Kernel in a Nutshell]]

Versione attuale delle 10:21, 28 set 2019

Debian-swirl.png Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

Introduzione

Integrit è un "file verification system": è assimilabile alla famiglia degli Intrusion Detection System o IDS e ha la funzione di verificare che determinati file non subiscano modifiche.

Questi controlli sull'integrità dei file hanno molti vantaggi:

  • non sono pesanti: infatti vengono eseguiti prevalentemente di notte e richiedono pochi minuti
  • sono utili: un aggressore che vuole nascondere dei file, accessi o servizi potrebbe modificare file come netstat, last, w, ls...
  • si affiancano a IDS di rete e software come rkhunter

Ovviamente non si tratta della soluzione di tutti i mali, in quanto potrebbe essere possibile che l'aggressore abbia modificato anche l'eseguibile di integrit, però un controllo in più non fa mai male!

Installazione

L'installazione è molto semplice, con privilegi di amministrazione: 

# apt install integrit

Configurazione

I file di configurazione si trovano in /etc/integrit. Dopo l'installazione sono presenti i seguenti file:

integrit.conf
un template di file di configurazione (infatti è tutto commentato, e quindi integrit non effettuerà alcuna azione se non configurato!), lo utilizzeremo in seguito come punto di partenza;
integrit.debian.conf
il file di configurazione utilizzato dal cron di Debian.

Integrit

Il file di configurazione di integrit è semplice ed è composto dalle seguenti sezioni (inizialmente commentate):

root
la directory di partenza (normalmente /)
know
il path per il database contenente lo stato conosciuto del sistema (default /var/lib/integrit/known.cdb)
current
il path del database usato per effettuare il confronto tra lo stato conosciuto e quello attuale (default /var/lib/integrit/current.cdb)

seguito da un elenco di file da ignorare.

La sintassi dell'elenco è la seguente: 

[action]/directory [controlli]

dove:

action
è facoltativa, e rappresenta l'azione da eseguire. L'azione di default è di esplorare la directory e tutto il suo contenuto. Le alternative sono:
! : l'operatore di negazione: !/etc indica di non controllare il contenuto della directory /etc;
= : indica di non esplorare ricorsivamente il contenuto della directory;
$ : permette di creare una regola che non va ad agire sulle sottodirectory ma solo sulla directory (ed i file contenuti) indicata
/directory
indica il percorso su cui agire;
[controlli]
permette di specificare i controlli da eseguire;
s : checksum;
i : inode;
p : permessi;
l : numero di link;
u : UID;
g : GID;
z : la dimensione dei file (risulta essere un controllo ridondante se viene effettuato anche il controllo del checksum);
a : la data di accesso;
m : la data di modifica;
r : reimposta la data di accesso (utilizzare con attenzione)
le opzioni possono essere scritte in due modi: in minuscolo, il che indica che il controllo deve essere fatto, oppure in maiuscolo, per indicare che il controllo non deve essere effettuato.

È necessario decommentare le opzioni principali del file, personalizzandole se necessario, e aggiungere le altre azioni desiderate, per poter eseguire il comando. Non c'è infatti un'impostazione di default!

Debian

Il file di configurazione /etc/integrit/integrit.debian.conf viene utilizzato dal cron presente in /etc/cron.daily/integrit.

Il file di configurazione è composto da quattro variabili:

CONFIGS
contiene l'elenco dei file di configurazione da far processare ad integrit. Dopo l'installazione è vuoto, quindi dovremo aggiungere quello che abbiamo precedentemente creato: /etc/integrit/integrit.conf;
EMAIL_RCPT
l'indirizzo del destinatario di posta elettronica a cui inviare la mail di notifica (root va bene se sono stati correttamente modificati gli alias di posta, altrimenti potete tranquillamente inserire il vostro indirizzo);
EMAIL_SUBJ
l'oggetto della mail che riceverete. Normalmente non è necessario effettuare modifiche;
ALWAYS_EMAIL
true se si desidera ricevere una mail di notifica anche quando non vengono riscontrate anomalia, false altrimenti.

Una volta modificato il file di configurazione non ci resta che testare il tutto con un semplice 

# /etc/cron.daily/integrit

magari impostando ALWAYS_EMAIL a true per effettuare un po' di debug.

Funzionamento

Il funzionamento è semplice: ogni volta che viene effettuato un update, viene creato il database current che raccoglie lo stato attuale del sistema. Ogni volta che viene effettuato un check, invece, viene confrontato il database di tipo current con il known, in caso di discrepanze (ed in base alle regole definite nel file di configurazione) viene generato il report.

Una volta controllate le discrepanze e verificato che siano corrette (in caso di aggiornamento di un pacchetto, ad esempio) è necessario aggiornare il database know con un semplice: 

mv /var/lib/integrit/current.cdb /var/lib/integrit/known.cdb

Controllo manuale

In caso di problemi è possibile effettuare un controllo manuale richiamando lo script cron (/etc/cron.daily/integrit) oppure con un semplice: 

# integrit -cu -C /etc/integrit/integrit.conf

Approfondimenti



Guida scritta da: MaXeR Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized

Estratto da "https://guide.debianizzati.org/index.php?title=Integrit:_file_verification_system&oldid=43271"