Arquivo

Archive for the ‘DNSSec’ Category

O DNS solidário

 

Introdução

 

Muitos são os processos que tornam a Internet um ambiente mais confortável. Confortável no sentido de segurança e, principalmente, qualidade. O DNS é um deles. Sob o ponto de vista do bem estar geral, o DNS é um dos mais importantes componentes. Servidores de DNS são gerenciados por empresas e provedores de serviço de Internet (pequenos, médios e grandes). Não é somente o sistema autônomo o pré-requisito para a existência de servidores de DNS. O pré-requisito é que a organização tenha pelo menos um domínio registrado.

Este texto está interessado em abordar a questão da qualidade do DNS sob a ótica de sua disponibilidade (com foco na topologia), e propõe um mecanismo criativo para diminuir significativamente a sua indisponibilidade, melhorando a qualidade da Internet e aumentando um pouco mais sua segurança.

Se a organização é pequena, mesmo que tenha diversos domínios, a recomendação é não pensar duas vezes e usar os servidores de DNS do Registro.br. Há duas restrições, entretanto, que impediriam o uso daqueles servidores: se o domínio tiver mais de 15 registros (digamos, subdomínios) ou se for necessário a implementação de reversos de IPv4 e/ou IPv6 (que é o caso dos sistemas autônomos). A proposta criativa está orientada para aquelas organizações que não podem usar os DNSs do Registro.br, na totalidade de suas demandas.

 

Topologia de servidores de DNS

 

A recomendação técnica mínima é que se tenha pelo menos dois servidores autoritativos de DNS: um primário e outro secundário. E, também, que haja outros servidores de DNS do tipo recursivos, disponíveis para consultas de nomes e reversos de IPv6/IPv4. Na maioria das vezes, isto não acontece. Primeiro, não é usual a disponibilidade de recursivos. Isto não representa um problema técnico se são usados recursivos disponíveis na Internet, como os do Google. O ruim, na história dos recursivos é não usar nenhum e deixar que o autoritativo aceite consultas e se torne um autoritativo-recursivo. Usar um servidor autoritativo como recursivo é possível, deste que isto seja feito através de visões, como permite o Bind. Uma visão é autoritativa e outra é recursiva. Mas, neste texto, a demanda para recursivos é abstrata, embora não se deixe de pensar que os recursivos depende de autoritativos disponíveis, para funcionarem. A preocupação é o respeito às melhores práticas, de no mínimo dois autoritativos. O uso do servidores DNS solidários permite a aplicação das melhores práticas e representar uma topologia conforme a Figura 1.

 

Topologia para um DNS Solidário

Figura 1. Topologia de um DNS Solidário.

 

Governança do DNS Solidário

 

Recorrendo à Figura 1 destaca-se:

  • A visão do Registro.br está restrita aos dois servidores à esquerda (secundário e primário). O nome primário, neste caso é dado ao servidor que irá transferir a zona para todos os outros secundários. Na realidade, o único primário (ou “master”), na acepção técnica de servidores DNS é o escondido, sobre o qual as zonas são manipuladas.
  • O dois servidores registrados no Registro.br devem estar em redes física e logicamente distintas.
  • O primário escondido pode e deve estar localizado em uma rede remota distante. Por exemplo, em uma empresa de hospedagem, preferencialmente disponível em um PTT. As facilidades de conexão aos PTTs, via transporte, devem ser consideradas, agora ou no futuro.
  • O recursivo, que pode ser mais de um (dado à sua facilidade de implementação), deve estar nas proximidades das redes solidárias.
  • O DNSSEC é um pré-requisito fundamental!

A governança do DNS Solidário deve ser no estilo “várias partes interessadas”. Em outras palavras, a governança deve ser uma organização independente, onde a administração é dada a algum membro da rede de provedores solidários, por um período de tempo pequeno e com participação efetiva de todos os envolvidos para que a estrutura/topologia estejam bem cuidada, focada no interesse comum, respeitando algumas particularidades de membros específicos. Não há necessidade de uma organização formal e a imagem que melhor se adapta é a estrutura da Internet Society (ISOC), especificamente, o IETF.

Custos serão os fatores fundamentais da organização solidária. Eventuais responsáveis não devem receber por seu trabalho. Entretanto, admite-se que o pessoal técnico seja remunerado. Níveis de dedicação variam em função da complexidade da estrutura.

