L'uso dei domini non registrati nei record SPF introduce un rischio per la sicurezza?

Naviga le tue risposte
1

Recentemente stavo leggendo la sintassi del record Sender Policy Framework (SPF) su OpenSPF.com.

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators. - Wikipedia

Ho notato che la sintassi SPF ci consente di utilizzare il "meccanismo di esistenza". Di seguito è riportato un esempio:

In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.

v=spf1 exists:example.com -all.

If example.com does not resolve, the result is fail. If it does resolve, this mechanism results in a match. - OpenSPF.com

Se sono corretto, solo example.com è autorizzato a inviare email, tutti gli altri mittenti sono contrassegnati come SPAM a causa del flag% fail% co_de. Supponiamo di aver usato il precedente record SPF sul dominio -all .

Quindi, example.org consente a example.org di inviare email in nome di example.com .

Ora supponiamo il dominio example.org scade ed è gratuito per la registrazione di nuovo e il record SPF sopra il example.com soggiorni invariati (leggi: indica example.com). In questo caso il record SPF di example.org avrà esito negativo su tutte le email poiché l'unico dominio consentito non esiste più.

Ora se un utente malintenzionato registra il dominio example.org disponibile. Quindi è in grado di inviare SPAM in nome di example.org, mentre il record SPF non gli impedirà di farlo?

In altre parole, se esiste l'uso dell'SPF, il meccanismo deve essere contrassegnato come un rischio potenziale? Oppure, l'utilizzo del meccanismo "esiste" di SPF introduce un rischio per la sicurezza?

Lo stesso vale per example.com , include: , ptr: e a: quando si punti a un dominio non registrati.

    
posta Bob Ortiz 05.07.2016 - 02:13
fonte

2 risposte

1

Non hai davvero capito il significato degli ESISTE, credo. Quello che descrivi (consenti a esempio.com di inviare posta da example.org) sarebbe INCLUSO! INCLUDE: example.com significa vedere il record spf per example.com e applicare le regole.

EXISTS è molto più semplice. Significa "Se il DN specificato si risolve in qualsiasi indirizzo, corrisponderà (indipendentemente dall'indirizzo a cui si risolve)."

Quindi la regola "v = spf1 esiste: example.com -all" è davvero inutile. Significa che example.com ha un set IP, passa la regola, altrimenti fallisce.

La regola EXISTS ha senso solo con macro . Ad esempio, è possibile utilizzare v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all per fare in modo che il destinatario controlli una blacklist IP e fallisca se l'indirizzo IP del mittente è nella lista nera. Potresti anche fare cose come controllare se l'utente esiste per il dominio e roba molto più potente.

Alla tua domanda se questo dovrebbe essere "contrassegnato come un potenziale rischio". No, non c'è più rischio rispetto a qualsiasi altra configurazione SPF. Se hai impostato SPF errato, potresti creare problemi. Ma questo è sempre un rischio. Se usi qualcosa di sbagliato, possono accadere cose brutte. ESISTE o anche INCLUDE non è più un rischio rispetto ad altre opzioni SPF.

    
risposta data 05.07.2016 - 10:40
fonte
1

SPF utilizza qualificatori (Pass, HardFail, SoftFail, Neutral) per determinare il livello di validità di una richiesta.

I qualificatori sono determinati controllando qualsiasi o anche tutti i seguenti meccanismi configurati:

ALL: corrisponde a tutto ciò che non è già definito da un altro meccanismo che corrisponde al meccanismo di tutti

A: Se il nome di dominio ha un record di indirizzo (A o AAAA) che può essere risolto all'indirizzo del mittente, corrisponderà.

IP4 / IPv6: se il mittente si trova in un determinato intervallo di indirizzi IPv4 / IPv6, corrisponderà.

MX: se il nome di dominio (DN) ha un record MX che risolve l'indirizzo del mittente, esso corrisponderà (come se la posta provenga da uno dei server di posta in arrivo del dominio).

PTR: se il DN (record PTR) per l'indirizzo del cliente si trova nel dominio specificato e tale DN si risolve nell'indirizzo del client (DNS inverso inoltrato-confermato), corrisponde. Questo non è più utilizzato.

ESISTE: se il DN specificato si risolve in qualsiasi indirizzo, corrisponderà (indipendentemente dall'indirizzo a cui si risolve). Questo è usato raramente. Insieme al linguaggio macro SPF offre partite più complesse come le query DNSBL.

INCLUDE: se la politica inclusa supera il test questo meccanismo corrisponde. Questo in genere viene utilizzato per includere le politiche di più di un ISP.

Quindi spetta all'amministratore scegliere un livello di sicurezza appropriato che copra i suoi bisogni. La risposta è no, un utente malintenzionato non sarà in grado di trarre profitto come nel tuo esempio, dato che l'amministratore ha reso il minimo necessario per una corretta implementazione di SPF.

    
risposta data 05.07.2016 - 09:32
fonte

Leggi altre domande sui tag

Rischia di evitare il rilevamento di AdBlock importando cookie o simulando la visualizzazione di annunci L'attaccante sa cosa faccio online e ha anche degli screenshot dal mio computer - come?