TECNOLOGIA GRATUITA: DNS - A HIERARQUIA DE NOMES DA INTERNET TÓPICO: ATRIBUTOS MX, SPF e DKIM DE UM NS

Transcrição

1 TECNOLOGIA GRATUITA: DNS - A HIERARQUIA DE NOMES DA INTERNET TÓPICO: ATRIBUTOS MX, SPF e DKIM DE UM NS 2012

2 Conteúdo 1. ATRIBUTO MX IPv Exemplo-1: Exemplo-2: Exemplo-3: Caso 1: Caso 2: IPv ATRIBUTO SPF PARÂMETROS DO SPF QUALIFICADORES DO SPF MODIFICADORES Exemplo: APLICAÇÃO DO SPF INTEGRAÇÃO COM DKIM APLICAÇÃO /10 -

3 1. ATRIBUTO MX O atributo MX designa o nó que executa o serviço SMTP associado a um FQDN (Full Qualified Domain Name/Nome de Domínio Completamente Qualificado) ou a um FQHN ( Full Qualified Host Name/Nome de um Nó Completamente Qualificado). Repare que é de um serviço SMTP e não, exatamente, da localização da caixa Postal (caixa de ) de um usuário. A sintaxe do atributo MX é: onde: FQDN FQHN IN MX pref FQHN-MX FQDN FQHN MX pref É o nome de uma ZONA. É o nome de um NÓ. É o atributo da designação Mail EXchanger. É um valor numérico que define a prioridade da designação. Quanto menor for este valor maior é a preferência na utilização do FQHN-MX designado. FQHN-MX É o FQHN do sistema MX, que tem um IP associado através do atributo A ou AAAA IPv Exemplo-1: Considere a ZONA empresa.com.br. Nesta ZONA tem-se o sistema com nome mensagem.empresa.com.br executando o serviço de correio via protocolos SMTP e/ou SMTPS configurado para receber mensagens no formato usuario@empresa.com.br. Neste caso, designa-se empresa.com.br. IN MX 10 mensagem.empresa.com.br. mensagem.empresa.com.br. IN A IPv4-3/10 -

4 Exemplo-2: Considere a ZONA empresa.com.br que troca uma grande quantidade de mensagens com seus clientes ao ponto de exigir mais de um sistema com serviço de correio eletrônico (SMTP) em alguns períodos do mês ou da semana. Agora, dois nós foram configurados com serviço de correio: mensagem.empresa.com.br e msgbck.empresa.com.br. Estes 2 nós receberão mensagens no formato usuario@empresa.com.br. Por algum motivo (sistema msgbck.empresa.com.br é mais lento, por exemplo) os sistemas externos devem tentar o envio através do nó mensagem.empresa.com.br e caso ele esteja muito ocupado então os sistemas externos devem tentar a conexão com msgbck.empresa.com.br. No caso, as designações seriam: empresa.com.br. IN MX 10 mensagem.empresa.com.br. empresa.com.br. IN MX 20 msgbck.empresa.com.br. mensagem.empresa.com.br. IN A IPv4-de-mensagem msgbck.empresa.com.br. IN A IPv4-de-msgbck Ao receber a resposta de uma requisição sobre o atributo MX, o sistema que pretende enviar a mensagem ordenará os registros em ordem crescente de preferencia e utilizará a primeira opção ordenada. Caso ocorra uma falha na comunicação então aquele sistema tentará a segunda preferencia Exemplo-3: Considere a ZONA empresa.com.br que troca uma grande quantidade de mensagens com seus clientes ao ponto de exigir mais de um sistema com serviço de correio eletrônico (SMTP) constantemente. Esse é o perfile de ocupação de grandes provedores de correio eletrônico tais como o Gmail, Hotmail, Yahoo, etc. O objetivo do administrador é distribuir as conexões pelos vários NÓS com SMTP. Há duas formas de se alcançar esse objetivo, que podem ser acumulativas. Uma delas é designar um FQHN-MX com vários endereços IPs (Caso 1). A segunda forma é criar vários registros MX com vários FQHN-MXs, tendo cada registro MX o mesmo valor de preferencia (Caso 2) Caso 1: empresa.com.br. IN MX 10 mensagem.empresa.com.br. mensagem.empresa.com.br. IN A mensagem.empresa.com.br. IN A mensagem.empresa.com.br. IN A mensagem.empresa.com.br. IN A Caso 2: empresa.com.br. IN MX 10 mensagem1.empresa.com.br. - 4/10 -

5 empresa.com.br. IN MX 10 mensagem2.empresa.com.br. empresa.com.br. IN MX 10 mensagem3.empresa.com.br. empresa.com.br. IN MX 10 mensagem4.empresa.com.br. mensagem1.empresa.com.br. IN A mensagem2.empresa.com.br. IN A mensagem3.empresa.com.br. IN A mensagem4.empresa.com.br. IN A Nos dois casos qualquer mensagem destinada a usuario@empresa.com.br chegará a qualquer um daqueles IPs. Porém, no caso 2, se a mensagem for enviada para usurio@mensagem2.empresa.com.br então somente aquele sistema será eleito como receptor daquela mensagem IPv6 Não há qualquer diferença quanto ao atributo MX para o IPv6 em relação ao IPv4. Contudo, enquanto há transição entre IPv4 e IPv6 é recomendável que o atributo MX seja específico para questionamentos conforme o protocolo de rede. Ou seja, se uma requisição vier de uma rede IPv6 então o DNS deve responder com um MX apontando para um FQHN-MX com atributo AAAA, mesmo que o FQHN-MX execute os dois protocolos (IPv4 e IPv6). Conforme a RFC5322 ainda não há uma padronização ou recomendação de prática, mas um estudo de caso pode ser considerado quanto a tomada de tal decisão. Considere um sistema FQHN-MX com pilhas IPv4 e IPv6, numa rede lógica interna onde os dois protocolos coexistem, mas sem enlace IPv6 para a Internet. Neste caso o requisitante questionará através do IPv4 pois não há como ele estabelecer uma conexão com a pilha IPv6 externamente e a requisição virá sob o IPv4, resultando numa resposta de MX de um FQHN-MX com A IPv4. - 5/10 -

6 Por outro lado ele poderá utilizar um conversor intermediário IPv4/IPv6, mas neste caso o conversor agirá como um proxy, tomando para si a identidade da conexão, o que representa uma requisição sob IPv6, resultando uma resposta de MX de um FQHN-MX apontando para AAAA IPv6. Se aquele mesmo sistema encapsular IPv6 sobre o IPv4, a requisição será IPv6, pois será a última pilha de rede a ser extraída. Se os protocolos são diferentes então não há conectividade estabelecida. Logo, apesar de ainda não existir uma padronização tem-se comportamentos definidos. 2. ATRIBUTO SPF O atributo SPF (Sender Policy Framework) foi introduzido para auxiliar as aplicações MTA identificarem se um MTA externo tem autorização para o envio de mensagens com remetente pertencente a uma ZONA. Ou seja, um NÓ duvidoso.empresa.sem.br pode enviar mensagem com remetente usuario@empresa.com.br? A zona empresa.com.br autoriza aquele envio? Assim, o SPF avalia o envelope da mensagem mas não avalia nem os cabeçalhos nem o conteúdo. Sob o ponto de vista técnico o atributo SPF autoriza um FQHN enviar mensagem - 6/10 -

7 utilizando um remetente FQDN PARÂMETROS DO SPF O SPF é um conjunto de parâmetros (ou mecanismos) assim definidos: A IP4 IP6 MX PTR ALL Se o A ou AAAA do FQHN-MX é o mesmo que enviou a mensagem. Informa a faixa de endereços IPv4 que estão autorizados a utilizar a ZONA do MAIL-FROM. Informa a faixa de endereços IPv6 que estão autorizados a utilizar a ZONA do MAIL-FROM. Se a ZONA tem um registro/atributo MX coerente com o MAIL-FROM: Se o atributo PTR do FQHN tem tem o mesmo IP da conexãodesignado a aquele nome. Comparar sempre QUALIFICADORES DO SPF Qualificadores são sinais que precedem os parâmetros. Qualquer parâmetro aceita os qualificadores: '~' '-' '?' '+' significa uma condição de debug, a comparação é aceita e um aviso em log é emitido. Não houve coincidência. Nega a condição. Quando -ALL então sinaliza a evidência de falsificação. Resultado NEUTRO. Indica que não uma política definida para o caso. Sinaliza que o resultado da regra implica em aprovação. JAMAIS insira este qualificador em ALL. - 7/10 -

8 2.3. MODIFICADORES As RFCs 4408 e 6652 preveem, ainda, 5 modificadores. exp, redirect, ra, rp e rr. Tais modificadores são adicionados aos parâmetros Exemplo: Considere o cenário: Os MTAs (Mail Trasfer Agent), em execução nos nós IPs e , com nomes mta1.empresa.com.br e mta2.empresa.com.br, podem enviar mensagens com MAIL-FROM: <usuario@empresa.com.br>. Um nó, nome malicioso.qualquerzona.br, com endereço IP , não pertencente à zona empresa.com.br, envia uma mensagem para o destinatário, que será recebido pelo MTA-DESTINATÁRIO. O DNS da zona empresa.com.br retorna: quando questionada pelo atributo SPF (ou TXT): empresa.com.br. SPF v=spf1 ip4: ip4: a:mta1.empresa.com.br a:mta2.empresa.com.br -all quando questionada pelo atributo IN A de mta1 ou mta2.empresa.com.br: mta1.empresa.com.br. IN A mta2.empresa.com.br. IN A quando questionada pelo atributo IN PTR de in-addr.arpa. e/ou in-addr.arpa.: in-addr.arpa. IN PTR mta1.empresa.com.br. - 8/10 -

9 in-addr.arpa. IN PTR mta2.empresa.com.br. Tão logo o envelope fornecer o MAIL-FROM (usuario@empresa.com.br), o MTA questionará o atributo SPF para o DNS da zona empresa.com.br, que retornará o registro acima. Em seguida o MTA-DESTINATÁRIO questionará os outros atributos. Mesmo que malicioso.qualquerzona.br se anuncie como pertencente à zona empresa.com.br não haverá condição satisfeita, o MTA-DESTINATÁRIO segue a decisão -all do SPF, ou seja, rejeitará a mensagem APLICAÇÃO DO SPF Ou seja, o atributo SPF é satisfatório para ZONAS onde seus usuários utilizam o sistema de correio eletrônico apenas internamente, mas não satisfaz uma condição onde os usuários internos utilizam sistemas externos para o envio de mensagens usando aquela zona. 3. INTEGRAÇÃO COM DKIM Não há um atributo específico DKIM (DomainKey Ideintified Mail) na tabela de tradução de NS, mas a integração DKIM, usada nos MTAs (Mail Transfer Agent), MUAs (Mail User Agent) e MSAs (Mail Submission Agent) é feita através de uma entrada de registro específica com atributo TXT na tabela de tradução direta de um NS. Considera-se que o DKIM siga as recomendações da RFC6376. O leitor deve considerar a atualização desta RFC e verificar se as informações aqui prestadas são relevantes. O DKIM utiliza o NS (especificamente um DNS) para obter o valor da chave pública DKIM de um domínio _domainkey de uma ZONA e para uma tag específica. Um MTA, MUA, MSA questionará o atributo TXT referente a requisição formada pela tag, seguinda do domínio _domainkey e completada pela ZONA. Ou seja, se a tag= Empresa-SA e a ZONA é empresa.com.br, deve existir um único atributo TXT com a entrada: Empresa-SA._domainkey.empresa.com.br. IN TXT v=dkim; p=chave-publica; s= onde: v p é a versão do DKIM. E DEVE iniciar com DKIM. é o indicador de uma chave pública que pode ser revogada a qualquer tempo. Esta chave NÃO DEVE ser criada por um CA (Certification Authority - Autoridade Certificadora) - 9/10 -

10 s é um seletor de finalidade. Pode ser um , uma data, um nome, e pode ter espaços. O valor da chave pública é obtida a partir da uma chave privada. Via OpenSSL, os comandos são: Para gerar a chave privada e armazená-la no arquivo private.key: openssl genrsa -out private.key 1024 Para criar a chave pública correspondente e armazená-la no arquivo public.key: openssl rsa -in private.key -pubout -out public.key O conteúdo de public.key, removendo os cabeçalhos e rodapé --- BEGIN PUBLIC KEY --- e --- END PUBLIC KEY -----, deve ser copiado para o valor de chave publica 3.1. APLICAÇÃO Enquanto o SPF opera com os dados de envelope de uma mensagem, o DKIM opera com os cabeçalhos e conteúdo, o que identifica um remetente externo sendo este autenticado pela chave DKIM e outros parâmetros. Ou seja, o DKIM permite que funcionários que trabalham fora da empresa e usam sistemas externos à empresa, usem o da zona da empresa, desde que insira a chave pública, a tag e o seletor correspondentes. Tal recurso atende a um cenário diferente do SPF. - 10/10 -