Arquivo

Archive for the ‘DNS’ 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

Meu ambiente de trabalho

Introdução

O tempo anda escasso, ultimamente. O de todo mundo, pelo que parece. Estou com dois artigos na agulha, um deles a continuação do último, sobre a conexão aos PTTs em IPv4 e IPv6. O outro é sobre um ano “quase” sabático, que me dei de presente, a partir de março de 2011. O ano “quase” sabático obrigou-me a preparar adequadamente o ambiente de trabalho. E vou descrevê-lo, por pura curiosidade, organização das idéias e reconher que, nas entrelinhas, será útil para muita gente. O bloque tem a vantagem de você escrever o que desejar para que leiam as pessoas que desejarem ler. No passado, chamávamos de “livre arbítrio”. Hoje seria mais prudente chamar de “escolha pessoal”. Geralmente, a “escolha pessoal” é baseada, EMHO, no conjunto de informações que um ser humano possui em sua cabeça, adquirida ao longo dos anos. Mas, o conjunto é complementado pela manipulação que o ser humano fez e faz, sistematicamente, do conhecimento adquirido. É uma questão um pouco mais complicada, pois vê-se, no dia-a-dia e na história, que este conjunto de conhecimento pode ser usado para o bem e para o mal.

O comentário da “escolha” aparece, a propósito de uma opinião que vi em um dos artigos do Silvio Meira onde, no debate alguém diz que uma pessoa é míope porque decide usar o Facebook. Em linhas gerais, justificou a miopia, pelo fato de que usar o Facebook está tornando mais rico o seu criador. É uma observação, a meu ver, sem propósito. Mas, trata-se de uma opinião. Não é possível preocupar-se com uma opinião (quando ela não é técnica), que você simplesmente não concorda. Minha escolha nestes casos é o da relevância. Se a opinião não técnica não for relevante ou não contribuir para o enriquecimento de minhas próximas escolhas, ignoro-a, no sentido de não participar do debate. Prefiro a visão shakesperiana: “A vida é uma simples sombra que passa (…); é uma história contada por um idiota, cheia de ruído e de furor e que nada significa”. Por outro lado, não acho que a história da miopia acima, qualifique um idiota. Pessoalmente, aperfeiçoei meu conhecimento, com a abordagem da opinião e na simples leitura. Sempre acontece, mesmo que inusitada.

Os recursos físicos

Tenho um “notebook” Dell Vostro 1320, com 8 GRam e um HD de 230 Gbytes. Localmente, tenho um “desktop” Intel Core 2 duo com 8 GRam e 2 HDs de 520 Gbytes. Remotamente, tenho uma outra máquina semelhante a este “desktop”. Para a Internet uso a Net com 10M de banda, que chega a 800 Kbps, medidos no SIMET do Nic.br. Para mim, a Net é uma provedora de serviços, no mínimo, irresponsável! Conectado à Net tenho um Mikrotik em uma máquina simples, com HD em “flash”, já há muitos anos.

No meu “notebook” tenho o Windows 7 Professional, em IPv4 e IPv6. O IPv6 é um túnel com a HE, que faço via anúncio de um /48 através do AS de minha empresa. Eventualmente, ativo uma VPN com um dos roteadores apropriados. Assim, consigo manter minhas configurações originais, onde estiver, em qualquer parte do mundo. Se não tenho Internet, mas há disponibilidade de celular, uso-a via meu iPhone. Complementarmente, tenho um “tablet” Samsung 8.1, que suporta alguns casos extremos e usado muito para leitura dos trabalhos em .pdf. Este conjunto de facilidades me satisfaz plenamente, no quesito de interconexão á Internet, que é o componente fundamental de trabalho e, via de regra, não me deixa ocioso, exceto quando for minha escolha. Fico ocioso, sempre, quando estou com meu neto querido.

As outras facilidade

