Arquivo

Archive for janeiro \13\-03:00 2009

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.

Todos os IPs do mundo (2)

Depois de conhecermos as atualizações dos IPs atribuídos para todo o mundo (em 1), o problema é descobrir de forma automática da real alocação de um determinado IP e qual seu responsável. Por outro lado queremos saber (também de forma automática), se um domínio existe e a quem ele pertence.

Uma das mais importantes ferramentas da Internet para obter tais informações é o whois. Um bom começo está na referência [2]. Tamanha importância, em mesmo grau, equivalente desprezo ao whois por aqueles que governam a Internet, aparentemente. Vejam que a referência [2], não é atualizada desde 2004.

Um dos melhores clientes do whois, que tive oportunidade de experimentar foi o do FreeBSD (7.1). Provavelmente é equivalente a qualquer sistema baseado em Unix. Para ele ser eficaz é bom ter a relação final da referência [2].

Ao Itinera ad futurum, o que interssa é um procedimento automático. Portanto, usaremos o Net_Whois do Pear, como ilustração. A experiência é fantástica!

O Net_Whois, em sua versão 1.0 possui algumas deficiências. Cheguei a localizar duas. Uma delas já há uma sugestão para alterar e trata-se de permitir o uso da linha de comando do whois no Unix. A outra, é o fato dele trazer uma cadeia de caracteres com LF e CR. Se alguém precisar da tabela ASCII, um bom local é aqui, na Wikipedia. Vejamos uma cadeia de caracteres resultante do Net_Whois:


% Copyright (c) Nic.br % The use of the data below is only permitted as described in % full by the terms of use (http://registro.br/termo/en.html), % being prohibited its distribution, comercialization or % reproduction, in particular, to use it for advertising or % any similar purpose. % 2009-01-06 15:11:33 (BRST -02:00) domain: nic.br owner: Núcleo de Informação e Coordenação do Ponto BR ownerid: 005.506.560/0001-36 responsible: Demi Getschko country: BR owner-c: FAN admin-c: FAN tech-c: FAN billing-c: FAN nserver: a.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: b.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: c.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: d.dns.br nsstat: 20090106 AA nslastaa: 20090106 nserver: e.dns.br nsstat: 20090106 AA nslastaa: 20090106 dsrecord: 57436 RSA/SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B dsstatus: 20090106 DSOK dslastok: 20090106 created: 19970711 #46903 changed: 20070606 status: published nic-hdl-br: FAN person: Frederico Augusto de Carvalho Neves e-mail: fneves@registro.br created: 19971217 changed: 20030721 % Security and mail abuse issues should also be addressed to % cert.br, http://www.cert.br/, respectivelly to cert@cert.br % and mail-abuse@cert.br % % whois.registro.br accepts only direct match queries. Types % of queries are: domain (.br), ticket, provider, ID, CIDR % block, IP and ASN.

Esse é um resultado vindo do whois.nic.br, um dos mais consistentes whois do mundo.

Uma análise mais detalhada nos indica que % antecede um comentário. Há os chamados objetos do whois cujo conteúdo são apêndices de palavras chaves, tais como domain:, nsstat: e outras. Todas as palavras chaves terminam com um :. O conteúdo de um objeto termina quando começa um outro objeto ou com, novamente, o %. E, um comentário termina com o final da cadeia de caracteres. Quem sabe, o conteúdo de um objeto também termina com o final da cadeia.

Nosso objetivo é desenvolver um algorítmo para reconhecer o que é comentário, o que é objeto e seu respectivo conteúdo. Se pensarmos em um algorítmo para transformar a cadeia recebida pelo whois em algo organizado como o whois do Unix, o problema fica resolvido. Para ser mais claro, desejamos transformar a cadeia no seguinte texto organizado:


% Copyright (c) Nic.br
% The use of the data below is only permitted as described in
% full by the terms of use (http://registro.br/termo/en.html),
% being prohibited its distribution, comercialization or
% reproduction, in particular, to use it for advertising or
% any similar purpose.
% 2009-01-06 15:11:33 (BRST -02:00)
domain: nic.br
owner: Núcleo de Informação e Coordenação do Ponto BR
ownerid: 005.506.560/0001-36
responsible: Demi Getschko
country: BR
owner-c: FAN
admin-c: FAN
tech-c: FAN
billing-c: FAN
nserver: a.dns.br
nsstat: 20090106 AA
nslastaa: 20090106
nserver: b.dns.br
nsstat: 20090106 AA
nslastaa: 20090106
nserver: c.dns.br
nsstat: 20090106 AA
nslastaa: 20090106
nserver: d.dns.br
nsstat: 20090106 AA
nslastaa: 20090106
nserver: e.dns.br
nsstat: 20090106 AA
nslastaa: 20090106
dsrecord: 57436 RSA/SHA-1 CCB7D717A8868B8739A78FEC8FB60E62EBE2D89B
dsstatus: 20090106 DSOK
dslastok: 20090106
created: 19970711 #46903
changed: 20070606
status: published
nic-hdl-br: FAN
person: Frederico Augusto de Carvalho Neves
e-mail: fneves@registro.br
created: 19971217
changed: 20030721
% Security and mail abuse issues should also be addressed to
% cert.br, http://www.cert.br/, respectivelly to cert@cert.br
% and mail-abuse@cert.br
%
% whois.registro.br accepts only direct match queries. Types
% of queries are: domain (.br), ticket, provider, ID, CIDR
% block, IP and ASN.

Um programador habilidoso talvez faça um algoritmo desses em 1 dia. Um programador experiente, com formação em Ciência da Computação (ou Engenharia da Computação), levará algumas poucas horas para criar um algoritmo eficiente e elegante. A questão de eficiência no caso da proposta acima é irrelevante, pois a cadeia resultante do whois é muito pequena para a capacidade de computação de um PC atual. Mas a elegância e clareza do algoritmo são as questões importantes para o sistema no qual ele será utilizado. O programador habilidoso, sem os fundamentos teóricos do programador experiente, provavelmente achará o algoritmo muito difícil e, certamente, tornará o sistema do qual fará parte, ineficiente.

O programador experiente usará as técnicas da Teoria dos Autômatos. Em particular, o Autômato de Pilha. Uma procura no Google, com esse título trará inúmeros referências importantes. Aplicar Autômato de Pilha no problema que temos de resolver é um exercício fascinante, da arte de programar.

Eis o algoritmo em PHP+PEAR:


<?php
function imprimeLinhaEZeraPilha ($pilha) {
$pilha = array_reverse($pilha); // Pilha que vira um array.
$linha = ”;
while (count($pilha) > 0) {
$linha .= array_pop($pilha);
}
echo ‘<tr><td colspan=”2″><font face=”Courier new” size=”2″>’ . $linha . ‘</font></td></tr>’;
return $pilha; // retorna Pilha vazia
}

//

require_once “Net/Whois.php”;

$server = “whois.nic.br”;
$query = “nic.br”;

$whois = new Net_Whois;

// Verifica o whois
$data = $whois->query($query, $server);

// whois.nic.br: dominio
$objetos = array();
$objetos[0] = ‘nulo:’;
$objetos[1] = ‘domain:’;
$objetos[2] = ‘owner:’;
$objetos[3] = ‘ownerid:’;
$objetos[4] = ‘responsible:’;
$objetos[5] = ‘country:’;
$objetos[6] = ‘owner-c:’;
$objetos[7] = ‘admin-c:’;
$objetos[8] = ‘tech-c:’;
$objetos[9] = ‘billing-c:’;
$objetos[10] = ‘nserver:’;
$objetos[11] = ‘nsstat:’;
$objetos[12] = ‘nslastaa:’;
$objetos[13] = ‘dsrecord:’;
$objetos[14] = ‘dsstatus:’;
$objetos[15] = ‘dslastok:’;
$objetos[16] = ‘created:’;
$objetos[17] = ‘expires:’;
$objetos[18] = ‘changed:’;
$objetos[19] = ‘status:’;
$objetos[20] = ‘nic-hdl-br:’;
$objetos[21] = ‘person:’;
$objetos[22] = ‘e-mail:’;
$objetos[23] = ‘created:’;
$objetos[24] = ‘changed:’;

echo ‘<table border=”0″ align=”left” cellpadding=”0″ cellspacing=”1″>’;

$alvo1 = “%”;
$alvo2 = “:”;
$alvo3 = ” “;
$pilha = array();
$pilha_auxiliar = array();

$novo_alvo1 = false;
// Percorre cada elemento do string
while (strlen($data) > 0) {
$elemento = substr($data, 0, 1);
if (ord($elemento) == 10 || ord($elemento) == 13) {
$elemento = ‘ ‘;
}
array_push($pilha, $elemento);
$data = substr($data, 1);
switch ($elemento) {
case $alvo1:
if (!$novo_alvo1) {
$novo_alvo1 = true;
if (count($pilha) > 1) {
array_pop($pilha);
$pilha = imprimeLinhaEZeraPilha ($pilha);
array_push($pilha, $elemento);
}
} else {
array_pop($pilha);
$pilha = imprimeLinhaEZeraPilha ($pilha);
array_push($pilha, $elemento);
$novo_alvo1 = false;
}
break;
case $alvo2:
// Desempilha o : e tudo que segue até um branco, empilhando na pilha auxiliar
$elemento = array_pop($pilha);

while (ord($elemento) !== ord (‘ ‘) && count($pilha) > 0) {
array_push($pilha_auxiliar, $elemento);
$elemento = array_pop($pilha);
}
// Monta string com o suposto objeto
$objeto = ”;
while (count($pilha_auxiliar) > 0) {
$objeto .= array_pop($pilha_auxiliar);
}
if (!array_search($objeto, $objetos)) {
// Não é um objeto, então, devolve para a pilha e continua
array_push($pilha, $elemento); // Empilha o branco antes % 2008-12-14 08:56:44 (BRST -02:00)
while (strlen($objeto) >= 1) {
$elemento = substr($objeto, 0, 1);
$objeto = substr($objeto, 1);
array_push($pilha, $elemento);
}
} else {
// É um objeto, então imprime a pilha e segue em frente após empilhar tudo que está na pilha auxiliar
$pilha = imprimeLinhaEZeraPilha ($pilha);
while (strlen($objeto) > 0) {
$elemento = substr($objeto, 0, 1);
$objeto = substr($objeto, 1);
array_push($pilha, $elemento);
}
}
break;
}
}
if (count($pilha) > 0) {
$pilha = imprimeLinhaEZeraPilha ($pilha);
echo ‘<tr><td colspan=”2″><font face=”Courier new” size=”2″> </font></td></tr>’;
}
echo ‘</table>’;
?>

%d blogueiros gostam disto: