The Onion Router (comunemente chiamato Tor) è un software che implementa la tecnica omonima dell’onion routing per contrastare quella forma di censura chiamata analisi del traffico.
Per capire il funzionamento e l’utilizzo di Tor, dobbiamo essere sicuri di conoscere quale problema vuole risolvere. Cosa è, quindi, l’analisi del traffico?

Con analisi del traffico si definisce una tecnica censoria basata sull’analisi passiva del traffico prodotto da una macchina o da un gruppo di esse. Ispezionando i pacchetti che escono da una rete, un attaccante è in grado di inferire un sacco di informazioni riguardanti l’origine di quei pacchetti. Pensate a una mail: un attaccante che ne intercetta il contenuto è in grado di sapere chi sia il mittente, a quale indirizzo sta scrivendo e cosa gli vuole comunicare. Quando questo concetto viene spostato a livello di traffico di rete lo scenario non cambia: un attaccante che intercetta un qualsiasi traffico di rete è in grado di inferire, dall’header dei pacchetti, chi li ha inviati, chi li riceverà e, guardando il body, cosa si vogliono comunicare.
Una prima soluzione a questo tipo di problemi è quello di impiegare la crittografia, sfortunatamente, in entrambi gli scenari descritti in precedenza, la crittografia stessa non è in grado di fermare l’analisi del traffico ma solo di impedire la lettura dei contenuti del corpo del messaggio: per come deve funzionare la comunicazione su Internet, le informazioni dell’header sono in chiaro e disponibili a chiunque riesca a leggerne il contenuto.
Questo problema è stato affrontato da tempo, con soluzioni più o meno efficaci: all’inizio degli anni 80 David Chaum propose le Mix Networks, una serie di proxy server da utilizzarsi in cascata. In questo modo un attaccante doveva ispezionare il traffico in più punti (all’uscita di ogni proxy, per la precisione) per poter inferire qualcosa di utile sul mittente del pacchetto che usciva dall’ultimo nodo della catena. L’idea di Chaum, benchè non utilizzata, è stato il seme che ha lanciato la ricerca sull’onion routing, letteralmente routing a cipolla.
La ricerca sull’onion routing è stata portata avanti nel corso degli anni 90 dallo United States Naval Research Laboratory che ha poi passato il lavoro alla Electronic Frountier Foundation e, Venerdì 13 Agosto 2004 al 13th USENIX Security Symposium, Tor è stato presentato al pubblico. Da li in poi lo sviluppo del programma è andato in crescendo, gli sviluppatori hanno salutato la EFF che ha dato casa alle prime versioni del programma e, al giorno d’oggi, Tor è un prodotto dell’ormai a se stante Tor Project.
Ma non è solo con la storia che si impara come funziona un protocollo, quindi rimbocchiamoci le maniche e guardiamo da vicino come funziona un programma. Guardiamo la prima figura:

i nodi con un simbolo + verde sono relay della rete Tor, Jane e Bob sono dei server pubblicamente raggiungibili da Internet, Alice è la nostra protagonista e sta utilizzando Tor in modalità client. Dave è un particolare server pubblico chiamato “Tor directory server”, lui e i suoi simili forniscono la lista pubblica di relay Tor e la mantegono periodicamente aggiornata. Il primo passo compiuto dal client Tor di Alice è, appunto, quello di contattare un directory server per ottenere la lista dei nodi marchiati con un simbolo + verde.
A questo punto Alice istruisce il proprio client di contattare il server Bob, per esempio perchè vuole visitare una pagina web ospitata li sopra, il nodo Tor di Alice si preoccupa di costruire una catena di nodi attraverso i quali invierà la richiesta, come mostrato nella seconda figura:

nella terminologia di Tor, i nodi prendono un particolare nome a seconda della loro posizione nella catena di comunicazione o circuito: il primo nodo si chiama Guard Node (nodo di guardia), il secondo Middleman Node (nodo intermediario) e il terzo Exit Node (nodo di uscita). La scelta dei nodi di una catena viene effettuata dal client di Alice in base alle informazioni ricevute dal directory server: ogni relay Tor quando si registra presso le directory invia il proprio indirizzo ip e una serie di caratteristiche. I nodi di uscita sono i più importanti: contattando loro personalmente le macchine esterne alla rete Tor devono dire esplicitamente di essere volenterosi e in grado di farlo. Parimenti, i nodi di guardia vincono questo status quando hanno servito la rete Tor per un lungo periodo: sono nodi fidati a cui possiamo affidare il primo passo per entrare nella rete. Tutti i rimanenti relay sono considerati nodi intermediari. Il perchè di queste scelte e di questa classificazione si può spiegare brevemente dicendo che sono il primo e l’ultimo nodo della catena che rappresentano un ottimo punto per attaccare il protocollo, purtroppo parlare di attacchi al protocollo Tor meriterebbe una serie di articoli a se stante, quindi per questa introduzione ci limitiamo a una seppur stringata spiegazione.
Un altro punto importante è osservare il colore delle frecce: la comunicazione che avviene all’interno della rete Tor è completamente crittata, questo impedisce a un attaccante che riesca a intercettare uno qualsiasi di quei messaggi, di ricostruire tutto il flusso. Nella figura, l’ultimo collegamento (tra Exit e Bob) non è crittato ma questo dipende dal tipo di richiesta che ha effettuato Alice a monte del circuito: nel nostro esempio abbiamo ipotizzato una pagina web servita con HTTP, se Alice avesse usato HTTPS anche l’ultimo link sarebbe stato verde. Va ribadito, comunque, che l’ultima comunicazione è estranea alla trasmissione di informazioni all’interno del protocollo di Tor.
Per capire come mai questo protocollo è resistente agli attacchi di analisi del traffico è utile analizzare cosa accade all’interno di un circuito:

questo è il pacchetto che viene inviato da Alice a Guard, il contenuto della buccia rossa è protetto con le chiavi di Guard stesso, quindi solo lui può leggere cosa c’è scritto. Leggendo le istruzioni contenute in questo strato, Guard capisce che deve inviare il resto del contenuto a Middleman:

questo è il contenuto visto da Middleman: come nel caso precedente la buccia di colore verde è leggibile solo dal destinatario. In questo strato Middleman legge che deve spedire il resto del contenuto ad Exit. Come potete notare, già a questo livello è sparita ogni indicazione riguardante Alice.

Questo è l’ultimo passaggio: Exit riceve da Middleman quello che rimane della cipolla, legge il contenuto decifrabile solo da lui e scopre che deve fare richiesta, secondo l’esempio che ci sta accompagnando per tutto l’articolo, di una pagina web presso il server Bob.
Una volta che Bob ha trasmesso il contenuto necessario ad Exit questo impacchetterà tutto e spedirà a Middleman il quale, vedendo che gli sta arrivando una risposta da Exit, passerà a Guard e questi chiuderà il circuito inviando la risposta ad Alice.
In questo modo il protocollo è in gradi di sconfiggere l’analisi del traffico: l’utilizzo della crittografia e del “remixaggio” dei pacchetti impedisce a un attaccante che osserva il traffico prodotto da uno qualsiasi dei nodi di correlarne il contenuto e il mittente. Inoltre, per prevenire che uno dei nodi del circuito possa leggere arbitrariamente il contenuto delle risposte, la comunicazione viene protetta con una chiave di sessione, che viene modificata frequentemente, apribile solo da Alice.

Per il momento questo è tutto: spero di aver stuzzicato il vostro interesse in questa tecnologia, l’installazione e l’utilizzo di questo programma sono sicuramente materiale per un prossimo articolo!

Installazione, configurazione ed utilizzo

Ma andiamo con ordine! Se non avete già installato questo web server, fatelo ora, usando il metodo più appropriato per la vostra distribuzione linux preferita. A questo punto dovete editare il file di configurazione di default che può essere apache2.conf oppure httpd.conf e assicurarsi che siano abilitati seguenti moduli:

• mod_authn_file
• mod_authz_user
• mod_auth_basic
• mod_auth_digest
• mod_dav_fs

I primi moduli sono necessari per regolare l’accesso alle risorse di apache, l’ultimo è quello che gestirà tutto il calendario.
Bene, ora modificate la configurazione del modulo dav_fs inserendo le segenti voci:

DavLockDB "/usr/var/DavLock"
<Directory "/srv/httpd/htdocs/calendars">
    Dav On
 
    Order Allow,Deny
    Allow from all
 
    AuthType Digest
    AuthName calendars
 
    AuthUserFile "/usr/user.passwd"
    AuthDigestProvider file
 
    <LimitExcept OPTIONS>
        require user nomeutente
    </LimitExcept>
</Directory>

La creazione del file /usr/user.passwd si effettua attraverso il seguente, semplice comando:

$ htdigest -c "/usr/user.passwd" calendars nomeutente

Ovviamente per le direttive siete liberissimi di scegliere i percorsi che più vi aggradano.
Vediamo cosa vogliono dire le varie opzioni:

• DavLockDB serve per specificare quale file apache userà come file di lock per impedire rovinose scritture simultanee sui file gestiti via dav_fs
• Dav On usato all’interno di un tag Directory abilita la gestione di quella cartella tramite il modulo dav_fs
• Seguono le direttive standard per gestire l’autenticazione degli utenti tramite file di password
• Infine con la direttiva LimitExcept si definisce il livello di accesso alle risorse

Questa ultima direttiva è decisamente importante: il modulo dav_fs permette di eseguire degli upload di file sul proprio web server e sicuramente non vogliamo che tale comportamento sia aperto e disponibile a qualsiasi utente di internet!
Così come è scritta, la direttiva richiede un accesso autenticato sia per la modifica dei calendari che per la loro lettura, se volessimo rilassare i permessi, possiamo usare LimitExcept GET OPTIONS: in questo modo è possibile a utenti non autenticati di visionare i file salvati in /calendars ma, francamente, sconsiglio di eseguire questo tipo di rilassamento.
Bene, il server è pronto! Aprite la vostra applicazione di calendaring preferita, potete create un nuovo calendario all’indirizzo http://server/calendars/calendario.ics e usarlo per la gestione dei vostri appuntamenti.

Possibili miglioramenti

Prima di concludere, lascio qualche considerazione per possibili migliorie:

• L’acesso protetto da password serve per controllare chi può accedere alle risorse e chi no, ma senza un adeguato supporto crittografigo risulta quasi inutile: vi consiglio di combinare questa configurazione con il supporto di apache per https o di modificare la regola Allow from per restringere l’accesso alle risorse solo da connessioni sicure come tunnel ssh o vpn
• L’architettura presentata è pensata per un calendar server casalingo, tuttavia scala bene se vogliamo tenere directory separate tra più utenti: basta replicare il blocco di direttive Directory per ogni utenza che si vuole aggiungere adattandola, ovviamente, al nuovo username. I problemi nascono quando si vogliono condividere i calendari in sola lettura:
  • Una prima soluzione, semplice, consiste nel mettersi d’accordo sull’accesso alle risorse: gli stessi client permettono di scegliere se impotare i calendari in sola lettura o meno.
  • Una seconda soluzione, più complessa, prevede l’utilizzo di più direttive Limit al posto di una LimitExcept, in questo modo potremmo usare, per esempio, Limit GET OPTIONS su valid_users per permettere la sola lettura agli utenti autenticati e Limit PUT al proprietario del calendario per permettere solo a lui la modifica dei contenuti. Tale strada, però, può essere potenzialmente pericolosa in caso di utilizzo di metodi http sconosciuti, per maggiori informazioni vi rimando alla documentazione ufficiale delle due direttive
• In questo articolo abbiamo usato il modulo dav_fs solo per gestire un file .ics ma in realtà abbiamo configurato un vero e proprio storage personale sul vostro server apache: potete prendere un qualsiasi client dav e caricare file sotto la cartella /calendars