Naturalmente, minhas maiores facilidades estão no “notebook”. Eis algumas delas:

  • Thunderbird: meu atual cliente de correio eletrônico. Não é meu preferido, infelizmente, mas dá para o gasto. Ele tem uma facilidade muito interessante que é o uso do PGP.
  • Browsers: Tenho quase todos, Chrome, Firefox, Explorer e Safari. Meu preferido é o Chrome. Antes era o Firefox, mas ultimamente com muitos problemas. Explorer só para alguns bancos, que não respeitam escolhas de seus clientes. Safari uso muito pouco, principalmente em testes de desenvolvimento.
  • Putty: minha principal ferramenta de ssh. É também, uma das mais importantes ferramentas de trabalho. Tenho outros, como o SCP, mas uso pouco.
  • Zope/Plone/Zeo: Uso pouco, no “notebook”. Somente para segurança de outros servidores, os quais uso muito.
  • Warftp: Insubstituível servidor de ftp. Entre outras funções ele é o principal componente de integração com o “tablet”. E, naturalmente, como integrador com os outros servidores.
  • PHPDesigner: Depois de muitos anos, há 5 uso-o preferencialmente. Está instalada, a versão 8. Não somente os programas em PHP, mas também, com editor de outras linguagens com C, Java e Perl, particularmente.
  • Wamp: Aplicação fantástica e simples, que implementa os servidores de MySQL, PHP, Apache em suas diversas versões, o que é muitíssimo útil.
  • Clientes para o MySQL: Tenho instalado o MuSQL Workbench, o MySQL Administrator e o MySQL-Front. Cada um com sua utilidade.
  • MikTex: Ferramenta preferida para os textos que preciso escrever em Latex. Ando me afastando um pouco do Latex e preferindo o Word. O Word é muito mais fácil para lidar, nos textos técnicos. O Latex é cansativo gerando muita perda de tempo na procura de compatibilidades. Mas, é insubstituível em alguns casos.
  • Office: Ótima ferramenta, pois domino-a. Além do Word sou usuário permanente do PowerPoint. Como não sou especialista em imagens, uso-o como intermediário para o aperfeiçoamento do que preciso, no Adobe Photoshop.
  • Adobe Photoshop: Para quem entende, deve ser uma maravilhosa ferramenta. Para mim resolve milhares de problemas relacionado com figuras, imagens, etc., que preciso no dia-a-dia.
  • eyeBean: Meu “softphone” preferido para testes e uso do FaleOK. Hoje tenho-o instalado no iPhone, também, e uso-o para receber e fazer chamadas via o FaleOK. Tenho números fixos em algumas cidades.
  • Wireshark: Eventualmente uso-o para avaliações e diagnósticos de problemas em redes. Pouca atividade, mas uma fantástica ferramenta, quando necessária.
  • Camtasia: Este e outros recursos estão associados a um Bamboo da Wacon, plugado em uma das USBs do “notebook”.
  • Enterprise Architect: Minha principal ferramenta de projetos e apoio ao desenvolvimento de idéias. Indescritível, os recursos disponíveis! É complexa e ao longo do tempo pode aperfeiçoar o uso.
  • FileZilla: Cliente preferido para ftp. Fica aberto o tempo todo no “notebook”.
  • Adobe Acrobat X: É um software de apoio. Usei-o muito quando meu orientador solicitou que os textos fossem feitos em Word e eu os fazia em Latex. Não entendi muito bem a razão dessa preferência já que existe hoje, o Adobe Reader X. Tal exigência, fez-me mudar em definitivo para o Word. No final, a mudança foi melhor e mais prática.
  • Skype: Há muito abandonei o MSN pelo Skype. Este é muito mais confortável e estável (pelo menos era, na época da escolha). Só uso o Skype para me comunicar com outros Skypes. Telefonia prefiro o FaleOK, muito mais flexível…
  • Segurança: Tenho vários anti-vírus e uso intensivamente o “firewall” do Windows 7.
  • VMWare: Ferramenta versátil e simples para criação de máquinas virtuais. Não fosse o VMWare não sei como poderia criar ambientes de testes, verificação de comportamento e integração (usualmente, em rede), de diferentes sistemas operacionais, tais como: Windows, Mikrotik, BSDs, Linux, etc. Cada um deles nas suas diversas versões.
  • CygWin: Ah! Grande achado! Tornou muito mais fácil lidar com o Windows, ao sair fora do “prompt”. Bem mais fácil!! Não se pode prescindir do CygWin, principalmente se você desenvolve com o apoio de “framework”, no Windows. Para se ter um exemplo, as duas figuras abaixo mostram o whois no CygWin e no Windows, respectivamente:

    Também, um recurso bastante valioso é o servidor sshd. Não tem preço!!