Organizações solidárias, principalmente em pequenos e médios provedores tendem ao aperfeiçoamento ao criativamente evoluírem para o ASN Solidário, Trânsito e Transporte Solidários, etc. Há exemplos práticos funcionando, embora sem uma organização efetiva, o que atrai alguns problemas, principalmente, no que diz respeito à qualidade de seus serviços de infraestrutura da Internet. Outros exemplos mostram a criação de organizações formais que aumentam consideravelmente os custos e a complexidade operacional tornando-se ineficientes. O modelo atual da Governança da Internet é um exemplo imperturbável!

Anúncios

DNSSEC II

O Registro.br, acaba de colocar no ar, uma ferramenta denominada DNSSHIM – DNS Secure Hidden Master, que promete facilitar nossa vida. Para quem possui uma topologia equivalente à mostrada aqui, certamente ficará agradecido. O melhor a fazer é testar a ferramenta e, esperar um pouco mais, pelo Free DNSSEC hosting anunciado na lista dnssec-deployment. Também, é de se esperar algumas mudanças para tornar o uso popular: “We don’t expect people to implement clients for it, we are providing a library and a shell like client for them.”, escreve o Frederico Neves e, na sequência ele ainda diz: “… So their provisioning system will talk EPP with the registry and the “simple” protocol with the DNS hosting back-end (DNSSHIM), instead of the hundreds of scripts magics they currently does…”. Essa última, a melhor velha notícia [3]. O Registro.br, nota-se pelas mensagens nas listas internacionais, faz inveja a outos NIRs do mundo. Eis as referências para o DNSSHIM, que inclui uma lista de debates:

[1] http://registro.br/dnsshim/.
[2] https://eng.registro.br/mailman/listinfo/dnsshim.
[3] libepp-nicbr: Biblioteca para cliente EPP do NIC.br.

Bloqueando ou censurando domínios (Bind e Unbound)

Últimas atualizações:
02/06/2009 – 10:33

Introdução

Dia 18/05/2009, a Abranet, recebeu uma notificação judicial para bloquear uma série de domínios relacionados com pornografia infantil. Esse artigo dá uma dica sumária de como fazer isso, usando servidores de nomes. O uso dos servidores de nomes elimina a preocupação de estabelecer os bloqueios (ou censuras) em equipamentos de borda (roteadores, firewall, entre outros), como inicialmente pensei em fazer, quando perguntaram-me como. Cheguei a passar uma mensagem na lista da Abranet solicitando idéias aos participantes. Os equipamentos de borda não são muito hábeis para tratar domínios, como sabemos. Boa parte da relação de dominios apresentados à Abranet, estavam hospedados no Google. Mas, acabei eu mesmo respondendo meu próprio e-mail indicando a referência [1], que aponta uma solução simples e imediata.

Coincidentemente, um dos colaboradores da Pegasus me ligou, antes da mensagem da Abranet, abordando questão semelhante, em um cenário ampliado. Sua preocupação estava voltada para a demanda de seus clientes em censurar sítios da Internet, com o objetivo principal de manter funcionários e familiares, longe das armadilhas preparadas, geralmente em mensagens (“malware”, por exemplo) e, principalmene, longe de sítios indesejáveis. O cliente mal avisado sobrecarrega a rede interna de uma empresa ou provedor, quando algum programa de má-fé se instala em seu equipamento vulnerável. Também, gera constrangimentos para a empresa ou o provedor, que estão sempre sendo solicitados por terceiros (os CERTs, principalmente), a tomarem providências em relação a máquinas comprometidas de seus usuários.

Ponderações sobre o projeto

