Sicurezza Email6 min
Roundcube Violato: Come Verificare e
Hacker sospettati di legami cinesi hanno bucato Roundcube in università americane. Se gestisci questo webmail, devi verificare SUBITO se sei compromesso. Ecco come.
LeggiTL;DR
- Cosa impari: come i criminali sfruttano la zona DNS
.arpae IPv6 reverse DNS per far passare phishing inosservato - Tempo richiesto: 10 minuti di lettura, 30-45 minuti per verificare le tue regole
- Difficoltà: medio-alta — serve accesso ai log del gateway email e conoscenza base di DNS e IPv6
Il problema
Se stai leggendo questo, probabilmente hai visto email di phishing passare che non avrebbero dovuto passare. SPF: pass. DKIM: pass. DMARC: pass. Reputazione dominio: ok. Eppure il tuo collega ha quasi cliccato su un link che scaricava un payload.
Non sei tu a sbagliare qualcosa. È una tecnica che sta girando tra i gruppi di threat actor più svegli in circolazione.
Il trucco: usare la zona DNS .arpa.
Come funziona il DNS al contrario
Quando il tuo gateway email riceve un messaggio, fa un controllo di reputazione sull'IP mittente. Manda una query PTR — cioè una ricerca DNS inversa — per sapere a che nome corrisponde quell'indirizzo IP.
In IPv4 queste query finiscono nella zona in-addr.arpa. In IPv6 finiscono nella zona ip6.arpa. Entrambe sono parte della stessa radice .arpa, che è un dominio speciale gestito da IANA, usato per infrastruttura DNS di base.
Ecco il punto critico: molti sistemi di reputazione trattano .arpa come dominio infrastrutturale legittimo. Non è in nessuna blacklist. Non ha storia di spam. È tecnicamente "neutro".
I threat actor hanno capito che se costruiscono i loro PTR record in modo da puntare a sottodomini .arpa con nomi apparentemente legittimi, il controllo di reputazione vede qualcosa come:
PTR: mail.gateway.telco-provider.ip6.arpa...e alcuni gateway lo trattano come un provider di telecomunicazioni affidabile. Spoiler: non lo è.
Il problema con IPv6
IPv6 complica ulteriormente la situazione. Un indirizzo IPv6 completo ha 128 bit, che in formato PTR diventano una stringa di 32 caratteri separati da punti, al contrario. Così:
2001:db8::1Diventa:
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpaMolti strumenti di reputation check fanno parsing di queste stringhe in modo superficiale. Cercano pattern noti, nomi di provider, keyword sospette. Una stringa così lunga e strutturata li manda in confusione.
E i threat actor li aiutano: registrano blocchi IPv6 (facili da ottenere, spesso gratuiti o quasi) e impostano PTR record che sembrano appartenere a provider legittimi.
Prerequisiti
Per seguire questa guida ti serve:
- Accesso admin al tuo gateway email (on-premise o cloud)
- Possibilità di fare query DNS manuali (dig, nslookup o qualsiasi tool equivalente)
- Accesso ai log SMTP in entrata, con visibilità su IP mittente, PTR e risultati SPF/DKIM/DMARC
- Facoltativo ma utile: un account su VirusTotal o MXToolbox per cross-check reputazione
Non devi essere un esperto di IPv6, ma aiuta capire la struttura base degli indirizzi e dei PTR record.
Step-by-step: come analizzare e mitigare l'attacco
Step 1 — Controlla i tuoi log per PTR sospetti con .arpa
Il primo passo è capire se il problema esiste già nel tuo ambiente. Vai nei log SMTP del tuo gateway e cerca connessioni dove il PTR dell'IP mittente contiene .arpa ma non segue pattern di provider noti.
Se hai accesso a una console Linux con i log, prova:
grep -i 'ip6.arpa\|in-addr.arpa' /var/log/maillog | grep -v 'PASS\|authenticated'Cosa cerchi: PTR record che hanno struttura strana, come sottodomini .arpa con nomi che sembrano provider ma che non riesci a verificare.
Esempio di PTR legittimo:
mail.example-provider.comEsempio di PTR sospetto:
outbound.smtp.eu-west-mail.ip6.arpaIl secondo sembra legittimo. Non lo è.
Step 2 — Verifica manuale di un PTR sospetto
Per ogni PTR che ti insospettisce, fai una verifica forward-confirmed reverse DNS (FCrDNS). Cioè:
- Prendi l'IP mittente
- Fai la query PTR per trovare il nome host
- Fai una query A o AAAA su quel nome host
- Il risultato deve corrispondere all'IP di partenza
# Esempio con dig
dig -x 2001:db8::1 +short
# Risposta: outbound.smtp.eu-west-mail.ip6.arpa.
dig AAAA outbound.smtp.eu-west-mail.ip6.arpa +short
# Risposta: deve tornare 2001:db8::1 per essere validaSe la risposta forward non corrisponde all'IP originale, o non risponde affatto, hai un PTR non verificabile. Questo è un segnale di allarme.
Molti gateway, purtroppo, non fanno questa verifica FCrDNS per default.
Step 3 — Aggiungi una regola per bloccare PTR non verificabili
Qui dipende dal tuo gateway, ma il concetto è universale: rifiuta o metti in quarantena le email che arrivano da IP il cui PTR record non supera il check FCrDNS.
Su Postfix, per esempio:
# In main.cf
smtpd_recipient_restrictions =
reject_unknown_reverse_client_hostname,
...reject_unknown_reverse_client_hostname rifiuta connessioni da IP che non hanno PTR record valido. Per casi più sofisticati come questo, aggiungi anche la verifica forward:
smtpd_recipient_restrictions =
reject_unauth_pipelining,
reject_unknown_reverse_client_hostname,
reject_unknown_client_hostname,
...Su altri gateway (Postfix, Exim, Exchange) la logica è simile ma la sintassi cambia. Cerca la voce corrispondente a "reverse DNS validation" o "FCrDNS check" nelle impostazioni.
Step 4 — Filtra i PTR che terminano direttamente in .arpa senza hostname leggibile
Un PTR legittimo di un provider email finisce con un hostname comprensibile, non con la notazione numerica raw. Aggiungi una regola per bloccare o aumentare lo spam score quando il PTR record è nella forma pura ip6.arpa senza prefisso descrittivo.
Esempio di regola SpamAssassin:
header ARPA_PTR_ONLY X-Originating-IP =~ /^\d/
rawbody __ARPA_RDNS /\.ip6\.arpa\.?$/
meta ARPA_SUSPICIOUS ARPA_PTR_ONLY && __ARPA_RDNS
score ARPA_SUSPICIOUS 3.5Adatta la logica al tuo sistema. L'idea è semplice: un IP mittente che ha come PTR solo la notazione reverse numerica, senza un hostname human-readable, è altamente sospetto per l'invio di email.
Step 5 — Verifica la configurazione IPv6 del tuo MTA in uscita
Qui si apre un problema inverso: se il tuo server invia email via IPv6 senza PTR record configurato correttamente, potresti essere tu a finire nei filtri degli altri.
Verifica:
# Trova il tuo IPv6 di uscita
curl -6 https://ifconfig.me
# Poi fai il PTR check
dig -x [tuo-ipv6] +shortSe non risponde nulla, o risponde con la notazione raw, contatta il tuo provider e fai configurare il PTR record correttamente. Esempio di come dovrebbe essere:
mail.tuaazienda.it.Non come appare in molte configurazioni di default:
2001-db8-0-0-0-0-0-1.provider-ipv6-range.ip6.arpa.Step 6 — Aggiungi controlli di reputazione IP sull'header Received
Gli header Received: di un'email mostrano tutti i server che l'hanno attraversata. Estrai gli IP da questi header e cross-checkali contro le principali blacklist IPv6.
Comando rapido:
# Estrai IP da un file .eml
grep -i 'received: from' email.eml | grep -oE '([0-9a-fA-F:]+:+[0-9a-fA-F:]+)'
# Per ogni IP, controlla su DNSBL IPv6
dig +short 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.black.uribl.comLe principali DNSBL con supporto IPv6 includono URIBL, Spamhaus ZEN, e Barracuda Reputation Block List. Molti gateway le interrogano solo per IPv4 — verifica che il tuo lo faccia anche per IPv6.
Verifica
Dopo aver applicato le modifiche, ecco come testare che tutto funzioni.
Test 1 — Invio da IP con PTR sospetto
Usa un servizio come mail-tester.com o costruisci un test interno con un server che abbia un PTR non verificabile. Il tuo gateway dovrebbe rifiutare o mettere in quarantena.
Test 2 — Verifica nei log
# Su Postfix
grep 'unknown reverse client' /var/log/mail.log | tail -20
# Dovresti vedere righe tipo:
# reject: RCPT from unknown[2001:db8::1]: 450 Client host rejected: cannot find your hostnameTest 3 — Cross-check reputazione IPv6
MXToolbox ha un tool di lookup blacklist: inserisci un indirizzo IPv6 sospetto e verifica quante liste lo segnalano. Se un mittente è pulito su tutte le liste ma arriva con PTR .arpa senza FCrDNS valido, la tua nuova regola dovrebbe comunque bloccarlo.
Tool utili:
dig -x [ip] +short— PTR lookup direttohost [ip]— alternativa più leggibile- MXToolbox Blacklist Check (supporta IPv6)
- IPinfo.io — info su ASN e geolocalizzazione dell'IP
Troubleshooting
La regola FCrDNS blocca email legittime da grandi provider
Alcuni provider (soprattutto cinesi o di certi mercati emergenti) non hanno PTR configurati correttamente anche per indirizzi legittimi. Aggiungi whitelist per ASN o range IP di provider certificati prima di abilitare il blocco duro. Inizia con un'azione di log-only per 48 ore per vedere cosa verrebbe bloccato.
Il gateway non supporta query PTR per IPv6
È più comune di quanto pensi, soprattutto su gateway datati. Verifica la versione del software e le note di rilascio. Se IPv6 PTR non è supportato, considera di abilitare la preferenza IPv4 per le connessioni SMTP in entrata nel breve termine mentre aggiorni.
Il PTR sembra legittimo ma l'email è phishing
Queste tecniche evolvono: PTR valido + dominio registrato da pochi giorni + nessuna storia email. Affianca la verifica PTR con controlli sull'età del dominio (puoi usare whois o servizi RDAP) e con analisi comportamentale del contenuto. Un gateway che analizza solo il perimetro SMTP non è sufficiente — serve analisi del contenuto. I filtri di MailSniper usano AI semantica che legge il contenuto del messaggio, non solo l'infrastruttura di invio.
Score spam alto ma messaggio non in quarantena
Verifica le soglie configurate. Molti gateway hanno soglie di default troppo alte (score 10+) per non generare falsi positivi. Con tecniche evasive come questa, un'email può accumulate 4-5 punti senza superare la soglia. Considera di abbassarla a 6-7 con test graduali.
Log mostrano PTR diverso da quello che vedi con dig
Il gateway potrebbe usare resolver DNS diversi con TTL cacheati. Svuota la cache del resolver DNS locale del gateway dopo ogni modifica alle regole PTR.
Conclusione
Questa tecnica è l'ennesima conferma che le difese perimetrali basate su reputazione non bastano da sole. I threat actor hanno imparato a navigare nell'infrastruttura DNS come se fosse casa loro.
I passi da portare a casa:
- Abilita FCrDNS check sul tuo gateway, anche per IPv6
- Logga e analizza i PTR record dei mittenti per 48 ore prima di applicare blocchi
- Aggiungi DNSBL IPv6 se non le hai già
- Verifica che il tuo server in uscita abbia PTR corretto — o sei tu il sospetto
- Affianca i controlli infrastrutturali con analisi del contenuto
Per chi non vuole gestire tutto questo manualmente, ha senso guardare a soluzioni che fanno questi controlli in automatico e in tempo reale — come funziona MailSniper mostra nel dettaglio come vengono gestiti i controlli reputazione IP, PTR e analisi contenuto in parallelo.
Il DNS è vecchio quanto internet. Ma usarlo contro di te? Questo è nuovo.