Finalmente, para ilustrar, eis a barra de tarefas do “notebook”:


Nos servidores local e remoto uso o FreeBSD (versão 9). Ambos possuem Apache2, MySQL5 e PHP5. Em ambos, como no “notebook” está instalado o Zope/Plone/Zeo. O Zeo admite perfeita integração entre os três, o que me deixa despreocupado em relação à segurança dos dados. No Plone local, mantenho toda e qualquer documentação de todos os servidores sob minha responsabilidade. Incluo todos os trabalhos em .pdf que mantenho em minha bibliografia no Word. Senhas (codificadas), IPs, v4 e v6 (uso a flecha para documentar), informações pessoais, agenda, etc., etc. O Plone é algo, também indescritível. Uso o Zope desde que ele apareceu pela primeira vez.

O servidor remoto tem um DNS escondido (Bind), que é “master” para um “master”, de um conjunto de outros servidores de dominio (autoritativos). Como recursivo, uso o Unbound no servidor local e em um outro servidor remoto.

Conclusão

O “notebook” tem suportado com altivez a demanda sobre ele. É claro que 16 GRam, no mínimo, com um processado I5 ou I7 seria o desejável. É o que provavelmente acontecerá em breve, espero. De resto estou muito feliz com meu ambiente, cuja foto parcial do local, segue abaixo!


Tipos de DNS e suas aplicações

Atualizado em: 31/05/2011.
Artigo originalmente escrito em 28/05/2009.

Introdução

 

É um artigo redundante. Mas, com o objetivo de deixar alguns pontos ainda não bem compreendidos. Além de dar ênfase à necessidade de implementação do DNSSEC.

Sob o ponto de vista de uma empresa, instituição ou de um provedor, existem dois tipos de servidores de DNS:

  • Autoritativo
  • Recursivo

Resolvedor não é um servidor de DNS. É um cliente (p. ex.: o navegador), de um servidor recursivo. Os servidores autoritativos não atendem a consultas do resolvedor. O resolvedor, geralmente fica no sistema operacional ou nos programas tipo ftp, ssh e, muitos outros que provocam o sistema operacional pesquisar os resolvedores. Servidores root são sevidores que informam aos recursivos a quem recorrer para encontrar o autoritativo que responda pelo domínio, em consulta. São servidores muito especializados e pode ser desprezado neste debate.

Existem inúmeros bons programas que implementam servidores de DNS: bind, unbound, djdns, etc. São ótimos! Cada um com suas vantagens e desvantagens. Por exemplo, o djdns, pelo menos até pouco tempo não implementava o DNSSEC. O bind é um dos mais completos, pois é autoritativo, recursivo e implementa o DNSSEC. O unbound somente implementa servidor recursivo e trata, eficientemente, o DNSSEC.

Quem precisa de um servidor autoritativo?

 

Somente quem precisar difundir dominios na Internet. O autoritativo é o servidor que está autorizado a responder por um domínio. A autoridade para que um servidor de DNS (autoritativo) responda pelo domínio é dada pelos registros de domínios, oficiais, de uma determinada região do mundo. No nosso caso, Brasil, quem fornece a autoridade para que um ou mais servidores autoritativos respondam por um domínio é o Registro.br. Como já falamos, a autoridade do Registro.br é reconhecida pelos servidores root, pois o Registro.br é um NIR (National Internet Register) responsável pelo Brasil e autorizado pelo LACNIC, que é um dos cinco RIRs (Regional Internet Register), do mundo. O Registro.br exige, no mínimo, dois autoritativos para repassar a autoridade. O Registro.br não faz nenhuma exigência em relação aos recursivos, em outras palavras, nem dá bola para eles.