Conversa vai e conversa vem, com outros técnicos e amigos levaram-me a conduzir um experimento tendo como base a solução simples proposta em [1], um pouco mais ampliada. Experiencia bem sucedida e, as convesas, conduziram-me às seguintes abordagens e questões, que não se esgotam, por si:

  1. O usuário dos servidores de nomes da rede deve ser informado porque o domínio não estava acessível.
  2. Manter o DNSSEC intocável.
  3. Somente os recursivos devem ser alterados. Os autoritativos continuam exercendo o papel a eles destinado, de somente exibirem as zonas da rede. Os dominios censurados são respondidos com autoridade somente para as respectivas redes internas.
  4. Fácil utilização e, imediata disponibilidade, relativos ao bloqueio ou censura.
  5. Os domínios devem ser classificados e sub-classificados (2 níveis): malware, pornografia, pornografia infantil, etc.
  6. Manter histórico das atividades, por domínio, rede, segmento de rede e cliente.
  7. Aplicável hierarquicamente, no sentido de que dominios são bloqueados ou censurados pela administração da rede, pelo administrador de cada segmento de rede e por seus respectivos clientes. E o processo deve permitir a reversibilidade.
  8. Deve o cliente ser impedido de usar servidores recursivos externos (por exemplo, o openDNS)?
  9. A idéia deve ser exposta no sentido de permitir que servidores extenos à rede a implementassem?
  10. Se a resposta à questão anterior for sim, um outro nível hierárquico deve ser implementado?

A resposta ao item 9 é não e responde portanto o item 10. O item 8 foi deixado para cada rede decidir e, a solução está associada aos equipamentos de borda. Para a implementação escolheu-se a linguagem Python. A justificativa pela Python se deu pelo fato da TeleSA ter nos oferecido, como hospedeiro, a base de conhecimento do Sistema FaleOK e do VoIP Completo, implementada sob o Zope 3. Por outro lado há um conjunto de ferramentas na Python para trabalhar com DNS (unbound, principalmente) e DNSSEC .

O projeto envolvendo o pessoal de engenharia de software está em desenvolvimento. Será divulgado, para que possa ser implementado por redes de terceiros (item 9), exigência da TeleSA, que tem fornecido sitemático apoio à Infraestrutura da Internet de seus parceiros e disponibilizou sua equipe de desenvolvimento, para o desenho da proposta.

Considerações sobre a implementação

Além dos servidores recursivos, o Apache (2.2), também está envolvido. Em etapas, a implementação, supondo que o dominio a ser bloqueado é o exemplo.com.br. Suponha, ainda, a topologia de servidores de DNS conforme descrita aqui e o dominio para redirecionamento é o pegasus.sec3.br, já com DNSSEC. Embora os exemplos abaixo estejam aplicados a um único domínio a ser censurado, eles podem ser extendidos para mais de um domínio. Automatizadas ou não, as etapas estão descritas para serem feitas manualmente.

Etapa 1 (Bind): Criar a zona de redirecionamento para os dominios censurados, no master.

Estamos, nesse caso, seguindo a proposta em [1] com pequenas modificações. Para isto, criamos uma zona denominada censurado, simplesmente assim:


$TTL 1w
@ IN SOA sn01.pegasus.sec3.br. suporte.pegasus.sec3.br. (
     2008070308 ; Versao
     3600       ; refresh (1 hora)
     1800       ; retry (30 minutos)
     604800     ; expire (7 dias)
     1800 )     ; default TTL (30 minutos)

     IN NS sn01.pegasus.sec3.br.
     IN NS sn02.pegasus.sec3.br.
     IN NS sn03.pegasus.sec3.br.
     IN NS sn04.pegasus.sec3.br.
     IN NS sn05.pegasus.sec3.br.
     IN NS sn06.pegasus.sec3.br.
     IN A 192.168.1.1
www IN CNAME censurado.

Etapa 2 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, no master.

Para facilitar o manuseio futuro, manual ou não, adicionamos no named.conf:


. . .
include “/algum_caminho_de_diretorio/includes/censurado.inc”;
. . .

Como estamos falando do master, geralmente escondido, não há necessidade de usar “view”. Em seguida, construimos o censurado.inc, com as referêncas às zonas censurado, exemplo.com.br e, todas os domínios que desejamos censurar, assim:


zone “censurado” {
  type master;
  file “diretorio_da_zona/censurado.zone”;
};
zone “exemplo.com.br” {
  type master;
  file “diretorio_da_zona/censurado.zone”;
};

Qualquer domínio a ser censurado será referenciado como o exemplo.com.br, isto é, sempre apontando para a zona censurado.zone.

Etapa 3 (Bind): Criar a referência à zonas do domínio de redirecionamento e para o exemplo.com.br, nos secundários.

Considere que a resposta ao domínio exemplo.com.br é somente para IPs da rede. Assim, sua implementação nos Binds secundários, deverá ser feita sob um “view” recursivo, exclusivo para tais IPs, no named.conf. A seguir construa as referências no include censurado.inc, para os respectivos primáros.


zone “censurado” {
  type slave;
  file “diretorio_da_zona/censurado.zone”;
  masters {
    IP_do_primario;
  };
};
zone “exemplo.com.br” {
  type slave;
  file “zonas/censurado.zone”;
  masters {
    IP_do_primario;
  };
};

Etapa 4 (Unbound): Garantir que os recursivos façam o redirecionameto do domínio.

No Unbound, a solução é mais simples. Basta acrescentar as linhas seguintes, ao unbound.conf, onde as duas últimas devem ser repetidas para cada domínio censurado:

local-zone: “censurado” redirect
local-data: “censurardo A IP_do_servidor_Apache”

local-zone: “exemplo.com.br” redirect
local-data: “exemplo.com.br A IP_do_servidor_Apache”

O Unbound irá redirecionar tanto o exemplo.com.br como o http://www.exemplo.com.br para o Servidor Apache.

Etapa 5 (Apache): Preparando servidor Apache para o receber o redirecionamento.

A configuração, também é bastante simples, dependendo da implementação do Apache. No meu caso, o Apache possui VirtualHost e um domínio principal. Então, dentro do VirtualHost do domínio principal, coloquei:

Redirect permanent / http://www.pegasus.sec3.br/

Finalmente, no arquivo httpd.conf, ou equivalente, inseri a seguinte indicação para o domínio censurado:


ServerAdmin email_do_administrador
DocumentRoot “/data/wwwroot/www.pegasus.sec3.br”
ServerName http://www.pegasus.sec3.br
ServerAlias http://www.censurado http://www.pegasus.sec3.br
ServerAlias censurado http://www.pegasus.sec3.br
AddType application/x-httpd-php .php
ErrorLog …
CustomLog …

Comentários adicionais sobre a implementação

  • Consider-se a configuração do bind supondo-o um servidor recursivo ou, recursivo e autoritativo. Nesse caso, o recursivo é um view acessível somente à rede interna.
  • Os comentários da Introdução e o item que a seguem mostram que há muitas outras aplicações além das restrições impostas pela Justiça. Criatividade, inovaçao e sugestões podem melhorar as propostas.
  • Para quem usa servidores de DNS com IPs não públicos, certos cuidados não são necessários, tornando mais simples, ainda, a implementação.
  • Há diversas formas de redirecioamento no Apache. Um bom começo pode ser visto em [2] e nos manuais do Apache, em particular sobre o mod_rewrite, em [3].

Referências

[1] Simpson, J. M., Blocking domain names with bind.
[2]
yolinux.com, Apache Web Server Configuration for Web Site Redirection.
[3] Apache 2.2, Módulo mod_rewrite.

DNSSEC I

O Nic.br está oferecendo um DPN para exercícios com o DNSSEC. Trata-se do sec3.br. É de graça e vale a pena pegar um domínio. Vou exibir minha experiência com o DNSSEC usando o pegasus.sec3.br que peguei por lá.

Veja aqui boas referências iniciais e na apresentação Tutorial DNSSEC, que parece estar sempre atualizada dá para completar o exercício sem problemas. Uma detalhada referência está em DNSSEC HOWTO, a tutorial in disguise. Há um e-mail de suporte. O pouco que usei desse suporte levou-me a imaginar que é melhor saber tudo sobre DNSSEC antes de solicitá-lo.

Há um conjunto de ferramentas interessantes em DNSSEC Tools. Quando houver bastante tempo disponível, vale a pena dar uma estudada.

Suponhamos que a zona do pegasus.sec3.br esteja assim definida, no arquivo pegasus.sec3.br.zone:


$TTL 1d

@ IN SOA sn01.pegasus.sec3.br. suporte.pegasus.sec3.br. (
     2008070308 ; Versao
     3600       ; refresh (1 hora)
     1800       ; retry (30 minutos)
     604800     ; expire (7 dias)
     1800 )     ; default TTL (30 minutos)

     IN NS sn01.pegasus.sec3.br.
     IN NS sn02.pegasus.sec3.br
     IN NS sn03.pegasus.sec3.br.
     IN NS sn04.pegasus.sec3.br.
     IN NS sn05.pegasus.sec3.br.
     IN NS sn06.pegasus.sec3.br.

     IN A 192.168.1.1
     IN MX 0 pegasus.sec3.br.

