Arquivo

Archive for the ‘Whois’ Category

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!


Anúncios

Curso IRR – Parte X: Relações entre objetos

Introdução

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } estabeleceram um enlace privativo (em vermelho), através de um acordo bilateral :

 

Figura 1: Um enlace privativo no cenário.

 

Ao desenvolver as políticas de roteamento para o cenário da figura 1, duas novidades aparecem. A primeira delas é o uso de ações nos atributos import e export do objeto aut-num. No exemplo abaixo, a ação utilizada é pref de preference, parâmetro já nosso conhecido, do BGP4. Ações e outros parâmetros permitidos nos atributos atributos serão discutidos formalmente nos segmentos da sequência desse treinamento. A outra novidade, na realidade é uma questão que aparece associada a possíveis inconsistências, ao definir ou projetar as políticas de roteamento. No contexto em que aparece uma inconsistência será elaborada uma orientação. Eis as políticas possíveis e suas especificações para o IRR, no cenário da figura 1:

  1. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Esse tráfego nunca poderá passar por \textbf{AS} _ \textbf{w }. Além disso, o enlace privativo nunca poderia ser usado para trânsito, originado de \textbf{AS} _ \textbf{x } e de \textbf{AS} _ \textbf{y }. Eis como ficariam os objetos aut-num para cada um dos \textbf{ASes}:
       aut-num:   \textbf{AS} _ \textbf{x }
       as-name:   \textbf{AS} _ \textbf{x }-NET
       descr:     \textbf{AS} _ \textbf{x }Autonomous System
       remarks:   ===============================================
       remarks:   http://www.exemplo.com.br
       remarks:   ===============================================
       remarks:   Security Note
       remarks:   Any Notification about \textbf{AS} _ \textbf{x } security please
       remarks:   e-mail to: asx.ABUSE@exemplo.com.br
       remarks:   ===============================================
       import:    from \textbf{AS} _ \textbf{w } action pref = 100; accept NOT \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS} _ \textbf{x }
       import:    from \textbf{AS} _ \textbf{y } action pref = 50; accept \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
       admin-c:   IDASx-NICBR
       tech-c:    IDASx-NICBR
       notify:    asx-admin@exemplo.com.br
       mnt-by:    MAINT-\textbf{AS} _ \textbf{x }
       changed:   asx-admin@exemplo.com.br
       remarks:   **************************
       remarks:   Test only.
       remarks:   **************************
       source:    PEGASUS
       password:  senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{x }
    
       aut-num:   \textbf{AS} _ \textbf{w }
       ...
       import:    from \textbf{AS} _ \textbf{x } action pref = 100; accept \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{x } announce ANY
       import:    from \textbf{AS} _ \textbf{y } action pref = 100; accept \textbf{AS} _ \textbf{y }
       export:    to \textbf{AS} _ \textbf{y } announce ANY
       ...
       
    
       aut-num:   \textbf{AS} _ \textbf{y }
       ...
       import:    from \textbf{AS} _ \textbf{w } pref = 100; accept NOT \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS} _ \textbf{y }
       import:    from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS} _ \textbf{x }
       export:    to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }
       ...
    
    

    Olhando a política definida para o \textbf{AS} _ \textbf{w } há uma visível inconsistência: ele anuncia \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y } (export: to \textbf{AS} _ \textbf{y } announce ANY) e, também, anuncia \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x } (export: to \textbf{AS} _ \textbf{x } announce ANY). Tal inconsistência está sendo resolvida nas políticas de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, respectivamente, com o uso da ação accept NOT, em um claro relacionamento entre objetos (nesse caso, uma inter-relação entre três objetos aut-num). Mas, quem está definindo a política é um ser humano e, consequentemente, muito sujeito a erros. Sobretudo, se a política for complexa! Felizmente, as ferramentas, cujas abordagens serão feitas nos próximos segmentos auxiliam-nos na tarefa de analisar a consistência de cada objeto e respectivos relacionamentos. O que elimina as preocupações associadas a consistências (ou inconsistências).

  2. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } poderia ser feita via \textbf{AS} _ \textbf{w }. Mas nunca, os enlaces para \textbf{AS} _ \textbf{w } poderiam ser usados para trânsito.Eis como ficariam os objetos aut-num para cada um dos \textbf{ASes}:
       aut-num:   \textbf{AS}_\textbf{x }
       ...
       import:  from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:    to \textbf{AS}_\textbf{w } announce \textbf{AS}_\textbf{x }
       import:  from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       export:    \textbf{AS} _ \textbf{x } \textbf{AS} _ \textbf{y }
       ...
    
       aut-num:   \textbf{AS}_\textbf{w }
       ...
       import:  from \textbf{AS} _ \textbf{x } action pref = 100; accept \textbf{AS} _ \textbf{x }
       export:    \textbf{AS} _ \textbf{x } announce ANY
       import:  from \textbf{AS}_\textbf{y } action pref = 100; accept \textbf{AS}_\textbf{y }
       export:    to \textbf{AS}_\textbf{y } announce ANY
       
       ...
    
       aut-num:   \textbf{AS}_\textbf{y }
       ...
       import:  from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:    to \textbf{AS} _ \textbf{w } announce \textbf{AS}_\textbf{y }
       import:  from \textbf{AS}_\textbf{x } action pref = 50; accept \textbf{AS}_\textbf{x }
       export:    to \textbf{AS}_\textbf{x } announce \textbf{AS}_\textbf{y }
       ...
    

    Neste exemplo, ao imaginar as politicas operacionais, \textbf{AS}_\textbf{x } receberá anúncios de \textbf{AS}_\textbf{y } tanto do \textbf{AS} _ \textbf{w } como do \textbf{AS}_\textbf{y }. No caso específico do anúncio para \textbf{AS}_\textbf{y }, a preferência é de menor custo, permitindo o uso do enlace privativo sempre que for necessário (tráfego de demanda entre eles), exceto tráfego de trânsito se falhar um dos respectivos enlaces com \textbf{AS} _ \textbf{w } pois, esse não aceita anúncio de um via o outro.

  3. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o enlace privativo falhar, a troca de tráfego entre \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } poderia ser feita via \textbf{AS} _ \textbf{w }. Se a conexão entre \textbf{AS} _ \textbf{y } e \textbf{AS} _ \textbf{w } falhar, o tráfego originado em \textbf{AS} _ \textbf{y }, o tráfego originado em \textbf{AS} _ \textbf{y } com objetivo de trânsito via \textbf{AS} _ \textbf{w } poderia usar o enlace privativo e a conexão de \textbf{AS} _ \textbf{x } com \textbf{AS} _ \textbf{w }.
       aut-num:  \textbf{AS} _ \textbf{x }
       ...
       import:   from \textbf{AS}_\textbf{w } action pref = 100; accept ANY
       export:   to \textbf{AS}_\textbf{w } announce \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 110; accept ANY
       export:   to \textbf{AS}_\textbf{y } \textbf{AS} _ \textbf{x }
       ...
    
       aut-num:  \textbf{AS}_\textbf{w }
       import:   from \textbf{AS} _ \textbf{x } action pref = 1; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
       import:   from \textbf{AS}_\textbf{y } action pref = 1; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 2; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       
    
       aut-num:  \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{w } 100 accept ANY
       export:   to \textbf{AS}_\textbf{w } \textbf{AS}_\textbf{y } announce \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS} _ \textbf{x }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
    

    O exemplo ilustra a importância de propagar informação de roteamento em todas as direções quanto existir um cenário em que essa política é exigida. Não é usual conectividade em uma única direção. Para efeito do próximo exemplo, vale lembrar que se a conexão entre \textbf{AS}_\textbf{y } e \textbf{AS}_\textbf{w } falhar, \textbf{AS}_\textbf{y } terá seu tráfego de trânsito via \textbf{AS} _ \textbf{x } e, vice-versa.

  4. \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } gostariam de trocar o tráfego entre si, exclusivamente via o enlace privativo. Se o link privativo falhar, o tráfego entre \textbf{AS} _ \textbf{y } e \textbf{AS} _ \textbf{x } poderia ser roteado via \textbf{AS} _ \textbf{w }. Se tal enlace também falhar ele poderia passar através de outras conexões de trânsito (digamos, \textbf{AS} _ \textbf{z } com conexão com \textbf{AS}_\textbf{y } ).
       aut-num:  \textbf{AS}_\textbf{y }
       ...
       import:   from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       export:   to \textbf{AS} _ \textbf{w } announce \textbf{AS}_\textbf{y }
       import:   from \textbf{AS} _ \textbf{x } action pref = 50; accept \textbf{AS}_\textbf{y }
       import:   from \textbf{AS} _ \textbf{x } action pref = 110; accept ANY
       export:   to \textbf{AS} _ \textbf{x } \textbf{AS}_\textbf{y }
       ...
       source: PEGASUS
    
       aut-num:  \textbf{AS} _ \textbf{w }
       ...
       import:   from \textbf{AS}_\textbf{y } action pref = 1; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       import:   from \textbf{AS} _ \textbf{x } action pref = 1; accept \textbf{AS} _ \textbf{x }
       import:   from \textbf{AS} _ \textbf{x } action pref = 2; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS} _ \textbf{x } announce ANY
       ...
       source: PEGASUS
    
       aut-num:  \textbf{AS} _ \textbf{x }
       ...
       import:   from \textbf{AS} _ \textbf{w } action pref = 100; accept ANY
       import:   from \textbf{AS} _ \textbf{z } action pref = 100; accept ANY
       export:   to \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x } announce ASy
       export:   to \textbf{AS} _ \textbf{z } \textbf{AS} _ \textbf{x } announce \textbf{AS}_\textbf{y }
       import:   from \textbf{AS}_\textbf{y } action pref = 50; accept \textbf{AS}_\textbf{y }
       export:   to \textbf{AS}_\textbf{y } announce ANY
       ...
       source: PEGASUS
    

    O exemplo acima é uma das variações alternativas. Fica como exercício imaginar outras.