Por ser o autoritativo autorizado pelo Registro.br, a responder por um domínio, ele é um servidor que deve ficar disponível para qualquer consulta feita na Internet. Ou seja, ele é um servidor aberto, sob o ponto de vista de consultas aos domínios sob sua jurisdição. Aqui mora o perigo! Se o servidor autoritativo não estiver muito bem preparado e, não usar o DNSSEC, sua vulnerabilidade passa a ser enorme! Ele está suscetível à chamada poluição de DNS (comprometimento, envenenamento), segundo os comprovados argumentos de Dan Kaminsky, cujos artigos e experimentos podem ser vistos em [1]. A era pós-Kaminsky felizmente trouxe melhoras sinificativas nos sistemas que implementam o autoritativo, principal alvo de ataques.

Se você possui poucos dominios, não se meta a perder tempo em estabelecer um servidor autoritativo. Use o serviços de empresas especializadas, garantindo algumas premissas básicas: (a) possuir pelo menos 2 autoritativos em redes diferentes e, preferencialmente, possuir o(s) servidor(es) autoritativo(s) principais, escondido(s), (b) implemente o DNSSEC, (c) possua mecanismos de criptografia para o tráfego relativo às transferência de zonas e, (d) seja de fácil utilização. Achar a empresa que forneça os serviços com tais características é uma tarefa razoavelmente complicada. Depois de achar, tudo fica bem melhor. Todo cuidado é pouco, contudo. Recentemente ouvimos histórias de envenenamento de servidores da Telefônica, Embratel, etc.

Quem precisa de um servidor recursivo?

 

Todos aqueles que possuem usuários ou máquinas com acesso à Internet, na rede sob seu controle. Por exemplo, tenho o Speedy na minha casa. Com cerca de 5 equipamentos. Implementei um recursivo por lá? Não! Uso o openDNS. Se ele falhar, uso o DNS da Telefônica. Ou seja, não possuo atividades sensíveis.

E na minha empresa? Ah, nela sim! A estrutura de meu sistema de servidores DNS está definida à semelhança da topologia mostrada aqui, onde em cada rede colocamos um ou mais recursivos.

O servidor recursivo tem uma característica interessante, diferentemente do autoritativo. Ele consulta o autoritativo, mas não está liberado para toda a Internet. Isto é, não deveria! Somente está liberado para as demandas de sua rede. Entretanto, ele traz as informações de domínios vindas de todos os autoritativos do mundo. Se algum autoritativo está comprometido, ele passará tais informaçoes para frente. Nesse caso, somente o DNSSEC poderá aliviar a tensão do comprometimento, já que é impossível criptogafar o tráfego entre recursivos e autoritativos, pelo menos por enquanto.

Porque tráfego criptografado entre os servidores autoritativos?

 

Para dificultar a vida do “homem do meio”, técnica muito usada para capturar tráfego entre servidores na Internet. Ele irá conseguir, mas terá de descobrir e adicionar a mesma técnica de criptografia e decriptografia. O DNSSEC adiciona, por outro lado, uma dificuldade a mais, nas tentativas de comprometimento dos servidores. É importante lembrar, que o DNSSEC não criptografa o tráfego nas transferências de zonas entre os autoritativos. Existem técnicas no bind para fazer isso. O DNSSEC garante a integridade dos dados, nesse caso, importantíssimo durante as consultas de recursivos, cujo procedimento recebe o nome de “cadeia de confiança” ou “cadeia de autenticação”.

Uma pergunta final

 

Ah, se meus servidores de DNS são seguros? Uai, espero que sim … Servidores de DNS são, provavelmente, os mais importantes componentes da infraestrutura da Internet. Talvez não seja suficiente, diante da competência dos “bad boys”. É preciso monitorá-los e ficar atento às recomendações constantes e avaliações dos melhores especialistas repassadas em listas técnicas nacionais e internacionais. Além de usar, efetivamente, os recursos inerentes ao próprio servidor de DNS.

