Era un po’ che non tiravo fuori la mia fissa con IPv6…
Dopo oltre due mesi di trasferta per finire l’infrastruttura di una nave, eccomi tornato alla carica con IPv6.
Continua a leggereEra un po’ che non tiravo fuori la mia fissa con IPv6…
Dopo oltre due mesi di trasferta per finire l’infrastruttura di una nave, eccomi tornato alla carica con IPv6.
Continua a leggereQuando si comincia ad utilizzare IPv6 in produzione su una configurazione LAN eterogenea iniziano i comportamenti a cui non siamo abituati.
Con IPv4 un host impostato per la configurazione automatica si assegna un indirizzo link-local (169.254.0.0/16, RFC3927) contatta il server DHCP per avere un indirizzo e, quando lo ottiene, scarta l’indirizzo link-local e avrà sempre solamente quell’indirizzo fino alla scadenza dell’affitto dello stesso.
(altro…)Ho deciso di cambiare qualcosa nelle configurazione casalinga introducendo un po’ di virtualizzazione, un firewall standalone e un tunnel IPv6 (spero) finalmente stabile.
Seguendo le istruzioni di Fabrizio ho configurato il Linux casalingo di frontiera con KVM e una VM su cui gira la versione 2.1 di pfSense. Alla fine la configurazione è (per scelta di non complicarmi troppo la vita per ora) la più classica e semplice: WAN<->firewall<->LAN con i servizi pubblicati in LAN nattati (per IPv4) 1:1, senza DMZ, per ora.
Questo mi ha permesso di togliere i mezzo dal Linux host la gestione del tunnel e altri servizi legati alla rete (come il DHCP e radvd).
Quello che serve per lo scopo di questo articolo è un tunnel IPv6 gratuito con Hurricane Electric (un solo /64 è sufficiente), una connessione con IP fisso e un firewall pfSense. Negli esempi che seguono gli IP sono ovviamente inventati (per IPv4) o del blocco /32 utilizzabile per la documentazione (per IPv6).
Mentre il conto alla rovescia dell’esaurimento dell’IPv4 continua, è opportuno valutare i rischi correlati all’adozione di IPv6.
Il NIST ha pubblicato un utilissimo documento in cui vengono dettagliate le linee guida per l’adozione sicura dell’IPv6 nelle organizzazioni.
Il documento è molto corposo e la prende veramente alla lontana, ma è utile a tutti perché non dà nulla per scontato; chi conosce già i dettagli dei protocolli IP può saltare i primi capitoli.
Nella guida vengono spiegati i meccanismi di passaggio da v4 a v6 e i rischi correlati.
Sam Bowne ha scoperto e verificato sul campo che molti sistemi operativi sono vulnerabili ad un attacco di RA flood.
L’attacco, che si verifica solamente se sono attivi lo stack IPv6 e l’assegnamento automatico dell’indirizzo, consiste nel bombardare la vittima con dei pacchetti RA creati appositamente con un numero tale di informazioni da mandare in crash i sistemi.
I sistemi interessati da questo problema sono moltissimi: Microsft Surface, Android, tutti gli iPad (incluso il mini), Mac OSX, Windows 7, Windows 2008 e Windows 2008 R2.
Se viene installato l’IPv6 Readiness Update su Windows il problema viene leggermente mitigato, anche se il sistema si congela durante l’attacco, per riprendersi una volta che l’invio di pacchetti termina.
Linux Ubuntu ha passato indenne questo tipo di attacco.
Non è la prima volta che viene dimostrata una vulnerabilità dei sistemi di autoconfigurazione di IPv6. Eventuali test in un ambiente non controllato dovrebbero essere condotti per il momento senza attivare questi automatismi sugli host per evitare che qualche buontempone si diverta con uno dei tanti script che sono in circolazione.
Sono sempre di più i prodotti e i sistemi operativi che supportano IPv6.
La quasi totalità di questi host è configurata per default in dual stack con DHCP su IPv4 e SLAAC su IPv6. Chi esegue l’installazione del dispositivo raramente si cura della parte IPv6 e procede solamente alla configurazione di IPv4, lasciando IPv6 attivo in SLAAC.
Purtroppo l’attuale implementazione di SLAAC non prevede alcuna forma di autenticazione o di validazione preventiva, posto che l’IT si sia già posto il problema dell’IPv6 nella sua LAN.
Il risultato è che a tutti gli host IPv6, inclusi i server, può essere assegnato un indirizzo IP da un software come radvd con lo scopo di creare una LAN parallela a quella esistente con delle regole di routing e di accesso completamente diverse. Piazzare una macchina Linux con radvd e un tunnel IPv6 con 2^64 indirizzi pubblici è più semplice di quello che sembra; una volta attivato il gateway, gli host con un IPv6 sarebbero accessibili da qualsiasi parte di Internet.
In questa fase transitoria è bene configurare correttamente gli host, disabilitando IPv6 (o lo SLAAC) dove non è ancora necessario. Agire solamente sul firewall di frontiera non è sufficiente perché nel caso indicato sopra il Linux potrebbe avere un punto di uscita diverso verso Internet.
Voglio segnalarvi una guida gratuita pubblicata da 01net.it su IPv6.
Alcuni argomenti sono condivisibili, altri meno ma l’importante è che se ne parli.
01net.it: Come e quando passare a IPv6
Ovviamente non si discute “SE passare a IPv6” ma del “COME passare a IPv6” essendo un passaggio obbligatorio e scontato. Quando? Prima possibile…
La prima versione di questo articolo spiegava in maniera onestamente un po’ cervellotica come abilitare su un server CentOS 6 la gestione degli host virtuali di Apache 2.2 basati sugli indirizzi (IP-based virtual host) per IPv6 e basati sul nome (name-based virtual host) per IPv4.
Questa revisione si propone lo stesso scopo, ma con un metodo molto più rapido e meno invasivo.
Nella documentazione di Apache viene detto esplicitamente che la gestione degli host virtuali basati sul nome è una tecnologia creata per far fronte alla scarsità degli indirizzi IPv4; dal momento che questo non è un problema di IPv6, possiamo usare tranquillamente gli host virtuali basati sugli IP. Questa tecnologia permette, tra le altre cose, di avere più certificati HTTPS caricati sul medesimo server.
(altro…)Questo articolo spiega come passare in IPv6 un mail server Linux con Postfix, Amavisd-new e Dovecot.
Il sistema di partenza è un Linux con il dual stack IPv4/IPv6 attivo e funzionante con un indirizzo pubblico IPv4 e uno IPv6. Anche il sistema di posta elettronica è perfettamente funzionante in IPv4 con le ultime versioni dei programmi indicati sopra installati da sorgente, non da pacchetto della distribuzione Linux. Ciò perché con IPv6 è sempre meglio avere le ultime versioni, anche se la maggior parte delle istruzioni che seguono dovrebbero funzionare anche con le versioni distribuite nei pacchetti standard.
Continua a leggereDa giorni cercavo una fonte di dati che mi permettesse di elaborare il numero degli IPv4 rimasti in modo analogo alla pagina del RIPE.
Avevo contattato il RIPE che mi aveva dato il permesso di rielaborare i dati che loro pubblicano ogni giorno, ma l’impresa si è rivelata più difficile del previsto, dal momento che non trovavo dei dati da aggregare che mi dessero come risultato un numero paragonabile a quello della loro pagina degli IPv4 disponibili.
Cercando in rete, ho trovato il sito di Geoff Huston con un sacco di informazioni e statistiche.
Elaborando un file specifico, sono riuscito ad ottenere un risultato con una grandezza comparabile a quella della pagina del RIPE, il mio benchmark, il risultato delle elaborazioni è mostrato qui a fianco, in cima alla colonna di destra. I dati elaborati vengono pubblicati con il permesso di Geoff.
Chiunque voglia avere questi risultati può utilizzare delle semplicissime API che ho approntato e ottenere con un HTTP GET i singoli numeri oppure la tabella intera. Contattatemi a lrosa(*)siamogeek.com per i dettagli.
Nota aggiunta il 30/9/2013: a questa soluzione è da preferire quella descritta in un articolo successivo con pfSense e KVM.
(alcune parti sono state modificate dopo la pubblicazione)
Questo articolo spiega come impostare un tunnel IPv6 con Linux CentOS 5 configurato come gateway, NAT e firewall di una LAN.
Lo scenario è il seguente: un router ADSL con IPv4 pubblico collegato ad un Linux che fa da NAT/firewall per la LAN. In questo esempio eth0 è l’interfaccia WAN con un IPv4 pubblico /29 e eth1 è l’interfaccia LAN con un IPv4 /24.
Alla fine della procedura la classe /64 di IPv6 pubblici con reverse DNS potrà essere utilizzata per assegnare indirizzi pubblici ai dispositivi IPv6 in LAN, incluso il gateway Linux.
Questo articolo inaugura una (spero) nutrita serie di articoli sull’IPv6 per cui è stata creata una tassonomia specifica.
L’idea è che tutti gli autori del blog condividano le proprie esperienze con IPv6 e le mettano a disposizione degli altri, che le possono consultare utilizzando le categorie nella colonna a sinistra.
Se qualcuno vuole contribuire come guest blogger oppure come autore ricorrente, per questo tema (o anche per altri) mi scriva pure a lrosa()siamogeek.com.
Scenario: abbiamo un server CentOS headless in hosting con un IPv4 fisso e configurato, che utilizziamo per fare amministrazione via ssh e dobbiamo aggiungere un indirizzo IPv6 che ci ha assegnato il fornitore.
La prima differenza rispetto ad un IPv4 è che non ci vengono assegnati, generalmente, uno o due indirizzi, ma un blocco. Nel mio caso mi hanno dato 2a01:4f8:d15:1c00::/64; dal momento che IPv6 ha 128 bit di indirizzo, un /64 significa che ho 64 bit di indirizzo fisso (2a01:4f8:d15:1c00) e altrettanti disponibili per il mio server. Un sogno, se ragioniamo con il razionamento di IPv4.