Em Tecnologia de Informação há um conceito antigo chamado de “AAA Architecture” (AAA vem de “Authentication, Authorisation and Accounting”, i.e. Autenticação, Autorização e Registo. Cada um destes tem um objectivo específico que vou ultra simplificar de seguida: – Autenticação: Elemento usado como prova de identidade. (QUEM) – Autorização: Elemento usado para definir o que se […]
Em Tecnologia de Informação há um conceito antigo chamado de “AAA Architecture” (AAA vem de “Authentication, Authorisation and Accounting”, i.e. Autenticação, Autorização e Registo. Cada um destes tem um objectivo específico que vou ultra simplificar de seguida:
– Autenticação: Elemento usado como prova de identidade. (QUEM)
– Autorização: Elemento usado para definir o que se é permitido fazer. (ONDE)
– Registo: Inscrição de factos e/ou actos em arquivo. (QUÊ/QUANDO)
Quando penso em Autenticação de Email (termo genérico dado a DMARC, SPF e DKIM), lembro-me sempre das minhas raízes em “Dados & Comunicações” e o quanto se parece com uma versão moderna e apurada, do clássico AAA.
Digamos que AAAP-Email (Authentication – DKIM, Authorisation – SPF, Accounting -DMARC and Policy de Email) é uma marca pela qual, a equipa de TI tem grande estima e consequentemente, não querem com certeza que seja usada para fins indevidos. Para mitigar o risco de o seu domínio “aaap.email” ser usado para phishing, foi implementada a configuração AAAP que passo a detalhar.
Contents
O que são o DKIM, DMARC e SPF e qual o seu objetivo?
Autenticação/DKIM
DomainKeys Identified Mail é definido através de um registo TXT no DNS do domínio:
“v=DKIM1;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV5OtEvd65r2LA2+qJBX3BmgbZw9ToHstygvbVIwv2N76NrJMq1d+C8KpXhC5EzO/3tKkKXNg8K3c1a8WQX4n1kkP7q5dcMyibBC209szXsLBoipr7G6nZFruE5cKTSQQ++4xuNzALWvtWeFnmOhfUdRWh693mFOvlX7j9ZId44wIDAQAB”
Através de cálculos matemáticos é verificado se a mensagem foi de processada por QUEM indicado e se mantém a integridade, usando a parte “secreta”:
“—–BEGIN RSA PRIVATE KEY—–
MIICXAIBAAKBgQDV5OtEvd65r2LA2+qJBX3BmgbZw9ToHstygvbVIwv2N76NrJMq
1d+C8KpXhC5EzO/3tKkKXNg8K3c1a8WQX4n1kkP7q5dcMyibBC209szXsLBoipr7
G6nZFruE5cKTSQQ++4xuNzALWvtWeFnmOhfUdRWh693mFOvlX7j9ZId44wIDAQAB
AoGAFZzB4PpGbQC5u7783cd+Q3eqxYoyExo5eGKfSj32UXSkfnA3lpZxtStYKuui
OTVz8dWBVxi2iK3jp7QyDDp7F/O8p6doEAWVYZyJe5SAMLQKrJ7x8bjzntkga35C
kPNlzSUvTACTxTf2JPedy97uvpVvqI7OrZ6Lls+XD8MwCiECQQD7VjI9qqb71L3h
7b4XlhYMhaEivOST0wu9unsEJiytsZjLzUIA/XTO5MyDKyvoFU+99kDSlCo0uZeJ
85ckg3vZAkEA2dzgsyKe4ohk1IDAmGZCrRUufEH1BGx/Ydi7YJCaBk1LEVf8DCU4
TpFItegoAacR5BzALpR74u7oWSOs1PARGwJBAK58huCc6tSGO1TwMjo5rhD/bICr
VpzxtYMARYr53aawVv2WAC6jx0YjPYAKpq62rOeaYCJRToPQHM5e2B03UvECQBQB
ZljMuw5OPAQPdqAH8+N06HncjKVFWUUg48PwQ1SE0HndPHXZDRyZ1rVthg7wyoHJ
6hPc6qtiCM/2qK49BTUCQDUSBxiOyanPw0d4GhGDh4QUcBDDsumyKwxnBNP1aF5t
VLT8LzzIWYiC7Zmfq3JfI0FidDr9vygPFE5VfRU7Q8E=
—–END RSA PRIVATE KEY—–“
(Boa! Eu adoro matemática, mas neste caso estou feliz por estes cálculos serem feitos por máquinas!) 🙂
Tem como objetivo assinar a mensagem o que permite a validação da autenticação e integridade no destino. Usa a relação matemática entre congos componentes numéricos; sendo que um deles é publicitado via um registo de DNS; sendo o outro secreto, é cuidadosamente guardado e do conhecimento exclusivo de quem envia.
Autorização/SPF
Sender Policy Framework é uma manifestação pública (novamente via um registo de DNS) de quais os IPs que têm permissão para enviar mensagens.
Tecnicamente é um registo de DNS contendo os IPs com permissão para envios de email do domínio (de ONDE) “aaap.email”. Neste caso específico apenas os servidores de email (mx):
“v=spf1 mx -all”
Por favor, note que sendo o SPF o pioneiro, inclui também uma política de preferência própria; o “-all” significa a ser considerado irregularidade e o “~all” apenas um possível equívoco (uma vez, que poder-se-á tratar ainda de experimentação).
Registo (DMARC)
Registo (Accounting)/DMARC: Domain-based Message Authentication, Reporting & Conformance esclarece o QUE deve ser feito às mensagens que falham a autenticação e/ou autorização (DKIM/SPF), assim como QUANDO, a frequência e para quem deve ser enviado os relatórios do QUE foi detectado vindo do domínio.
“v=DMARC1; p=reject; rua=mailto:dmarc@aaap.email; ruf=mailto:forensic@aaap.email; rf=afrf; pct=100;”
O toque extra do DMARC é que proporciona a declaração da Política a aplicar às mensagens, em caso de discrepâncias no SPF e/ou DKIM.
Conclusão
Se algum sujeito mal intencionado tentar usar o domínio para enviar mensagens “spoofed” (boas velhas gírias) para phishing, os servidores de destino vão consultar todos os elementos necessários directamente no DNS do domínio e com estes, aferir a veracidade e integridade da origem anunciada e em caso de violação, quais as acções que deve tomar seguindo a política do domínio (e pelo domínio) declarada o que significa neste caso a rejeição. (indicado pela parte “p=reject”; a minha política é a de rejeição das mensagens em caso de incumprimento) tornando menor o risco.
Essas mensagens não vão chegar a lado nenhum. Essa é uma das razões pela qual a configuração manual do DKIM, SPF e DMARC são tão importantes. A marca em si permanecerá intacta e consequentemente, respeitável.