O DNSSEC nos tranquiliza porque confere ao DNS, três garantias fundamentais, repetindo algumas que já falamos: (a) a identidade da origem ou, a autenticidade do recursivo (consulta) ou autoritativo (transferência de zonas), que está buscando a informação, (b) a integridade dos dados, através de chaves públicas de criptografias associadas ao dominio e, (c) o reconhecimento da não existência de um nome ou tipo de registro de DNS. Três pontos tão importantes, que não se pode imaginar porque DNSSEC não está implementado em todos os domínios. Veja as referências do artigo DNSSEC I, nesse blogue.

Por fim, algumas empresas, com grande número de domínios para publicação, implementam um outro tipo de DNS, denominado forwarder (reencaminhador), como forma de evitar a exposição direta de seus recursivos. Elas recuam os servidores para trás do firewall e colocam o encaminhador em uma DMZ, por exemplo, acessível a todos os equipamentos que consultam por domínios. Trataremos desse tipo de servidor de DNS, em outra oportunidade.

Imperdível, no e-learning do RIPE NCC (o RIR europeu), [2], sobre como se relacionam os dois tipos de DNS tratados acima, os resolvedores clientes e os servidores root.

Autoritativos do Registro.br

 

O Registro.br disponibiliza servidores autoritativos gratuítos, com DNSSEC incluído. Vale a pena usá-los, como o objetivo de eliminar os servidores autoritativos locais e, assim reduzir, enormemente, o esforço de manutenção. Há uma restrição de no máximo 40 registros (ou apontamentos), por zona. Usando tais servidores pode-se manter somente os recursivos, localmente, e reduzindo o esforço de manutenção, drasticamente. Uma boa alternativa é usar o unbound, como recursivo. Naturalmente, a recomendação é de que o recursivo seja compatível com o IPv6, também. Uma outra restrição dos autoritativos do Registro.br é o fato de não suportarem zonas reversas.

Cenário futuro para o DNS

 

Os autoritativos do Registro.br possuem restrições. Imagina-se que há uma motivação para isso. O Registro.br não dá maiores informações à comunidade, sobre as razões das restrições. Paul Vixie, que mantem um blogue interessante em [4], escreveu um recente artigo, [3], no qual, comenta (subliminarmente), a iniciativa do ISC (que produz e distribui o bind) em cobrar para a instalação de secundários, [5]. O principal argumento, sempre é o de que o funcionamento adequado do DNS é demasiadamente importante para a Infraestrutura da Internet. O Registro.br, ao implementar sua disponibilidade restrita, de autoritativos, talvez se justifique sob o mesmo argumento. Mas, a limitação do Registro.br, em 40 RRs, poderia viabilizar o futuro, sob um modelo muito parecido com o do ISC, [5].

À luz de tais movimentos é preciso pensar, bastante, antes de decidir sobre o modelo de servidores de DNS a ser escolhido. Assim como a sociedade, classificada pelos filósofos contemporâneos, sob um modelo sociocultural pós-moderno*, a Infraestrutura da Internet está, também, em forte transformação!



* Os filósofos contemporâneos estão atentos aos debates orientados às mudanças de nossas atuais condições culturais, sociais e existenciais. Pós-modernidade não parece ser um conceito adequado. Então estão propondo modelos alternativos, tais como, hipermodernidade, de Gilles Lipsovetsky, ou modernidade líquida, de Zygmunt Bauman, entre outros. Há uma entrevista muito interessante de Zygmunt Bauman, na revista “filosofia”, Ano V, No. 58, página 6, onde há um destaque para: “A propensão a mudar de forma sob a influência de mínimas, fracas e ligeiras pressões é apenas o traço mais óbvio da atual condição sóciocultural“.


 

Referências

 

[1] Dan Kaminsky, Sobre envenamento do DNS e artigos correlatos.

[2] RIPE-NCC, DNS Basics.

[3] Paulo Vixie, Anycast, Unicast, or Both?, Disponível em: http://www.circleid.com/posts/20110531_anycast_unicast_or_both/. Acessado em 31/05/2011.