Conclusioni

Questo è tutto! Come avete potuto notare la creazione di un server per un calendario remoto personale non è poi tanto difficile, per quanto riguarda invece gli ambienti enterprise questa soluzione potrebbe essere un po troppo stretta ma in questo caso si possono applicare le altre idee proposte oppure sposarsi su programmi dedicati come la suite Zimbra oppure il Calendar Server di Apple.

Alla prossima!

Debian e le distribuzioni da lei derivate, utilizzano l’accoppiata apt-get e dpkg per installare e mantenere aggiornati i programmi. Mentre dpkg si preoccupa di lavorare esclusivamente in locale, scompattanto i pacchetti ed assicurandosi che la loro installazione sia portata a buon fine, è apt-get il vero cavallo da lavoro: si preoccupa di mantenere aggiornati gli indici per il reperimento dei pacchetti, calcola e risolve le dipendenze al momento dell’installazione di un nuovo programma e si preoccupa di scaricare il deb dai repository remoti.
Quest’ultima azione, il download, può incidere notevolmente sulle performance della rete, specialmente se si è scelto di installare diversi pacchetti (si pensi agli effetti di un apt-get install ubuntu-desktop sopra un Ubuntu base system) e se questa operazione viene effettuata da più di un computer della stessa rete.

Una prima soluzione potrebbe essere quella di tenere un repository locale e scaricare i pacchetti necessari da quel repository, sfortunamente questa soluzione richiede un notevole consumo di spazio ed ogni giorno è necessario scaricare gli aggiornamenti al repository anche se alcuni o tutti dei programmi scaricati non sono necessari.
Per ovviare a questi effetti entrano in gioco i proxy apt: risolvono il problema di consumo di banda tenendo nella cache locale i pacchetti richiesti e sono meglio della presenza di un repository personale in quanto non si devono sprecare spazio e banda per avere tutti i pacchetti salvati nella cache in ogni momento.
La soluzione più semplice per installare un proxy apt è quella di eleggere, se già presente, il proxy della rete a fare anche da proxy per i deb scaricati: da un lato si ha un immediato vantaggio di configurazione, con poche righe uno squid è in grado di tenere in cache pure i pacchetti dei programmi, dall’altro si hanno delle limitazioni sulla flessibilità di configurazione e sui protocolli supportati per il download dai repository.
Per superare anche queste limitazioni è sufficiente utilizzare un programma dedicato al caching dei deb, quello storico è apt-proxy seguito, in ordine cronologico, da approx, apt-cacher e apt-cacher-ng. In questo articolo parleremo dell’utilizzo di approx perchè è il più vecchio proxy apt funzionante, in quanto il povero apt-proxy mostra i segni dell’età non risultando affatto scalabile su larga scala.
Il comportamento dei proxy apt è molto semplice: vengono configurati per fornire la cache di alcuni repository, quando un client li contatta e richiede un pacchetto, i proxy controllano la presenza del pacchetto nella loro cache, se questo manca verrà scaricato dal repository e passato al client altrimenti verrà servita la copia locale, risultando così estremamente veloce e risparmiando un download extra inutile. L’installazione di approx è immediata:

root@proxy:~# apt-get install approx

una volta finito il processo, si deve editare il file /etc/default/approx solamente nel caso sia necessario fornire al nostro proxy apt… un proxy per uscire! Per esempio:

# Default settings for approx, included by the /etc/init.d/approx shell script
 
# Uncomment and edit this definition to have approx use a proxy server
export http_proxy=il-mio-proxy:porta

A questo punto si può procedere alla vera configurazione di approx, il file /etc/approx/approx.conf:

# Here are some examples of remote repository mappings.
# See http://www.debian.org/mirror/list for mirror sites.
 
debian          http://mi.mirror.garr.it/mirrors/debian
security        http://security.debian.org/debian-security
volatile        http://volatile.debian.org/debian-volatile
 
# The following are the default parameter values, so there is
# no need to uncomment them unless you want a different value.
# See approx.conf(5) for details.
 
#$interface      any
$port          80
#$max_wait      10
#$max_rate      unlimited
#$user          approx
#$group         approx
#$syslog         daemon
#$pdiffs        true
#$verbose        false
#$debug         false

La prima sezione specifica a quale nome faranno riferimento i repository proxati, la sintassi è molto semplice:

nome_repo      url_repo

così facendo, all’indirizzo http://proxy/nome_repo risponderà la cache di url_repo o, come accade nella prima riga del nostro file di configurazione, http://proxy/debian/ è una cache per http://mi.mirror.garr.it/mirrors/debian.
A questo punto basta modificare il /etc/apt/sources.list delle macchine della propria rete e del proxy stesso, utilizzando i nuovi url:

http://proxy/debian/   lenny main contrib non-free
http://proxy/security/   lenny/updates main contrib non-free
http://proxy/volatile/   lenny/volatile main contrib non-free

La seconda sezione, invece, si occupa della gestione delle opzioni di configurazione del comportamento di approx stesso, nel nostro esempio abbiamo configurato come porta di ascolto la 80, al contrario del default storico di apt-proxy: la 9999. Se non avessimo cambiato la configurazione, il proxy avrebbe comunque funzionato ma nei client si doveva configurare esplicitamente la porta di ascolto del server usando, per esempio, una riga come http://proxy:9999/debian/ lenny main contrib non-free.
Il proxy è ora in piedi, sta venendo utilizzato dai client e possiamo anche dimenticarci della sua presenza! Se però vogliamo provare a verificare manualmente il suo comportamento, approx ci fornisce due ulteriori programmi che vengono usati esclusivamente da cron per mantenere in forma il proxy ma che il sistemista curioso può provare a lanciare manualmente.
Il primo programma è update_approx che viene schedulato come giornaliero al momento dell’installazione, questo programma si preoccupa di aggiornare la lista e le versioni dei programmi reperibili dai repository remoti.
Il secondo è gc_approx, il garbage collector: come dice il nome, questo programma si preoccupa di tenere pulita la cache di approx, eliminando i pacchetti superfli e non più disponibili dai repository remoti. Al momento dell’installazione questo programma viene schedulato come settimanale.
Credo che valga veramente la pena installare approx o un altro proxy apt: il risparmio di banda è notevole già da quando si utilizzano solo due macchine e la vostra connessione vi ringrazierà

Puppet è una infrastruttura per l’automatizzazione della gestione e amministrazione di un parco macchine UNIX-like.
Il framework è composto da un puppet master che è il server centrale incaricato di raccogliere tutte le azioni e i file di configurazione utilizzati e da svariati puppet, agenti che vengono installati sulle macchine che si vogliono controllare e periodicamente contattano il master per conoscere nuove configurazioni e controllare se il proprio stato è in linea con quanto richiesto dal server centrale. Per ultime ci sono le recipe, le ricette, file di testo che descrivono le azioni da intraprendere sui puppet e i file di configurazione da utilizzare.

Puppet è disponibile già pacchettizzato per la maggior parte delle distribuzioni Linux, vediamo come è possibile eseguire un setup di prova di un puppet master e di un singolo client su macchine Debian Etch. Prima di proseguire, però, una piccola nota: la versione inclusa in Etch è piuttosto vecchia e non implementa alcune feature interessanti, come la gestione delle ricette via moduli, presenti in versioni più recenti del programma. Se si vuole sperimentare con queste nuove caratteristiche è comunque sempre possibile installare senza problemi i pacchetti dal repository Testing, in quanto gli sviluppatori si assicurano che tali pacchetti siano sempre compatibili con la versione Stable della distribuzione.

1. Il puppet master
Raggiungete la macchina prescelta come puppet master che chiameremo, senza troppa fantasia, master e installate i programmi necessari:

root@master:~# apt-get install puppetmaster

Questa operazione installerà anche le dipendenze, compreso il pacchetto per l’agent puppet.
L’installazione terminerà con uno sconfortante errore: niente paura! Il master non è ancora stato configurato a dovere e gli script di init non sono in grado di avviarlo correttamente.
Preoccupiamoci innanzitutto di permettere l’accesso ai file che verranno serviti dal nostro master, editate il file /etc/puppet/fileserver.conf e aggiungete una riga per permettere l’accesso alla sottorete 192.168.0.0/24 (per esempio):

[files]
  path /etc/puppet/files
  allow 192.168.0.0/24

A questo punto creiamo una configurazione iniziale, editate il file /etc/puppet/manifests/site.pp con il seguente contenuto:

# Main puppet master configuration
import "classes/*.pp"
 
node default {
  import sudo
}

La prima riga richiede l’inclusione dei file .pp (le ricette) presenti nella cartella classes, vedremo tra poco come crearli, le successive definiscono la configurazione di default da servire ai nodi e questa richiede l’implementazione della ricetta “sudo”.
Vediamo, dunque, la nostra prima ricetta: “sudo”, questa ricetta si preoccupa di controllare che i permessi del file /etc/sudoers siano corretti. Creiamo la cartella per le ricette:

root@master:~# mkdir /etc/puppet/manifests/classes

Dopo di che scriviamo il file /etc/puppet/manifests/classes/sudo.pp:

# Testing class for sudoers permissions
class sudo {
 
        file { "/etc/sudoers":
                owner => "root",
                group => "root",
                mode => 440,
        }
 
}

Il master è stato configurato correttamente, occupiamoci ora del client locale, editate /etc/puppet/puppetd.conf con i seguenti contenuti:

[puppetd]
# Make sure all log messages are sent to the right directory
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
server=master

Fatto! Master e puppet (locale) sono stati configurati correttamente, proviamo quindi la configurazione in locale, come prima azione simuliamo un guasto cambiando i permessi di sudoers:

root@master:~# chmod 700 /etc/sudoers

Ora, riavviamo i servizi del master e del puppet locale:

root@master:~# /etc/init.d/puppetmaster restart
root@master:~# /etc/init.d/puppet restart

Se ora controlliamo nuovamente sudoers dovremmo trovare i suoi permessi originali a 440

2. I puppet
Un puppet master senza alcun puppet client non ha alcun senso di esistere, vediamo quindi come è possibile configurare un ipotetico client che ripsponda all’indirizzo puppet1 come client per il master configurato in precedenza. Il pacchetto necessario è puppet, quindi installiamolo:

root@puppet1:~# apt-get install puppet

Ed editiamo il suo file di configurazione, /etc/puppet/puppetd.conf, usando lo stesso identico contenuto già riportato in precedenza:

[puppetd]
# Make sure all log messages are sent to the right directory
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
server=master

Il client è configurato e pronto a ricevere istruzioni. Prima di poter ricevere istruzioni, però, è necessario che il master conosca il client e lo autorizzi a ricevere le istruzioni registrate. Per fare ciò cominciamo ad avviare il client:

root@puppet1:~# /etc/init.d/puppet restart

Spostiamoci sul server e controlliamo la coda di richieste:

root@master:~# puppetca --list

Dovrebbe apparire il nome del client, nel nostro esempio è puppet1, firmiamo quindi il suo certificato e abilitiamolo a ricevere le configurazioni:

root@master:~# puppetca --sign puppet1

Fine! Master e puppet sono ora configurati correttamente, facciamo un ultima prova simulando lo stesso guasto provato in precedenza sul nostro client: alterate i permessi di /etc/sudoers nel client, dopo di che riavviate il servizio:

root@puppet1:~# /etc/init.d/puppet restart

E il file sudoers verrà corretto, di nuovo

Puppet non si limita a sistemare permessi sui files ma si occupa anche di trasferire contenuti e assicurare l’installazione di pacchetti o l’esecuzione di comandi, il wiki raccoglie documentazione in quantità per creare le proprie ricette ed è un ottimo punto di partenza per ottenere più informazioni.