Nos bastidores: as configurações feitas em @gov.br para barrar emails falsos
Emails falsos com endereços reais não são raros, mas há prevenção; conheça os principais mecanismos e o que foi feito no caso @gov.br
Você recebe um email que te deixa em pânico. Para ter certeza sobre o que aparece ali, você analisa a mensagem e nota que o conteúdo é fraudulento. Ufa! Mas, espera: o remetente mostra um endereço legítimo! Como pode? Olha, esse tipo de email falso é comum, tanto que, recentemente, vimos um exemplo que trazia um endereço @gov.br.
Acredite em mim: disparar emails falsos e colocar neles remetentes baseados em domínios reais não é difícil. É por isso que golpes por email são tão frequentes.
A boa notícia é que existe proteção. A má é que os mecanismos preventivos não são “instalados de fábrica”: eles precisam ser implementados pelo administrador do domínio. É aí que os problemas — ou as soluções — começam. Você vai descobrir o porquê nas próximas linhas.
O email é “frágil” por natureza
Não tem outro jeito: falar em segurança de email requer mergulhar em uma piscina de termos técnicos. Mas não se preocupe. Eu vou explicar o significado e o contexto de cada um deles.
Comecemos por um dos alicerces do email: o SMTP (Simple Mail Transfer Protocol). Esse é o nome do protocolo que permite a um email ser enviado de um servidor a outro — ou seja, que faz a mensagem sair da origem para chegar ao destino.
Resumidamente, o processo funciona assim: quando um email é enviado, o servidor SMTP do serviço que você usa entrega a mensagem imediatamente caso o destinatário tenha o mesmo domínio que o seu (por exemplo, quando origem e destino têm endereço @tecnoblog.net); se o domínio for diferente, o servidor SMTP se conectará a outros até o destinatário ser alcançado.
Quando o servidor SMTP de destino é encontrado, este encaminha a mensagem a um servidor IMAP (Internet Message Access Protocol) ou POP3 (Post Office Protocol) que, por sua vez, a disponibilizará ao usuário.
Toda essa dinâmica funciona bem, mas o SMTP é um protocolo antigo — as suas especificações remetem ao início dos anos 1980. Sabe o que isso significa? Que o protocolo tem deficiências de segurança, afinal, muitos dos problemas que existem hoje com o email não era previstos naquela época.
Felipe Guimarães, COO da Uni-IT, faz um interessante comparativo com as clássicas cartas em papel:
Na época em que nos comunicávamos por cartas, era possível escrever no envelope que o remetente era o Felipe, e dentro do envelope, no cabeçalho da carta, colocar o remetente como qualquer outra pessoa, com uma mensagem persuasiva para manipular quem lia. (…) O email foi criado exatamente igual, é uma representação daquele sistema, mas na forma digital, inclusive com as fragilidades.
Em outras palavras, o email, da forma como foi criado, permite que o remetente seja falsificado (entre outros problemas). Não seria mais fácil, então, acabar com o email? Não é tão simples. Novamente, Guimarães explica:
Como toda tecnologia, o email vive em constante evolução e ainda é o mecanismo mais bem feito para que exista uma comunicação descentralizada. Digo descentralizado pois cada empresa tem seu servidor e suas configurações, onde todos os seus emails estão, são de sua propriedade, possuem documentos sigilosos anexados e mensagem sensíveis.
Os novos sistemas de comunicações são de processamento, armazenamento e gerência centralizada. No WhatsApp, por exemplo, as mensagens são trafegadas em servidores do Facebook [Meta] sem controle algum da empresa que utiliza este serviço de mensageria como meio de comunicação.
Além dos fatores apontados por Guimarães, o email funciona como um endereço digital, de fato, não exige interação em tempo real, é de fácil utilização, entre outras vantagens.
Se é assim, convém proteger o email, não acabar com ele.
Armas contra emails falsos
No decorrer dos últimos anos, vários mecanismos foram criados para tornar o email mais seguro. No que diz respeito ao combate a mensagens falsas, três deles se destacam (mas não são os únicos): o SPF, o DKIM e o DMARC. Todos têm a função primária de coibir fraudes, mas cada um faz esse trabalho de um jeito diferente:
- SPF: sigla para Sender Policy Framework, o SPF é um mecanismo que checa se o email recebido oriundo de um domínio, como tecnoblog.net, vem de um endereço IP autorizado pelo administrador desse endereço;
- DKIM: essa é a sigla para DomainKeys Identified Mail; com o DKIM, o administrador do domínio estabelece um meio de autenticação baseado em criptografia, de modo que a organização “assina” o cabeçalho do email com uma chave privada e o destinatário confirma a sua autenticidade com a respectiva chave pública;
- DMARC: o DMARC (Domain-based Message Authentication Reporting and Conformance) utiliza tanto o SPF quanto o DKIM para checar a autenticidade de emails; se alguma anormalidade for identificada, a mensagem problemática poderá ser aceita mesmo assim, ficar em quarentena (geralmente, ir para a caixa de spam) ou ser rejeitada no destinatário, tudo dependerá da configuração de DMARC aplicada ao domínio que aparece como remetente daquele email.
Esses três recursos são importantes mecanismos de prevenção de spoofing (quando uma mensagem falsa se passa por algo emitido por uma organização legítima) ou outras fraudes envolvendo emails. Tão importantes que são amplamente aceitos por plataformas de email, como Gmail, Yahoo Mail, Outlook.com e Zoho, só para citar os exemplos mais famosos.
O SPF é importante por indicar quais servidores têm permissão para enviar emails; o DKIM, por checar se a mensagem sofreu adulterações; o DMARC, por executar uma rotina de autenticação que, quando identifica inconsistências, instrui o servidor do destinatário sobre o que fazer (deixar passar, colocar em quarentena ou rejeitar).
“O DMARC tem uma funcionalidade extra, que poucos profissionais de TI ou cibersegurança conhecem, que é a rede de inteligência que pode ser formada, utilizando essa tecnologia”, complementa Guimarães.
Mas há um detalhe crítico: essas proteções precisam ser implementadas proativamente, ou seja, cabe o administrador do domínio ativá-las e configurá-las. Só que muitas organizações — inclusive governamentais — não fazem esse trabalho ou o fazem de maneira incompleta.
Vide o caso do email falso com domínio @gov.br reportado pelo Tecnoblog no início de fevereiro. O problema só aconteceu porque o governo brasileiro não fez a lição de casa, certo? Mais ou menos. Para entendermos essa história, precisamos compreender como os domínios são gerenciados.
Como domínios são organizados (inclusive no Brasil)
Explicando rapidamente, domínios são endereços de sites na internet. Sem ele, você teria que digitar o endereço IP de todo e qualquer serviço web. Mas, provavelmente, isso você já sabe. O que não é tão claro é o fato de esses endereços seguirem uma estrutura hierárquica.
Essa hierarquia é separada por pontos, de modo que os níveis mais elevados, que chamaremos por enquanto de “domínio de topo”, fiquem à direita. É o caso de tecnoblog.net: o domínio em si é “tecnoblog” e o domínio de topo é a parte “.net”.
Neste ponto, é válido você saber que os domínios de topo (.net, .com, .br e tantas outras terminações) são chamados de TLD (Top Level Domain).
Há dois tipos de TLD: ccTLD (Country Code Top-Level Domain), que indica domínios direcionados a países (como o .br para o Brasil), e o gTLD (Generic Top-Level Domain), que designa domínios que não são, necessariamente, atrelados a uma região geográfica (como .com e .org).
Domínios gTLD são administrados pela ICANN (Internet Corporation for Assigned Names and Numbers) — você pode registrar esses e outros tipos de domínio facilmente a partir de companhias intermediárias, como Namecheap e Google Domains.
Já endereços ccTLD, via de regra, são administrados por entidades locais. No Brasil, os domínios .br são gerenciados pelo CGI.br (Comitê Gestor da Internet no Brasil) por meio do NIC.br (Núcleo de Informação e Coordenação do Ponto BR).
É por isso que, quando você quiser registrar um endereço .com.br ou .blog.br, por exemplo, deve fazê-lo a partir do Registro.br, serviço do NIC.br criado especificamente para esse fim.
Mas há um tipo de endereço que pessoas físicas ou empresas privadas não podem registrar: aqueles terminamos em .gov.br. Esse tipo de domínio só pode ser usado por órgãos governamentais do Brasil.
Se registar o domínio, tem que protegê-lo
Em abril de 2020, o Recode reportou que muita gente recebeu um email em nome da Organização Mundial da Saúde (OMS) que pedia doações em bitcoins para o combate à COVID-19.
Teve quem acreditasse na mensagem por esta ter como remetente o endereço donate@who.int. De fato, who.int é o endereço internacional da OMS. Mas o email era falso.
Por padrão, os servidores SMTP (de envio de email, relembrando) não checam a identidade do emissor, daí a importância de mecanismos como SPF, DKIM e DMARC serem devidamente configurados.
O Recode constatou que, na época, os administradores do endereço who.int tinham configurado o SPF no domínio, mas não havia nenhuma política de DMARC ativada. Os responsáveis só configuraram o DMARC para rejeitar mensagens que não passam pela autenticação em maio de 2020.
Agora, voltemos para o caso do email @gov.br. Uma consulta de whois no Registro.br mostra que o domínio inss.gov.br, por exemplo, é administrado pela Dataprev. Já o domínio gov.br não é administrado por nenhum órgão específico. Isso significa que não é possível ativar proteções para esse domínio, certo? Na verdade, é.
Dias depois de noticiarmos o email falso com endereço @gov.br, o domínio gov.br passou a apresentar uma configuração de SPF. Mas, se não há nenhuma entidade respondendo por esse domínio na primeira olhada, quem fez essa configuração?
Como o domínio .gov.br foi protegido
Somente a entidade que controla o ccTLD .br poderia dar a resposta: o NIC.br. Em entrevista ao Tecnoblog, Frederico Neves, diretor de serviços e tecnologia da entidade, confirmou que, em 8 de fevereiro, o próprio NIC.br fez não uma, mas duas configurações para coibir emails falsos com endereço @gov.br.
Neste ponto, devo destacar um detalhe: ao digitar ‘gov.br’ no navegador, você verá uma página com vários serviços públicos públicos. Mas repare que o endereço gov.br simplesmente redireciona para www.gov.br, domínio este que está sob os cuidados da Secretaria de Governo Digital (SGD). Por que isso é relevante aqui? Você vai descobrir agora.
Neves explicou que o protocolo SMTP tenta verificar se o domínio do destinatário tem um MX record (de Mail Exchanger), ou seja, uma instrução de DNS que direciona os emails daquele domínio para os servidores que hospedam essas mensagens.
Porém, se o domínio existir, mas não tiver um MX record, o passo seguinte será o de tentar obter uma outra instrução chamada A record que, basicamente, é um registro que vincula um domínio a um endereço IP.
Por passar a apontar para www.gov.br no começo de 2019, um A record foi criado para o domínio gov.br naquela época. Essa simples configuração pode fazer muitos serviços “entenderem” que emails @gov.br existem, mesmo não havendo um MX record para isso.
Essa é uma das razões pelas quais emails @gov.br falsos podem ter passado pelos filtros de segurança de determinadas plataformas.
Foi então que, no começo de fevereiro, o NIC.br foi procurado pela governo federal para tratar do problema. O domínio gov.br é especial, digamos assim — qualquer problema nele pode afetar domínios nos níveis seguintes —, razão pela qual somente a entidade lida com as suas configurações.
De acordo com Neves, dois registros foram implementados na zona de DNS (a área onde as configurações devem ser feitas) do gov.br como medidas protetivas:
Um record para garantir que não existe nenhuma possibilidade de se originar mensagens @gov.br. É um record MX nulo. O que é isso? Se você consultar um record MX para gov.br, vai voltar [como resultado] uma prioridade zero apontando para a raiz. Essa é a maneira padrão de se informar que aquele domínio não recebe email.
(…) Foi implementado também um record SPF nulo (…), o que quer dizer que ninguém pode originar mensagens @gov.br.
Bom, ficou claro que, além de uma configuração envolvendo uma instrução MX, o NIC.br ativou uma configuração de SPF para o domínio gov.br. Mas e o DKIM e o DMARC?
Especificamente para o domínio gov.br, essas configurações não são necessárias, de acordo com Neves: “como temos um MX nulo, que deixa claro que ninguém pode emitir e receber mensagens @gov.br, isso [a necessidade de DKIM e DMARC] está eliminada”.
Mas note que, para domínios que recebem e enviam emails, a exemplo de tecnoblog.net, o DKIM e o DMARC permanecem sendo importantes (e as instruções MX e SPF não devem ser tão restritivas).
Deixe o desconfiômetro ligado
Além dos mecanismos abordados aqui, plataformas de email apostam em aprendizagem de máquina e outras técnicas para combater o problema do email falso. Mas não existe nada 100% seguro, até porque, como frisa Neves, servidores de email podem ter configurações diferentes e que, eventualmente, ignoram as políticas preventivas.
Se é assim, tomar cuidado com o que chega à sua caixa de entrada é mandatório, sempre.
Um fator que pode te ajudar a lidar com o problema é este: emails falsos frequentemente tentam despertar um senso de urgência ou oportunidade. Isso pode ser feito por meio de uma mensagem que afirma que você tem uma dívida de alto valor (urgência) ou que ganhou um prêmio (oportunidade), por exemplo.
Por isso, sempre que algo inesperado chegar ao seu email, não abra o anexo ou o link indicado de imediato. Analise a mensagem com cuidado e, na dúvida, procure a entidade ou empresa mencionada ali pelos canais oficiais.
Para quem administra a zona de DNS de um domínio (ou mais), pensar no problema é mais do que necessário. Como relata Felipe Guimarães, da Uni-IT, “pouquíssimas empresas possuem os mecanismos de segurança de email implementados”. Vai por mim: ativá-los pode evitar muitas dores de cabeça.
