Muovere i primi passi in IPv6 (dal tunnel broker all'host ipv6 only)

L'articolo che sto scrivendo ha un taglio più tecnico, per cui non me ne vogliano i meno esperti (a cui comunque cerco spesso di dedicare anche articoli "digeribili"), ma sarebbe opportuno che il lettore conosca cos'è un IPv4 e la relativa logica di routing legata alla maschera di rete, inoltre è necessario avere già conoscenze sui meccanismi di NAT per meglio comprendere il proseguo.

Lo scopo è quello di far muovere i primi passi e consentire al lettore di creare un laboratorio di test per effettuare una serie di esperimenti.

L'architettura presa in esame non prevede che il proprio ISP fornisca nativamente IPv6, quindi utilizzeremo un TunnelBroker, ovvero un  servizio in grado di creare un tunnel con il nostro gateway ed erogarci una classe /64 di IPv6 (di 18 milioni di miliardi di IP pubblici, ma questo lo vedremo avanti).

Premessa

Visto il taglio tecnico, mi dilungherò poco sulle premesse: oramai anche i muri sanno che gli IPv4 sono praticamente terminati su RIPE e ARIN, quindi la situazione (seppur se ne parli da molto tempo) riveste carattere d'urgenza. Piuttosto è importante sfatare alcuni miti per cui è opportuno che il lettore legga queste FAQ in italiano ad opera di ipv6italia (gruppo non più attivo, ma le cui fonti risultano comunque estremamente utili e preziose).

E' altrettanto opportuno che il lettore sappia leggere un IPv6, quindi rimando a https://it.wikipedia.org/wiki/IPv6 e nello specifico la sezione di "Notazione per gli indirizzi IPv6".

Primo Step: creare un collegamento ad un Tunnel Broker

Come abbiamo visto poc'anzi, un servizio di Tunnel Broker si occupa di fornire connettività IPv6 tunnellizzandola su una esistente IPv4, esso ci darà a disposizione una classe IPv6 /64 liberamente utilizzabile, ovvero 18446744073709551616 IP Pubblici Statici (per dirla con nomi familiari). Opzionalmente è possibile richiedere una /48 con un semplice click, ma ritengo che non siano particolarmente necessari i 1208925819614629174706176 indirizzi IP di questa maschera di rete. (almeno non ora, non parleremo di subnetting)

Nel nostro esperimento (estremamente pratico), ci collegheremo su https://www.tunnelbroker.net/, effettueremo una registrazione, quindi cliccheremo su Create Regular Tunnel. A questo punto potremo scegliere il nodo di collegamento IPv4 tra una serie corposa di Server sparsi in tutto il mondo.

A questo punto avremo tutto per creare un Tunnel tra noi e loro per utilizzare la nostra classe IPv6.

Potremo avere visibilità degli IP pubblici utilizzando il semplice tool CIDR Calculator per IPv6 reperibile qui https://www.ultratools.com/tools/ipv6CIDRToRange (in effetti non è proprio banale calcolare la notazione CIDR in v6!).

Secondo Step: Configuriamo il nostro router-tunnel

Qualcuno dovrà fare un tunnel, nel nostro caso il router che si occuperà di fare questo è un pfSense la cui documentazione relativa a questo aspetto è estremamente dettagliata e reperibile qui: https://docs.netgate.com/pfsense/en/latest/interfaces/using-ipv6-with-a-tunnel-broker.html

 

Se tutto va bene ed abbiamo seguito la guida "religiosamente", avremo il tunnel online. 

Interfaccia Tunnel online

Architetturalmente abbiamo deciso di mettere, a seguire, un firewall Stormshield dietro il pfSense, pertanto quest'ultimo non viene utilizzato come firewall, ma come semplice router.

Facciamo qualche prova utilizzando http://www.ipv6now.com.au/pingme.php

Perfetto, siamo belli, biondi e con gli occhi azzurri.

Terzo Step: La nostra LAN full IPv6

A questo punto abbiamo messo il firewall Stormshield a valle del pfSense (abilitandolo all'IPv6) in bridge, così da consentire l'adozione degli IPv6 pubblici su tutta la LAN. Il NAT su IPv6 non è necessario e da un punto di vista di sicurezza, in verità, non apporta alcun beneficio rispetto ad un filtro ben strutturato... anzi.

Configurato correttamente il Firewall in bridge, potremo notare sull'interfaccia out il traffico IPv6 mediante un tcpdump:

A questo punto abbiamo messo un server vmware direttamente connesso all'altra interfaccia del bridge sul firewall, così da poter installare due macchine virtuali, una Linux ed una Windows.

NB: Abbiamo abilitato sul firewall il DHCP6 Server, tuttavia esso non era indispensabile avendo lasciato abilitati i protocolli di Router Advertisemen (RA), di cui tuttavia ci occuperemo in un prossimo articolo.

A conti fatti, l'architettura che abbiamo realizzato è la seguente:

Qualche test

A questo punto abbiamo la nostra rete Full IPv6, ovvero ora non sussiste alcun IPv4 tradizionale (per la cronaca, il protocollo IPv4 è stato proprio disabilitato all'interno delle VM).

Le VM navigano (sui siti, pochi, IPv6 abilitati). Ovviamente Debian si è riuscito nativamente a scaricare i suoi aggiornamenti fin dalla fase di installazione. Come DNS abbiamo messo (quando facevamo da DHCP6 Server) i DNS6 di CloudFlare 2606:4700:4700::1111 e 2606:4700:4700::1001.

In sostanza, le due macchine tra di loro si pingano, raggiungono l'esterno e sono contattabili dall'esterno. Hanno, di fatto, degli IP pubblici. In questa fase non sono stati messi dei filtri, ne parleremo più avanti, è un laboratorio. Da notare che questa architettura non utilizza ovviamente NAT. Era banale da precisare (trovandoci in Bridge), ma è importante entrare nell'ottica che il NAT appartiene al mondo IPv4, e non a quello IPv6 (il NAT-PT è un'altra storia, prima o poi lo approfondiremo).

A questo punto, non posso che augurare al lettore sopravvissuto "buon divertimento" con i nuovi host IPv6 only. Buoni esperimenti!

E poi?

Le domande che a questo punto il lettore dovrebbe essersi già posto sono:

• In una rete fullbridge (un po' come accade nei campus), come faccio a creare delle policy di firewalling?
• In una rete fullbridge, come gestisco le VLAN e la relativa compartimentazione?
• Il DHCPv6 Relay che vedo ha più IP, che ruolo ha la Router Advertisement (RA) in tutto questo?
• Perchè la mia scheda di rete ha un indirizzo speciale fe80::/10 valido (da RFC) per lo specifico link fisico? (ovvero: cosa significa link fisico?? Che centrano i layer più bassi? Parleremo di Scope Address, un nuovo concetto) 
• Facciamo alcune considerazioni di sicurezza, l'assenza del NAT semplifica di molto la gestione (NO! Il NAT non si applica per motivi di sicurezza ma solo per incrementare il numero di IPv4 utilizzabili!), inoltre il numero sproporzionato di indirizzi IPv6 rende difficoltoso il lavoro degli scanner generici. Tralasciando le fantasie sul supporto IPsec nativo di IPv6 rispetto a IPv4, che altri scenari si aprono sotto il fronte security?

Ne parleremo nel prossimo articolo, nel frattempo sarebbe interessante confrontarci sul tema. Lasciate pure nei commenti i vostri contatti (se personali non li pubblicherò, i commenti sono moderati). Ogni confronto è bene accetto, anche non necessariamente epistolare.

RA su StormShield

RA su pfSense

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

MicroFollie dei filtri antispam Outlook/Live/Hotmail

Come molti dei miei lettori sanno, uno dei nostri prodotti di punta è il DM Pro, ovvero un MailServer basato su piattaforma Linux con Postfix come MTA. Inizialmente abbiamo avviato questo progetto timidamente, per poi acquisire sempre maggior know-how nel corso di questi intensi 8 anni di attività. Ne abbiamo viste di tutti i colori ed il nostro osservatorio umano ha classificato e creato oltre 25.000 regole personalizzate e specifiche per combattere lo spam. Insomma, la posta elettronica è un argomento complesso "sotto al cofano", ma è anche uno di quei settori dove abbiamo investito maggior tempo.

Purtroppo accade che alcuni grandi nomi decidano di non rispettare i protocolli standard (abbiamo in passato già parlato dei "capricci" di Microsoft in questo articolo) ed implementino variabili spesso fantasiose degli stessi. Anche per questo motivo può accadere che una email perfettamente lecita e formattata, inviata da un MailServer perfettamente configurato, finisca nello spam.

Per i meno addetti ai lavori, finire o meno in spam è una questione di reputazione. Migliore sarà la reputazione del mio MailServer, più probabilità ho di recapitare un'email al mio destinatario. Definiamo però reputazione perchè, in questo caso, reputazione è una parola che ha un ampio respiro. Fondamentalmente ci sono due momenti in cui un'email può essere rifiutata:

1. In fase di contatto con l'MTA: ovvero quanto il mailserver mittente si presenta a quello di destinazione. Se vieni escluso in questa fase, probabilmente l'hai fatta grossa. Si tende, infatti, a limitare il rifiuto in questa fase in quanto il reject darà un errore di tipo 5.x.x, ovvero l'email verrà rifiutata senza se e senza ma. E' il caso (spesso, poi ognuno configura il proprio server come meglio crede) di un'email contenente un virus, o listata in una RBL particolarmente affidabile, o magari in caso di email inviata da una classe di IP pubblici.
2. In fase di analisi: ovvero quando l'email ha passato i primi controlli, è stata totalmente scaricata e presa in carico dall'MTA e viene inviata al motore antispam (tipicamente SpamAssassin). Qui possiamo fare un controllo aggiuntivo che prima non potevamo fare, ovvero leggerne il contenuto intero (il body) e muoverci di conseguenza. A questo punto ogni cosa sviluppa un punteggio, al superamento di una soglia l'email verrà classificata come spam (e normalmente contrassegnata e spostata comunque dall'LDA nella casella di destinazione ma nella directory IMAP Junk). Un testo bianco su sfondo bianco, ad esempio, svilupperà un punteggio di 0.3, che si aggiungerà (sepre ad esempio) al punteggio di 3.0 se il link all'interno dell'email è ritenuto spam da una DBL, e così via. La soglia standard è 7, se l'email supera questo punteggio è spacciata. Un'email perfetta ha ottenuto un punteggio di 0.

Il fattaccio

Ebbene, ultimamente abbiamo notato che i filtri antispam di Microsoft (applicati quindi a Hotmail, Outlook, Live e tutti i servizi correlati) penalizzano MailServer perfettamente leciti la cui colpa è, probabilmente, non aver acquistato un prodotto Office 365.

Ma andiamo con ordine. Il MailServer in questione è stato perfettamente configurato:

• Reverse DNS perfetto
• Protocollo SPF perfettamente implementato
• Protocollo DKIM perfettamente implementato
• Protocollo DMARC perfettamente implementato
• Punteggio ottenuto con mail-tester.com di 10/10 (il massimo, qui un punteggio alto invece è positivo)

ma le email ad un indirizzo hotmail finiscono in "indesiderata".

Apriamo un ticket al provider che erroneamente classifica l'email come spam e l'operatore, onestamente ignaro delle motivazioni astruse che stanno alla base del diniego nel recapito della posta, ci risponde di iscriverci al programma Outlook SNDS e al programma Outlook JMRS. Rispettivamente un programma di analisi reputazionale degli indirizzi IP e di reportististica dello spam.

Bene, ai punti sopra, quindi aggiungiamo:

• Iscrizione al programma SNDS per gli IP correlati agli MX
• Iscrizione al programma JMRS per i domini gestiti

Ma nulla, le email continuano inspiegabilmente a finire in spam nonostante il monitoraggio indichi come status "normal", ovvero senza alcun problema.

In qualche meandro della rete si vocifera che randomicamente un'email inviata da un altro client di posta (ad esempio Thunderbird) venga ritenuta spam solo perchè l'utente non ha come molti acquistato Outlook, ma noi non vogliamo crederci. Proviamo con Outlook e, ad onor del vero, anche qui l'email finisce in spam.

Il caso di "bullismo informatico" da parte del colosso verso il piccolo qui diviene evidente, ci impuntiamo, siamo certi di aver fatto le cose per bene e incalziamo pretendendo una risposta. Il supporto tecnico ci risponde:

Apply for the Sender Score Certified Mail program.
If you are doing all the above and you continue to have deliverability issues, you may wish to consider joining the Sender Score Certified Mail Program, a third party program administered by Return Path, Inc. Many legitimate mailers and marketers have qualified and joined this program to improve mail deliverability and decrease email from being filtered to the Junk E-mail Folder. Sender Score (https://returnpath.com/solutions/email-deliverability-optimization/ip-certification/) is the only service to which we subscribe.

Che per i più pigri significa:

Se stai facendo tutto quanto sopra e continui ad avere problemi di consegna, potresti prendere in considerazione l'idea di aderire al Programma di posta certificata Sender Score, un programma di terze parti gestito da Return Path, Inc. Molti mailer e rivenditori legittimi si sono qualificati e si sono uniti a questo programma per migliorare la consegna della posta e ridurre il filtraggio della posta nella cartella Posta indesiderata. Il punteggio mittente (https://returnpath.com/solutions/email-deliverability-optimization/ip-certification/) è l'unico servizio a cui ci abboniamo.

In sostanza: se il tuo MailServer è perfettamente configurato ma la tua unica colpa è non utilizzare un nostro software o un nostro servizio, allora per consegnarci la posta puoi iscriverti a pagamento a questo servizio esterno.

Forse è uno scherzo, il primo aprile è distante, ma magari c'è stato un cambiamento nel calendario americano, chi lo sa. Rispondo alle 7.53 indicando che una risposta simile non è accettabile, noi siamo in regola, abbiamo fatto tutte le cose per bene e devono approfondire il ticket.

Mi arriva un'email alle 8.11:

Thank you for contacting Microsoft Technical Support. The service request has been archived due to inactivity. If you still require assistance, please contact us via support.microsoft.com or 1-800-Microsoft.

Onestamente per molto meno Microsoft ha ricevuto multe milionarie e la prepotenza e l'arroganza di chi si sente in diritto di dettare leggi in un mondo che segue standard e regole, è imbarazzante. E questo si aggiunge all'incredibile politica di licensing folle basata su core che ha aumentato, in molti casi, il costo dei sistemi operativi di svariati ordini di grandezza. Ma questa è un'altra storia e, soprattutto, del tutto lecita. 

In ogni caso, manterrò aggiornato questo articolo.