[4] Paulo Vixie, vixie’s blog, Disponível em: http://www.isc.org/blogs/vixie. Acessado em 31/05/2011.

[5] ISC, SNS@ISC: ISC’s Name Service. Disponível em: https://www.isc.org/solutions/sns. Acessado em 31/05/2011.

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.

DNS: Um exemplo de topologia

DNS, ninguém tem dúvida representa para a Internet, o mesmo que o ar para o ser humano. Embora esse fato seja reconhecido, as preocupações com os servidores de DNS são relegadas a um último plano. Eis alguns exemplos do que se vê por ai, inclusive em provedores de médio e grande porte:

  1. Usam dois servidores de DNS (o mínimo exigido), em uma mesma máquina.
  2. Usam dois servidores de DNS, na mesma rede.
  3. Não se preocupam com o TTL das zonas.
  4. Ignoram a importância do reverso, achando que o reverso reproduz uma transparência indesejável, o que é uma falácia.
  5. Não estão preocupados com o DNSSEC. Qualquer dia desses, o Registro.br irá dar um prazo para implementar o DNSSEC (espera-se).

Seria bom pensar a respeito dos itens acima. O Itinera, desde seu inicio segue a seguinte topologia em seus servidores de DNS:

Antes da primeira versão do Itinera, a topologia acima existia e mantida manualmente. Nas primeiras versões do Itinera, não se usava o conceito de base de dados. Agora, com o Itinera ad futurum as bases de dados são usadas para cada grupo de servidores. A topologia acima, com ou sem base de dados pode, sem muito trabalho, existir com manutenção manual, trazendo grandes vantagens, em particular sob o ponto de vista da segurança. Mesmo que se venha a usar o DNSSEC, o qual exigirá um esforço de manutenção mais sistemática nos servidores (há ferramentas disponíveis para tratar o DNSSEC manualmente.

Eis algumas características importantes, que permitem implementações de variações do modelo acima:

  • É usado o BIND nos autoritativos e Unbound nos recursivos. Para ambos, há uma preocupação, firme, em manter atualizado com a última versão.
  • Todos servidores autoritativos estão rodando em FreeBSD. Nem todos os recursivos estão sob FreeBSD.
  • Os servidores primários (P) são em número de dois, para permitir redundância. São atualizados via rsync.
  • Os servidores primários são escondidos, aos quais, somente os servidores do tipo master (M) possuem acesso. Além das restrições naturais do BIND, são impostas regras de “firewall” locais e nos “gateways”. Isso torna o conjunto seguro? Provavelmente, não. Mas torna-o menos vulnerável.
  • Todos os servidores estão em redes distintas e remotamente localizados, exceto os recursivos (R), distribuídos a critério dos donos das redes que usam o Itinera.
  • Os servidores M, embora redundantes, não estão disponíveis. Somente um cuida dos servidores autoritativos (A).
  • Não há base de dados local ativa, em nenhum servidor (PE, M, A ou R). Há replicação da base de dados, mantendo uma simples cópia atualizada diante de qualquer alteração.
  • Todo o tráfego na direção das bases de dados e suas cópias, usa openSSL.
  • A cada duas horas, se houve alteração em algum dos servidores um backup é automaticamente acionado, sobre o servidor que sofreu a alteração, exceto nos A e R.
  • Todos os servidores são monitorados, para efeito de verificação em suas atividades.
  • Não há estatísticas de tráfego e/ou utilização geral do servidor. Está na pauta para incluir. Periodicamente, é feito manualmente, usando as ferramentas do BIND e outras disponíveis.
  • Embora testado, não foi implementado o procedimento automático de gerenciamento do DNSSEC. Entretanto, toda a estrutura dos PEs foram alteradas para facilitar a implementação do DNSSEC. Em outro artigo, falarei sobre o DNSSEC, especificamente.
  • Todos os servidores estão com NTP. Três deles integrados aos servidores do Nic.br. O restante são clientes destes três e servem como clientes para máquinas das redes locais.
%d blogueiros gostam disto: