Considerazioni sulla sicurezza IPv6 da non trascurare

Si è tentati di considerare IPv6 un sostituto diretto di IPv4 che ha semplicemente uno spazio di indirizzamento più grande. In termini di sicurezza, alcune differenze reali meritano di essere comprese, invece di dare per scontato che tutto ciò che vale per IPv4 resti invariato.

La blocklist va costruita a parte, non solo allungata

IPv6 ha i propri intervalli privati, di loopback e link-local, strutturati in modo diverso dai corrispettivi IPv4. Un controllo di sicurezza che sa analizzare e filtrare solo gli intervalli IPv4 lascerà passare in silenzio tutti questi indirizzi sul versante IPv6: non perché IPv6 sia meno sicuro, ma perché le protezioni equivalenti non sono mai state realizzate per esso.

Indirizzi IPv4-mapped: un punto cieco facile da trascurare

IPv6 prevede una notazione per incorporare un indirizzo IPv4 dentro uno IPv6, ad esempio ::ffff:127.0.0.1, che si riferisce allo stesso indirizzo di loopback del semplice 127.0.0.1, solo scritto in forma IPv6. Un controllo che filtra correttamente il loopback IPv4 ma non scompone questa forma incorporata approverà un indirizzo funzionalmente identico a uno che altrimenti avrebbe bloccato senza esitazione.

• Qualsiasi sistema che confronta gli indirizzi risolti con una blocklist ha bisogno di una logica davvero separata e completa per IPv6, non dell'assunto che le regole IPv4 si generalizzino automaticamente.
• Gli indirizzi IPv6 IPv4-mapped vanno scomposti e controllati specificamente con le regole IPv4, non valutati come indirizzi IPv6 opachi.
• I sistemi dual-stack (la maggior parte di quelli moderni) devono applicare entrambi i controlli in modo coerente, perché un attaccante userà semplicemente la famiglia di indirizzi su cui si trova il controllo più debole.

Niente di tutto questo è un motivo per evitare IPv6: una maggiore diffusione è in generale un bene, e la superficie d'attacco specifica di IPv6 non è intrinsecamente più grande di quella di IPv4. È un motivo per assicurarsi che la logica di sicurezza che gestisce gli indirizzi sia stata effettivamente costruita e testata per entrambe le famiglie, e non per una sola con l'altra aggiunta in un secondo momento.

NAT64 aggiunge un secondo livello di traduzione da conoscere

Alcune reti solo IPv6 usano NAT64 e DNS64 per permettere ai propri client di raggiungere comunque la parte di Internet solo IPv4: DNS64 sintetizza al volo un record AAAA per un dominio che ha solo un record A, incorporando l'indirizzo IPv4 in un prefisso speciale (64:ff9b::/96 è il valore predefinito più noto), e NAT64 riconverte nel vero IPv4, al margine della rete, il traffico diretto a quell'indirizzo sintetico. È un meccanismo legittimo e utile, ma significa che un indirizzo che ricade in quell'intervallo specifico non è un semplice indirizzo IPv6 da valutare a sé: è IPv4 travestito da IPv6, e va scomposto e controllato con le regole IPv4 esattamente come un indirizzo IPv4-mapped.

Testare la logica di sicurezza significa testare entrambe le famiglie

È facile che i test automatici si sbilancino in silenzio verso IPv4: la maggior parte dei domini di esempio, delle fixture di test e dei controlli manuali rapidi lo usa per impostazione predefinita senza che nessuno lo decida di proposito. Una suite di test per qualsiasi componente che risolve e filtra indirizzi è affidabile solo quanto la sua copertura IPv6: i casi per gli intervalli privati, di loopback e link-local visti sopra, per un indirizzo IPv4-mapped e per un indirizzo sintetizzato in stile NAT64 meritano ciascuno asserzioni esplicite, non un semplice «probabilmente funziona allo stesso modo». Il codice di sicurezza che gestisce gli indirizzi è proprio il tipo di logica in cui un percorso non testato e uno rotto sono indistinguibili finché non è un attaccante a scoprirne per primo la differenza.