Infraestrutura da Internet

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:

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:

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:

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.

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.