Outros objetos

Os objetos do IRR relacionam-se entre si e há particularidades nesse relacionamento, dependendo dos objetos envolvidos. Nos próximos segmentos estaremos de uma maneira formal, descrevendo todos os objetos com base, principalmente, das referências [2] e [3].

Há uma boa referência no RIPE [4] onde uma interface amigável permite a criação de objetos, com ajuda, inclusive. Devemos lembrar duas coisas ao usar tal ferramenta: (a) não enviar o objeto para o RIPE e sim visualizá-lo e, (b) nem todos os objetos são compatíveis com as bases IRR tradicionais. Por exemplo, o objeto limerik, entre outros.

Manutenção do ASN no Registro.br

Esse segmento se baseou em [1] que foi atualizada por [2] e [3]. Mesmo assim é um excelente tutorial e recomenda-se para uma agressiva leitura. Ela é uma RFC tão útil que existe uma versão em português (de Portugal). Não perdeu sua utilidade entretanto. Para ver um exemplo que todos sempre procuram, começamos pelo whois -c br AS22548, do Nic.br. O resultado é o seguinte:

   aut-num:     AS22548
   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
   routing-c:   FAN
   abuse-c:     FAN
   created:     20011016
   changed:     20050531
   inetnum:     200.160.0/20
   inetnum:     2001:12ff::/32
   as-in:       from AS3549 100 accept ANY
   as-in:       from AS10429 100 accept ANY
   as-in:       from AS16735 100 accept ANY
   as-out:      to AS3549 announce AS22548
   as-out:      to AS10429 announce AS22548
   as-out:      to AS16735 announce AS22548

