[precedente] Piedone - Copertina - Costruire RPM [successivo]

Articoli

IPSEC per Linux

Come descritto dal draft-ietf-ipsec-arch, lo scopo dell'architettura IPSEC è quello di fornire sicurezza di tipo crittografico all'IP layer, sia per IPv4 sia per IPv6.

L'insieme di servizi forniti riguarda, tra gli altri: controllo d'accesso, integrità, autenticazione, confidenzialità.

Due protocolli concorrono al raggiungimento di questi obiettivi. L'Authentication Header (AH) e l'Encapsulating Security Payload (ESP).

Il vantaggio di tecnologie di questo tipo è la totale trasparenza dal punto di vista dell'utente e la compatibilità con altri host che non adottino questi meccanismi di protezione del traffico di rete.

Sistemi operativi BSD-derived come OpenBSD già offrono un'implementazione IPSEC integrata nel kernel, a partire dalle versioni più recenti.

Per quanto riguarda Linux si stanno affacciando le prime soluzioni sotto licenza GNU GPL, seppur ancora a livello alpha, che aggiungono il supporto IPSEC alla versione stabile del kernel 2.0.33.

Nei prossimi paragrafi verranno esaminate differenze e modalità di installazione di due diverse implementazioni, Klips (conosciuta anche come Freeswan) e ipnsec.

Per informazioni su Klips consultare http://www.xs4all.nl/~freeswan,
mentre per ipnsec ftp://ftp.eunet.cz/icz/ipnsec.

Per i test sono state utilizzate le seguenti versioni:

L'ambiente di prova è costituito da due macchine Linux collegate in rete ethernet.

Caratteristiche delle due implementazioni

Per fare in modo che due sistemi IPSEC arrivino a scambiarsi dinamicamente le Security Associations (SA) e le chiavi crittografiche necessarie a stabilire una connessione sicura è necessario un protocollo di Session Key Management.

Freeswan adotta il protocollo ISAKMP, mentre ipnsec preferisce Photuris.

Nelle versioni testate nessuno dei daemon di keymanagement supporta entrambe i protocolli.

Klips e ipnsec si installano come moduli del kernel.

Klips: installazione e configurazione

Le user-level utility e il daemon ISAKMP/Oakley (Pluto) compilano senza dare errori.

Anche il patching del kernel si riduce alla modifica del Config.in sotto net/ e alla copia della directory ipsec/ con i sorgenti e gli include necessari alla compilazione del modulo ipsec.o.

In fase di compilazione emergono alcuni problemi legati alle opzioni di debug. Risolti questi il modulo viene compilato.

Effettuato il reboot ed inserito il modulo nel kernel, bisogna ora configurare l'interfaccia ipsec0, mediante semplici comandi. 

host1:~# tncfg attach ipsec0 eth0
host1:~# ifconfig ipsec0 10.100.100.1 netmask 255.255.255.0
host1:~# route del 10.100.100.0
host1:~# route add -net 10.100.100.0 netmask 255.255.255.0 dev ipsec0

Analogamente su host2: 

host2:~# tncfg attach ipsec0 eth0
host2:~# ifconfig ipsec0 10.100.100.2 netmask 255.255.255.0
host2:~# route del 10.100.100.0
host2:~# route add -net 10.100.100.0 netmask 255.255.255.0 dev ipsec0
Dopo aver opportunamente modificato il file isakmp-secrets da installare sotto /etc, su entrambe gli host si lancia il daemon Pluto.

Alcune distribuzioni di Linux non hanno il device urandom e Pluto, non potendo operare un test in fase di avviamento, segnala l'errore via syslog daemon. 

mknod /dev/urandom c 1 9
per ovviare al problema.

Dopo aver sistemato interfacce e route table, bisogna convincere i due Pluto ad avviare lo scambio delle SA. Ciò viene fatto mediante l'utility whack. 

host:~# whack 501 10.100.100.2 500 10.100.100.1 255.255.255.255 10.100.100.2 255.255.255.255 encrypt

A questo punto, tutto è pronto per la prima connessione in transport mode bidirezionale.

Ciò significa flusso nei due sensi di pacchetti autenticati e crittati.

Ad esempio, un ping da host1 a host2 genera un'ICMP echo request che prima di essere passata all'eth0 a cui ipsec è agganciato, viene crittata in DES e autenticata in MD5. Su host2 l'ICMP echo reply viene a sua volta crittata e autenticata prima di essere trasferita all'eth0.

È possibile anche effettuare un setup in transport mode unidirezionale. In questo caso i pacchetti di ritorno viaggiano in chiaro.

In un'altra finestra potrete verificare con un network monitor tipo Iptraf o tcpdump l'effettivo scambio di pacchetti incapsulati.

È sempre possibile controllare IPSEC route e SPI (Security Parameter Index): 

cat /proc/net/ipsec-eroute
cat /proc/net/ipsec-spi

Supponiamo ora di avere tre segmenti di LAN: lan1, lan2 e lan3. lan1 comunica con lan3 attraverso lan2, sulla quale sono presenti i due gateway per lan1 e lan3. È ipotizzabile un tunnel IPIP tra i due gateway lan1-lan2 lan2-lan3.

         lan2 ---------+------------------+------------------------
                       |                  |
       HOST1        GATEWAY_1-2           |
         |             |                GATEWAY_2-3     HOST3
  lan1 --+-------------+------             |              |
                                  ---------+--------------+---- lan3

In questo caso un ping da host su lan1 ad un host su lan3 genera l'ICMP echo request che raggiunge il gateway su lan2, viene incapsulato in IPIP, crittato in DES, autenticato in MD5, immesso nel tunnel con il secondo gateway, estratto, decrittato ed inviato all'host di destinazione sul segmento lan3.

ipnsec-0.84

Petr Novak, autore di ipnsec, segue da vicino il lavoro fatto dal progetto Freeswan ma se ne discosta, come vedremo, per ciò che concerne alcune scelte progettuali.

Nella versione precedente (0.82) si annunciava la piena interoperabilità con OpenBSD. Le sostanziali modifiche introdotte con la 0.84 hanno per il momento reso incompatibili le due implementazioni del protocollo di gestione delle chiavi (Photuris).

ipnsec presenta un'interfaccia con lo stack TCP/IP completamente diversa.
Non vi è più la necessità di configurare con tncfg le interfacce ipsec*. In fase di caricamento, il modulo ipnsec.o aggancia automaticamente tutte le interfacce IP.

Effettuata questa operazione su entrambe le macchine si tratta ora di configurare nel kernel le SA, operazione fattibile mediante l'utility ipsecadm, che può essere utilizzata per specificare le modalità di crittazione e autenticazione.

Ad esempio su host1, con uno script: 

# SP for incoming traffic
ipsecadm -enc des -auth md5 -src 10.100.100.2 -dst 10.100.100.1 -spi 1234 -key 11223344aabbccdd -authkey 11223344
# SPI for outgoing traffic
ipsecadm -enc des -auth md5 -src 10.100.100.1 -dst 10.100.100.2  -spi 1234 -key 11223344aabbccdd -authkey 11223344
# IPSec AH route for all traffic from host1 to host2
rt 10.100.100.1 255.255.255.255 10.100.100.2 255.255.255.255 -1 -1 -1 10.100.100.2 1234 1
In teoria il processo potrebbe essere reso automatico grazie al daemon photurisd. Tuttavia, nonostante il successo nella compilazione il daemon non si avvia per un errore critico in una chiamata setsockopt(). Provando la versione precedente (0.82), si riesce, non senza difficoltà soprattutto nella sistemazione dei file di configurazione, ad avviare lo scambio dinamico delle SA. Ma il daemon non è stabile e spesso il processo muore senza dare segnali di errore.

Il setup manuale prima illustrato non espone a questi rischi.

Conclusioni

IPSEC porta un indubbio vantaggio in termini di sicurezza, trasferendo al network layer i problemi di autenticazione e confidenzialità prima risolti con soluzioni tipicamente ad application layer (ad es. ssh, kerberos, ssl).

Generalmente queste ultime costringono l'utente ad apprendere nuovi comandi, nuove modalità operative etc. Raramente si ha a che fare con sostituzioni drop-in di client e server.

Lo svantaggio principale al momento è rappresentato dalla scarsa compatibilità di queste versioni GNU GPL con altre implementazioni per sistemi operativi diversi. Si tratta comunque di alpha software che dovrebbe in tempi non troppo lunghi avvicinarsi alla piena interoperabilità con altre soluzioni.

di Paolo Rocchi

[precedente] Piedone - Copertina - Costruire RPM [successivo]