pegasus.sec3.br. IN TXT “v=spf1 a mx -all”

www IN CNAME pegasus.sec3.br.
mcw IN CNAME pegasus.sec3.br.
ftp IN CNAME pegasus.sec3.br.
sn01 IN A 172.16.2.2
sn02 IN A 10.0.1.1
sn03 IN A 10.1.1.1
sn04 IN A 10.2.1.1
sn05 IN A 10.3.1.1
sn06 IN A 10.4.1.1

Há 7 etapas envolvidas no processo de preparar uma zona para o DNSSEC:

  1. Geração da chave KSK: Esta operação é executada uma única vez, desde que os resultados sejam preservados, pois as chaves nunca expiram. Executei o seguinte comando:


    dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE pegasus.sec3.br

    Como resultado, se separamos um diretório para cada zona, veremos os respectivos arquivos da chave pública e privativa:


    [root@testejb pegasus.sec3.br]# ls
    Kpegasus.sec3.br.+005+07609.key Kpegasus.sec3.br.zone.+005+07609.private
    pegasus.sec3.br.zone

  2. Incluir o arquivo da chave pública KSK no arquivo de zona: Também, somente executada uma única vez. Inclua no final do arquivo de zona:



    ;; KSKs
    $include Kpegasus.sec3.+005+23658.key

  3. Assinar a zona: Esta operação deve ser executada à primeira vez logo após a inclusão do arquivo com a chave pública KSK e todas as vezes em que houver alteração na zona e/ou vencimento da assinatura. Portanto, guarde-o (eu guardo em um .txt no próprio diretório da zona). Executei o comando, onde -e 20090630200000 é a data de vencimento das chaves:


    dnssec-signzone -z -e 20090630200000 -o pegasus.sec3.br pegasus.sec3.br.zone

  4. Tratar os registros DS: Ao terminar a assinatura da zona o arquivo onde estão os registros DS é criado: dsset-pegasus.sec3.br.. Pegue as duas linhas desse arquivo e inclua no arquivo de zona pegasus.sec3.br.zone, LOGO após o último NS. Altere o sequencial da zona e assine a zona novamente, com o mesmo comando acima. Veja que irá precisar de incluir (à primeira vez) o registro DS no Registro.br. O conteúdo do arquivo dsset-pegasus.sec3.br., é mostrado abaixo e em vermelho os respectivos dados que deverão ser colocados no Registro DS 1 da zona, no Registro.br.

    pegasus.sec3.br. IN DS 22852 5 1 5773872FD2E2017C0007C8B6025F708DAB747CC2
    pegasus.sec3.br. IN DS 22852 5 2 934502EF4E4AE1F182A87F9370D86A184AEEF4C7D323AEDC80DD0FD2 BFA8C868.

  5. Assine novamente a zona: Após colocar os registros DSs, no arquivo pegasus.sec3.br.zone assine novamente a zona com o mesmo comando que usou para assinar á primeira vez , ou seja:

    dnssec-signzone -z -e 20090630200000 -o pegasus.sec3.br pegasus.sec3.br.zone. Observação: Não é necessário alterar o sequencial.

  6. Altere a referência do arquivo de zona no named.conf: Fique atento para que o novo arquivo de zona termine com .signed. Não é mandatório, mas o .signed permite, imediatamente, saber que a zona foi assinada. Faço isso, no master e em todos os secundários autoritativos. Reinicie os servidores de DNS, na ordem necessária.

  7. Alterar o registro DS do domínio, no Registro.br: Isso deve ser feito à primeira vez, somente. A figura abaixo mostra os campos a serem alterados, com base no conteúdo do arquivo dsset-pegasus.sec3.br., exibido no item 4, acima. Veja a ilustração na figura abaixo.

    Figura que ilustra os campos preenchidos, da zona, no Registro.br:
    registro-ds
  8. Alterando a zona: Ao fazer uma alteração em zona já assinada, altere o sequencial, comente as duas linhas com os registros DS, e reassine a zona, como feito acima. Em seguida, retire os comentários colocados nas linhas dos registros DS e assine novamente a zona (não precisa alterar o sequencial, nessa etapa.

Também, incluo meus domínios assinados, aqui, após a publicação do Registro.br.

%d blogueiros gostam disto: