12. Considerazioni sulla Sicurezza

Questa sezione tratta le considerazioni sulla sicurezza specifiche di DMARC.

12.1. Metodi di Autenticazione

DMARC è costruito sopra SPF e DKIM. La sicurezza di DMARC dipende quindi dalla sicurezza di questi meccanismi sottostanti. Gli implementatori devono avere familiarità con le considerazioni sulla sicurezza sia di SPF [SPF] che di DKIM [DKIM].

Punti chiave:

1. Sicurezza SPF: SPF può essere aggirato se un attaccante può inviare posta attraverso un server autorizzato nel record SPF.

2. Sicurezza DKIM: Le firme DKIM possono essere falsificate se la chiave di firma è compromessa. La gestione delle chiavi è critica.

3. Sicurezza combinata: Il requisito di DMARC per l'Identifier Alignment fornisce un'autenticazione più forte rispetto a SPF o DKIM da soli.

12.2. Attacchi agli URI di Report

Un attaccante potrebbe tentare di far sì che i ricevitori di posta inviino grandi volumi di report all'indirizzo di una vittima:

1. Pubblicando un record DMARC per un dominio sotto il controllo dell'attaccante con l'indirizzo della vittima nei tag "rua" o "ruf".

2. Inviando grandi volumi di posta non autenticata che afferma di provenire da quel dominio.

Il meccanismo di verifica descritto nella Sezione 7.1 previene questo attacco richiedendo che le destinazioni di report esterne autorizzino esplicitamente la relazione di reporting.

Inoltre, i ricevitori di posta dovrebbero:

• Implementare la limitazione del tasso sulla generazione di report
• Monitorare i pattern di reporting insoliti
• Rispettare le richieste di cancellazione dai destinatari dei report

12.3. Sicurezza DNS

DMARC si basa pesantemente sul DNS per la distribuzione delle policy. Le considerazioni sulla sicurezza DNS includono:

1. Spoofing DNS: Un attaccante che può falsificare le risposte DNS potrebbe:

   • Fornire una falsa policy DMARC
   • Reindirizzare i report a un indirizzo controllato dall'attaccante
   • Causare denial of service rimuovendo i record delle policy

2. DNSSEC: L'uso di DNSSEC può mitigare i rischi di spoofing DNS. Gli implementatori dovrebbero considerare di distribuire DNSSEC per i domini che pubblicano policy DMARC.

3. Cache Poisoning: Il cache poisoning DNS potrebbe causare la memorizzazione nella cache e l'applicazione di policy DMARC errate.

12.4. Attacchi al Nome Visualizzato

DMARC non protegge dagli attacchi alla parte del nome visualizzato del campo RFC5322.From. Un attaccante può utilizzare un nome visualizzato che appare affidabile mentre utilizza un dominio diverso nell'indirizzo:

From: "Banca Affidabile" <[email protected]>

Gli utenti potrebbero vedere solo "Banca Affidabile" e non notare il dominio mittente effettivo. Questa limitazione è esplicitamente notata come fuori ambito nella Sezione 2.2.

L'educazione degli utenti e i miglioramenti del MUA (come la visualizzazione prominente dell'indirizzo email effettivo) sono necessari per affrontare questa minaccia.

12.5. Indirizzi di Report Esterni

Quando i report DMARC vengono inviati a indirizzi esterni (indirizzi presso domini diversi da quello su cui si sta facendo il report), si applicano diverse considerazioni sulla sicurezza:

1. Esposizione dei dati: I report contengono informazioni sull'infrastruttura email del dominio e sui pattern di traffico. Queste informazioni potrebbero essere preziose per gli attaccanti.

2. Fiducia nelle terze parti: I proprietari di domini devono fidarsi dei destinatari di report di terze parti per:

   • Gestire i dati dei report in modo sicuro
   • Non abusare delle informazioni
   • Conformarsi alle normative applicabili sulla privacy

3. Verifica: Il meccanismo di verifica nella Sezione 7.1 garantisce che le destinazioni esterne siano autorizzate, ma i proprietari di domini dovrebbero comunque considerare attentamente quali informazioni stanno condividendo.

12.6. Protocolli Sicuri

Sebbene DMARC stesso non richieda l'uso di protocolli sicuri specifici, gli implementatori dovrebbero considerare:

1. DNSSEC: Come menzionato nella Sezione 12.3, DNSSEC può proteggere dagli attacchi di spoofing DNS.

2. TLS per i report: Quando si inviano report via email, l'uso di STARTTLS o altri meccanismi di crittografia protegge il contenuto dei report in transito.

3. HTTPS per gli URI di report: Se future estensioni consentono URI HTTPS per la consegna dei report, TLS dovrebbe essere utilizzato per proteggere i dati dei report.

4. Archiviazione sicura delle chiavi: Le chiavi private DKIM devono essere archiviate in modo sicuro per prevenire la compromissione.

---