As linhas em negrito é que o que interessa nessa abordagem. Ela representa o que foi informado nos espaços correspondente a as-in e as-out do ambiente do ASN na área privativa do Registro.br. Está de acordo com a especificação da RFC1786, [1] e ainda não foi atualizada.

O aut-num do AS22548 está cadastrado no RADB e um whois -m AS22548, nos trás o seguinte:

   whois -m AS22548

   aut-num:    AS22548
   as-name:    REGISTROBRNET
   descr:      Registro.BR the .br registry
   import:     from AS3549   accept ANY
   import:     from AS10429   accept ANY
   import:     from AS16735   accept ANY
   import:     from AS112   accept AS112 AND {192.175.48.0/24}
   import:     from AS30122   accept AS30122 AND {192.228.80.0/24}
   import:     from AS30122   accept AS3557 AND {192.5.5.0/24}
   import:     from AS31529   accept AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS3549   announce AS22548 AND {200.160.0.0/20}
   export:     to AS3549   announce AS30122 AND {192.228.80.0/24}
   export:     to AS3549   announce AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS10429
               action community = { 10429:110 };
               announce AS22548 AND { 200.160.0.0/20 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS112 AND { 192.175.48.0/24 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS30122 AND { 192.228.80.0/24 }
   export:     to AS10429
               action community = { 10429:110 };
               announce AS31529 AND { 194.246.96.0/24 } AND { 194.0.0.0/24 }
   export:     to AS10429
               action community = { 10429:122 };
               announce AS3557 AND { 192.5.5.0/24 }
   export:     to AS16735   announce AS22548 AND {200.160.0.0/20}
   export:     to AS16735   announce AS112 AND {192.175.48.0/24}
   export:     to AS16735   announce AS30122 AND {192.228.80.0/24}
   export:     to AS16735   announce AS31529 AND {194.246.96.0/24} AND {194.0.0.0/24}
   export:     to AS16735
               action community = { 16735:900 };
               announce AS3557 AND { 192.5.5.0/24 }
   ...
   

A especificação das políticas do AS22548 no IRR está perfeita e já usa as recomendações da RFC2622, em [2]. Os atributos import e export representam, respectivamente, as-in e as-out, na nova sintaxe da RPSL, [2]. Assim, na área de informações do AS no Registro.br é construido com as políticas de roteamento do respectivo AS. Quase ninguém preenche tais espaços mas, o exemplo ilustra como deve ser feito.

O exemplo, ilustra, também uma política de roteamento quase completa (falta o IPv6). Olhar políticas já criadas no IRR é uma boa maneira de consolidar o conhecimento necessário.

Itens relacionados:

Referências do segmento

[1] RFC1786, Representation of IP Routing Policies in a Routing Registry (ripe-81++) T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu [ March 1995 ] (TXT = 133643) (Status: INFORMATIONAL) (Stream: Legacy)
[2] RFC2622, Routing Policy Specification Language (RPSL) C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes RFC2280) (Updated-By RFC4012) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps)
[3] RFC4012, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates RFC2725, RFC2622) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP)
[4] Updating RIPE Database. Disponível aqui!

Categorias:BGP, IRR, Peering, Protocolos, TCP/IP, Whois

Curso IRR – Parte IX: objeto aut-num

Introdução

A referência [2] é uma descrição da RPSL (Routing Policy Specification Language) e foi atualizada por [3], que estende para IPv6. É uma linguagem muito poderosa, que permite aos administradores e operadores de redes especificarem políticas de roteamento em vários níveis e, escalável, ou seja, preparada para receber especificações de novos protocolos que, eventualmente, surjam no futuro. Finalmente, foi projetada com a expectativa de estabelecer políticas de roteamento globalmente que permitissem, cooperativamente, sua manutenção através de bases de dados distribuídas devidamente homologadas ou reconhecidas.

Definindo políticas de roteamento através da RPSL os administradores de ASes:

  • Melhorariam, cada vez mais, a integridade do roteamento na Internet.
  • Usariam ferramentas, que a partir do alto nível de especificação da RPSL, gerassem as configurações necessárias aos diversos roteadores disponíveis.
  • Teriam uma documentação de toda a política de roteamento, da topologia de suas redes e, fácil de ser lida, entendida e mantida, com visão de conjunto.
  • Teriam disponível uma linguagem baseada em objetos, que representam informações de política de roteamente e informações administrativas, extremamente importantes para todos os administradores de redes. Tais objetos são registrados no IRR por pessoas autorizadas.
  • Estariam confiantes (como consequência da cooperação), de que é uma ferramenta capaz de contribuir para que as configurações dos roteadores onde, a pouca intervenção humana protegeria adequadamente seus ambientes, de informações pouco precisas por motivações acidentais ou maliciosas. Vide [3].

As referências [1] e [2], são respeitadas pelos servidores do IRR, que fazem uma análise sintática e semântica sobre os atribustos e seus respectivos valores (como os compiladores). Mais recentemente, os servidores do IRR se ajustaram aos novos objetos propostos na RPSL e estão mais poderosos ao dar sustentação às ferramentas de manipulação das informações da base de dados do RADB (também, as homoladas – intermediárias – e, as privadas). Ganharam os administradores de ASes.

Recomenda-se a leitura do item 2 de [1]: “RPSL Names, Reserved Words, and Representation”.

O objeto aut-num

O objeto aut-num descreve as informações sobre um AS e suas políticas de roteamento, tanto sob o ponto de vista dos anúncios, como da aceitação de redes. Ele se aplica tanto ao IPv4 como ao IPv6.

Um dos mais importantes objetos de uma base IRR usa, intensivamente, a capacidade de relacionamento dos objetos, entre si. Alguns já vistos e outros a serem descritos nesse treinamento nos próximos segmentos. Assim, o objeto aut-num é combinado com o objeto que caracteriza o roteador (inet-rtr) e que fornece o número do sistema autônomo, indica as interfaces do roteador e que por sua vez é combinado com o objeto que mapeia os ASes envolvidos (as-set) e, finalmente se estendem aos objetos route(6) e route-set, dando segurança à informação dos prefixos que são anunciados. Os objetos as-set, route-set e inet-rtr serão discutidos nos próximos segmentos, mas podem ser encontrados em [1] e [2]

Os atributos do objeto aut-num

aut-num:        [obrigatório]  [único]      [primary/look-up key]
as-name:        [obrigatório]  [único]      [ ]
descr:          [obrigatório]  [único]      [ ]
member-of:      [opcional]     [multiplo]   [inverse key]
import:         [opcional]     [multiplo]   [ ]
export:         [opcional]     [multiplo]   [ ]
default:        [opcional]     [multiplo]   [ ]
remarks:        [opcional]     [multiplo]   [ ]
admin-c:        [obrigatório]  [multiplo]   [inverse key]
tech-c:         [obrigatório]  [multiplo]   [inverse key]
cross-mnt:      [opcional]     [multiplo]   [inverse key]
cross-nfy:      [opcional]     [multiplo]   [inverse key]
notify:         [opcional]     [multiplo]   [inverse key]
mnt-by:         [obrigatório]  [multiplo]   [inverse key]
changed:        [obrigatório]  [multiplo]   [ ]
source:         [obrigatório]  [único]      [ ]

Usando o objeto aut-num

No que segue, algumas adaptações foram feitas de [4].

Um cenário simples, para começar

A figura 1 exibe esse cenário simples e, razoavelmente comum:

Figura 1: Uma representação simples de uma conexão usando o BGP

Na figura 1, acima, a política de roteamento tendo em vista o conceito básico de anúncio e aceitação, para que dados da \textbf{Rede 1 } possam trafegar na direção da \textbf{Rede 2 } e vice-versa, está resumida nos seguintes pontos:

  1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{y }.
  2. \textbf{AS} _ \textbf{y } deve aceitar o anúncio de \textbf{AS} _ \textbf{x } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 2 } para a \textbf{Rede 1 }.
  3. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{x }.
  4. \textbf{AS} _ \textbf{x } deve aceitar o anúncio de \textbf{AS} _ \textbf{y } e usá-lo, isto é: permitir que pacotes fluam da \textbf{Rede 1 } para a \textbf{Rede 2 }.

O objeto aut-num é quem nos permitirá explicitar a política acima no IRR, através dos atributos import e export. Os respectivos objetos aut-num relativos aos sistemas autônomos \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, enviados para \textbf{email\_automatico@} \textbf{redepegasus.net.br} seriam:

aut-num:    \textbf{AS} _ \textbf{x }
as-name:    \textbf{AS} _ \textbf{x }-NET
descr:      \textbf{AS} _ \textbf{x } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asx.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:     to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
admin-c:    IDASx-NICBR
tech-c:     IDASx-NICBR
notify:     asx-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{x }
changed:    asx-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{x }

aut-num:    \textbf{AS} _ \textbf{y }
as-name:    \textbf{AS} _ \textbf{y }-NET
descr:      \textbf{AS} _ \textbf{y } Autonomous System
remarks:    ===============================================
remarks:    http://www.exemplo.com.br
remarks:    ===============================================
remarks:    Security Note
remarks:    Any Notification about ASx security please
remarks:    e-mail to: asy.ABUSE@exemplo.com.br
remarks:    ===============================================
import:     from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:     to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
admin-c:    IDASy-NICBR
tech-c:     IDASy-NICBR
notify:     asy-admin@exemplo.com.br
mnt-by:     MAINT-\textbf{AS} _ \textbf{y }
changed:    asy-admin@exemplo.com.br
remarks:    **************************
remarks:    Test only.
remarks:    **************************
source:     PEGASUS
password:   senha_decriptografada_do_mantenedor_\textbf{AS} _ \textbf{y }

Simplificando a apresentação

Para efeito didático, iremos suprimir os atributos já conhecidos e, assim, representaremos nosso objeto, da seguinte forma, com o nome de “Configuração”:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{x }
...
aut-num: \textbf{AS} _ \textbf{y }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{y }    
...

Configuração 1. Cenário simples

Um cenário não tão simples

Vamos ampliar para o cenário representado na figura 2, abaixo, onde agora podemos identificar a Internet:

Figura 2. Um cenário não tão simples

Em tese são quatro, os administradores de ASes envolvidos nesse cenário. Pouco se conhecem e devem pensar de maneira independente. O caráter colaborativo do IRR, entretanto induz a pensarmos que cada um deles estará atento às especificações dos outros em relação à política de roteamento. Tal atenção ocorre de três maneiras: (a) pela pesquisa à base IRR em relação aos ASes que fazem “peering” (seja qual for o tipo de tráfego), (b) durante o uso das ferramentas de apoio (p.ex., RTConfig), momento em que possíveis inconsistências podem ser encontradas e, (c) através de ferramentas de monitoramento próprias ou de terceiros (p.ex., MyASN). Vale um comentário de que tais ferramentas estão cada vez mais interessantes e eficazes, com mudanças nos protocolos e nos equipamentos (em especial roteadores). Um dos indutores dessas transformações é a área de conhecimento que está sendo chamada de “route analytics”. Eis as observações que caracterizam a política de roteamento do cenário exibido na figura 2, sob o ponto de vista de cada um dos sistemas autônomos envolvidos:

  • Sob o ponto de vista do \textbf{AS} _ \textbf{w }:
    1. \textbf{AS} _ \textbf{w } fornece trânsito para \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }.
    2. \textbf{AS} _ \textbf{w } fornece rotas locais para \textbf{AS} _ \textbf{z }.
    3. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{x }.
    4. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para para o resto do mundo.
    5. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{x } para \textbf{AS} _ \textbf{y }.
    6. \textbf{AS} _ \textbf{w } deve aceitar o anúncio de \textbf{AS} _ \textbf{y }.
    7. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para para o resto do mundo.
    8. \textbf{AS} _ \textbf{w } deve anunciar a rede de \textbf{AS} _ \textbf{y } para \textbf{AS} _ \textbf{x }.
    9. \textbf{AS} _ \textbf{w } deve anunciar a rede do \textbf{AS} _ \textbf{y } para para o \textbf{AS} _ \textbf{z }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{x }
    1. \textbf{AS} _ \textbf{x } deve anunciar a \textbf{Rede 1 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{x } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{y }
    1. \textbf{AS} _ \textbf{y } deve anunciar a \textbf{Rede 2 } para \textbf{AS} _ \textbf{w }.
    2. \textbf{AS} _ \textbf{y } deve aceitar o tráfego vindo de \textbf{AS} _ \textbf{w }
  • Sob o ponto de vista do \textbf{AS} _ \textbf{z }
    1. \textbf{AS} _ \textbf{z } deve aceitar todos os anúncios vindos de \textbf{AS} _ \textbf{w }.

O objeto aut-num sob a ótica do \textbf{AS} _ \textbf{w }

Vamos nos abstrair de alguns pontos da política de roteamento, nesse exemplo. Primeiro, não iremos definir a política para os itens 4 e 6. Isso porque nos falta algumas considerações sobre outros objetos e recursos dos respectivos atibutos. Portanto, deixaremos para abordar no próximo segmento. Segundo, não estamos interessados em em detalhes do \textbf{AS} _ \textbf{z } exceto o fato de que ele recebe anúncios do \textbf{AS} _ \textbf{w }.

Dito isso, eis o objeto aut-num para o \textbf{AS} _ \textbf{w }:

aut-num: \textbf{AS} _ \textbf{x }
...
import:  from \textbf{AS} _ \textbf{x } accept \textbf{AS} _ \textbf{x }
import:  from \textbf{AS} _ \textbf{y } accept \textbf{AS} _ \textbf{y }
import:  from \textbf{AS} _ \textbf{z } accept \textbf{AS} _ \textbf{z }
export:  to \textbf{AS} _ \textbf{x } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{y }
export:  to \textbf{AS} _ \textbf{y } announce \textbf{AS} _ \textbf{w } \textbf{AS} _ \textbf{x }
export:  to \textbf{AS} _ \textbf{z } announce \textbf{AS} _ \textbf{w }
...

Configuração 2. Sob a ótica do \textbf{AS} _ \textbf{w }

Uma pergunta que pode surgir, ao olhar a configuração 2 é: os anúncios de \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y } já não fazem parte dos anúncios de \textbf{AS} _ \textbf{w }? Boa pergunta! Fica como exercício. Assim, também, os objetos aut-num para os demais ASes envolvidos.

Adicionando mais complexidade ao cenário

A figura 3, abaixo representa um cenário onde \textbf{AS} _ \textbf{x } e \textbf{AS} _ \textbf{y }, através de um acordo bilateral estabeleceram um enlace privativo (em vermelho):

Figura 3: Um enlace privativo no cenário.

Iremos abordar esse novo cenário, na Parte X. A figura foi colocada antes, para se pensar sobre quais preocupações devem ser inseridas na política de roteamente. Por exemplo, se o enlace para o provedor de trânsito falhar, os \textbf{ASes} do acordo bilateral irão permitir o acesso ao trânsito pela conexão privativa?

Itens relacionados:

Referências do segmento

[1] \textbf{RFC2622}, Routing Policy Specification Language (RPSL) C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg, M. Terpstra [ June 1999 ] (TXT = 140811) (Obsoletes \textbf{RFC2280}) (Updated-By \textbf{RFC4012}) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[2] \textbf{RFC4012 }, Routing Policy Specification Language next generation (RPSLng) L. Blunk, J. Damas, F. Parent, A. Robachevsky [ March 2005 ] (TXT = 35217) (Updates \textbf{RFC2725 }, \textbf{RFC2622 }) (Status: PROPOSED STANDARD) (Stream: IETF, WG: NON WORKING GROUP).

[3] \textbf{RFC2725 }, Routing Policy System Security C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy [ December 1999 ] (TXT = 101649) (Updated-By \textbf{RFC4012 }) (Status: PROPOSED STANDARD) (Stream: IETF, Area: ops, WG: rps).

[4] Wijayatunga, C. (Part I) e Upadhaya, G. R. (Part II), APNIC Internet Routing Registry Tutorial. Disponível em http://www.sanog.org/resources/sanog4-IRR-Tutorial-champs.pdf. Acessado em: 29/04/2010.

[5] Cisco, BGP Best Path Selection Algorithm. Disponível em: http://www.ciscopartner.biz/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml. Acessado em: 29/04/2010.

Categorias:IRR, Peering, Protocolos, TCP/IP, Whois

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>’;
?>

Todos os IPs do mundo (1)

Algumas vezes precisamos de informações sobre a origem de um IP específico. Em ftp://ftp.lacnic.net/pub/stats parece estar atualizado (?), ASN, IPv4, IPv6 alocados e atribuídos ao respectivo RIR: LACNIC, AFRINIC, APNIC, LACNIC e RIPNCC.

Um script, em PHP + PEAR, pode trazer isso todos os dias automaticamente, colocando-o na CRONTAB:


#!/usr/local/bin/php -q
<?php

require_once “PEAR.php”;
require_once ‘Net/FTP.php’;

$test = new Net_FTP(‘ftp.lacnic.net’, 21);

$test->connect();
$test->login(‘anonymous’, ‘fulano@exemplo.com.br’);

$test->cd(‘/pub/stats/lacnic/’);
$test->get(‘delegated-lacnic-latest’, ‘/tmp/delegated-lacnic-latest’, true, FTP_ASCII);

$test->cd(‘/pub/stats/apnic/’);
$test->get(‘delegated-apnic-latest’, ‘/tmp/delegated-apnic-latest’, true, FTP_ASCII);

$test->cd(‘/pub/stats/arin/’);
$test->get(‘delegated-arin-latest’, ‘/tmp/delegated-arin-latest’, true, FTP_ASCII);

$test->cd(‘/pub/stats/ripencc/’);
$test->get(‘delegated-ripencc-latest’, ‘/tmp/delegated-ripencc-latest’, true, FTP_ASCII);

$test->cd(‘/pub/stats/afrinic/’);
$test->get(‘delegated-afrinic-latest’, ‘/tmp/delegated-afrinic-latest’, true, FTP_ASCII);
$test->disconnect();

?>

Os scripts aqui exibidos foram testados sob FreeBSD, exceto se for dito ao contrário.

Categorias:Whois Tags:, , ,
%d blogueiros gostam disto: